1. 47
  1.  

  2. 17

    Might be an unpopular opinion but I’d pick nano over vim any day.

    1. 2

      It may be unpopular but it gets the job done. Personally I’d pick vim, but that’s decades of experience to lean on.

    2. 7

      nano is my go-to editor and I have only good things to tell about it.

      Also, unlike Vim (and Emacs for a long time) it supports the XDG spec.

      1. 2

        If you feel comfortable elaborating, I’m curious why you’d pick it over other editors. Are you primarily sshing to places that don’t always have other editors installed?

        1. 7

          That is mostly my use case with it. nano works out of the box. It requires no configuration and it’s the same everywhere. That is valuable to me as I need to change a setting or tweak a service file or whatever. It’s not my main editor. I use VSCode for that. You could argue that I could use vi for this, but I just need to change a damn file. I’m not going to work on it for long. Maybe I’ll tweak a line or two and move on with my life. I can use vi, but really, it’s an extra mental load when all I’m doing is scrolling down a file to find the setting I need to change to “yes”.

          1. 2

            that makes complete sense. i definitely wasn’t asking from a position of trying to evangelize my own approach. thanks for explaining

        2. 1

          Also, unlike Vim (and Emacs for a long time) it supports the XDG spec.

          It is possible to configure vim to respect XDG. I have this in my ~/config/vimrc:

          set undodir=${XDG_CACHE_HOME}/vim/undo//
          set dir=${XDG_CACHE_HOME}/vim/swap//
          set backupdir=${XDG_CACHE_HOME}/vim/backup//
          

          These tell vim to put everything in .cache (I also create those directories if they don’t exist in a file included from my .bashrc because vim sulks if they don’t exist). This also avoids cluttering my filesystem with ~ and .swp files: they all go in ~/.cache where I can clean them out centrally if I ever want to.

          I have this in a file included from my .bashrc:

          export EDITOR=vim
          export VIMINIT="source ${XDG_CONFIG_HOME}/vimrc"
          

          The second of these lines tells vim to source my ~/.config/vimrc file when it starts up. It will also try to source .vimrc but it’s quite happy if that doesn’t exist.

          With this combination, I don’t have a ~/.vimrc and everything seems to work quite happily in XDG locations.

          1. 3

            I don’t think there’s any question about a highly configurable editor being able to be made to respect XDG. But that’s not really the same as supporting it, is it? That’s a quite a bit of configuration, in files for two different programs. And even then you have to manually create directories to get it to play nice.

        3. 5

          nano is my daily driver of editors, never really understood the amount of negativity it seems to attract.

          1. 2

            I think it’s not the inherent qualities of nano that cause it to be so reviled, but the fact that in some distributions it’s the default editor. All of my experiences with nano can be described as follows: “Ok, $EDITOR and $VISUAL are not set, so git commit opens the confusing default editor; how do I exit this?” This happens fairly often if you have to jump between various machines. I didn’t even actually ever try using nano seriously and only know of it due to these frustrating experiences, which, irrationally, link this editor in my head with the general sense of irritability. I don’t go around disparaging nano, but can see why some people do.

            1. 2

              Maybe there’s something to this, but what would you propose happens instead? The program refuses to run until $EDITOR is set? That would certainly be more frustrating and confusing for many than Nano. Maybe vi or ed? If you find it easier to exit one of those than an editor with a permanent label in the corner telling you how to quit, I don’t know how to argue. A GUI editor? That wouldn’t work well on servers.

              Maybe I’m sheltered, but the only people I’ve heard speak down on Nano are those who use advanced editors like Emacs, Vim, and now VSCode. If one is at a level where they are comfortable in any of these, I think it’s reasonable to expect them to be able to export $EDITOR wherever they go.

              Regardless, I still don’t see why people go around disparaging nano if they find it irritating. Just as I don’t understand why people disparage Vim or Emacs. It solves nothing and is kind of juvenile.

              1. 1

                Any fixed option would likely frustrate a lot of people, so is it even a problem to be solved, as opposed to a sad fact of life? It seems that it’s only the emotional response to nano that is harmed here. Also, having used both vi(m) and emacs, I agree that nano is a much more sensible default than they are.

                That said, if one did pose this as a problem, one solution would be to allow the user to choose among the popular editors in $PATH via dialog(1), though in my opinion, this would be overengineering given the low impact of the issue.

                1. 1

                  That seems like a great solution, and reminds me of the select-editor command. I don’t know what actually makes use of it, but when run it has a list like you said, and sticks a binary to run in a dotfile. It’d have to be patched in to software in some way I guess, unless the dotfile was sourced by the default shell, but I like where you’re coming from. Overengineering? Probably.

          2. 3

            those were some of the things that you can do with nano that a lot of people don’t seem to realise. it is definitely not up to the level of vim or emacs, but it is a very capable editor.

            I think that this is just the reason why so many people are surprised when someone invests time into nano: If you’re ready to learn an editor and invest your time, why not use something as widespread as vi or as powerful as Emacs? As a TA, I usually recommend people use nano over vim when starting to work in a shell environment, but if they seem interested in learning more, it seems to make sense to look elsewhere?

            1. 3

              I think it depends what the person wants. Nano is in my reckoning quite equivalent to Notepad++, and there are a lot of people out there who find Notepad++ the comfiest environment for them. The features in the article are essentially equivalent to what I use in vi/Vim, except with a modeless paradigm. Vim offers more (I don’t think vi does), but most people really don’t need more. Emacs is slightly different, but once again those features are the core of what I do. The Emacs advantage comes from being a whole interface rather than an editor. In my experience, Nano is as widespread as vi these days, and out of the box is friendlier.

              I don’t know. The point of the article wasn’t really to convince anyone to switch to Nano. Personally I use Emacs and am very content, but I was fed up with Nano being used as a punchline by people who hadn’t even actually looked at it.

              1. 1

                Oooh I wouldn’t go nearly that far to call nano equivalent to Notepad++. Notepad, yes, but the ++ has so many “advanced” features, and most of them out of the box, that it’s simply not the same category.

                At least that’s my opinion. But of course, what you use your editors for and what I use them for are probably vastly different.

                1. 2

                  I didn’t necessarily mean in terms of features (and in terms of features, just skimming the documentation it appears to have significantly more than both Nano and itself last time I used it). I do object to the Notepad comparison, which was what sparked the entire article in the first place. Notepad only allows the editing of plain text files. Nano has multiple features to benefit programmers and fit pretty well in a Unix environment.

                  By comparing Nano to Notepad++, I was definitely focusing on the “comfiness” aspect. That is, a primary goal is to be intuitive as well as power. Notepad++ fits in well on Windows and behaves as one would expect a Windows program to behave. I believe that Nano is the Unix equivalent.

                  Out of interest, what do you use your editors for? You’re probably right, I don’t program professionally and mostly do typesetting.

            2. 3

              Honestly, I originally chose Vim because I naively thought it would give me more credibility as a developer. I didn’t think nano was a toy, I just thought it would be easier to fool people into thinking I knew what I was doing if they saw me fire up a Vim session or if they saw my carefully crafted .vimrc. I’m comfortable enough with Vim now that I don’t feel the need to consider another editor at the moment. But I’m not as insecure as I was back then so I might choose something else if I had to do it all over again now.

              1. 3

                nano was my go-to CLI editor for a long time. I eventually replaced it with micro, a self-described successor. In both cases I always liked that I could use them out of the box and that they felt relatively close to the GUI editors I used more frequently (in terms of keybindings and editing modes). Learning vim or emacs never felt worth the time.

                1. 2

                  I used micro for a while, and I definitely think that the “self-described” part is important. I found it very different to nano, and that confused me (although that might be because I haven’t used any “normal” editors for so long). It was also a significantly larger program with no real gain: I used the same few features. I am glad it works for you, that is all that matters.

                2. 2

                  nano also supports syntax highlighting https://askubuntu.com/questions/90013/how-do-i-enable-syntax-highlighting-in-nano though I personally use https://github.com/scopatz/nanorc for better definitions.

                  I also mainly switched to micro (except for git commits), though I have some issues with clipboard over ssh, in that case I usually fallback on nano.

                  1. 2

                    It seems like vi lite with emacs-ish bindings (chording over combinations).

                    1. 2

                      Pretty much. Although some of the common keybindings are different enough it can get confusing (C-w, C-s, for example).

                    2. 2

                      One positive that I’ve learned over time about nano is that it’s consistent; before I learned the differences between vi, vim and vim.tiny (the minimal build Debian uses), I would often find myself looking for features that weren’t there. I’ve never seen a nano with features configured out, though I’ll have to peruse the source this afternoon to see what can actually be turned on and off!

                      1. 1

                        i have always liked nano but never tried to look deep. great writing.

                        1. 1

                          I use jove for many of the same things, and I’d like to add another advantage: It allows full-speed typing. Emacs, for example, does not. You have to start it, wait for a window to become ready, then resume typing.

                          Editors like jove, nano and vi accept commands from the moment you’re done invoking them, even before the kernel has started paging the editor’s executable into memory.

                          1. 3

                            I only have to open Emacs once every time I restart my machine, so it is non-problem for me.

                            1. 1

                              I’ve not used Jove. Is it Emacs without the lisp, like mg or zile? I use mg on OpenBSD sometimes, but forget whether I’m in Emacs and get frustrated when things don’t work.

                              I can’t say I’ve ever experienced the problem you describe, but I work quite slowly. I just timed opening Emacs from cold, and it takes just over a second. It takes less than half a second after that, even without using emacsclient. That’s still fifty times slower than nano, true, but it seems to grab keypresses from the get go as well - every time I started typing as soon as I pressed enter and all the text showed up.

                              1. 2

                                Yes. Jonathan (whose last name I’ve forgotten) wanted an emacs and wrote one, in C. I tested a couple of curses-based editors with emacs keybindings and found jove best, and it’s stayed with me for 25 years. Maybe mg or zile are better nowadays. I do use emacs itself for when I’m working in the editor, but jove’s my to-go when I’m working on the command line.

                                I know that a lot of people either never work on the command line and/or can’t type quickly. But for those of us who can type quickly and do work with command lines, being able to type at the editor without any pause is valuable.

                                When I looked for jove, emacs itself would either accept keypresses at once or require you to wait for it to open an X11 window depending on…. I think there were two conditions, but I can’t remember. It’s been so long.

                                1. 1

                                  Did jove use to be “joe” (Joe’s Own Editor)? I think it used the slang library, like the slrn newsreader.

                                  1. 2

                                    You might be thinking of JED there - that one definitely used slang. https://en.wikipedia.org/wiki/JED_(text_editor)

                                    1. 1

                                      Correct, someone named Joseph created JOE:

                                      https://joe-editor.sourceforge.io/

                                    2. 2

                                      No, that’s a completely different editor written around the same time. Someone named Joe wrote one, someone named Jonathan wrote the other.

                                    3. 1

                                      Oh I see, I forgot that Emacs had an X11 version. I always run Emacs in the terminal so don’t need to wait for a window to spawn. I’m glad you’re happy with Jove!

                                2. 1

                                  I really like projects such as micro, because while I think that it’s good to have a million editors that are basically the same some diversity and projects trying to do stuff differently is good.

                                  1. 1

                                    I was under the impression that micro aimed to get rid of diversity in the terminal editor space by moving to standard GUI keybindings?