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

91–100 of 125 posts

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

#91

Post by hhas01 »

mongol wrote: post #63
coldtea wrote: 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?

Doesn’t have the beautiful Display Postscript/LeX-esque typography that I want, and less said about Lots of Irritating Silly Parentheses the better, but even 1980s tech was doing it better:

https://www.youtube.com/watch?v=o4-YnLpLgtk

I think there are lessons to be had from the likes of Smalltalk and Logo too. Highly expressive without insane levels of cryptic inconsistent punctuation rules and UX man-traps.

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

#93

Post by desmap »

dijit wrote: post #85
desmap wrote: post #82

Earlier quoted context omitted.

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.

Just checked out Sway's intro video, this looks promising! Would you mind to elaborate if Sway is ready for being a daily driver + how is multi-monitor support (all monitors same dpi and also with different dpi levels).

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

#94

Post by desmap »

kody wrote: post #12

Very nice! I've tried to switch over to a terminal-based workflow but Qt Creator, VS Code, and Firefox for Atlassian products have been the main holdouts for me. I can't see myself moving away from Qt Creator, but I would kill for an ncurses app for editing Confluence pages and reviewing pull requests without 1200ms between every. single. click. At the very least this article has given me the itch to dust off the old…

VS Code is very good at connecting to remote servers/wsls/etc being just a dumb client. I still use VS Code next to all my terminal apps because some stuff is unmatched in VS Code, eg Pythons Interactive Console paired with a Jupyter server (1000x better than any notebook).

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

#95

Post by lenkite »

SabbathHex wrote: post #25
kody wrote: post #12

Very nice! I've tried to switch over to a terminal-based workflow but Qt Creator, VS Code, and Firefox for Atlassian products have been the main holdouts for me. I can't see myself moving away from Qt Creator, but I would kill for an ncurses app for editing Confluence pages and reviewing pull requests without 1200ms between every. single. click. At the very least this article has given me the itch to dust off the old…

Re: Confluence. I was at the same point about a year ago and wrote a small python script that posts pages that I write locally in vim to Confluence: https://github.com/SabbathHex/confluence_poster The downside is that due to Atlassian limitation and phasing out of wiki markup it's not possible to retrieve articles from Confluence. This script is not suitable for collaborative editing of the same page. Script is quite…

This uses the confluence API and does not simulate the web-ui right ? Our admins disabled API access to confluence sadly.

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

#96

Post by briggers »

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.

Yes! I do this and love it. Works locally or via SSH with no difference at all.

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

#97

Post by RaycatRakittra »

desmap wrote: post #79
_huayra_ wrote: post #53

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…

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 opinion.

Just remember: Emacs' main strength comes from how malleable and extensible it can be. Give it time; don't jump ship after a few bumps. Patch it up with some Elisp and keep sailing.

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

#98

Post by tomtomtom777 »

yudlejoza wrote: post #41

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?

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

#99

Post by desmap »

RaycatRakittra wrote: post #97
desmap wrote: 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…

> 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?

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

#100

Post by RaycatRakittra »

desmap wrote: post #99
RaycatRakittra wrote: post #97

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?

That's really gonna come down to your workflow and use cases. For me, the Lisp is a bit more welcoming than VimScript for me. It's much easier to test out a small snippet of something in-buffer which might grow into something else.

But, putting Lisp aside, going through the growing pains was worth it for me because of org-mode. I'm certain Vim might have something similar but the proper `org` package is definitely on my list of benefits. I have an org-file that tracks my time and generates invoices with a click of a button. Another one documents all the API calls in another project with interactive areas, thanks to org-babel. I think being able to craft documents like this is invaluable but again, it's gonna come down to how you do work and what makes you happy/efficient.

Post reply on HN