Live data from Hacker News

GNU nano is my editor of choice (2021)

ariadne.space

271–280 of 303 posts

Re: GNU nano is my editor of choice (2021)

#271
post #128

Earlier quoted context omitted.

The so-called "Unix spirit" is itself a rather hilarious mistake from the early days of software engineering, when programmers knew essentially nothing about human/computer interaction and foolishly believed that "efficiency" in a mathematical sense translates to efficient workflows. It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of func…

Integration does not presuppose hard coupling. Different components can integrate and coordinate through standards. I would argue that having one big app is the one of the worst methods of integration.

> Different components can integrate and coordinate through standards.

We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks.

There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands.

Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end.

[1] https://www.nushell.sh/

Re: GNU nano is my editor of choice (2021)

#272
post #270
post #128

Earlier quoted context omitted.

The so-called "Unix spirit" is itself a rather hilarious mistake from the early days of software engineering, when programmers knew essentially nothing about human/computer interaction and foolishly believed that "efficiency" in a mathematical sense translates to efficient workflows. It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of func…

> It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation. Yes, so much integration that despite JetBrains IDE functionality being first-class, we have still seen the rise of LSP over the last few years. That's more like the Unix philosophy, not less. And that's not even to mention that s…

LSP took off because it was designed and heavily promoted by one of the most powerful technology corporations on the planet, who already had the ears of tens of millions of developers.

The number of proposed "standards" for solving similar problems over the years that have failed or even been completely ignored is legion. LSP is one of only a handful of software integration standards that have ever found widespread adoption. Meanwhile, there are hundreds if not thousands of integration problems where no standard is in sight.

This universal vision where micro-programs process and pass around standardized data is never going to happen, except on platforms that are completely controlled by a single vendor (see Apple).

Re: GNU nano is my editor of choice (2021)

#273
post #231

Earlier quoted context omitted.

Which vim? I prefer neovim personally, but it is not my default editor. I want JetBrains to get off their butts and implement first-party support for Neovim. They would be able to fully ditch their awful vim emulator, and I'm honestly astounded they still have not done a neovim first party plugin yet, or anyone for that matter (last I looked anyway). It would solidify vim for me permanently, being able to pop it into…

I've tried to like neovim but plain vi works best for me. I've tried to like nano too. Since you brought up JetBrains, I use no products made by them, at all, any more. I use Eclipse and I don't use a vi plugin in Eclipse. My habit is if in bash, use vi, if in an IDE (or otherwise at my Ubuntu or Windows (work...I know) desktop), use a regular type of editor. If I were young and never worked on old Korn shell systems…

> Since you brought up JetBrains, I use no products made by them, at all, any more.

Just curious. Why?

Re: GNU nano is my editor of choice (2021)

#274
post #92

Earlier quoted context omitted.

When people don't know what ^X means - it's Linux, most tools are very specific of flags and the order in which you put them on the command line. So is nano saying - SHIFT-[6](^)-SHIFT-X - SHIFT-[6](^)-x - CTRL-[6](^)-SHIFT-X - CTRL-[6](^)-x All I see is '^X', on my keyboard '^' is on 6. Why the hell isn't this working? Little does little Sally know that this is a UNIXism, carat means 'CTRL', X is really just 'x' - b…

Is there a particular reason why you seem to imply that little knowledge == female? Sometimes the meme of "we need to mention girls more" works in unexpected directions if people are not careful.

I think you're overly sensitive about things that aren't there

Re: GNU nano is my editor of choice (2021)

#275
post #236
post #65

Earlier quoted context omitted.

Vi is fortunately present on just about every unix-like system and in busybox. Typing "v" in the pager and getting thrown into nano always prompts me to installing vim and changing the default editor. When I got into Linux there was no nano, only vi and ed. Pico came later with the Pine e-mail client.

> " Pico came later with the Pine e-mail client " Nope. GNU Nano, like a lot of the early GNU utilities, emulates Pico. I was using Pico/Pine around 1994/95 on UNIX workstations, and Pico was the default editor.

Pico came later than vi/ed. I know nano is a pico clone which first appeared in '99 or so.

Re: GNU nano is my editor of choice (2021)

#276
post #131
post #92

Earlier quoted context omitted.

Is there a particular reason why you seem to imply that little knowledge == female? Sometimes the meme of "we need to mention girls more" works in unexpected directions if people are not careful.

Sally is a quranic boy and girl name. Is there any particular reason why you seem to imply that the the comment above mentioned a female? There’s no indication of gender.

Because Harry.

Re: GNU nano is my editor of choice (2021)

#277
post #233

Earlier quoted context omitted.

I think that's why I've never shifted from vi to nano, it appears to be a regular editor but ignores all common key bindings, ctrls+s doesn't save, ctrl+f doesn't find, ctrl+h doesn't replace, etc.

I just fired up Nano on Ubuntu 18 installation. When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt. Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the…

You're right ctrl+s works, I tried it, I always thought it had to be ctrl+o since that's what the bottom panel shows. I was encouraged so I highlighted some text then tried ctlr+c and ctrl+v, unless I hit a wrong key somewhere, it didn't work.

Re: GNU nano is my editor of choice (2021)

#278

> modal editing doesn’t really fit my mental model of how an editor should work The whole point of vim is that you change your mental model to become faster at editing text. People don't come into programming with a blank slate about editors, they were introduced to wysiwyg editors from an early age because of Microsoft Word, web based text input, and now phones (with emojis too). A mental model had been impressed al…

> The whole point of vim is that you change your mental model to become faster at editing text. The whole point of vi and vim was to edit text visually, instead of as lines. Bill Joy reflecting on vi in 1984:[1] "REVIEW: What would you do differently? JOY: I wish we hadn't used all the keys on the keyboard. I think one of the interesting things is that vi is really a mode-based editor. I think as mode-based editors g…

>> The whole point of vim is that you change your mental model to become faster at editing text.

> The whole point of vi and vim was to edit text visually, instead of as lines.

My language was very imprecise here, I should know better when commenting on Hacker News. I didn't mean the original motivation for creating vi, but the main reason why someone in 2022 would learn vim with all the other text editors out there now. The main feature of vim at this point is the modal editing that requires you to change how you think about text editing. If you aren't going to accept this new paradigm, then there's no point learning vim in the first place beyond how to enter and exit insert mode, save, and quit.

Re: GNU nano is my editor of choice (2021)

#279
It seems Ariadne hasn't yet come across a code maintenance situation that she couldn't overcome by expenditure of keystrokes into a typewriter-like program.

There is an illusion that it is all you need because using such a thing you can certainly crank out volumes of brand new content. If you have a clear idea of what you're writing, maybe just backspacing over the odd typo is all you need to forge ahead. And you can easily make small fixes to existing content with Nano, Notepad and whatnot. The more you have to think to make those fixes and the smaller is the actual textual change, the less of an impediment is it to use a "nonprogrammer's editor". If it took you 180 minutes to figure out it, shortening the editing from 30 seconds to 5 seconds succumbs to Amdah'ls Law; the speedup is virtually nil.

There can be a range of editing needs in between these use cases, in the context of development.

From Ariadne's experience I don't have the sense that she's worked in a software organization in a team, working on big changes to a big, existing code base and such and under pressure. Moreover, even in such an environment, there are those who survive somehow with goofy non-programmers' editors. You know the types; they announce themselves with their tattle-tale trail of wrong formatting (e.g. tabs where there should be spaces, incorrect indentation, ^M carriage returns in Unix-formatted files ...) spurious blank lines, or else trailing newline at the end of the file, trailing whitespace in lines and such. The times when raw editing is really the bottleneck are rare; and in all the other times, Amdahl's is ever present. Someone who has somehow figured out what needs to be changed where (with no help from any code navigation features in their glorified typewriter) can just crank it out. If what should take 5 minutes takes 45, it's not a big deal in the big picture. The assiduous Turtle armed with Notepad will beat the Hare who aptly uses a programmer's editor, but is unable to settle down to work.

I can see how a developer could convince themselves that all they need is a glorified typewriter program for coding, and easily brush aside any evidence to the contrary. What you Get Done with that typewriter is your direct, personal experience, whereas how other people work is just anecdotes, not hard data.

Re: GNU nano is my editor of choice (2021)

#280
post #277

Earlier quoted context omitted.

I just fired up Nano on Ubuntu 18 installation. When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt. Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the…

You're right ctrl+s works, I tried it, I always thought it had to be ctrl+o since that's what the bottom panel shows. I was encouraged so I highlighted some text then tried ctlr+c and ctrl+v, unless I hit a wrong key somewhere, it didn't work.

Ctrl-C and Ctrl-V are not common keybindings, unless we are talking about the Microsoft Windows environment, and graphical environments aped after it.

In the GNU/Linux environment, the standard keybindings are the Emacs-derived ones. Ctrl-A to go to the start of the line, Ctrl-E to jump to the end, ... pasting is called "yank" and mapped to Ctrl-Y.

Your point stands since GNU Nano doesn't stick to these either.

Ctrl-C is interrupt in the TTY environment. This is so entrenched that programs which obtain Ctrl-C as ordinary input rather than a SIGINT signal still use it for interruption. E.g. in Vim, we can use Ctrl-C to interrupt long operations.

Ctrl-V is entrenched as a "verbatim" key: insert the following character literally, even if it is a control character.

Post reply on HN