Re: thoughts on status messages

[Mike Frysinger]

On 07 Mar 2021 12:20, Benno Schulenberg wrote:
> Op 05-03-2021 om 19:02 schreef Mike Frysinger:
> > when you have constantshow enabled, moving the cursor at all will clear
> > those messages.  and there's no way to bring them back.  so if nano did
> > show something that happened to catch my eye but i started editing too
> > fast, it'd be gone forever.
> 
> From this I guess that a keystroke that reshows the last shown message
> would already be a great help?

that would mitigate it a bit.  if you have more than one error message,
things would get clobbered.  but i guess if the message is maintained on
a per-buffer basis rather than per-session, it wouldn't be so bad.  e.g.
if i open 10 files and 3 have errors, i would want to see the error for
the respective file when i flipped to the buffer for it.

> > * messages would stack up & disappear automatically at the bottom of the
> >   screen rather than being a single line shared with the constantshow.
> 
> As you use constantshow, maybe it would help if an error message overrode
> constantshow for ten or twenty keystrokes?  By default (when not using
> --quickblank or --constantshow or --minibar) nano leaves any message on
> the screen for twenty keystrokes.  Maybe it should keep error messages
> onscreen for that long also when --constantshow is used?

that might be helpful: show it for the next 5 seconds or 10 keystrokes,
whichever comes first.

> (By the way: what info do you need from --constantshow?  All nine items,
> or are there things you can absolutely do without?)

i use all of them, albeit at different frequencies.  i think the ones i use
constantly are line pos, col pos, and col count.  the char count less often,
but not never.

i kind of wish it wasn't so jumpy, but i've gotten used to it.  maybe:

[ line %*i/%i (%2i%%),
* the current line width should be the same as the max line width
* the percentage should float between 2 & 3 cols rather than 1 & 2 & 3

col %*i/%i (%3i%%),
* the current col width should be the same as the max col width
* it should always be at least 2
* the percentage should stay fixed at 3 cols since the cursor is frequently
  at the end col in the current line as one types

char %*i,%i (%2i%%) ]
* the current count width should be the same as the max count width
* the percentage should float between 2 & 3 cols rather than 1 & 2 & 3

> > * turn the "Modified" space in the upper right into more of a flag space
> >   for multiple states.  M for modified, R for read-only, LF/CRLF for the
> >   line ending mode, etc...
> That already kind of exists, since nano-5.3: --stateflags.  Except that
> it shows states of the editor, not states of the buffer.

hmm, i had missed that option.  i should prob read the NEWS more :p.

> With --stateflags, a modified buffer is indicated by a star after the
> file name (in the title bar or in the mini bar).  When a file is not
> writable, maybe a minus or equals sign could be shown?  And when this
> unwritable buffer was modified, an exclamation mark?

i know the editor is tight on space, but i always flinch when i see a string
of LxJ&(*a{} and i'm supposed to know what they mean.  to your point about
needing to open up the manual and find the decoder ring for these things ? :)

> I don't really see the need to indicate the line ending somewhere, as I
> think DOS-formatted files are getting exceedingly rare on Unix systems.

if you spend your entire life in UNIX, then this is prob accurate.  but as
soon as you have to work or collaborate cross-platform, it comes up quite
often.  i'll point out that there's an active Windows port of nano, and at
least a few users of it (including myself every few months).  in real life,
i don't have the luxury of telling our corporate users & partners to stop
using Windows and sending me patches they made on it ;).  people will do
just about anything ... i've seen customers maintain their Linux kernels
in Microsoft Visual SourceSafe (VSS).  they shipped that stuff.
-mike