Live data from Hacker News

A terminal-based workflow for research, writing, and programming

jacobzelko.com

111–120 of 125 posts

Re: A terminal-based workflow for research, writing, and programming

#111

Earlier quoted context omitted.

Starting with Tmux was quite eye-opening to me for exactly this reason. The power of composable tools is hard to exaggerate.

Can you give some examples of what you're able to do or what exactly you mean by composing in this context? I've used tmux a bit but just to split windows and restore sessions...

Vim + Tmux + SSH is probably the most common/generic example. This stack allows me to, for example, work from my iPad Pro.

Re: A terminal-based workflow for research, writing, and programming

#112
post #99

Earlier quoted context omitted.

I would give it another shot. I was a Vim zealot that converted over with Spacemacs, but I ditched Spacemacs once I knew the names of the packages I used the most. The package `evil` is enough to satisfy your modal editing needs (perhaps you already knew about it). Anything that doesn't fit your workflow can be changed to fit into that same modal editing paradigm. It just takes time but it's worth it in my humble opi…

> It just takes time but it's worth it in my humble opinion. But why? Because I have a better scripting language? Are there more benefits beyond having lisp?

I can't reply to your deepest comment in this thread, but I'm following up on that:

* Try spacemacs. Though I'm a Doom user, spacemacs is much more approachable out of the box. You can just uncomment things and have it work well. * Use Emacs 27.1 or later because it has faster JSON parsing -> crucial for good LSP performance

A few ways to get started are learning how to search for things within Emacs:

* C-h f: find documentation for any function by name * C-k k: find the documentation for any keystroke function * If you want to see what commands are going on: install command-log-mode. it will give you a buffer to see what commands you run with every keystroke * I don't remember if spacemacs has it or not, but the following two packages are crucial when you want to learn more: which-key (to show the keys available when you press something like C-x) and helpful mode [0]. I'm pretty sure spacemacs has these by default, but if not they're golden!

Re: A terminal-based workflow for research, writing, and programming

#113
post #54

Hey everyone! I am the author of the article! If you have any questions, feel free to ping me and I will try to respond in a timely fashion! I intend to always keep this article up to date so feel free to bookmark it for a future reference. Further, it makes my heart so so happy to see so many people being either inspired, interested, or curious about my workflow! I think the best workflow is the one that works for y…

Check out hunter instead of ranger, and sk instead of fzf

Thanks for the recommendations! Will give them a look.

Re: A terminal-based workflow for research, writing, and programming

#114
post #7

There's a lot of really good stuff in here about quick access to things. I feel sad that we're all still doing this stuff in teletype emulators, though. Why can't we have this and nice GUIs, too?

I, on the other hand, feel sad that we don't have better terminals, but still rely on ancient teletype protocols, escape codes, and arcana. I'd very much like an advanced, still cli/terminal, interface option.

I yearn for a truly modern, speedy and advanced terminal that grows beyond the mold and mindset of a text-only line-by-line Unix terminal.

Terminals of 2020 and beyond need to have first-class support for audio, video, images, and peripheral interactivity/customization. Terminology and iTerm 2's ability to display pictures, and some terminals' support for Sixel is one of the directions I want to see progress in.

- It should be possible to `cat` an image, or a video, or even previews of Word and Photoshop documents. Terminology, iTerm 2 and Sixel-compatible terminals have this to some extent, but it's not standardised and doesn't have a broad support base.

- Programs should be able to raise notifications without relying on third-party/OS-provided utils that have a drastically different API and availability across platforms.

- Rich read-only visualisations of progress should be possible to call up with a few lines of code. I want to see a `dd`, `mv` or `cp` with a graphical progress bar at the bottom of my window. If my OS supports it, I want this to integrate with the UI like the progress widget on my taskbar.

- We should be able to render a piece of output in 3D, if we so desire. I don't want Crysis, but I do want a Matlab logo that I can rotate by dragging my mouse and graphs that zoom when I Ctrl+scroll at them.

- Support for file pickers and rich selection/filtering of file/directory lists. Not for sandboxing, but for convenience.

- A command line builder (like one of the classic Apple OSes had, cannot find a reference now, or something like the one in Fish but more advanced). Only valid combinations of parameters will be supported, mutually exclusive commands are impossible to select. Any arguments that are files will be possible to use with a file picker. Any argument that's a date will get a calendar widget. Any argument that's a boolean or an enum will get a checkbox or drop-down respectively.

- Terminals should be able to intake gigabytes of input per second, up to the limit of the hardware, without choking up.

- We should be seeing 60FPS and beyond as a normal feature.

- We should finally get unlimited scrollback enabled by default. The terminal emulator should keep everything that I've seen before, and remember it for me. We have the space for it, either in RAM or persistent storage. If not, it should be adaptable and drop the scrollback buffer that is lower priority than other applications on the system if they need more resources.

- Unicode should come as standard. Emoji should come as standard.

- End termcap. We should be able to hash out ONE standard to rule them all. We've had 50 years to come up with ideas and opinions. Version it so that we can release a V2 in 2100.

- While we are at it, end Bash and come up with a saner shell notation that doesn't overload single/double quotes, the ampersand, > amd 101 keys. We have two Alts, two Ctrls, and a whole function key row. Let's make use of them for non-printable character input and interaction with the terminal.

- (Debatable) consider adding hypertext support. It's here to stay, and not just in the form of HTML.

There's more that can be added, but really, I think terminals deserve better.

Re: A terminal-based workflow for research, writing, and programming

#115

Title, especially with the inclusion of 'research,' is overly broad, and gimmicky. A (quantitative) researcher, involved in serious plotting, illustrations, and diagrammatic analysis, wouldn't last half-a-day in this workflow.

You seem to be using a rather specific meaning of the word "research". If, for example, I pause coding and spent a few hours comparing and reading about various libraries to aid in a certain task, wouldn't this task be best described as "research" as well?

And you would call that "research" terminal-based?

Re: A terminal-based workflow for research, writing, and programming

#116
post #63
post #7

Earlier quoted context omitted.

I, on the other hand, feel sad that we don't have better terminals, but still rely on ancient teletype protocols, escape codes, and arcana. I'd very much like an advanced, still cli/terminal, interface option.

I would probably agree, but what do you think a better terminal would be like, compared to the traditional ones?

My attempt at answering that question: https://news.ycombinator.com/item?id=25305383

Re: A terminal-based workflow for research, writing, and programming

#117
I yearn for a truly modern, speedy and advanced terminal that grows beyond the mold and mindset of a text-only line-by-line Unix terminal.

Terminals of 2020 and beyond need to have first-class support for audio, video, images, and peripheral interactivity/customization. Terminology and iTerm 2's ability to display pictures, and some terminals' support for Sixel is one of the directions I want to see progress in.

- It should be possible to `cat` an image, or a video, or even previews of Word and Photoshop documents. Terminology, iTerm 2 and Sixel-compatible terminals have this to some extent, but it's not standardised and doesn't have a broad support base.

- Programs should be able to raise notifications without relying on third-party/OS-provided utils that have a drastically different API and availability across platforms.

- Rich read-only visualisations of progress should be possible to call up with a few lines of code. I want to see a `dd`, `mv` or `cp` with a graphical progress bar at the bottom of my window. If my OS supports it, I want this to integrate with the UI like the progress widget on my taskbar.

- We should be able to render a piece of output in 3D, if we so desire. I don't want Crysis, but I do want a Matlab logo that I can rotate by dragging my mouse and graphs that zoom when I Ctrl+scroll at them.

- Support for file pickers and rich selection/filtering of file/directory lists. Not for sandboxing, but for convenience.

- A command line builder (like one of the classic Apple OSes had, cannot find a reference now, or something like the one in Fish but more advanced). Only valid combinations of parameters will be supported, mutually exclusive commands are impossible to select. Any arguments that are files will be possible to use with a file picker. Any argument that's a date will get a calendar widget. Any argument that's a boolean or an enum will get a checkbox or drop-down respectively.

- Terminals should be able to intake gigabytes of input per second, up to the limit of the hardware, without choking up.

- We should be seeing 60FPS and beyond as a normal feature.

- We should finally get unlimited scrollback enabled by default. The terminal emulator should keep everything that I've seen before, and remember it for me. We have the space for it, either in RAM or persistent storage. If not, it should be adaptable and drop the scrollback buffer that is lower priority than other applications on the system if they need more resources.

- Unicode should come as standard. Emoji should come as standard.

- End termcap. We should be able to hash out ONE standard to rule them all. We've had 50 years to come up with ideas and opinions. Version it so that we can release a V2 in 2100.

- While we are at it, end Bash and come up with a saner shell notation that doesn't overload single/double quotes, the ampersand, > amd 101 keys. We have two Alts, two Ctrls, and a whole function key row. Let's make use of them for non-printable character input and interaction with the terminal.

- (Debatable) consider adding hypertext support. It's here to stay, and not just in the form of HTML.

There's more that can be added, but really, I think terminals deserve better.

Re: A terminal-based workflow for research, writing, and programming

#118
post #79

Earlier quoted context omitted.

Tried so many times to get into emacs (3 or 4 times) and once into org mode. It unfortunately never made click despite my love for any kind of terminal app and also competition in this space. Just emacs lisp would be the reason to switch from vimscript but again I just couldn't get warm with emacs. Also I think that the paradigm of modal editing is key to editing, not because I am used it, it just makes sense to have…

I would give it another shot. I was a Vim zealot that converted over with Spacemacs, but I ditched Spacemacs once I knew the names of the packages I used the most. The package `evil` is enough to satisfy your modal editing needs (perhaps you already knew about it). Anything that doesn't fit your workflow can be changed to fit into that same modal editing paradigm. It just takes time but it's worth it in my humble opi…

Emacs is malleable, but it shows that it comes from a pre-CUA era. IMO, they should just drop the existing UI preset into a "legacy UX" package that old-timers can keep, and come up with a new preset that will be familiar to users of post-Win95 machines.

IntelliJ does this right. You are dropped into a brand-new, complicated editor, but the basics like the arrow keys, Ctrl+C/Ctrl+V, ctrl+arrow key movements, menus and lots of other bits are already familiar to you. You may remap the editor in any way you want, but you are likely to override a few presets and get on with your day, than rewire the entire thing.

Re: A terminal-based workflow for research, writing, and programming

#119

A good alternative to strictly terminal-based workflows are tiled window managers. The big gain is that you don't have to give up all those gui apps as they blend in next to the terminal apps quite well.

For those who enjoy experimenting with window managers, might I suggest PaperWM for your next experiment?

Instead of fitting all your windows within your monitor's boundaries, PaperWM sets all windows to take full height and gives you an infinite horizontal axis to arrange them on. I'm thoroughly enjoying it and vastly prefer it to tiling and floating windows

https://github.com/paperwm/PaperWM

Re: A terminal-based workflow for research, writing, and programming

#120
post #79

Earlier quoted context omitted.

I think author (and other folks who have this vim+tmux+other tools type of workflow) would really like Emacs, especially Org mode. I have a very similar set of tools for a pure-Emacs workflow to this: - org-roam - org-noter - persp mode with persistent sessions - vterm + eshell - various plugins for org bibtex / latex All of this in Doom Emacs gives me the same functionality. I do admit that it took a large amount of…

Tried so many times to get into emacs (3 or 4 times) and once into org mode. It unfortunately never made click despite my love for any kind of terminal app and also competition in this space. Just emacs lisp would be the reason to switch from vimscript but again I just couldn't get warm with emacs. Also I think that the paradigm of modal editing is key to editing, not because I am used it, it just makes sense to have…

Use lua https://github.com/neovim/neovim/issues/7895#issuecomment-73...
Post reply on HN