bugGNU nano - Bugs: bug #50123, version 2.7.4 and older would...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #50123: version 2.7.4 and older would color far too much after a change

Submitter:  Benno Schulenberg <bens>
Submitted:  Sun 22 Jan 2017 09:05:26 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Fri 24 Feb 2017 10:30:07 AM UTC, comment #3: 

Anyway, to repeat: things were fixed by commit 9a4a5454.

Benno Schulenberg <bens>
Group administrator
Mon 23 Jan 2017 08:29:55 PM UTC, comment #2: 

No, the proposed different method of resetting multidata doesn't help -- not in current git.  The reason is the mechanism that is explained in bug #50121: it simply gets confused when a line contains multiple matches: it always thinks that the first one is a start match and the latter an end match.

Benno Schulenberg <bens>
Group administrator
Mon 23 Jan 2017 07:10:19 PM UTC, comment #1: 

Another illustration of miscolorings: run 'stty cols 80 && stty rows 24 && /home/ben/Programoj/nano-2.7.4/src/nano --syntax=2 +12,29 NEWS', then type nine times M-=, and then press <Del> on the frist quote of "Shemesh! Shemesh!".  Wow: the preceding paragraph becomes green!  In general this should be impossible: nothing that I do here can create colors before the current position; it can only wipe them.  With one exception: when there is an unterminated start match before the current position and we create an end match here.  Apparently in this case nano-2.7.4 mistakenly finds that there is an unterminated start match somewhere scrolled off at the top.

Anyway, this and the other miscoloring are fixed by commit 9a4a5454 in the git repo.  Why then report these bugs here?  Because I had to justify the change, and give reasons why it's not good to revert it.

In current git, the above example does not recolor the paragraph before "Shemesh! Shemesh!", but the text after it, as it should.  /But/: only until the line containing "set fill" -- the line after retains the old coloring.  This is because the resetting of the multidata does not go far enough.  In fact, when something in the start/end matches changes, /all/ the multidata for it should be reset, and then recomputed from the top of the file.  Or... resetting it backward from the current position it should go until a CBEGINBEFORE /or/ a CSTARTENDHERE and stop there, and /not/ blot out those two values, or until a CENDAFTER, and blot out that value.  Resetting forward, it should simply blot out all values until EOF.

Benno Schulenberg <bens>
Group administrator
Sun 22 Jan 2017 09:05:26 PM UTC, original submission:  

To reproduce, add the following three lines to your ~/.nanorc:

syntax "2"
color brightred start="^\<" end="^201."
color green start=""" end="""

Then run 'src/nano -Y2 +7 NEWS'.  Note that the year numbers are red and the release names are green.  Now press M-= twice to scroll the top two lines of the file offscreen.  Then press <Del>.  In current git the whole 2.7.3 paragraph becomes red (except "Ontbijtkoek"), as it should, and for the rest nothing changes.  Good!

If, however, you do the same exercise with version 2.7.4 or earlier, then almost /everything/ turns green, and "Ontbijtkoek" becomes red.  It is almost as if it resets /all/ multidata when it should reset only the multidata for red.  I don't get it.

Testing this...  Yes, it actually /does/ reset the multidata for both colors.  Why?  ...  Because in reset_multis() it doesn't look for an end match /after/ a start match, it just looks for each of them from the head of the line, and if start and end regex are equal... it will not find the second possible match and start will not be smaller than end, and thus it will /think/ things have changed and will reset the multidata.  And then in the older versions it will get the backtracking wrong and color everything in the reverse manner of what is needed.

Well, even though it resets too much multidata, in the git version it gets the backtracking right and thus recolors everything correctly.  No problem.  Except... in the case of bug #50121: then it doesn't reset the multidata /far/ enough, it seems.  Testing this...  No, even when doing extra resets, or resets all the way to the end of the file, it still gets it wrong on the overnext line after the change.  :(

Benno Schulenberg <bens>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-02-24 bens Open/ClosedOpen Closed
    2017-01-23 bens StatusNone Fixed
        Assigned toNone bens

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code