bugGNU nano - Bugs: bug #41313, too greedy Python docstring...


bug #41313: too greedy Python docstring highlighting

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Wed 22 Jan 2014 08:44:44 PM UTC  
Severity:  3 - Normal Status:  Duplicate
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.


( Jump to the original submission)

Sat 18 Jul 2015 07:39:22 AM UTC, comment #12:

The basic issue has been fixed in SVN, r5307. The fix should appear in nano-2.4.3.

If with that version you still have any problems with multiline-regex highlighting, please report another bug.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 11 Jul 2015 06:56:55 AM UTC, comment #11:

The underlying issue has been re-reported as bug #45525. See the patch there for a fix. If you could test that patch, that would be great.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Tue 21 Apr 2015 04:57:49 PM UTC, comment #10:


I'd like to confirm/second Cody A. Taylor's comment. This get's basically fixed by using the python.nanorc from v2.2.6.

So why not simply include this. It's much better than the current one which is not usable (by "not usable" I mean the described problem) + I don't see any benefit from it...

Tested/working on Arch Linux.


- Happy nano user using nano for everything

Cem Aydin <rebootl>
Wed 25 Mar 2015 03:44:41 PM UTC, comment #9:

"Misolorations"? Oh dear, that is fishy. :)

"The miscolorations are an inherent problem..." is what I meant, of course.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 23 Mar 2015 12:51:43 PM UTC, comment #8:

The misolorations are inherent problem of multiline regexes where the start and stop strings are the same (or very nearly the same). For a more detailed discussion see bug #26762.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 23 Mar 2015 12:22:30 PM UTC, comment #7:

Well, there is a patch for that, but it is costly: it reevaluates the multiline regexes for the whole file for every single edit. On a large file this will probably cause some slowdown. (With src/text.c, 3480 lines, I /think/ to notice a small delay.)

Please test and see how you fare, and please report back.

(file #33430)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 22 Mar 2015 09:32:11 PM UTC, comment #6:

Attached example for faulty Syntax highlighting (mesed_up.py)

Thu 22 Jan 2015 05:18:36 AM UTC, comment #5:

After a bit more investigation it seems to be nanorc dependent.

This works well (and is in the 2.2.6 release):

The downfall being the starting sequence must be followed by a non-newline character. I think that's a small price to pay to allow you have the rest of your syntax highlighting rules. If you really hate using the first line of your docstring you can always use """\ to enable the regex.

Cody A. Taylor <code_m>
Wed 21 Jan 2015 09:11:35 PM UTC, comment #4:

Do you mean you don't see the problem with 2.2.6 with its native python.nanorc? And with 2.3.99 with itsnative pyhton.nanorc? Or do you use the same nanorc for running both version of nano? If not, could you try? And try running 2.2.6 with the pyhton.nanorc from 2.3.99, and the other way around?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Tue 20 Jan 2015 05:51:31 PM UTC, comment #3:

I've been having this trouble with the latest svn version (2.3.99pre1-svn revision 5104).

Meanwhile if I run version 2.2.6 on the same file I don't experience this issue.

Cody A. Taylor <code_m>
Wed 26 Feb 2014 01:10:30 PM UTC, comment #2:

Currently the regexes for triple-quoted strings are like this:

color brightgreen start="\"\"\"[^"]" end="\"\"\""
color brightgreen start="\'\'\'[^']" end="\'\'\'"

I suggest to change them to this:

color brightgreen start="\"\"\"[^"),]" end="[^(]?\"\"\""
color brightgreen start="\'\'\'[^'),]" end="[^(]?\'\'\'"

This improves the colouring (reduces spillover) in one case: passing multiline strings as function arguments.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Tue 25 Feb 2014 02:23:04 AM UTC, comment #1:

This can never be implemented properly with nano's current syntax highlighting engine. I've written nanorc files for a few dozen languages already, and this was the only case where I concluded that no highlighting at all was better than a workaround. Not to be dismissive of nano, but the real fix is to use an editor that does full lexical analysis instead of regex matching.

Wed 22 Jan 2014 08:44:44 PM UTC, original submission:

When a Python file contains at least two docstrings, things
after the first docstring and before the last docstring which
are on the same line as any docstrings itself get coloured
mistakenly as brightgreen too.

Then deleting any line (^K) in the file between any pair of docstrings, causes all the text between the first and last docstrings to be coloured brightgreen.

See attached example file -- which does not contain actually
docstrings, but short strings to show the problem clearly.

(This was also reported as bug #34323, probably, because I
can't see the screenshots.)

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 Files:

Attached Files
file #33430:  recolor-on-every-edit.patch added by bens (877B - text/x-diff - patch to avoid miscolorations)
file #33425:  messed_up.py added by None (147B - document/unknown - Example for faulty syntax coloring (since v2.3.6))
file #30350:  whoops.py added by bens (167B - text/x-python - example file that shows too greedy string colouring)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rebootl (Posted a comment)
  • -email is unavailable- added by code_m (Posted a comment)
  • -email is unavailable- added by bens (Submitted the item)

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

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-07 bens Open/ClosedOpen => Closed
    2015-07-11 bens StatusNeed Info => Duplicate
    2015-03-25 bens StatusNone => Need Info
    2015-03-23 bens Attached File- => Added recolor-on-every-edit.patch, #33430
    2015-03-22 None Attached File- => Added messed_up.py, #33425
    2014-02-26 bens Assigned toNone => bens
    2014-01-22 bens Attached File- => Added whoops.py, #30350

    Back to the top

    Powered by Savane 3.3