Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#408 very long lines may be truncated after replace operation

development
closed-fixed
Program (402)
7
2006-08-13
2004-08-24
Anonymous
No

I am using 5.5RC1, and just noticed that my very very
long lines were
truncated after "line commenting" them.

This topic was brought up before in the FAQ, and in the
following link
(from Apr 2002).
http://www.nedit.org/pipermail/discuss/2002-
April/001676.html

When replacing a line with regular expression, the line
might truncate
to 511 chars.
One of the solutilong suggested at the above thread,
was to change
SEARCHMAX, in source/nedit.h from 511 to something
bigger.

example for such a replace:
replace_all("^.*$", "#&", "regex")

regards,
Arnon Sharlin

Discussion

  • Thorsten Haude
    Thorsten Haude
    2005-02-07

    • priority: 5 --> 7
     
  • Thorsten Haude
    Thorsten Haude
    2006-04-02

    Logged In: YES
    user_id=119143

    Andy, you said in the ML that you bumped up the value from
    511 to 16383. Is this the version you still use? Any
    negative effect?

     
  • Andrew Hood
    Andrew Hood
    2006-04-02

    Logged In: YES
    user_id=36856

    Yep. Still using 16383 and if I remember correctly 32767 in
    some builds.

    The only potential issue could be the amount of memory used.
    There could be a lot of static buffers of size SEARCHMAX.

    Changing to dynamic buffers looks like a lot of work, and
    pointless in these days of cheap memory.

     
  • Logged In: NO

    I think the user should get an error if trying to operate on
    a line larger than SEARCHMAX, so data wont get lost, no
    matter how large the SEARMAX param is.

    arnon

     
  • Logged In: NO

    > The only potential issue could be the amount of
    > memory used. There could be a lot of static buffers
    > of size SEARCHMAX.

    Doesn't sound very good :(

    > Changing to dynamic buffers looks like a lot of work, and
    > pointless in these days of cheap memory.

    Cheap they may be, but not everybody gets to enjoy the
    luxury of upgrading their systems. Especially the older
    [non-linux] ones.

    -TK

     
  • Thorsten Haude
    Thorsten Haude
    2006-04-03

    Logged In: YES
    user_id=119143

    >> The only potential issue could be the amount of
    >> memory used. There could be a lot of static buffers
    >> of size SEARCHMAX.

    >Doesn't sound very good :(

    From a quick look over the code, SEARCHMAX only affects the
    two dialogs permanently, ~45k. The rest is in auto
    variables, mostly in callbacks.

    While 45k is non-negligible on some systems, the alternative
    is NEdit silently erasing data. There may be worse things an
    editor can do but I can't think of anything.

    There are warnings, but as far as I can see only on the GUI
    level, not for macro searches. This is also expressed by a
    comment in lines 4346ff. I will look into it; feel free to
    chime in.

     
  • Thorsten Haude
    Thorsten Haude
    2006-04-03

    • assigned_to: nobody --> yooden
     
  • Thorsten Haude
    Thorsten Haude
    2006-04-04

    Logged In: YES
    user_id=119143

    NEdit gives a warning in the terminal if the replacment is
    truncated (source/regularExp.c:SubstituteRE()).

    This is not enough of course.

     
  • Thorsten Haude
    Thorsten Haude
    2006-04-15

    Logged In: YES
    user_id=119143

    Please have a look at the attached patch. A few minor things
    are still missing, but it should work alright.

     
  • Thorsten Haude
    Thorsten Haude
    2006-04-16

    Logged In: YES
    user_id=119143

    New patch. Please have a look at the states in
    ReplaceInSelection(), I might have missed something.

     
  • Randy Kramer
    Randy Kramer
    2006-04-30

    Logged In: YES
    user_id=116756

    See also bug 1479505.

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-13

    • status: open --> closed-fixed