bugGNU nano - Bugs: bug #48521, whitespace at start of line is not...

 
 

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

bug #48521: whitespace at start of line is not colored consistently

Submitter:  None
Submitted:  Fri 15 Jul 2016 09:46:33 AM UTC
   
 
Severity:  3 - Normal Status:  Works For Me
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Fri 22 Jul 2016 02:37:11 PM UTC, comment #11: 

Thank you for investigating so thoroughly, and for reporting back.

(I would mark this "Not Our Bug", but Savannah doesn't know that status.)

Benno Schulenberg <bens>
Group administrator
Fri 22 Jul 2016 02:11:17 PM UTC, comment #10: 

The glitch is definitely not in nano. It was ltrace'd into a minimal reproducer for ncurses.

It only shows up on terminals based on gtk2 vte, which is unmaintained upstream. It does not show up on gtk3 vte (gnome-terminal) and on terminals that do not rely on vte (tty/xterm/konsole). So there is no need for me to bring this upstream.

Thank you for your help and your patience.

Anonymous
Mon 18 Jul 2016 07:58:38 PM UTC, comment #9: 

Further questions: what terminal are you using?  Does it also happen in xterm?  And of a VT (Ctrl+Alt+F2, for example)?

And what is your locale?  The full output of 'locale'.

Benno Schulenberg <bens>
Group administrator
Mon 18 Jul 2016 06:53:13 PM UTC, comment #8: 

If you see colors when running with --syntax=none, then it cannot be nano miscoloring things.  I begin to suspect that it is ncurses.

Please test with nano-2.4.0 and 2.5.0 and 2.5.3 also on Fedora 23.  If none of them show colors (with --syntax=none) on Fedora 23, then it is certain that the problems lies not with nano.

(By the way, do you have a 'set whitespace ...' command in your ~/.nanorc or /etc/nanorc?)

Benno Schulenberg <bens>
Group administrator
Mon 18 Jul 2016 11:16:50 AM UTC, comment #7: 

This is git bisect result, run from 2.4.0 (good) to 2.5.0 (bad) on fedora 24:


954d04bc5961afb390326333f0bc35b1e99884a5 is the first bad commit
commit 954d04bc5961afb390326333f0bc35b1e99884a5
Author: Benno Schulenberg <bensberg@justemail.net>
Date:   Sat Sep 5 09:14:24 2015 +0000

    Forcing a redraw of a line only when it contains a multicolumn character,
    as that is the only known situation where things go wrong.  This spares
    all regular text a significant slowdown.


    git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5370 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

:100644 100644 763098644f9dbd5943d5518010c39210fcd50e42 983bbe70b68786c8ec83f2b713424f47b74beab9 M        ChangeLog
:040000 040000 70e8ed53df205c032c87e42f2024f7b837b425f0 fecea2aa63847773f3478b73846e9ee7a1cb0628 M        src


Let me clarify the behavior. The spaces are not colored when I paste or load the file; as soon as the cursor is moved over any of the spaces, all of them are colored; then, 1. if the cursor is moved up/down, the spaces are uncolored, 2. instead, if the cursor is moved left/right, the spaces that are or were under the cursor are uncolored, while the others stay colored. I am not referring to the C syntax highlighting, sorry for not having emphasized it before.

This also happens when I paste into an empty buffer and haven't yet saved to a file.

This also happens when I "start nano with --syntax=none, and paste the reproducer into it", both with and without the filename.c. I don't see the C syntax highlighting, but that's not my issue actually.

I can upload the image on another website of your choice, if you prefer; I chose imgur.com as a popular image sharing website and can assure you the url is not shortened or obfuscated.

Fedora 23 is on the same machine.

Anonymous
Sat 16 Jul 2016 12:25:31 PM UTC, comment #6: 

When you paste into an empty buffer, and haven't yet saved it to a file, there should be no colors at all, because nano has not yet chosen any syntax.

If you start nano with --syntax=none, and paste the reproducer into it, do you see colors?  And if you open filename.c (with the reproducer in it) with --syntax=none, do you see colors?  And if so, what colors?

(Sorry, I'm not looking at obfuscated URLs nor at anything binary.)

Fedora 23 is on the same machine?  Can you compile 2.5.3 from source there yourself, and run src/nano with your reproducer and see what happens?

Benno Schulenberg <bens>
Group administrator
Sat 16 Jul 2016 11:53:39 AM UTC, comment #5: 

It does not happen on nano 2.4.2 + fedora 23, with the very same reproducer.

Anonymous
Sat 16 Jul 2016 11:53:22 AM UTC, comment #4: 

There are no tabs in my case, only spaces. I know that tabs are colored, but I did not expect a space-only indent to be colored as well.


Another weird thing is http://imgur.com/w7iBuKl - (there are no tabs here as well) scroll to the 'char *p' line on the first column, then move the cursor to the right along the spaces - each of them is un-colored when traversed. So the left half of the indent can be uncolored and the rightmost be colored.

Sorry for not explaining myself well, but I meant both pasting into an empty buffer (as in launching ''nano'' from the shell) and opening a filename.c file that contains the content.

Anonymous
Sat 16 Jul 2016 09:20:17 AM UTC, comment #3: 

Ah, now I get what you mean.  The whitespace before "char *p" was red instead of blank.  That is because, when using the default syntax, tabs after spaces get colored.  Press M-P (Alt+P) to see what I mean -- you have (or had) one or more spaces (·) there before a tab (»), instead of all spaces or only a tab.

Works as intended.

Benno Schulenberg <bens>
Group administrator
Fri 15 Jul 2016 10:27:20 AM UTC, comment #2: 

Paste?  But into where?  Into a blank buffer?  But then nano doesn't color anything.

Nano's chooses a syntax based on the filename extension (or on a header line, but that doesn't work for C files).  So... is your file actually called "name.c"?  Or something else?

But still, there is no syntax that colors /leading/ whitespace, so I am perplexed as to why you are seeing colors there.

Benno Schulenberg <bens>
Group administrator
Fri 15 Jul 2016 09:52:54 AM UTC, comment #1: 

Sorry, submitted without 'verbatim' tags so whitespace was swallowed. Trying to post it again, anyway it is just 4 spaces indent in the function body and 8 spaces indent in the 'for' body.


void f(char *s, ...) {
    va_list ap;
    va_start(ap,s);
    for (;;) {
        char *p = va_arg(ap,char*);
        printf("%018p, %s", p, (long)p & 255 ? p : ";");
        if(!p) break;
    }
    va_end(ap);
}


Anonymous
Fri 15 Jul 2016 09:46:33 AM UTC, original submission:  

Paste the following, scroll up and down. The leading whitespace is colored on the line 'char *p', but not on the following and preceding lines.

void f(char *s, ...) {
    va_list ap;
    va_start(ap,s);
    for (;;) {
char p = va_arg(ap,char);
        printf("%018p, %s", p, (long)p & 255 ? p : ";");
        if(!p) break;
    }
    va_end(ap);
}


nano 2.5.3 + fedora 24 + xfce4-terminal

Anonymous

 

(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 (Posted a comment)
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-29 bens Open/ClosedOpen Closed
    2016-07-22 bens StatusNeed Info Works For Me
        Assigned toNone bens
    2016-07-18 bens StatusInvalid Need Info
    2016-07-16 bens StatusNeed Info Invalid
    2016-07-15 bens StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code