bugGNU nano - Bugs: bug #50121, adding or deleting a start/end...

 
 

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

bug #50121: adding or deleting a start/end match for a symmetrical multiline regex will not recolor all of the subsequent text

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

Sun 12 Feb 2017 07:08:13 PM UTC, comment #3: 

Fixed in git, b3bcc8ee.

(The original description of the problem was wrong, though: older would not invert the color on /all/ the subsequent text.  It would just invert it as far as the resetting of the multidata reached.  If there are just a few matches in the file or on the screen, it will /seem/ to invert all the green, but it really doesn't.  So I might wish to change the description of this bug: "adding or deleting a start/end match for a symmetrical multiline regex will not recolor all of the text that follows it".  But... let it be.)

Benno Schulenberg <bens>
Group administrator
Sun 12 Feb 2017 07:00:17 PM UTC, comment #2: 

Using the same syntax as in comment #0, run the following with version 2.7.4:

  src/nano --syntax=quotes +34,29 NEWS

Press <Del> to remove the leading quote of "Leuven".  See how all the text after Leuven becomes green, except Suni and Marika (you may have to PageDown to see this).  But... all the lines after the "Marika" line stay colored the way they were.  Which is wrong and confusing.

Now run the same command in git, and press <Del>.  Press <PageDown> a few times.  All the green has correctly been inverted.  Now type ^W god <Enter>.  Hey, things are still colored in a non-inverted manner.  Now type M-\, and then press and hold <PageDown> until you've reached the end of file.  Then type M-W to find god again.  Ah, now things are inversely colored everywhere.

The only way to solve that, is to recalculate the multidata for the entire file whenever the multidata of any line changes.  For now we will not take that drastic step -- with the current (and the next) commit, things work better than they did, and will be sufficient in mist cases.  I hope.  :)

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

What happens is this: when the line after the "set fill" line gets redrawn, it first looks on the preceding line, finds an unterminated start match, and then seeks for a matching end on the current line, finds it, paints the head of this line, goes on, finds a new start, and paints the tail of the line.  Then the next line gets painted: it first looks on the preceding line, finds a start match before "set nowrap", doesn't realize that in fact this is an end match, goes on, finds and end match after the "set nowrap", doesn't realize that in fact this is a start match, goes on, finds no further starts, and so concludes that there is no unterminated start before the current line.  But that is wrong.

All that it needs to do, instead of trying to find start and end matches in the preceding line, is look at the /multidata/ of the preceding line: that data contains /all/ the info that we need.  And it has the info of its preceding lines calculated into it, so the data should be fully correct.  In other words: if the multidata of the preceding line is CENDAFTER of CWHOLELINE, it means that there is an unterminated start match before the current line, and what we have to do is: look for an end match on the current line (or later lines) and /not/ first look for a start match here.

Also, if the multidata of the preceding line is CNONE or CBEGINBEFORE or CSTARTENDHERE, we know that all start matches before the current line are balanced by end matches, so we don't need to go looking for any starts on preceding lines, we can just skip ahead and look for starts on the current line.

Only when the multidata has not been initialized (like when a file has been inserted, or (shait) text has been pasted), is any backtracking from the current line needed.

Attached is a first patch that fixes this bug for some cases.  It does a way with all resetting of multidata, because it just messes things up, overwriting valid classifications for lines that scrolled off the screen at the top.

(file #39542)

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

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

syntax "quotes"
color green start=""" end="""

Then run 'src/nano --syntax=quotes +28,53 NEWS'.  The cursor sits on the "a" before "set fill".  Now press <Del> three times.  Notice how the green coloring changes but /stops/ at the end of the next line, /without/ there being any quote there.  Wrong.

Older versions of nano would swap around the green on /all/ the lines after the deleted quote.  That may seem like a waste of effort, but it is the correct thing to do.  So nano should do that again.

The offending commit is 9a4a5454.  Apparently there is something there that I'm not getting.

Benno Schulenberg <bens>
Group administrator

 

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

 

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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-02-24 bens Open/ClosedOpen Closed
        Summarythe &quot;improved&quot; painting logic has an unwanted effect adding or deleting a start/end match for a symmetrical multiline regex will not recolor all of the subsequent text
    2017-02-12 bens StatusIn Progress Fixed
    2017-01-23 bens Attached File- Added 0001-painting-make-use-of-the-multidata-of-the-preceding-.patch, #39542
        StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code