On some terminals cursor invisible on tabs and trailing spaces

[Hubbitus]

Plese refer to ​https://bugzilla.redhat.com/show_bug.cgi?id=461366 for more information.

Please attention to:
​https://bugzilla.redhat.com/show_bug.cgi?id=461366#c17 - testet terminal (emulators)
​https://bugzilla.redhat.com/show_bug.cgi?id=461366#c20 - adding [Colors] sections helps.

So, now need fixing default color scheme for capability with wide range of terminals.

[slavazanko]

created branch 385_fix_color_of_tabs_and_spaces (parent: master)

Initial commit: changeset:13d8d4e7ce6fc69582c0ac80e7f66e81dfec778b

Review&vote, please.

[ossi]

this gets a clear reject from me. i made the color intentionally as subtle as possible, otherwise the feature gets plain annoying. it's not mc's responsibility to work around people's badly configured displays (the balance of contrast and brightness makes a *huge* difference) and terminals with totally braindead color schemes (which don't resemble the ANSI color values even remotely).
fwiw, it is possible to force xterm not to use the current character cell's inverted colors for the cursor. not sure it is possible via an escape sequence, though. somebody needs to read some docs ...

[Hubbitus]

Replying to ossi:

this gets a clear reject from me. i made the color intentionally as subtle as possible, otherwise the feature gets plain annoying. it's not mc's responsibility to work around people's badly configured displays (the balance of contrast and brightness makes a *huge* difference)

Contrast and brightness balance there absolutely have no sense. I test it on My Fedora 9 with old CRT display and different brightness/contrast settings and on My notebook with fully updated Fedora 10 on TFT matrix - result the same - cursor invisible. This is very enrages.

and terminals with totally braindead color schemes (which don't resemble the ANSI color values even remotely).

As mentioned before there also standard Linux text console too (even without any X server). So, I think if it have bugs there bug in Lunux kernel by your things?

fwiw, it is possible to force xterm not to use the current character cell's inverted colors for the cursor. not sure it is possible via an escape sequence, though. somebody needs to read some docs ...

I compleatly do not known *HOW* fix this bug. May be it is possible using termcap and determinate can terminal use this color or not, and dependently form it set color lightblue, or other (green, black or something else)? What you think?

[Hubbitus]

Additionaly I think "editwhitespace=black,blue" seen more esthetic. In case the "true" resolve of error will not be found.

[Hubbitus]

Sorry, sorry. I mean "editwhitespace=green,blue" in post before!

[ossi]

Replying to Hubbitus:

Contrast and brightness balance there absolutely have no sense. I test it on My Fedora 9 with old CRT display and different brightness/contrast settings and on My notebook with fully updated Fedora 10 on TFT matrix - result the same - cursor invisible.

cheapo TFTs certainly often fall under the "badly configured" category, i.e., they just suck.
to check whether your settings are ok in the low-brightness range, see this screenshot: ​http://techbase.kde.org/images.techbase/c/c4/SchemeMidnightMeadow.png - if you don't see the line edits in it, then you have a problem.

As mentioned before there also standard Linux text console too (even without any X server).

it works just as it is supposed to do in a linux console (tested without a framebuffer console).
konsole's default color scheme is braindead - the first thing i do is switching to linux colors, which then works just as good as in a real linux console. it looks similar to the first screenshot posted to the linked redhat bug, though xterm's default scheme uses somewhat overdriven colors as well.

having said all that, i'm all for making the cursor (even ;) more visible, but not at the cost of changing the colors of the whitespace visualizers.

fwiw, 1-2 years ago xterm did indeed have a bug where the cursor did rather bizarre things under mc, but that's been fixed since.

for reference, here are my relevant xterm-related Xresources:

XTerm*boldMode: false
XTerm*colorBDMode: true
XTerm*colorBD: #FFFFFF
XTerm*background: #000000
XTerm*foreground: #B2B2B2
XTerm*color0: #000000
XTerm*color1: #B20000
XTerm*color2: #00B200
XTerm*color3: #C07000
XTerm*color4: #0000B2
XTerm*color5: #B200B2
XTerm*color6: #00B2B2
XTerm*color7: #B2B2B2
XTerm*color8: #545454
XTerm*color9: #FF0054
XTerm*color10: #00FF54
XTerm*color11: #FFFF54
XTerm*color12: #0000FF
XTerm*color13: #FF00FF
XTerm*color14: #00FFFF
XTerm*color15: #FFFFFF

[winnie]

I also think that this is nothing for us.. it seems to be a bug in several konsole clients, there was also a report in debian (see #469251), but this was related to a bug in gnome-terminal.

I would suggest to close this as invalid.

[Hubbitus]

Replying to ossi:

cheapo TFTs certainly often fall under the "badly configured" category, i.e., they just suck.
to check whether your settings are ok in the low-brightness range, see this screenshot: ​http://techbase.kde.org/images.techbase/c/c4/SchemeMidnightMeadow.png - if you don't see the line edits in it, then you have a problem.

I thought I see all (now on CRT display Samsung SyncMaster? 755df where I have not any troubles in other applications except mc). But mey be I misunderstood you? What exactly I can see on this test and where?

As mentioned before there also standard Linux text console too (even without any X server).

it works just as it is supposed to do in a linux console (tested without a framebuffer console).

I'm also test without frame buffer. And really supposed disappearing current editing position cursor?? Slava also confirm it (please see post in Fedora Bugzilla).

konsole's default color scheme is braindead - the first thing i do is switching to linux colors, which then works just as good as in a real linux console.

We speak not about Konsole one. And real linux console also do not work properly, as I mention above.

having said all that, i'm all for making the cursor (even ;) more visible, but not at the cost of changing the colors of the whitespace visualizers.

Ok. Can we saparately change cursor color on separate visualizers?

fwiw, 1-2 years ago xterm did indeed have a bug where the cursor did rather bizarre things under mc, but that's been fixed since.

for reference, here are my relevant xterm-related Xresources:

Sorry, I do not uderstand this. What is it?

And what more I think. You want 'lightblue tab visualiser on standard blue background'. And what color of cursor must be by you idea?
I can make screenshots on all tested terminal emulators (except Linux text console because don't know how do it, or even can do it in Virtual machine, if you want).

[ossi]

Replying to Hubbitus:

Replying to ossi:

to check whether your settings are ok in the low-brightness range, see this screenshot: ​http://techbase.kde.org/images.techbase/c/c4/SchemeMidnightMeadow.png - if you don't see the line edits in it, then you have a problem.

I thought I see all (...). But mey be I misunderstood you? What exactly I can see on this test and where?

just compare with a lighter, higher-contrast scheme like ​http://techbase.kde.org/images.techbase/6/6f/SchemeChrome.png - if there are any features which you don't see in the darker one, then you have a problem.

Ok. Can we saparately change cursor color on separate visualizers?

see my very first comment.

for reference, here are my relevant xterm-related Xresources:

Sorry, I do not uderstand this. What is it?

X configuration data. ;)
"man xrdb" is a good starting point.

You want 'lightblue tab visualiser on standard blue background'.

yes

And what color of cursor must be by you idea?

i don't mind. i guess standard blue characters in a gray block (i.e., like it is without any highlighting) would be just fine.

[Hubbitus]

Replying to ossi:

just compare with a lighter, higher-contrast scheme like ​http://techbase.kde.org/images.techbase/6/6f/SchemeChrome.png - if there are any features which you don't see in the darker one, then you have a problem.

This is not such horrible as previous one :) And yes, I see all components on both screenshots.

Ok. Can we saparately change cursor color on separate visualizers?

see my very first comment.

About read docs and change default color scheme for terminal emulator??? Yes, It helps (as mentioned, ROXTerm shows cursor position in "GTK" color scheme oppositee to "Default"), but really it is intended for users change default settings of terminal to use mc???

You want 'lightblue tab visualiser on standard blue background'.

yes

And what color of cursor must be by you idea?

i don't mind. i guess standard blue characters in a gray block (i.e., like it is without any highlighting) would be just fine.

Would? Ok, I make question in another way, what color you set to it now by default in mc?

For what I question about it - I try check what cursor visible on terminals who change default colour cheme (i.e. have workaraund for yours colors) or irrelevant to it.

[ossi]

Replying to Hubbitus:

Can we saparately change cursor color on separate visualizers? [...]
what color you set to it [cursor?] now by default in mc?

the two answers are in the second part of the first comment. really. ;)

fwiw, i think we might need to use a softcursor to get what we need - i don't think the vga cursor can use independent colors in the first place.

[Hubbitus]

Replying to ossi:

the two answers are in the second part of the first comment. really. ;)

Sorry. I triple time read it and can't understand.
With conjuction with you answer #6 I can undarstand what I can change any color to any on my machine. But primarly question - can yours make mcedit robust and working in similar way on wide range of terminals?

Why cursor always visible with suggested black color but only sometimes in lightblue?

For the information, I make screenshots on many terminal emulators (I try add screen in Linux Console from VirtualBox? shortly): ​http://ru.bir.ru/_temp/mcedit/
Please, especially note what color of cursor almost everywhere different where it is visible!

fwiw, i think we might need to use a softcursor to get what we need - i don't think the vga cursor can use independent colors in the first place.

I'm compleatly do not known how it shold be implemented.

[ossi]

Replying to Hubbitus:

Replying to ossi:

the two answers are in the second part of the first comment. really. ;)

Sorry. I triple time read it and can't understand.

ok. the paragraph implies three things:

• we don't set any cursor, but rely on the terminal doing the right thing. many terminals (notably the vga console and xterm in the default configuration) will have a cursor which uses the (inverted) colors of the current character cell. unfortunately this will make the cursor "subtle", just as the whitespace is meant to be.
• xterm can be configured to use another cursor style. some other terminals do that by default.
• it *might* be possible to change some terminals' cursor style programmatically

But primarly question - can yours make mcedit robust and working in similar way on wide range of terminals?

yes ... either way.

Why cursor always visible with suggested black color but only sometimes in lightblue?

that might be some magic/breakage in the terminal itself.

For the information, I make screenshots on many terminal emulators (I try add screen in Linux Console from VirtualBox? shortly): ​http://ru.bir.ru/_temp/mcedit/
Please, especially note what color of cursor almost everywhere different where it is visible!

gnome-terminal, roxterm-default & tilda do indeed have *no* cursor at all. that might mean that you did the screenshot while in an invisible phase of a blinking cursor, or that the terminal is plain broken - nothing mc should care about.
konsole and xterm are the only terminals which use an inverted-color cursor ... which surprises me a bit. oh, well.

fwiw, i think we might need to use a softcursor to get what we need - i don't think the vga cursor can use independent colors in the first place.

I'm compleatly do not known how it shold be implemented.

that's actually simple. don't worry.

[jengelh]

I am also against 385; keep brightblue-on-blue - or, here is the deal, make it configurable.

• The cursor *is* visible on Linux console (80x25 on tty1), it's that thing that blinks every so slightly, though it's brightblue
• xterm/putty use a gray block cursor generally
• the cursor not displaying in some terms (gnome-terminal, etc.) is a bug of libvte (reported -> ​http://www.nabble.com/libvte:-bugs-td22014292.html , of course no one took note of it)
• strange color defaults for X11 terminal emulators (too dark, too bright, blue is some whacky sky color, 0xAA is the default dark component for VGA mode); sane set enclosed below

*VT100*color0: #000000
*VT100*color1: #AA0000
*VT100*color2: #00AA00
*VT100*color3: #AA6600
*VT100*color4: #000080
*VT100*color5: #AA00AA
*VT100*color6: #00AAAA
*VT100*color7: #AAAAAA
*VT100*color8: #555555
*VT100*color9: #FF0000
*VT100*color10: #00FF00
*VT100*color11: #FFFF00
*VT100*color12: #0000FF
*VT100*color13: #FF00FF
*VT100*color14: #00FFFF
*VT100*color15: #FFFFFF
*VT100*colorULMode: on
*VT100*colorUL: #60AAAA
*VT100*colorBD: #FFFFFF

[Hubbitus]

Replying to jengelh:

• The cursor *is* visible on Linux console (80x25 on tty1), it's that thing that blinks every so slightly, though it's brightblue

In jabber conference we also come to decision what key there "blinking cursor"!!!
So, as it is turned off at least in Fedora (for low power consumption reasons) it do many troubles. Try turn off blinking, and I think you can see this bug!

• the cursor not displaying in some terms (gnome-terminal, etc.) is a bug of libvte (reported -> ​http://www.nabble.com/libvte:-bugs-td22014292.html , of course no one took note of it)

It have worth. Thank yuo very much. Please provide link to the bug if it if exists, not on mailing list.

[slavazanko]

Good big speach from one little patch :)
In jabber-room we found out that it is really not a problem MC.

Is this must mean, that this ticket must will closed (like propose Patrick Winnertz)?

[Hubbitus]

I'm fill bug on fedora-kernel - ​https://bugzilla.redhat.com/show_bug.cgi?id=503687 , possible it is truly its and VTE bugs.

So, now I close it (as opener) as invalid and reopen leter if necessary.