Re: [Nano-devel] RFC: nano's justifications are poorer than those of Pico -- okay to improve?

[Benno Schulenberg]

Op 26-05-18 om 04:04 schreef David Ramsey:
> Addendum: I've tried this, and it doesn't seem to be a problem.
> 
> I've tried it with indentation consisting of one space on the first
> line, two on the second line, etc., all the way up to 178 spaces.  Also,
> I've done it via both breaking lines (if the terminal is only 80 columns
> wide, justify will do this) and joining them (if nano is run with the
> option "-r 100000", justify will do this, assuming no line is actually
> that long).

Thanks for all that testing.

> With your new definition of what constitutes a paragraph [...], it
> doesn't actually go all the way back to the beginning.

I think it does.  When creating a "pathological" file:

  for x in $(seq 87654); do echo "flush"; echo "  indented"; done >bigfile

then running 'src/nano --ignore bigfile' and typing:  M-/  aaa  ^J
the result is: Segmentation fault.

When using $(seq 76543) instead, the justification succeeds.

Running the failing command in valgrind gives this:

==6411== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==6411== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==6411== Can't extend stack to 0x1ffe8010a8 during signal delivery for thread 1:
==6411==   no stack segment
==6411==
==6411== Process terminating with default action of signal 11 (SIGSEGV)
==6411==  Access not within mapped region at address 0x1FFE8010A8
==6411== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==6411==    at 0x5384F1F: re_string_reconstruct (regex_internal.c:571)
==6411==  If you believe this happened as a result of a stack
==6411==  overflow in your program's main thread (unlikely but
==6411==  possible), you can try to increase the size of the
==6411==  main thread stack using the --main-stacksize= flag.
==6411==  The main thread stack size used in this run was 8388608.

So... it will be necessary to somehow limit the depth of recursion.

> It also doesn't
> seem to be any slower than usual, although I haven't timed it
> specifically (for what that's worth, if anything).

In the pathological case above, the delay is noticeable.  But true,
in the average case it will be maybe twice as slow as before, but
that's fine with me.

Benno

signature.asc
Description: OpenPGP digital signature