Re: things on the minibar are distracting

[Seb]

Hi Benno,


> If the minibar would be placed at the top of the screen, then also the 
> status bar and the prompt bar would have to be there, otherwise we 
> wouldn't gain an extra line.  But the thought of having status messages 
> like "Not found" at the top is horrible.  And the thought of having a 
> prompt there is even worse.

I see. I use "set nohelp". Would it be possible, for this option, to use 
the bottom-most lines of the screen to display the file's contents and if 
^W is pressed (for example), to replace the bottom-most lines by Nano's 
message? In other words, to reserve the space for Nano only when it 
needs it?

> > thus it "flashes" and it distracts me from what I'm typing. The 
> > information "line count,char count" is already available with ^C, does 
> > it really need to be available at all times?
> ^C gives /far/ too much information.  All the needless info shown by ^C 
> is one of the two reasons that made me make --minibar.  From among all 
> that info all I want is the column number of the cursor.  The line 
> number is there only to let it make sense.

If ^C is too chatty, why not change ^C? (Although it seems fine for my 
uses.)
I don't really want to argue about what's useful or not; my main point is 
that to me, flashing numbers are distracting.
Would there be a middle ground in an rc-setting that would let the user 
choose the color for "line,column" and "charcode"? I could then set them 
to the background's color :-)

> > * Idem for the Unicode code, it flashes and seems rarely useful.
> It is rarely useful, but it is the other reason why I made --minibar:
> sometimes I come across invalid bytes and I want to see what code they
> are.  Having to select the fragment, write it out to a file, exit from
> nano, xxd the little file, and then restart nano was a nuisance.

I don't deny that it can be really useful to see charcodes. I merely say 
that it is rarely useful. Thus it may not deserve a permanent (and 
flashing) place on the screen.

> Having this info the whole time in the bottom bar may be a distraction 
> to you, but fifteen years of using nano has made me ignore whatever is 
> on the bottom row -- unless I hear a beep or invoke a prompt.  I see 
> things on that row only when I directly look at it.

It's been a long time since I've had messages at the bottom of the screen.

> > To go even further along the "minibar" idea: would it be possible to 
> > let this line disappear completely with a keyboard toggle, perhaps ^C?
>
> (You probably mean M-C, as the --minibar option turns M-C into a no-op.)
> Hmm...  That would be an idea.  It would not give another extra line of 
> editing space, though, because that bottom line needs to stay reserved 
> for status messages and prompt bar.  But... see attached patch for a 
> rough first implementation.

The patch (for v5.5) failed with the message:

patching file src/nano.c
Hunk #1 FAILED at 185.
Hunk #2 FAILED at 2080.
2 out of 2 hunks FAILED -- saving rejects to file src/nano.c.rej

The file src/nano.c.rej contains:
===========================================================================
--- winio.c
+++ winio.c
@@ -185,7 +185,7 @@ void read_keys_from(WINDOW *win)
        curs_set(1);

 #ifndef NANO_TINY
-   if (currmenu == MMAIN && ISSET(MINIBAR) && lastmessage > HUSH &&
+   if (currmenu == MMAIN && ISSET(MINIBAR) && ISSET(CONSTANT_SHOW) && lastmessage > 
HUSH &&
                        lastmessage != INFO && lastmessage < ALERT) {
        timed = TRUE;
        halfdelay(8);
@@ -2080,6 +2080,12 @@ void minibar(void)
    wchar_t widecode;
 #endif

+   if (!ISSET(CONSTANT_SHOW)) {
+       blank_statusbar();
+       wrefresh(bottomwin);
+       return;
+   }
+
    /* Draw a colored bar over the full width of the screen. */
    wattron(bottomwin, interface_color_pair[TITLE_BAR]);
    mvwprintw(bottomwin, 0, 0, "%*s", COLS, " ");
===========================================================================

I don't know why this mentions winio.c, or what went wrong.
Any idea?

> > > ? Option 'set markmatch' highlights the result of a successful search 
> > I love it already.
> I like the improved visibility of the found occurrence, but having it 
> marked is a bit of a hindrance.  Apparently, after having searched for 
> something, I often want to delete the relevant line, but now the first 
> ^K deletes the found text.  It needs a second ^K to delete the line. I 
> still haven't gotten used to this.

Ah, yes, I didn't notice the "mark" part; this part feels awkward indeed.
(Most of the time, I search a string to find an occurrence, not to delete 
anything.)


Sébastien.