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

GNU nano is my editor of choice (2021)

ariadne.space

Post reply on HN
Print view View original

281–290 of 303 posts

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

#281

Post by [deleted] »

dolni wrote: post #269
kazinator wrote: post #264

Earlier quoted context omitted.

There are only two kinds of non-modal editors. 1. A useless, primitive thing in which every single keystroke inserts a character or performs an edit action, and then returns to the initial state. Typically found in the simplest edit controls offered by a windowing UI, or very simple command line editors. 2. A command-oriented editor in which every action is performed by typing a line of input, terminated by Enter to…

Suggesting that nano and vim are both "modal editors" because nano has some confirmation dialogs is not a deep insight, it's just pedantry. And it ignores the entire reason why you'd describe an editor as modal: that changing modes is integral to the editing experience. You can't change modes in nano to make editing more efficient.

[deleted]

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

#283

Post by tobbob »

yakshaving_jgt wrote: post #76
tobbob wrote: post #31

I've never seen the point in spending time and effort learning and memorising a bunch of vim commands. If I need to do more than simple edits to a file, I'll have a graphical desktop installed and use vscode. I tend to use nano if using a CLI as it's more intuitive.

I've never seen the point in spending time and effort learning and memorising a bunch of contextual menus that I need to point and click through. If I need to do more than simple edits to a file, I'll do the same thing as I would when making simple edits to a file or composing an email, I'll crack open vim and get to work.

You don't need to spend any time or effort memorising a bunch of menus.

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

#284

Post by yakshaving_jgt »

tobbob wrote: post #283
yakshaving_jgt wrote: post #76

Earlier quoted context omitted.

I've never seen the point in spending time and effort learning and memorising a bunch of contextual menus that I need to point and click through. If I need to do more than simple edits to a file, I'll do the same thing as I would when making simple edits to a file or composing an email, I'll crack open vim and get to work.

You don't need to spend any time or effort memorising a bunch of menus.

Nothing is going to convince me that a more conventional GUI text editor provides better ergonomics than something like vim or emacs.

If you don’t like that kind of editor, that’s fine. You do you.

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

#285

Post by yakshaving_jgt »

samwillis wrote: post #53
forgotpwd16 wrote: post #38

Earlier quoted context omitted.

I don't understand something. In order to remote develop you've to install VSCode to the remote machine?

Sort of... VSCode will temporarily download and install its remote server on the remote machine, under your user home, when you connect to it. You don't have to do it yourself. To connect it's just plain ssh, so as long as you can login you can use it remotely. As soon as you connect it gives you a file file browser to select the root for VSCodes built in file browser side bar. My understanding is VSCode has a client…

FWIW, vim can edit files over ssh. You still use your local vim, so you don’t need to [even temporarily] download/install your configuration/plugins on the remote machine.

An alternative approach might be to mount the remote directory as a file system with sshfs.

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

#286

Post by yakshaving_jgt »

pjmlp wrote: post #225
elsjaako wrote: post #158

Earlier quoted context omitted.

I know I'm not going to convince everyone, and I know that there are other advanced options that compete (people tell me I'm missing out because I don't use an IDE with all the auto complete stuff). But I see a lot of people using a text editor that's basically notepad, possibly with syntax highlighting. For an occasional edit that's fine, but if you regularly spend more than an hour editing a file, you would benefit…

IDEs of course, and if stuck on UNIX without an IDE, either Emacs (muscle memory goes back to XEmacs glory days) or VSCode. Pure text editor, Notepad++.

What do you think an IDE has that a proficient vim user is lacking?

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

#287

Post by yakshaving_jgt »

virtualritz wrote: post #199
elsjaako wrote: post #87

Earlier quoted context omitted.

I'm an enthousiastic vim user. I think everyone who spends a lot if time editing text and who doesn't use vim (or similar) is probably missing out (including the author of this article). I think vim is really good. But I 100% agree that vim is a stupid default. In almost every context it's going to confuse more people than it makes happy.

> [...] everyone [...] who doesn't use vim (or similar) is probably missing out (including the author of this article) Did you read the article? The author used both emacs and vim. Quote: "I don’t like either of them, for differing reasons: modal editing doesn’t really fit my mental model of how an editor should work, [...]" I don't get how people who like modal editing can't accept that other people don't. From my e…

> From my experience with editor debates this weirdly seems to be much more common than the reverse.

This reads like confirmation bias to me, and I would argue the inverse.

Otherwise, I agree with you. It’s ok that people have their own preferences.

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

#288

Post by MisterTea »

virtualritz wrote: post #212
MisterTea wrote: post #171

Earlier quoted context omitted.

> Replacing Vi(m) with Nano in the standard install was one of the most important UX decisions made by the major distros in recent years It sounds like you want a unix with the UI/UX of a different OS. If a user is coming from a world where editors have all coped MS-DOS edit and its notepad progeny then nano makes sense. I am sure this goes for whatever default editor comes with Mac. If a user is coming from a Unix w…

Your point seems to assume that reading manuals is the 'right' way to learn about working with a system. While it is the preferred way for myself I acknowledge that it is not for a lot of other people. Furthermore you can easily configure any distro today to 'respect history' as much as you desire by changing a few config files. That doesn't change the face that the average person interacting with a *nix OS today wil…

> The people who came up with what you call 'history' simply had no clue about it.

Saying they didn't have a clue is both disingenuous to those who worked hard on these problems and flat out wrong.

These programs were written for text terminals running over links who's speed was measured in hundreds or thousands of bits per second. The UI had to be as simple and efficient as possible to enable a decent UX over such slow lines. The UI was sacrificed for the UX. Of course after networks got faster these editors weren't necessary but guess what, they were understood, worked and there by default. And they still are. I see no issue with this and learning vi is actually simple once you RTFM.

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

#289

Post by glowingly »

3836293648 wrote: post #202
korrt wrote: post #180

Earlier quoted context omitted.

If I forget to change the default editor in Debian and Nano pops up, I have to consult a search engine how to exit it. Just like other people do for Vim, except that Nano's interface is horrible. It is a weird decision, much like shipping Exim as the default MTA.

If you're googling how to exit nano you're blind. The one thing nano does right with its defaults is to list all the common bindings at the bottom of the screen

^X is …?

It totally obviously means shift + 6 + X.

Too bad that doesn’t exit the program.

Macs in 2022 have an extra ^ on the correct button.

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

#290

Post by throw10920 »

palata wrote: post #266
throw10920 wrote: post #235

Earlier quoted context omitted.

> The problem is that it makes it harder for the app to have sane defaults. How is this not trivially solved by having the app ship with its own set of bindings, then provide a simple toggle switch between "use app defaults" and "use OS defaults/user preferences" that is displayed on first use? > That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my pref…

> You're advocating for needlessly restricting user choice Nope, I'm advocating for letting the app developers do what they want. Enforcing apps to honor the system-wide defaults (not even talking about how to actually enforce it) would just break emacs and vim, for instance. > How is this not trivially solved [...] Well first you need to find a way to integrate that toggle in your UI without people complaining too m…

> Nope, I'm advocating for letting the app developers do what they want.

You're contradicting yourself. Your comments above are specifically arguing against the idea of implementing this system at all:

> Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults.

That is an argument against the OS-meddles-with-the-keybindings system, period. Your statement "I'm advocating for letting the app developers do what they want" is flat-out false - you are advocating against app developers implementing this system at all (and therefore advocating against letting them do what they want) by claiming that it is a bad model.

Additionally, you're trying to quietly change the discussion from "what makes things best for the user/what is good UX" (which has been the actual conversational topic) to "what do app developers want to do" which is completely orthogonal and irrelevant to this discussion.

> Well first you need to find a way to integrate that toggle in your UI without people complaining too much...

...and now you've stopped trying make arguments about the concept itself, and are trying to start arguing about hypothetical implementation problems to argue that the concept is unsound. (MacOS has effectively solved all of these problems, by the way, so this line of reasoning doesn't even pan out - MacOS's model is existence proof that such a system can be effectively implemented and that users will like it)

> That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.

Finally, there's more redirection from "is it a good idea" to "will people implement it" - again, unrelated and irrelevant to the conversational thread.

Do you have anything actually relevant that you'd like to add?

Post reply on HN