Second editor

Core files

By “core files”, I mean fundamental files that configures your environment. They are always open in my second editor just in case I need them. Examples are:

“Core files” are the fundamental files configuring your environment:

the C:/Windows/System32/drivers/etc/hosts
the .profile file
the .npmrc file
the terminal configuration file (wezterm.lua for me)
fundamental scripts for the current project, if any

The main issue with core files is that you set them up once and then forget about them, as they rarely need to be modified. You especially forget their location. Better keep them open in this second editor.

What's more, the need for a new shortcut or for an improvement never arises during free time. It's always in the middle of a task. To improve your setup thus entails that you first leave the task pending. And then if you have to waste time to find the appropriate core file, you may give up, even for little improvements.

I already gave up a couple of times, only to be pushed again later on. As a result, I developed the habit of always having my core files opened. And it has been for the better.

Keeping them open in the second editor is important because:

we easily forget where they even are located (as we rarely have to modify them).
we always discover an improvement for them right in the middle of a task that we have to then put on hold.

If we have to first find the proper core file for even the little things, we may give up on many improvements.

Taking notes

For every big task I have at work (usually materialized by a ticket in JIRA), I create a folder named with the id and a quick description. With such a folder, you never lose any information or you never have a hard time finding them: it is the natural place for everything related to the task. In no particular order:

Have dedicated folders for your tasks so as to always have a natural place to store and search information about the task, like:

notes
todo-lists
code snippets
logs
data
screenshots

My main editor is all about coding so it deals with none of the above. That's for the second editor. And it better be lightweight and fast. That's why I'm using Notepad++. It does not matter if it lacks a few features out-of-the-box for code.

A "notes" file contains all the salient links and data and findings and code snippets, you name it. Some code snippets are so long that they get their own file. In any case, they are the reason why your second editor must have syntax highlighting.

Logs and data often have their own files too. And I need to process them some more: either by formatting the data or by extracting some data. Which is why the second editor must provide editing helps and have a replace feature with regexp.

Lastly, it can be hard to group some data and name the containing file, as the data is in many pieces of different natures: some code snippets here, a link or two there, some lines of logs, etc. If the data is temporary or specific, I isolate it in an unsaved tab. That's why the second editor must preserve unsaved documents.

I don't like unsaved tabs, as it means I have pending work which is not even saved properly. So I develop a strong sense of urgency. But sometimes an unsaved tab is long-lived. I then know I got things wrong and that I have to save it explicitly. Recently though, I noticed I use very few unsaved tabs. Instead, I create lots of small files named notes-<subject>.txt.

The role of the second editor is to help you with these files. And so it needs:

to be lightweight and fast
to have syntax highlighting (for code snippets)
to have editing helps and a replace feature with regexp (for logs and data)
to preserve unsaved documents (for temporary or specific data that you do not wish to save ; but I now tend to create lots of small files named notes-<subject>.txt)

Notepad++ is a really good second editor.

Todo-list

I find plain-text to be alright for todo-lists. It is flexible, fast and easy to save. With cheap but sensible formatting, I have a clear overview of the whole plan. Maybe some dedicated softwares are better but I have yet to hear a good reason why.

Plain-text is also great when you have no clear plan. It is easy to brainstorm and then organize your ideas. It is also easy to split tasks or add more fine-grained ones as you complete your notes with some pseudo-code or links.

Managing tasks is simple:

Plain-text is fine for todo-lists: flexible, fast and easy to save. Even without a clear plan, it is easy to organize your ideas after a brainstorm session. To manage tasks:

one task per line
indent to set some sub-task
use the hyphen to materialize clearly these lists
delete a line when the task is done
⇒ seeing the todo-list shrinking really feels like you are moving on!
maybe a last section to gather the finished tasks (but I can see that with Git)

Finally, I must say it is a pleasure to delete lines. The act itself is rewarding as it means “task done” but the visual effect of the todo-list shrinking accompanies it very well and boosts me up. It's the little things, really.

Here's an example:

Example:

- task 1

- task 2
   - subtask 2.1
   - subtask 2.2
   notes
   more notes
   https://interesting-link.com

- task 3



Another section
---------------

Full of notes and links.
https://another-interesting-link.com
https://yet-another-interesting-link.com


-----------------------

- task done 1
- task done 2

Shortcuts

open new tab	Ctrl + N
close tab⁽¹⁾	double-click on the tab
open file	Ctrl + O
delete a line⁽²⁾	Ctrl + D
toggle comment	Ctrl + Q
trigger box selection	Alt + Shift
open containing folder	right-click on tab ⇒ Open into
closing to the right	right-click on tab ⇒ Close multiple tabs

(1): not the default behavior in Notepad++.

(2): key bindings differ among editors.

Data cleanup

When I process data, especially logs or query results, I always use the following actions to clean up the data:

in Edit > Blank operations:
- trim trailing spaces
- trim leading spaces
in Edit > Line operations:
- remove empty/blank lines
- sort lines
- remove duplicate lines

Basic regular expression syntax

Pattern	Effect	Example	Result
a character	match the character	`b`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
a character	match the character	`=`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
several characters	match several characters	`ba`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `*`	the character can be absent or present one or more time	`fo*`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `+`	the character cannot be absent it must be present one or more time	`fo+`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `{<number>}`	the character must be present the exact number of time	`fo{1}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`fo{2}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`fo{3}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `{<min>,<max>}`	the character must be present at least min times and at most max times	`fo{1,2}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`fo{1,3}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`fo{3,10}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `{<min>,}`	the character must be present at least min times	`fo{1,}`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `.`	match any character	`f.`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
modifier `.`	match any character	`.a`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `\d`	match any digit	`\d\d`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `^`	match start of line	`^foo=`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `$`	match end of line	`\d$`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `[]`	match any character in brackets	`^[bf]`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`a[rz]=`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`f[oa]*`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `[^]`	match none of the characters in brackets	`[^or]=`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `[^]`	match none of the characters in brackets	`=[^\d]`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
range `[-]`	match characters between …	`[a-z]+` lowercase characters	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`[A-Z]+` uppercase characters	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
		`[0-9]+` digits	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `\s`	match any whitespace (regular space, tab, newline)	`\s`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
special `\<character>`	denote the character escape any special behavior	`\*`	match one star

Greedy search

By default, regular expressions match in a “greedy” manner, that is the modifiers * and + match as many characters as possible. To invert this behavior, you can use the modifiers *? and +?: this is “lazy” matching.

It is possible to get the lazy behavior by using the special syntax [^] to explicitly exclude the character coming after * or +.

Type	Example	Result
greedy	`.*=\d`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
lazy	`.*?=\d`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`
lazy	`[^=]*=\d`	`foo=1 bar="blabla" baz=2 & foo=10 faz="text" foo=100`

Data extraction with capturing groups

To extract data, use the replace feature with regexp. To capture a part of a pattern, use parentheses. And in the replacement pattern, use \1 to refer to the first group of parentheses, \2 to refer to the second, etc.

Here is a very classic task: extracting all the keys, where the format is key=value. Let's use this data for instance:

foo=1
bar="blabla"
baz=2 & foo=10
faz="text"
foo=100

I usually proceed like this:

clean up the data
⇒ remove leading & trailing spaces, and also remove empty lines
ensure all lines only follow the format key=value, i.e. we have to handle line with multiple fields.
⇒ replace <space>&<space> by a newline (no need for regexp, just enter the space themselves: & )
⇒ if the & character can be surrounded by zero or more spaces, use the following regexp: \s*&\s*
use a capturing group to keep only the keys: ^(.*)=.* and then replace with first group: \1
sort the keys and remove duplicates

The process is a bit involved: one may think that there could be some more magic in regexp to use instead. Well, maybe. I never searched much as regexps get unreadable quickly. There are three main reasons for that:

the regexp is long
it has many modifiers and special characters
it covers too many cases

Beware, regexps get unreadable quickly as:

they get long
they hold many modifiers and special characters
they cover too many cases

This last point is important: regexps are bad when the format you want to parse contains alternate ways of expressing things and some edge cases. Clean up and uniformize the data goes a long way to simplify subsequent regexps. It also provides a reusable starting point for any other search or data extraction you may need in the future.

You may want to keep a copy of the raw data because a simple clean up is not always enough. You may need to apply several extractions, which are destructive in essence, before reaching the final extraction. Never hesitate to make copies of the raw data or of the intermediate data.

As a rule, always clean up and uniformize the data first. And never hesitate to make copies of the data.