bugGNU nano - Bugs: bug #45525, multiline regexes are too greedy

 
 

bug #45525: multiline regexes are too greedy

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Fri 10 Jul 2015 08:36: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.

 

Sat 18 Jul 2015 07:40:41 AM UTC, comment #3:

A further improved patch went into SVN, r5307.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 10 Jul 2015 09:14:05 PM UTC, comment #2:

Okay, I think I've got it fixed. See attached patch.

(file #34421)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 10 Jul 2015 08:38:32 PM UTC, comment #1:

Oh, the line should be:

syntax "strings"

It doesn't work without the quotes. :|

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 10 Jul 2015 08:36:26 PM UTC, original submission:

Add the following two lines to your .nanorc file:

syntax strings
color green start="'" end="'"

Then start nano with 'nano xxx -Y strings' and type the following three lines:

before 'first' after
middle
before 'second' after

In my opinion, only the words first and second should be coloured green, and all the other words not. But currently nano will colour also the words after "first" and on the same line green, and the words before "second" and on the same line, and often also all the lines in between (depending on whether you've just loaded the file or made an edit in one of the affected lines).

It seems that this is caused by nano searching, when it has already found a match for the end regex, for more matches for the start regex, starting at where it found the last start. But it shouldn't start there; it should start looking only after the found end. Any other start between the found start and the found end is irrelevant. And certainly when it has categorized a match as an end, it should not consider this any more as a possible start too.

Well... maybe the matching code still does the right thing, but when the time comes to actually colour the line, the end is also seen as matching a start, so colouring starts there again too.

(This issue was originally reported as bug #41313, but there the basic problem got snowed under.)

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:
   

Attached Files

 

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

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 07 Dec 2015 03:14:31 PM UTCbensOpen/ClosedOpen=>Closed
    Sat 18 Jul 2015 07:40:41 AM UTCbensStatusIn Progress=>Fixed
    Sat 11 Jul 2015 07:12:48 AM UTCbensStatusNone=>In Progress
      Assigned toNone=>bens
    Fri 10 Jul 2015 09:14:05 PM UTCbensAttached File-=>Added fencing-in-the-matches.patch, #34421

    Back to the top


    Powered by Savane 3.1-cleanup1