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

 
 

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

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

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

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

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 24 Feb 2017 10:30:07 AM UTCbensOpen/ClosedOpen=>Closed
    Mon 23 Jan 2017 07:10:19 PM UTCbensStatusNone=>Fixed
      Assigned toNone=>bens

    Back to the top


    Powered by Savane 3.1-cleanup1