Live data from Hacker News

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

jacobzelko.com

81–90 of 125 posts

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

#81
post #73
post #72

I use Alacritty,zsh,oh-my-zsh and fzf like you, but I have never used tmux and lsd, do they have any highlight?

Tmux is great for persistence. It’s also basically required for working remotely. Allows you to, across sessions, to reconnect to the same flow. I have it set up to have multiple views of the same set of windows, so I can scroll through them independently. I’d say it is one of the best utilities I use.

Mosh supports roaming. Or are you referring to something else about reconnecting?

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

#82
post #77

Earlier quoted context omitted.

Nice to hear and need to try it again. I stopped using it 2017. Another gripe I had with i3 was that setting up proper hidpi support was a mess, maybe this improved as well. I know that the latest Ubuntu got here quite well, allowing also 25% steps etc.

Hidpi is still a total crapshoot on linux (depending on distro and window manager). My current setup uses xrandr to scale my 4k to 1440p. It's not perfect, but it's better than other options.

Yeah hidpi on Linux is pretty underwhelming and it seems that nobody really cares. I think Windows needed years to match macOS and is now on the same level. Still Windows notebooks barely have more then 200dpi unless there are from the premium segment. Whatever, at least the software side is great now. But on Linux, Ubuntu just had until last year hidpi only in 100% steps paired with dozens of glitches here and there. Sad since especially a terminal looks just terrific in 300dpi (UHD on 13" or 8k on 32").

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

#83

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.

To "kludge together a bunch of disparate terminal programs" is not conceptually different than "kludge together a bunch of disparate elisp functions". Some of us live inside the command line, some of us live inside emacs, most of us live inside a web browser.

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

#85
post #82

Earlier quoted context omitted.

Hidpi is still a total crapshoot on linux (depending on distro and window manager). My current setup uses xrandr to scale my 4k to 1440p. It's not perfect, but it's better than other options.

Yeah hidpi on Linux is pretty underwhelming and it seems that nobody really cares. I think Windows needed years to match macOS and is now on the same level. Still Windows notebooks barely have more then 200dpi unless there are from the premium segment. Whatever, at least the software side is great now. But on Linux, Ubuntu just had until last year hidpi only in 100% steps paired with dozens of glitches here and there…

I think you're probably right, but my experience (Sway on Arch) has been nothing other than pretty excellent.

It supports fractional scaling and different scales for different attached screens.. You have to tell the system you want it (`swaymsg 'output scale 1.5'`) but it works.

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

#86

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.

To "kludge together a bunch of disparate terminal programs" is not conceptually different than "kludge together a bunch of disparate elisp functions". Some of us live inside the command line, some of us live inside emacs, most of us live inside a web browser.

Yes, I also found "kludge together a bunch of..." a bit misleading since this atomic nature of *nix is why we use it.

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

#87
post #68
post #29

Earlier quoted context omitted.

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 don't have to spend hours learning and configuring things

I got 70% of my sysadmin skills because of hanging out 24/7 in the shell and configuring things.

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

#88
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.

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

The disadvantage of that is that i3 is not aware of a window's contents. A terminal multiplexer however knows what the current working directory in each terminal pane is, and if you open a new split it can be automatically set to the same path. This makes the whole process a little bit smoother.

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

#89
I love text, and I love IPC.

I hate what 1970s terminal culture does to both.

Why can’t we have modern text-driven interfaces* that are both parsimonious and elegant? The mighty Knuth gave us TeX 40 years ago, and our hardware has long since passed the point where doing the job right demands a significant number of cycles (even with the clattery mess that is Unicode standard), so there really isn’t any excuse for such awful regressive primitivism now.

Because I don’t care that OP’s workflow works well for OP; I care about workflows that work better. For everyone.

/cynical idealist

--

* Traditionally “text-driven interface” means keyboard-driven, but if you aren’t paying attention to the rise of spoken words then you’re missing the next great opportunity to open up computing to all 8Bn of your fellow humans.

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

#90
post #76

Earlier quoted context omitted.

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

I posted in another comment more about my view on i3. However, compared to tmux it also lacks the capability to be used via ssh. At the end of the day there are not really comparable but yeah, I prefer to work with tmux+nvim on a *nix environment through ssh, all wrapped in a typical window manager such as Windows which handles stuff like hidpi, meta window management, device management etc. The good thing is that I…

That is why I prefer the static tiling approach compared to the common dynamic tiling window managers. The important difference is that a static window manager never reorders or resizes windows unless you tell it to, and this leads to the same flexibility but without being forced into a predetermined layout.

I like it a lot but it's rare, the only one I've used is stumpwm.

Post reply on HN