Re: [Nano-devel] [PATCH] enable searching (^W) in a help text (^G)

[Rishabh Dave]

On Fri, Dec 2, 2016 at 4:55 PM, Benno Schulenberg
<address@hidden> wrote:
>
> On Thu, Dec 1, 2016, at 19:58, Rishabh Dave wrote:
>> unwrapping help text to the original length when
>> window's size is changed very quickly,
>
> ??

Cause of the "76 business".

>> Also I came across the solution to the issue with multibuffer
>
> Clever.  But what if nano dies while showing a help text?
> Where did the buffer contents go?  The user doesn't know.
> (And no: more explanations in the manual are no good.)
> So no, not acceptable.

No modification in die() or die_save_file() would help? We can open
the old buffer there.

> But leave that problem for now.  And leave also this problem:
> run src/nano, type ^G M-/ and resize the window -- the screen
> jumps back to the start of the help text.  In current nano the
> cursor will stay roughly in the same area.  It should continue
> to do that.

I do remember writing the code for this before (even added a comment
there in similar words as you). But I guess, I forgot to re-add it
somewhere after fixing so many things.

> +bool window_went_below_76 = FALSE;
> +       /* Gives the help text the original look when window size jumps
> +        * from something below 76 to directly something above 76.  */
>
> It is a mystery to me why this is needed.

Same mystery that led you to type question marks above.

> +           /* Rewrap if needed, else refresh. */
> +           if (COLS < 76 || window_went_below_76) {
> +               window_went_below_76 = COLS < 76 ? TRUE : FALSE;
> +               display_the_help_text(TRUE);
> +           }
>
> Aaah, this 76 business is an optimization...

Optimization was only complementary, but mainly I wrote it for a bug.
Do this without the patch applied - src/nano, ^G, change the window
size until the first line can contain only this "The nano editor is
designed to emulate". Now, increase window size to something more than
76. Do this as fast you can without stopping at any value below 76.
You will see the help text remains as it is.

Another way to encounter the bug is to read the code for above
scenario. When you increase screen size from something below 76 to
more than something than 76 without stopping anywhere between, text
don't rewrap, because the condition in if-statement dictates it (COLS
would be greater than 76).

> Don't bother with
> optimizations, just always recreate the help-text temp file when
> the window is resized.  It makes things easier to understand.

Well you confuse me. Sometimes you want optimization and sometimes not.

> Also, your optimization goes wrong when a translator has made
> some description of a shortcut into a very long line -- the
> German translation contains some overlong lines: with your
> patch they are not unwrapped even when there is space.

Couldn't see that happen. If you give me a recipe, I will fix it.

>            if (line > 0)
> -               line--;
> +           do_up(FALSE);
>         } else if (func == do_down_void) {
> -           if (line + (editwinrows - 1) < last_line)
> -               line++;
> +           do_down(FALSE);
>
> Both those should use TRUE.  Pressing <Up> or <Down>
> in the help text should immediately scroll the screen, not
> move the cursor.

With that you can scroll down screen till it goes completely blank.

> +       } else if (func == do_research) {
> +           do_research();
>
> It needs a 'focusing = TRUE' inserted to get the normal
> behavior for re-searches back.

What does focusing achieve, couldn't figure... I tried testing without
and with making the change you asked for.

> -    if (ptr < end_of_intro && COLS > 74)
> +    if (COLS > 74)
>         wrapping_point = 74;
>
> Only the introductory text should be wrapped at a maximum
> of 74 columns, not the descriptions of the shortcuts -- those
> should be wrapped at COLS.

In that case long shortcut description won't be displayed completely.
"should be wrapped at COLS" -- didn't get you.