bugGNU nano - Bugs: bug #50787, titlecolor not respected on Alpine...

 
 

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

bug #50787: titlecolor not respected on Alpine when invoked with file argument, until a full screen refresh

Submitter:  avih <avih>
Submitted:  Wed 12 Apr 2017 08:49:50 AM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Fri 05 May 2017 09:18:59 AM UTC, comment #25: 

Released in 2.8.2.  Thanks again for reporting.

Benno Schulenberg <bens>
Group administrator
Mon 17 Apr 2017 08:15:31 PM UTC, comment #24: 


> Ah! Okay! From your use of the word "reversed" in comment #2 I had understood that somehow nano used the default inverse video when the bug showed itself.


Well, I can't repeat the (always same) bug symptoms on every comment ;)

Initial report :

> I have ~/.nanorc containing the following two lines only ...
> When nano is invoked without any arguments, the title color is correct - black on green.
> When nano is invoked with a file name (tested few), e.g. "nano ~/.nanorc" then the title color is same as the edited file - white on black.


Comment 2 added that without setting custom colors, the bug didn't manifest. I.e. the correct default title colors (reverse attribute, visible as black on white) were always displayed correctly.

But anyway, I've seen worse communications in the past ;) Glad we got past it, and that eventually (with the additional/corrected message info) it matched your expectations.

Thanks for taking care of it!

avih <avih>
Mon 17 Apr 2017 07:27:21 PM UTC, comment #23: 


> The right status message was (is, I'm literally copying it now
> from nano which has the no-info patch applied) "[ Read 40152
> lines (Converted from DOS and Mac format) ]"


Ah, okay: a non-Unix file.  That was expected: the "no-info" patch suppressed statusbar output just for Unix files.

> The TL;DR of my description is that with the "no-info" patch:
> - The bug is fixed when I loaded a small file
> - The bug was not fixed when I loaded a big (binary) file.


A more correct description would be: miscoloration did not show itself with a Unix file, but did show with a non-Unix file.

> No. same symptoms as I described initially for the bug - the title
> is indistinguishable from the text (color/bold/inverse wise).


Ah!  Okay!  From your use of the word "reversed" in comment #2 I had understood that somehow nano used the default inverse video when the bug showed itself.  Okay, got it now.

> Right, indeed confirmed fixed with clean git-master 700c5c93 for
> my 3 test cases: no file, small file, and big file.


Thanks for confirming, and for reporting in the first place.  :)

(For completeness: the commit that fixed this is b98545f4.)

Benno Schulenberg <bens>
Group administrator
Mon 17 Apr 2017 06:23:45 PM UTC, comment #22: 


> Huh? If the "no-info" patch was applied, it should never show the "Reading File" message, no matter how big the file is.


Right, apologies, I indeed described the wrong message.

The right status message was (is, I'm literally copying it now from nano which has the no-info patch applied) "[ Read 40152 lines (Converted from DOS and Mac format) ]" - this is a binary file.

Other than that though, the rest was described correctly.

The TL;DR of my description is that with the "no-info" patch:
- The bug is fixed when I loaded a small file
- The bug was not fixed when I loaded a big (binary) file.

Specifically:

> Are you sure you were running the patched nano and not an unpatched one?


Yes.

> > Same symptoms too - titlebar has the same colors as the content.


> To be sure: with "same colors" you the same colors but in inverse video? Because when the titlecolor colors don't apply, and --boldtext is not used, then the titlebar should be in inverse video.


No. same symptoms as I described initially for the bug - the title is indistinguishable from the text (color/bold/inverse wise). I.e. if I didn't know the top line is nano's title, I could have mistaken it to be part of the content (the file I'm editing).

In my terminal which is white text on black background, where nano shows the loaded file's content with those colors, on this case (big file where the bug is not fixed) the title has exactly the same attributes too as the content - white text on black background, not bold and not inverse.

> Anyway, I have added a doupdate() in titlebar() in git


Right, indeed confirmed fixed with clean git-master 700c5c93 for my 3 test cases: no file, small file, and big file.

> My machine has just 1G, and a little Atom processor, so I'm not going to try any VM stuff


I just tried it (with the x86 image) in a VM with 384M ram and a single weak core, and the procedure I described still works ;) (however, 256M ram was too little. ./configure completed but then it ran out of space I think while compiling gnulib).


avih <avih>
Mon 17 Apr 2017 09:16:36 AM UTC, comment #21: 
  • "you the same" => "you mean the same"
Benno Schulenberg <bens>
Group administrator
Mon 17 Apr 2017 09:15:37 AM UTC, comment #20: 


> However, since I had the big file invocation at my shell history,
> I tried that too, and on this case the bug was not fixed (and
> the "Reading file" status was displayed).


Huh?  If the "no-info" patch was applied, it should never show the "Reading File" message, no matter how big the file is.  Are you sure you were running the patched nano and not an unpatched one?

> Same symptoms too - titlebar has the same colors as the content.


To be sure: with "same colors" you the same colors but in inverse video?  Because when the titlecolor colors don't apply, and --boldtext is not used, then the titlebar should be in inverse video.

Anyway, I have added a doupdate() in titlebar() in git.  It doesn't do any harm.  And when loading a file of half a million lines (and using a syntax with multiline regexes), then the titlebar will appear a little earlier than without this doupdate(), and I kind of like that -- it shows how much time it takes to precalculate the multicolor info.

So, I think this bug should be "fixed" now -- that is: the bug in ncurses/musl has been worked around by nano.

(My machine has just 1G, and a little Atom processor, so I'm not going to try any VM stuff.  :)  And I don't have a spare USB stick to play with at the moment.  And I don't need to: if you say that the extra doupdate() fixes it, that's good enough for me.)

Benno Schulenberg <bens>
Group administrator
Fri 14 Apr 2017 10:20:47 PM UTC, comment #19: 

FWIW, if you feel adventurous and want to try/debug it yourself, here are exact steps to get there in a VM or actual system without touching its HDD, which should take less than 5 minutes if everything works as expected:

- Download alpine-vanilla-3.5.2-x86_64.iso (80M) from https://alpinelinux.org/downloads/
- Boot it in a [V]M with an ethernet card. No HDD required (live CD). I have 2G ram.

- Login as root (no password). You're now in a Busybox (ash) shell and have vi.
- "setup-interfaces" (then enter, enter, enter to setup eth0 and dhcp).
- "ifup eth0" which should report the dhcp lease if successful.
- "echo http://nl.alpinelinux.org/alpine/v3.5/main >> /etc/apk/repositories"
- "apk update && apk add build-base ncurses-dev" to install the build deps.
- "wget http://ftp.gnu.org/gnu/nano/nano-2.8.1.tar.gz"
- "tar xvf nano-2.8.1.tar.gz && cd nano-2.8.1"
- "./configure && make"

The resulting ./src/nano should now exhibit the issue.

- Feel free to add other useful tools, e.g. "apk add bash vim git gdb strace"
- Find more available packages e.g. "apk search gnu"

avih <avih>
Fri 14 Apr 2017 08:43:57 PM UTC, comment #18: 


> Try loading a file that consists of a few hundred thousand lines ... Without the doupdate(), you are staring at a blank screen ... With the doupdate(), you see the message "Reading File" ...


Indeed, I observe the same and now understand where the removal makes a difference.


>  try the first of the two attached patches (the "no-info" patch) -- it simply prevents any data being written to the statusbar before drawing the titlebar. With it, the titlebar should always have the correct color on your system. Yes?


Almost :)

When invoking with a small file such as ~/.nanorc, the problem is indeed fixed and the titlebar colors are correct.

However, since I had the big file invocation at my shell history, I tried that too, and on this case the bug was not fixed (and the "Reading file" status was displayed). Same symptoms too - titlebar has the same colors as the content.


> Then undo that patch and try the second one (the "pause" patch) -- it pauses for a second and a half after drawing the titlebar, so you can verify that the bar has the right color straightaway and does not acquire it by a later doupdate(). Right?


Not sure. Here's what I see:

- When invoking with a small file, I right away see the title with the correct colors, and the statusbar ("[ Read 3 lines ]") with its correct colors and nothing else. I.e. other than the title and status it's a blank screen. No "shortcuts toolbar" at the bottom, no file content, etc. 1.5s later I see the rest.


- When invoked with a big file, I observe the following sequence of events:

1. I see a status message of "[ Reading file ]" but otherwise the screen is completely blank. No title or titlebar, no "shortcuts toolbar" below the statusbar, no file content, etc. Just status message in correct colors on a blank screen.

2. Shortly (~300 ms - till the file got read) afterwards I see the final title and status message, each with its correct respective colors. Same as when invoking with the short file, the screen is otherwise blank - it contains perfect title and statusbar on an otherwise blank screen with no content or "shortcuts toolbar" at the bottom.

3. 1.5s later the content and the bottom "shortcuts toolbar" appear, but otherwise the title and statusbar are unmodified (and correct, color and content wise).

avih <avih>
Fri 14 Apr 2017 07:59:34 PM UTC, comment #17: 

If you remove the doupdate() call in statusbar(), of course things will still work correctly -- they did so before.  The doupdate() call was added there for a specific reason: to get an informative message to the screen straighaway at startup.  Try loading a file that consists of a few hundred thousand lines -- a giant log file is a common case.  Without the doupdate(), you are  staring at a blank screen and are left wondering what is happening.  With the doupdate(), you see the message "Reading File", and you know you have to be patient.

(Oops: I meant commit cc2d3705 -- the first "c" was dropped earlier.)

(Yes, any promptbar has the same color as the titlebar, not the same color as a message on the statusbar -- this is to help distinguish a prompt from a message.  We could have chosen to allow configuring a third color, but... better not.)

No, the fully-redraw-topline.patch did not have the desired result.  Okay, try the first of the two attached patches (the "no-info" patch) -- it simply prevents any data being written to the statusbar before drawing the titlebar.  With it, the titlebar should always have the correct color on your system.  Yes?

Then undo that patch and try the second one (the "pause" patch) -- it pauses for a second and a half after drawing the titlebar, so you can verify that the bar has the right color straightaway and does not acquire it by a later doupdate().  Right?

(file #40408, file #40409)

Benno Schulenberg <bens>
Group administrator
Fri 14 Apr 2017 04:38:40 PM UTC, comment #16: 


> When pressing ^W to search, the statusbar changes correctly to the search prompt (and correct colors everywhere). Typing text updates the statusbar correctly while typing.


When I wrote this, I had the titlecolor and statuscolor configured identically, and so couldn't see which config colors it was using.

I now configured them differently, and now I see that the search prompt uses the titlecolor values. So except for the prompt (and the text typed into it) which uses the titlecolor, the rest of the messages which I described earlier are using the correct different statuscolor.

This seems to also be the behavior of a clean nano build, so my previous observation that everything behaved correctly (fixed) with doupdate() removed from statusline(...) still stands.

avih <avih>
Fri 14 Apr 2017 04:19:20 PM UTC, comment #15: 


> So... instead of the other patches, please try the attached one


With only 40406-full-redraw-topline.patch: Not fixed.

> ... just to see if my suspicion is correct.


Not sure I got which result would confirm it, so you could say anything you want ;)

As a further attempt, I then reverted this patch and got back to clean git b7166d5c, and then I removed "doupdate();" at winio.c:2177 (inside the statusline function), and now everything seems OK both on startup and also later:

- When invoked without arguments: titlebar colors are OK and no status message (as expected).

- When invoked with a file argument: titlebar colors are correct, and there's also a statusbar message (number of read lines) with correct colors. That was the symptom of the issue, and now it's fine.

- When pressing ^W to search, the statusbar changes correctly to the search prompt (and correct colors everywhere). Typing text updates the statusbar correctly while typing.

- Exiting a search with ^C: updated correctly to a "[ Canceled ]" message.

- Performing the search with Enter for a non-existing string: statusbar updated correctly with "[ ... not found ]".

- Performing the search with Enter for an existing string moved the cursor to the correct position and cleaned the statusbar correctly.

- During all this time the titlebar colors were correct, as well as the statusbar colors (when there's a status message).


I'm not at all suggesting I know why removing the doupdate() call inside statusline(..)  works, but as far as I can tell, it does.

avih <avih>
Fri 14 Apr 2017 09:18:35 AM UTC, comment #14: 

Thanks for finding the exact commit.  To be precise, though: commit c2d3705 did not "introduce" the issue -- it merely /exposed/ the issue.

You see, it cannot be a race issue, because nano is a single thread.  And it cannot be an ordering issue, because all that the above commit does is /add/ a doupdate() call -- it doesn't reorder the calls and it doesn't remove any calls (even though it may look like that).  All that the commit does is add a doupdate() earlier in the process, and as a consequence a /later/ doupdate() does something /different/ and fails to work correctly.  This is absurd and clearly a bug in ncurses.  It reminds me of bug #31743.  So... instead of the other patches, please try the attached one, just to see if my suspicion is correct.

(file #40406)

Benno Schulenberg <bens>
Group administrator
Thu 13 Apr 2017 07:08:17 PM UTC, comment #13: 

Sorry for the spam, but it might be worth reconsidering the data points we have:

- When invoked without arguments, the title colors are correct (and the title is not empty - it shows nano's version and "empty buffer"), and there's no status message.

- When invoked with a file argument, we have the bug - the (non empty) title uses the default content colors (so indistinguishable from the content - colors wise), and there is a status message "[ Read 3 lines]".

- The issue was introduced in a commit titled "Updating the screen immediately when a message is posted on the status bar."

In my very humble opinion, and as someone which doesn't know the codebase at all, these facts might also suggest a race or ordering issue at the nano code, i.e. not necessarily an ncurses+musl issue.

avih <avih>
Thu 13 Apr 2017 06:53:39 PM UTC, comment #12: 


>> If you can, please test also with at least 2.5.3. If that version works okay, you may want to bisect.
> Same issue also with 2.5.3 ...


Well.. while the above is correct, 2.4.3 doesn't have the bug, and neither does 2.5.1 .

The issue was introduced on 2.5.2, and more specifically (after bisection) on git-cc2d3705 "Updating the screen immediately when a message is posted on the status bar."

FYI.

avih <avih>
Thu 13 Apr 2017 06:06:26 PM UTC, comment #11: 


> But maybe it has something to with having two versions of ncurses on your system...?


No, as far as I can tell this is not an issue, or at least the same symptoms still exists with only one version of ncurses.

I verified it by booting the Alpine 3.5.2 official standard ISO as a live CD, then added the latest nano package from the Edge repository (2.8.1), which also pulls ncurses version 6 and that's it, and the problem still exists.

avih <avih>
Wed 12 Apr 2017 06:49:11 PM UTC, comment #10: 

My suspicion is that it's a flaw in ncurses that gets exposed when running on musl.  But maybe it has something to with having two versions of ncurses on your system...?

Anyway, first I'm going to fiddle a bit with things -- because all these reset_cursors and wnoutrefreshes seem superfluous.  I'll try and trim those down first, and then will return here later.

Benno Schulenberg <bens>
Group administrator
Wed 12 Apr 2017 04:01:26 PM UTC, comment #9: 


> Is there a simple way to detect that nano is being compiled on Alpine or musl? ...



I'm speaking for neither musl nor Alpine, but as far as I know - no (I think musl is even explicitly opposing such usage).

My suggestion:
- Please summarize your suspicions and ad-hoc workaround.
- I'll try to bring this summary to musl's author, if relevant.
- I'll post here if I get anywhere meaningful (not guaranteed).

Alpine can either use the workaround patch for its own build, or just ignore the issue considering its low impact (my assessment). In any case, this ticket can serve as reference.

Sounds reasonable?

Regardless, I appreciate your time and help.


avih <avih>
Wed 12 Apr 2017 03:39:22 PM UTC, comment #8: 

Is there a simple way to detect that nano is being compiled on Alpine or musl?  So that we can do something like:

#ifdef USING_MUSL
    doupdate();
#endif.

Benno Schulenberg <bens>
Group administrator
Wed 12 Apr 2017 03:08:44 PM UTC, comment #7: 

Same base setup as before without the previous patches.

- With 40374-trim-titlefunc.patch: Not fixed.
- With 40375-later-update.patch: Fixed.

avih <avih>
Wed 12 Apr 2017 02:57:24 PM UTC, comment #6: 

Instead of the previous two patches, please try the attached two.  First the "trim" one, and if that does not avoid the issue, then the "later" one instead.

(file #40374, file #40375)

Benno Schulenberg <bens>
Group administrator
Wed 12 Apr 2017 12:06:49 PM UTC, comment #5: 

Thanks for the quick reply.

I did have a /etc/nanorc but everything in it is commented out. Nevertheless, I removed it and made sure the issue still exist.

The following tests are with nano git master b7166d5c, without /etc/nanorc, and with ~/.nanorc the same as at the initial report:

- Only with 40373-force-update.patch: Fixed.
- Only with 40372-blank-bar-twice.patch: Not fixed.
- With both: Fixed.

So it seems 40373-force-update.patch alone is enough to fix the issue on this system. The other patch seemingly has no effect.

avih <avih>
Wed 12 Apr 2017 11:47:12 AM UTC, comment #4: 

Yes, I suspected the problem is limited to Alpine Linux, because it uses musl.  It is probably some misinteraction between musl and ncurses.

Okay, Ctrl+L gives the correct colors.  So it is some "startup" problem -- it seems the cursor must have moved around a bit before the top row will be drawn correctly.  Please try current git with the attached two patches, first the one, then the other, then both.

> if I remove the titlecolor line from ~/.nanorc, then
> it does show correctly (black on white - reversed)


That is weird: attribute setting works straightaway, but not when color is involved.  :|  This is not a bug in nano -- all we can do is try and work around it.

Do you have an /etc/nanorc on your Alpine install?  If so, please move it out of the way so you really get only your ~/.nanorc.

(file #40372, file #40373)

Benno Schulenberg <bens>
Group administrator
Wed 12 Apr 2017 11:06:38 AM UTC, comment #3: 

I just tested it also on Ubuntu 16.04.2 LTS, and it does NOT have the issue. I tested the pre-packaged nano (2.5.3) and also compiled the latest git-master and on both cases the title colors are correct also when invoking with a file argument and without the need to resize or ^L .

Considering I can only observe the issue with Alpine-linux, and that even on this system the default colors work well, and it also exist with nano 2.5.3 on this system, it seems the issue is more limited than I thought initially, possibly specific to this system, and therefore should not be considered high priority.

Sorry for the false alarm.

That being said, I'm still available for further analysis if you can guide me.

avih <avih>
Wed 12 Apr 2017 10:41:18 AM UTC, comment #2: 


> When you invoke nano with a file argument and you type ^L, does the titlebar then acquire the correct color?


Yes, ctrl+l also fixes the colors (without needing to resize the terminal).


> What version of ncurses is used on your system? What is the exact default size of your terminal (stty size)? What is your locale (locale)?


$ stty size
(xfce4-terminal or st:) 24 80
(when ssh from windows:) 43 122

Locale: I didn't set a system locale and I'm using the system as English-only (with en-US KB FWIW). LC_LANG and LC_ALL are not set. I tried also the following invocations prefixes (e.g. "LC_ALL=C nano ~/.nanorc"), and the issue is still not fixed:
LC_ALL=C
LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8

ncurses: It seems 6.0-r7 (pre-packaged) for "ncurses", "ncurses-libs", "ncurses-dev" and "ncurses-static", and I also have "ncurses5-libs" which is seemingly version 5.9-r1. FWIW, the ncurses 6.0-r7 build file is https://git.alpinelinux.org/cgit/aports/tree/main/ncurses/APKBUILD?id=6d539efc7cd7c6d419ebde10c222be8f3f04938b (I haven't built it myself but supposedly I'm using its output).

The output from ./configure (with git-master) for ncurses is:
Using ncursesw as the curses library
checking for use_default_colors in -lncursesw... yes
checking for set_escdelay in -lncursesw... yes
checking for key_defined in -lncursesw... yes


> If you can, please test also with at least 2.5.3. If that version works okay, you may want to bisect.


Same issue also with 2.5.3 (with git-162d534f: ./autogen.sh && ./configure && make). ctrl+l or resize fixes it here too. (off topic - both autogen, configure and make are so much shorter and faster than with 2.8.0 ... yes, I know why.. just saying ;) ).


Probably worth noting which I omitted from the original report, if I remove the titlecolor line from ~/.nanorc, then it does show correctly (black on white - reversed) also when invoked with a file argument. All my terminals are set/default to white text on black background.

avih <avih>
Wed 12 Apr 2017 09:50:00 AM UTC, comment #1: 

When you invoke nano with a file argument and you type ^L, does the titlebar then acquire the correct color?

What version of ncurses is used on your system?  What is the exact default size of your terminal (stty size)?  What is your locale (locale)?

If you can, please test also with at least 2.5.3.  If that version works okay, you may want to bisect.

Benno Schulenberg <bens>
Group administrator
Wed 12 Apr 2017 08:49:50 AM UTC, original submission:  

This issue exists with nano 2.8.0 as well as with current git-master 1e8f6fd7 (bump version to 2.8.1). I didn't test prior versions. Tested on Alpine-linux (Edge).

I have ~/.nanorc containing the following two lines only:

set titlecolor black,green
set statuscolor black,green

When nano is invoked without any arguments, the title color is correct - black on green.

When nano is invoked with a file name (tested few), e.g. "nano ~/.nanorc" then the title color is same as the edited file - white on black.

Resizing the terminal makes the title get the correct colors, and it seems to stay correct until nano is closed.

This was tested with few terminals (xfce4-terminal, st, others).

The (bottom) statuscolor does not seem to be affected by this issue.

avih <avih>

 

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

Attached Files
file #40408:  no-info.patch added by bens (998B - text/x-diff)
file #40409:  pause-after-update.patch added by bens (322B - text/x-diff)
file #40406:  fully-redraw-topline.patch added by bens (324B - text/x-diff)
file #40374:  trim-titlefunc.patch added by bens (356B - text/x-diff)
file #40375:  later-update.patch added by bens (373B - text/x-diff)
file #40372:  blank-bar-twice.patch added by bens (325B - text/x-diff)
file #40373:  force-update.patch added by bens (312B - text/x-diff)

 

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)
  • -email is unavailable- added by avih (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 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-05 bens Open/ClosedOpen Closed
    2017-04-17 bens StatusIn Progress Fixed
    2017-04-17 bens Severity3 - Normal 2 - Minor
    2017-04-14 bens Attached File- Added no-info.patch, #40408
        Attached File- Added pause-after-update.patch, #40409
    2017-04-14 bens Attached File- Added fully-redraw-topline.patch, #40406
    2017-04-12 bens Attached File- Added trim-titlefunc.patch, #40374
        Attached File- Added later-update.patch, #40375
        StatusNone In Progress
        Assigned toNone bens
    2017-04-12 bens Attached File- Added blank-bar-twice.patch, #40372
        Attached File- Added force-update.patch, #40373
        Summarytitlecolor config not respected until the terminal is resized when invoked with file argument titlecolor not respected on Alpine when invoked with file argument, until a full screen refresh

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code