[Nano-devel] On the future of nano

[David Ramsey]

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.