Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jacobzelko.com

Post reply on HN
Print view View original

61–70 of 125 posts

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

#61

Post by pjmlp »

__turbobrew__ wrote: post #5

Having a terminal-based workflow is a lifesaver in the era of work from home. When using a terminal based workflow I cannot tell the difference between working locally and working on a machine I have SSH'ed into located at my office (10ms round trip ping). Even when I VPN into work, ssh into a box at work, then ssh to a jumpbox in AWS, and then ssh from the jumpbox to an EC2 server the experience is still flawless.

I guess you never did telnet over modem connections.

My RDP connection over VPN works without issues.

When it fails, using ssh wouldn't be much better anyway.

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

#63

Post by mongol »

coldtea wrote: post #7
madhadron wrote: post #3

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 would probably agree, but what do you think a better terminal would be like, compared to the traditional ones?

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

#64

Post by madhadron »

chubot wrote: post #21
madhadron wrote: post #3

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 collected some experiments in that area here (and anyone should feel free to add more, including their own): https://github.com/oilshell/oil/wiki/Interactive-Shell Many of the articles have nice screenshots / animations to give you a feel for what it is. I plan to turn https://www.oilshell.org/ into a library and I hope people will build GUIs around it. There are some UI possibilities that are difficult or impossib…

So I recently started a job where I'm on Windows, and I've found myself surprisingly enamored of PowerShell. So many of the things that the shell got wrong are done right. The authors wanted to use , etc. as their real meanings, but apparently the early users rebelled at the idea that > was no longer redirect to file. But things that would be nightmares in unix shells, such as going in and adding a new element as the last child of only one of four elements in an XML document (based on its attribute value) are a few lines of code. I still have decades of muscle memory in bash, but I find myself reaching for PS more and more.

The problem is that you really need an interface for loading software components into your system at runtime, which .NET provides, but aside from .NET or COM I am unaware of any other equivalent system. Java's OSGi is the closest, and ugh...

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

#65

Post by ephimetheus »

thecedarprince wrote: post #50
tomcat27 wrote: post #47

Earlier quoted context omitted.

Did you consider writing in Sublime text?

I actually wrote my entire thesis in VSCode with LaTeX workshop! I have friends who swear by Sublime - I can see why! It's really powerful. Traditional GUI editors are great for when I was working on my thesis but I opted for a lighter solution as I do a lot on my laptop at once. The fewer CPU intensive programs for my workflow, the better.

I’m doing the same right now. It’s pretty good.

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

#66

Post by rusticpenn »

desmap wrote: post #44
snicker7 wrote: post #13

At risk of being /that guy/, I find that emacs gives me a nice & consistent "one-stop-shop" for text-based apps instead of having to kludge together a bunch disparate terminal programs. Also, +1 for Julia.

Just the combination of tmux and nvim with shared ctrl-hjkl between both nvim and tmux panes is so buttersmooth and no other setup has given me such an seamless interoperability between an editor and an OS. What this means: you can switch between tmux panes or nvim panes or from tmux to nvim and back always with the same shortcut. This is the most underrated killer feature.

I am not sure if you tried i3 window manager. It provides similar features but with more freedom.

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

#67

Post by rusticpenn »

ekianjo wrote: post #19
asciimov wrote: post #16

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.

Tiled windows managers have issues though. Last time I tried i3wm for example, there was no default support for sleep, energy saving and hardware keyboard shortcuts and you had to take care of all of that instead of the usual GNOME/KDE to do it for you. The best option is to install tiled windows managers plugins within GNOME or KDE on Linux.

I installed the i3 version of Manjaro and it came with everything out of the box.

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

#68

Post by nbwl »

bch wrote: post #29
__turbobrew__ wrote: post #5

Having a terminal-based workflow is a lifesaver in the era of work from home. When using a terminal based workflow I cannot tell the difference between working locally and working on a machine I have SSH'ed into located at my office (10ms round trip ping). Even when I VPN into work, ssh into a box at work, then ssh to a jumpbox in AWS, and then ssh from the jumpbox to an EC2 server the experience is still flawless.

I was thinking about this today - that is: a terminal (“minimal”) setup may well have prepared those of us who practice it - for remote work (great news if a pandemic strikes!) I wondered though, if there’s no way to objectively “score” the advantage of, say, terminal-minimalism vs. GUI-maximalism, what might some discussions of t-min vs GUI-max be? What, if anything, does t-min really cut us out of while we’re prepa…

Pros of t-min: - overall greater speed using a computer, you become what people call a "power user". - some sysadmin knowledge. Adopting a terminal based workflow requires to tinker with your system (systemd, sh scripts, building certain repo for a tool you want etc.).

Pros of GUI-max: - You don't have to spend hours learning and configuring things. - Certain tools are just better when they are built out in a GUI for you. I think here in particular of C/C++ debuggers, it's hard to get a nice experience in the terminal.

As for objectively "scoring" it's hard to assign real values. You could eventually measure speed. I have worked in production support solving a lot of benign problems on a day to day basis. This is when I adopted my terminal based workflow. It was way faster than my other teammates using desktop apps.

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

#69

Post by nbwl »

bigdict wrote: post #52
desmap wrote: post #44

Earlier quoted context omitted.

Just the combination of tmux and nvim with shared ctrl-hjkl between both nvim and tmux panes is so buttersmooth and no other setup has given me such an seamless interoperability between an editor and an OS. What this means: you can switch between tmux panes or nvim panes or from tmux to nvim and back always with the same shortcut. This is the most underrated killer feature.

Does NeoVim support that out if the box? For regular Vim I'm using https://github.com/christoomey/vim-tmux-navigator .

I don't think so. I had to use that package too in neovim.

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

#70

Post by chubot »

madhadron wrote: post #64
chubot wrote: post #21

Earlier quoted context omitted.

I collected some experiments in that area here (and anyone should feel free to add more, including their own): https://github.com/oilshell/oil/wiki/Interactive-Shell Many of the articles have nice screenshots / animations to give you a feel for what it is. I plan to turn https://www.oilshell.org/ into a library and I hope people will build GUIs around it. There are some UI possibilities that are difficult or impossib…

So I recently started a job where I'm on Windows, and I've found myself surprisingly enamored of PowerShell. So many of the things that the shell got wrong are done right. The authors wanted to use , etc. as their real meanings, but apparently the early users rebelled at the idea that > was no longer redirect to file. But things that would be nightmares in unix shells, such as going in and adding a new element as the…

I haven't used PowerShell much, but I skimmed a 500+ page book on it, and I've heard a lot of mixed feedback on it.

Some people love it and some people hate it. Some more responses here:

https://news.ycombinator.com/item?id=24873410

I guess what I'll say is that I hope the Oil ecosystem will grow the things that people like about it, that aren't tied to Windows. Windows and Unix are fundamentally different and it means they need fundamentally different shells, since a shell is by definition a language closely tied to the OS.

You can run powershell on Unix, and bash on Windows, but even on the same OS they are somewhat disjoint tools!

Post reply on HN