Vim + markdown (evolved into standardized DSL for note-taking) + git.
What I’m here to say is that programmers’ tooling is a great fit for knowledge management. Fuzzy file finding / fuzzy grep is something you can get for free with plugins, and any interaction like going-to-previous-file-by-date can be easily achieved with editor scripting. Version control (Git in this case) allows per-line editing history & multi-machine granular merge and basically adds another dimension to text editing: time. All versions of the text exist in their own right and can be inspected and rolled back to. I use heavily optimized editor keys for 2-3 keypress commit-related operations, most of it came for free with plugins. The power of Vim for text editing is not to be underestimated as well.
Another thing perhaps worth mentioning is tiling window management + tmux. I have tmux / terminal sessions for different knowledge-management tasks (notetaking while reading an article is a different tmux session than daily agenda e.g.) bound to key combinations so that they can be accessed with low latency. The lowest-latency inbox is just a text field that appends to a file, for use when any distraction is to be avoided.
Basically my point here is, learning Unix is high value, because no premade tooling can be as well-designed as a hand rolled one, for under-explored domains.
Basically my point here is, learning Unix is high value, because no premade tooling can be as well-designed as a hand rolled one, for under-explored domains.
Entirely seconding the bit about hand-rolled tooling, with the caveat that there is a lot of hand-rolling you can do without learning Unix. (This is not to denigrate the value of Unix, but only to avert the possibility of someone reading this and thinking “oh, but learning Unix sounds hard and is not really for me, I guess hand-rolling my tools isn’t an option”—it very much is! There are many paths to DIY.)
Agree. Reason I used the term Unix is because of it’s famous philosophy of composable tools and plain text.
E.g. the frequency + recency filter that I use is a separate program, that can be in turn applied in different parts of the system (e.g. before feeding the input to fuzzy select tool like fzf, but not necessarily): https://github.com/ccheek21/fre
I love how you emphasized learning Unix tools. I use other things mentioned here except tmux. Would you be willing to share your tmux workflow in more detail with keybindings?
Here’s .tmux.conf, however it mostly covers the in-tmux things like split/tab management (e.g. I open & switch to new tabs with alt-1/2/… instead of default C-b 1/2/… This mirrors the browser behavior and is 1 less keypress):
Tmux allows neat tricks like sending a window between sessions or sending keypresses to a session. E.g. I have a script called “portal” that opens a new window in a target tmux session (that we’re opening a “portal” to) with the current directory, and brings that window to the foreground.
Another benefit of tmux is that all of my editor sessions are independent of Xorg and so can survive a restart of X or be reused from a different X session (e.g. when testing a WM).
Here’s sort of a teaser of which tmux / urxvt sessions I have bound in sxhkd (some are still bound from dwm config):
The launchers themselves (e.g. “ship”, “tower”, “girl”) are unfortunately not online at this point. What these files do is open (with few exceptions) a floating window with the named tmux session and bring it to front, or run the args in a new tmux window of the target session. These are the different-purpose knowledge-management sessions I was referring to.
Between those are 2 firefox sessions, which is another thing perhaps worth mentioning. I run 8 thunderbird sessions with RSS feeds and and ~20 firefox sessions. Two of those found in sxhkd config are floating, for quick anonymous / non-anonymous-programming-related lookups. I find separating the browser sessions very valuable for honing the suggestion streams that google / youtube / … throw at us.
Vim + markdown (evolved into standardized DSL for note-taking) + git.
What I’m here to say is that programmers’ tooling is a great fit for knowledge management. Fuzzy file finding / fuzzy grep is something you can get for free with plugins, and any interaction like going-to-previous-file-by-date can be easily achieved with editor scripting. Version control (Git in this case) allows per-line editing history & multi-machine granular merge and basically adds another dimension to text editing: time. All versions of the text exist in their own right and can be inspected and rolled back to. I use heavily optimized editor keys for 2-3 keypress commit-related operations, most of it came for free with plugins. The power of Vim for text editing is not to be underestimated as well.
Another thing perhaps worth mentioning is tiling window management + tmux. I have tmux / terminal sessions for different knowledge-management tasks (notetaking while reading an article is a different tmux session than daily agenda e.g.) bound to key combinations so that they can be accessed with low latency. The lowest-latency inbox is just a text field that appends to a file, for use when any distraction is to be avoided.
Basically my point here is, learning Unix is high value, because no premade tooling can be as well-designed as a hand rolled one, for under-explored domains.
Entirely seconding the bit about hand-rolled tooling, with the caveat that there is a lot of hand-rolling you can do without learning Unix. (This is not to denigrate the value of Unix, but only to avert the possibility of someone reading this and thinking “oh, but learning Unix sounds hard and is not really for me, I guess hand-rolling my tools isn’t an option”—it very much is! There are many paths to DIY.)
Agree. Reason I used the term Unix is because of it’s famous philosophy of composable tools and plain text.
E.g. the frequency + recency filter that I use is a separate program, that can be in turn applied in different parts of the system (e.g. before feeding the input to fuzzy select tool like fzf, but not necessarily): https://github.com/ccheek21/fre
I love how you emphasized learning Unix tools. I use other things mentioned here except tmux. Would you be willing to share your tmux workflow in more detail with keybindings?
Here’s .tmux.conf, however it mostly covers the in-tmux things like split/tab management (e.g. I open & switch to new tabs with alt-1/2/… instead of default C-b 1/2/… This mirrors the browser behavior and is 1 less keypress):
https://github.com/mwgkgk/dotfiles/blob/master/tmux/.tmux.conf
Tmux allows neat tricks like sending a window between sessions or sending keypresses to a session. E.g. I have a script called “portal” that opens a new window in a target tmux session (that we’re opening a “portal” to) with the current directory, and brings that window to the foreground.
Another benefit of tmux is that all of my editor sessions are independent of Xorg and so can survive a restart of X or be reused from a different X session (e.g. when testing a WM).
Here’s sort of a teaser of which tmux / urxvt sessions I have bound in sxhkd (some are still bound from dwm config):
https://github.com/mwgkgk/dotfiles/blob/master/sxhkd/sxhkdrc
The launchers themselves (e.g. “ship”, “tower”, “girl”) are unfortunately not online at this point. What these files do is open (with few exceptions) a floating window with the named tmux session and bring it to front, or run the args in a new tmux window of the target session. These are the different-purpose knowledge-management sessions I was referring to.
Between those are 2 firefox sessions, which is another thing perhaps worth mentioning. I run 8 thunderbird sessions with RSS feeds and and ~20 firefox sessions. Two of those found in sxhkd config are floating, for quick anonymous / non-anonymous-programming-related lookups. I find separating the browser sessions very valuable for honing the suggestion streams that google / youtube / … throw at us.