[Nano-devel] On the future of nano

From: David Ramsey Subject: [Nano-devel] On the future of nano Date: Tue, 2 Apr 2019 13:48:52 -0500

Hello, Benno. Consider this a belated reply to: http://lists.gnu.org/archive/html/nano-devel/2019-01/msg00040.html I meant to get to it sooner, but fixing the code in nano when I can has been a higher priority for me. And I much prefer actually improving the editor to arguing over maintenance issues. Until the recent release, that is. ---------- > And the Ctrl+Left/Right was implemented in nano not because we wanted > to follow Pico but because I have been asking for it since 2006. You cut out the relevant part of the quote when replying. *Interpreting double Escape followed by Left and Right* as Ctrl-Left and Ctrl-Right is something Pico does and nano doesn't. > I want ^K to do what the user most likely expects, not the least > "destructive" thing -- there is M-U, after all; I use it every few > minutes. You keep phrasing things like this as "what most users expect", but you keep acting as though what most users expect aligns exactly with what you expect. There have already been some examples given of users who don't. Do they not count, except when they agree with you, or except when you generously decide to listen to them? > WTF? Stop making me guess and speak clear language. Fine. There have been complaints about some of the changes you've made, but you've mostly ignored them, or acted as though they don't matter. And there are major deficiencies in the current version of nano that need fixing. True, they're more about functionality added to nano than changes to nano's Pico compatibility, but if you won't listen to most complaints about the one, you won't listen to most complaints about the other. And there is a difference between "I'm not complaining because I like how things are" and "I'm not complaining because I know from experience that it won't make any difference, even though I don't like how things are". Here's the list of the most important issues. * Word-cutting, back in September 2018. You said you were applying the patch for it, but put in a last-minute change which made it behave asymmetrically before committing it, and didn't bother getting any feedback on the changed version before committing it. Brand complained afterward; you accused him of having an attitude (among other things) and ignored him. I complained afterward; you said it didn't matter for text (leaving out that it *would* matter for code) and ignored me. References here: http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00024.html http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00027.html http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00031.html http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00036.html http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00034.html http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00052.html And then, earlier this month, you changed the messages to reference "chopping" instead of "zapping", which was inconsistent. Brand pointed this out, but you ignored him, and I would have pointed it out, but you'd already decided it wasn't important, so you'd ignore me again if I had. References here: http://lists.gnu.org/archive/html/nano-devel/2019-03/msg00020.html http://lists.gnu.org/archive/html/nano-devel/2019-03/msg00024.html * The linter title bar color, back in October 2018. You insisted on reusing the selected text color for that, even though it would have been simple to add a separate color for it. Brand pointed out that there were possible accessibility issues with doing that; you ignored him. I pointed out that a separate color for the linter title bar could be reused for other (non-error) messages meant to be extra visible to the user; you ignored me. And yet, despite the fact that you don't want to add another color for linter messages, you don't seem to be averse to adding extra interface colors for features that *you've* added, such as the guide-stripe. References here: http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00096.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00103.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00109.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00112.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00119.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00120.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00115.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00121.html http://lists.gnu.org/archive/html/nano-devel/2018-10/msg00122.html http://lists.gnu.org/archive/html/nano-devel/2019-03/msg00002.html * 256-color support, back in February 2018. Yes, it's a cosmetic thing, but having color and/or display attributes is, by definition, cosmetic. The original version was simplified to not use indexed colors, which made sense, seeing as indexed colors had arbitrary values. However, even after the simplified version, you went off on how you thought specifying fallbacks was really specifying two colors and turned the whole idea down, despite the fact that 256 colors aren't guaranteed to be available and the fallbacks were required (what should work differed markedly from what did work). References here: http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00068.html http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00125.html http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00128.html http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00127.html http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00151.html http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00159.html * The lack of extrapolated key bindings; including raw control characters in the nanorc that won't even work properly if any keys are rebound is so limited as to be almost useless, but you keep saying it's unnecessary to fix that, and complain about having to add code to fix it. Reference here: http://lists.gnu.org/archive/html/nano-devel/2018-09/msg00000.html * The removed per-file syntax formatter. You haven't bothered putting it back in, and fought it initially by claiming that manually piping a file via ^R^X could be an effective substitute. In the original bug #54889, Patrick Bogen chimed in with an example as to why that was not an effective substitute, and offered to help you reimplement the formatter: http://savannah.gnu.org/bugs/?54889#comment6 And you replied that his example was "spamming" you with "irrelevant stuff", closed that bug, and opened a new bug: http://savannah.gnu.org/bugs/?55365 in which you claimed that the old bug was "polluted with irrelevant stuff". So an example of why your proposed solution won't work (which, coincidentally, was one that required no actual work on your part) was "irrelevant spam", an offer of help coding a good solution was ignored, and the bug in which this happened was closed and labeled so that others would most likely ignore it? (Or would you have preferred to delete that bug instead of just closing it, so that no one could actually read it and see what it really contained?) * Miscellaneous problems with shortcut lists. Meta-Left Arrow and Meta-Right Arrow don't work when UTF-8 mode is disabled, because the Unicode characters for the left and right arrows only show up in UTF-8 mode, and you're not willing to do any extra work to make the help screen dynamic enough to handle the words "Left" and "Right" or their translations again. Also, the lack of visible shortcuts for most of the functionality in the help viewer is a problem (if someone's new to nano, they won't know about the shortcuts if they're invisible), and you're not willing to fix that either. I could go on, but I think I've made my point. Given what you say here about "complex stuff": http://lists.gnu.org/archive/html/nano-devel/2018-11/msg00031.html combined with your insistence that nano should be small and simple, and your insistence that what you want matters above all (some of which *is* your prerogative as maintainer, but some of which goes too far, given your tendency to disregard what others who use this editor want)... What conclusion am I supposed to draw from all this, other than that * as maintainer, you think this is *your* personal editor and your accommodating other people is optional (as seen when you say you'll go against your own preferences "for now", which means what? you'll change it once you think no one's paying attention?) * as maintainer, you want everything in the editor to be simple because you can't handle anything that isn't simple Just to be clear, I'm not knocking your coding abilities per se. You do have some good ideas regarding this editor, and you're good at simplifying code in ways I wouldn't think of. But your insistence on oversimplifying things at times, and your way of leading this project (and dealing with opposition) are major problems. If you keep going the way you are, you'll end up with an editor that only you want to use, and that's not something I'm willing to support. Frankly, I care about the project as a whole more than you. As for what you say about maintainership in the above link, I've been looking into that ever since you posted it. (Or did you think I was just silently letting it go?) So let's say I take you up on it. This can go one of three ways: 1. You put out 4.1, we have a relatively painless transition after which I'm back in charge, and you can keep contributing in some capacity if you want to. The fixes and features that nano's needed for a while go in. 2. You fight me on the issue of maintainership, and I fork nano instead (I'm loath to do it, but if it's either that or have nano keep going down the wrong path, I'll have to do it). The needed fixes and features that nano's needed for a while go into the fork, at least. 3. You flip out, accuse me of having an attitude, tell me to fuck off, and come up with a list of reasons why complaints from people other than you somehow don't count, and I save myself a lot of aggravation and go with option (2) above. In terms of coding, Brand and Patrick have said they'd be willing to help me. It's your choice. Either way, I don't work for you anymore.

reply via email to



[Prev in Thread] Current Thread [Next in Thread]