Re: [Nano-devel] [PATCH 1/2] display: let the title bar show when nano is in linting mode

[Brand Huntsman]

On Tue, 23 Oct 2018 18:01:48 +0200
Benno Schulenberg <address@hidden> wrote:

> How come you can't read selected text?  You purposely chose a color
> combination that makes selected text unreadable?  But how then do you
> work with Replace when it asks "Replace this occurrence" when you've
> used a regex for searching? You can't see what exactly the regex has
> matched.

My issues, including the fact that I mostly do slow manual search and replace, 
aren't important. I have never used the linter (outside of current testing) and 
have no plans to ever use it. But improving features others use is important, 
even if I don't use them myself. And if I did use the linter, I could patch 
this mistake, others can't. I can also patch when NOTICE, using SELECTED_TEXT, 
leaks into the rest of nano.


> > I understand your position though, most developers don't care about 
> > accessibility because it works fine for them.  
> 
> How can you imply that I don't care about accessibility?  What did the
> --showcursor option get added for?  And why was its meaning extended
> just recently?

Why would you even bring that up? Caring doesn't stop at just one feature.


> > errorcolor, noticecolor and yesnocolor are accessibility features
> > that benefit all users equally.
> 
> True.  But they are not a necessary part of the linter patches.

Showing "linter" in titlebar and enabling help bar are important for someone 
who accidentally turned on the linter. Highlighting linter messages is a fluff 
patch that could wait until nano has proper support for it. And the 
promptcolor/yesnocolor patches would benefit far more users than the 0002 
linter patch ever will. It isn't worth all this drama and breakage.

The NOTICE/noticecolor patch could also be written and tested in
minutes, and applied to git. It should default to hilite_attribute instead of 
getting a custom default like errorcolor. Linter 0002 could then be a three 
line patch to use NOTICE. Other messages can be changed later as they are found.


> > And the purely decorative unicode arrows in help use more
> > code and other resources than adding a couple new interface
> > colors.  
> 
> The arrows are not purely decorative: they work in other languages
> whereas "Left" and "Right" and such don't.

Why can't left/right/up/down be translated like all other text in nano? Unicode 
fonts don't work everywhere and some fonts don't render all characters 
correctly. And have you tested the unicode arrows with various free screen 
readers? I haven't, but the screen reader must lookup the names of non-standard 
characters, and the name of "◀" is "Black Left-Pointing Triangle". There are 
also other readability problems on the help page. The ^ is probably not read as 
"control", the "M-" is probably not read as "meta" and the "Sh-" is probably 
not read as "shift".

The only valid reason for unicode arrows is to prevent the "M-Righ" issue. But 
that could be fixed by dynamically adjusting the left column and indenting 
wrapped descriptions. If the first+second key names on help page is more than X 
characters or Y% of window width, it could drop the second name for that 
function to prevent the left column from becoming too wide. And then a nanorc 
setting could be added later on to expand ^, M- and Sh- in help page and help 
bar (if that is even read by a screen reader).