Re: [Midnight Commander] #113: savannah: make tabs and trailing spaces visible

["Ticket System" <tickets midnight-commander org>]

#113: savannah: make tabs and trailing spaces visible
-------------------------+--------------------------------------------------
  Reporter:  slavazanko  |       Owner:       
      Type:  defect      |      Status:  new  
  Priority:  major       |   Milestone:       
 Component:  mc-core     |     Version:  4.6.1
Resolution:              |    Keywords:       
  Blocking:              |   Blockedby:       
-------------------------+--------------------------------------------------
Description changed by slavazanko:

Old description:

> Original: http://savannah.gnu.org/bugs/?13146
>
> ||Submitted by:||Oswald Buddenhagen <ossi>||Submitted on:||Sat 21 May
> 2005 07:25:17 PM UTC||
> ||Category:||Editor||Severity:||3 - Normal||
> ||Status:||In Progress||Privacy:||Public||
> ||Assigned to:||None||Open/Closed:||Open||
> ||Release:||current (CVS or snapshot)||Operating System:||All||
>
> Discussion:
> {{{
> Sun 06 Jul 2008 04:12:04 PM UTC, comment #24:
>
> I noticed I cannot just use the Unicode characters (like p->ch = 0xB7),
> as that does not take into account terminals that are not in UTF-8. But
> the fix is simple enough (p->ch = SLsmg_Is_Unicode ? 0xB7 : ".").
>
> BTW, I also implemented the MS Word-style "tabs", i.e. printing a right-
> arrow in the middle of a tab. I sort of prefer it over the "<---->" tabs.
> It is a patch that currently replaces the existing tab mechanism, but
> IMHO this should all be made configurable once the maintainers decide to
> wake up and give me some sort of ok...
>
> (file #16007)
>         Jan Engelhardt <hirogen2>
> Sun 06 Jul 2008 01:24:09 PM UTC, comment #23:
>
> Patch #4 -- cedit-symbol-prefs.diff
>
> This patch changes the space fill character to some Unicode dot (·) [this
> one is also available on the text console], and makes the <------> tab
> filler into the Unicode ◀──────▶ too.
>
> (file #16006)
>         Jan Engelhardt <hirogen2>
> Sun 06 Jul 2008 01:21:22 PM UTC, comment #22:
>
> Patch #3 -- cedit-fix-whitespace.diff
>
> We definitely need to set MOD_WHITESPACE or the space between tab stops
> is drawn with some random color.
>
> (file #16005)
>         Jan Engelhardt <hirogen2>
> Sun 06 Jul 2008 01:19:54 PM UTC, comment #21:
>
> Patch #2 -- cedit-eol-mark.diff
>
> This patch implements comment #8's suggestion to use ¶ as an EOL marker.
> It can be toggled using the Options>Highlight options dialog, or, of
> course, by editing ~/.mc/config directly.
>
> (file #16004)
>         Jan Engelhardt <hirogen2>
> Sun 06 Jul 2008 01:17:43 PM UTC, comment #20:
>
> Ok since nobody replied here are some patches of my own.
> They require that mc(edit) has COMPLETE support for UTF-8!, which is not
> the case in the mc source distribution. The openSUSE .src.rpm has the
> required utf8 bits. Will try to make them submit theirs.
>
> Patch #1 -- cedit-configurable-highlight.diff
>
> This is for comment #19; it allows to switch highlighting. Firstly, it
> adds a dialog (Options > Highlight options) where you can precisely
> select what to highlight
>
> [ ] Global syntax highlighting
>
> [ ] Tab highlighting (those <------> markers, which, btw, can get very
> ugly if you have lots of code)
>
> [ ] Whitespace highlighting (dots at the end-of-line, and, if tab
> highlighting is disabled, anywhere on the line)
>
> One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2, for
> the latter two, I added Ctrl-V as a hotkey which cycles through the
> possibilities. My personal preference is to have Tab highlight OFF and
> Whitespace highlight ON.
>
> (file #16003)
>         Jan Engelhardt <hirogen2>
> Fri 29 Feb 2008 07:16:33 PM UTC, comment #19:
>
> Oh, god... I just updated my Debian box, and I now run MC 4.6.2-pre1 (as
> outputted by mcedit --version). It appears that this patch is included in
> this version of mcedit. I really dislike it. Besides suffering from the
> 'cursor disappearing' thingy, I just think its ugly. But that's my humble
> opinion :)
> How can I disable it? The patches attached to this report don't seem to
> make a new configurable parameter available in the configuration dialogs.
>         Jurrie Overgoor <leadpumper>
> Tue 04 Sep 2007 05:29:40 AM UTC, comment #18:
>
> Pavel, I applied your patch to vte-0.16.8. It works.
>         Andrew Borodin <a_borodin>
> Mon 03 Sep 2007 01:15:42 PM UTC, comment #17:
>
> Ok. I tracked the "bug" to vte_terminal_determine_colors() in the vte
> package. To request brighter colors one forces the terminal into "bold
> mode". It seems that in this mode vte allows only the foreground color to
> be bright. In vte's terms a bright color is the same color as the normal
> one but with a special flag set. So what happens is that when the time
> comes for the cursor to blink vte switches the current forground color
> with the current background color and vice versa... As I said above
> both colors are indentified in the same way but one has a special flag,
> however vte uses this flag to brighten the foreground color so at the end
> we end up as if nothing happened. It's hard to say whether this is the
> desired behaviour .. I'll attach a simple patch which changes vte to do
> what seems more logically correct... and I'll open a report in gnome's
> bugzilla.
>
> (file #13873)
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Fri 31 Aug 2007 04:19:43 PM UTC, comment #16:
>
> IMO, this must be a bug in gnome-terminal. It doesn't behave properly if
> one uses both the bright and normal colors as the background and
> foreground of the same cell. I changed the
> the definition of "editwhitespace" to "brightred,red" and the cursor is
> not displayed in this case as well. I also changed the color for
> brightblue in my gnome-terminal profile to a different color but no
> matter the cursor wasnt displayed. I'll see if they have a bugreport in
> their bugzilla.
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Fri 31 Aug 2007 09:28:17 AM UTC, comment #15:
>
> This may be a bug in gnome-terminal as well... I am also using gnome-
> terminal and no matter the color scheme the cursor is invisible. I'll
> investigate further...
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Fri 31 Aug 2007 06:07:28 AM UTC, comment #14:
>
> Oswald, you are right. This effect is depending on terminal emulation
> program and color scheme.
>
> In linux console, cursor is visible every time. The color of cursor is
> changed to light blue in tab and trailing space positions, but cursor is
> visible.
>
> The same is in xterm under X. xterm doesn't have any non-default cursor
> settings.
>
> In gnome-terminal and multi-gnome-terminal, which I use, cursor changes
> its color and becomes invisible. ("Green on black" color scheme and
> "Linux console" palette are used in both those programs.)
>
> Is it possible to make the same cursor color in positions of visualized
> tab an training space as in positions of other symbols?
>         Andrew Borodin <a_borodin>
> Thu 30 Aug 2007 12:58:35 PM UTC, comment #13:
>
> that's weird ... i see no such effect (little surprisingly). though with
> some terminals/color combinations it becomes light blue, too, and thus
> hardly visible, but i don't think we can do much about that.
>         Oswald Buddenhagen <ossi>
> Thu 30 Aug 2007 12:39:39 PM UTC, comment #12:
>
> Yep. As I said - i'll be fixing the patch... I prefer to have it in CVS
> even if it has minor glitches. In the meantime if you find any other
> problems with it - please, feel free to report them.
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Thu 30 Aug 2007 12:29:20 PM UTC, comment #11:
>
> Cursor in TAB and trailing space position is disappeared. This is very
> uncomfortable.
>         Andrew Borodin <a_borodin>
> Mon 27 Aug 2007 12:08:04 PM UTC, comment #10:
>
> The patch is in CVS now. I've commited mcedit-visible-ws-v2.diff with no
> changes whatsoever ... I'll be making changes to it as discussed in this
> bugreport in the next few weeks.
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Thu 09 Aug 2007 08:53:35 PM UTC, comment #9:
>
> i considered making all whitespace visible, but somehow found it
> pointless and even counterproductive for my use cases.
> for linefeeds, i really see no use case ...
> regarding the use of special characters, this is not doable without utter
> hackery. mc is restricted to the abstract char set provided by
> ncurses/slang, which unfortunately does not provide these chars.
>         Oswald Buddenhagen <ossi>
> Thu 09 Aug 2007 08:28:12 PM UTC, comment #8:
>
> This mcedit-visible-ws-v2.diff works great with mc-4.6.1
> What a pity it is not inside mc by default. The light blue color is great
> - it shows invisible characters but not disturbs reading/editing.
>
> There is one little thing I would like to see:
> make tabs, all spaces and carriage returns visible like in OpenOffice/M$
> Word.
>
> This means that:
> -all spaces are visible as dots ···· (unicode 00B7) (not only trailing
> but all - this is comfortable when hunting for double/multi spaces
> between words).
> -tabs are visible as arrows → (unicode 2192) (somethhing like -> mc uses
> semigraphics so can draw arrows too)
> -carriage returns are visible as reversed P character ¶ (unicode 00B6)
> (I know this is poor description but just run OO Writer or Word to see
> how these formating characters are marked).
>
> I really would like to see this patch in mc as default. It is very
> helpful and allows to keep .conf files clean.
>         Zbigniew Luszpinski <mr_zbiggy>
> Sun 05 Feb 2006 04:51:56 PM UTC, comment #7:
>
> it just occurred to me, that i don't want two separate shortcuts for
> toggling these options. two separate persistent options in the config
> dialog are ok, but there should be only one "quick toggle" shortcut
> (ctrl-w) that disables both at once, and is not saved anywhere.
> i suppose the envisioned ctrl-s shortcut for toggling syntax highlighting
> should be non-persistent as well.
>         Oswald Buddenhagen <ossi>
> Mon 30 Jan 2006 05:16:22 PM UTC, comment #6:
>
> Single patch is OK.
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Mon 30 Jan 2006 04:33:20 PM UTC, comment #5:
>
> ok, here's a patch which allows enabling visible trailing whitespace and
> visible tabs independently. i'm not eager to split it into two patches;
> they are too much related.
> i just threw in the options as variables right above the relevant
> function - i'd prefer you wrapping this into proper configurability
> (options in the edit config dialog and keyboard accels) yourself, as i'd
> have to research how to do it first. :}
>         Oswald Buddenhagen <ossi>
> Mon 30 Jan 2006 04:19:36 PM UTC, comment #4:
>
> ok, i changed my mind - i have a strong opinion now. :)
> i think it's right that trailing tabs should not prevent preceeding
> spaces from being marked as trailing: if trailing whitespace removal is
> implemented, all these chars will be equally killed away.
>         Oswald Buddenhagen <ossi>
> Mon 30 Jan 2006 03:53:54 PM UTC, comment #3:
>
> I did try it and have been playing with it for a while. This patch
> adds (1) visible trailing spaces and (2) visible tabs. In fact I prefer
> to think of it as two separate patches. As you suggested on the list it
> should be enhanced so that the user can switch this functionality on and
> off via a fast key. I would add that the user should be allowed to enable
> (1) without enabling (2) and vice versa.
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Mon 30 Jan 2006 03:35:14 PM UTC, comment #2:
>
> well, tabs should stay tabs. masking them away in this special case would
> just lead to surprises.
> not sure about your example. it's true that it looks a bit weird. otoh,
> such whitespace is plainly broken, so it should look broken. :) also, if
> you change it, suddenly chars in the middle of a line will vanish/appear
> if you (append past/remove up to) the trailing tabs. it depends on
> whether one wants to get the static or the dynamic case nicer.
> the patch is really simple, so give it a try. after all, i have no
> particular opinion on this matter - i need to highlight trailing
> whitespace only to annihilate any occurrences of it anyway. :-)=)
>         Oswald Buddenhagen <ossi>
> Mon 30 Jan 2006 03:09:00 PM UTC, comment #1:
>
> How about considering the trailing tabs a trailing whitespace too and
> marking all the traling whitespace with just a dot ?
>
> Now if a have a like like this:
>
> int func()<space><space><space><space><tab><tab>
>
> i get
>
> int func() <><------><------>
>
> This is pretty inconsistent and annoying (IMO).
>         Pavel Tsekov <ptsekov>
> Project Administrator
> Sat 21 May 2005 07:25:17 PM UTC, original submission:
>
> visible tabs help putting the tabs where you want them, particularly when
> trying to stay consistent with the style of text written by somebody
> else.
> making trailing whitespace visible helps avoiding it in undesired places.
>
> here is a patch that accomplishes this. it is missing an option to
> disable this feature, so i post this as a wish instead of as a patch.
>
> i wanted the visibility to be as subtle as possible. therefore just
> changing the background color (see leading tabs in Makefile highlite) was
> no option. so i paint tabs as excerpts of <------> and spaces as dots. to
> make it really subtle, i paint it bright blue on dark blue (the regular
> background) - this is hardly visible, unless you are looking for it. i
> know of no way to make it equally subtle on monochrome displays,
> so the feature is disabled alltogether there.
> the whitespace becomes invisible when the text is selected, as there is
> no possibility to merge colors. it'd be nice to fix this generally.
> the highlite color is not defined by syntax highlighting, but by an extra
> palette entry. i think this makes sense.
> this feature overrides other colors that might be defined for whitespace,
> like the red background of tabs in Makefiles. the block in #if 0 would
> preserve the color of already highlighted whitespace, but it's a too
> broad criterion. i don't think ignoring this fact is a problem, as you
> can recognize the tabs anyway (obviously).
> note, that you can't just copy such text from the terminal, as the
> pseudo-whitespace chars will show up in the copy. therefore a hotkey to
> switch it off quickly would be useful. otoh, a) the problem that this
> feature is disabled in selected blocks is an advantage in this context
> and b) by copying, you would be destroying the original whitespace
> anyway.
> }}}

New description:

 Original: http://savannah.gnu.org/bugs/?13146

 ||Submitted by:||Oswald Buddenhagen <ossi>||Submitted on:||Sat 21 May 2005
 07:25:17 PM UTC||
 ||Category:||Editor||Severity:||3 - Normal||
 ||Status:||In Progress||Privacy:||Public||
 ||Assigned to:||None||Open/Closed:||Open||
 ||Release:||current (CVS or snapshot)||Operating System:||All||

 Discussion:
 {{{
 Sun 06 Jul 2008 04:12:04 PM UTC, comment #24:

 I noticed I cannot just use the Unicode characters (like p->ch =
 0xB7), as that does not take into account terminals that are not in
 UTF-8. But the fix is simple enough (p->ch = SLsmg_Is_Unicode ? 0xB7 :
 ".").

 BTW, I also implemented the MS Word-style "tabs", i.e. printing a
 right-arrow in the middle of a tab. I sort of prefer it over the
 "<---->" tabs. It is a patch that currently replaces the existing
 tab mechanism, but IMHO this should all be made configurable once
 the maintainers decide to wake up and give me some sort of ok...

 (file #16007)
         Jan Engelhardt <hirogen2>
 Sun 06 Jul 2008 01:24:09 PM UTC, comment #23:

 Patch #4 -- cedit-symbol-prefs.diff

 This patch changes the space fill character to some Unicode dot (·)
 [this one is also available on the text console], and makes the
 <------> tab filler into the Unicode ◀──────▶ too.

 (file #16006)
         Jan Engelhardt <hirogen2>
 Sun 06 Jul 2008 01:21:22 PM UTC, comment #22:

 Patch #3 -- cedit-fix-whitespace.diff

 We definitely need to set MOD_WHITESPACE or the space between tab
 stops is drawn with some random color.

 (file #16005)
         Jan Engelhardt <hirogen2>
 Sun 06 Jul 2008 01:19:54 PM UTC, comment #21:

 Patch #2 -- cedit-eol-mark.diff

 This patch implements comment #8's suggestion to use ¶ as an EOL
 marker. It can be toggled using the Options>Highlight options
 dialog, or, of course, by editing ~/.mc/config directly.

 (file #16004)
         Jan Engelhardt <hirogen2>
 Sun 06 Jul 2008 01:17:43 PM UTC, comment #20:

 Ok since nobody replied here are some patches of my own.
 They require that mc(edit) has COMPLETE support for UTF-8!, which
 is not the case in the mc source distribution. The openSUSE
 .src.rpm has the required utf8 bits. Will try to make them submit
 theirs.

 Patch #1 -- cedit-configurable-highlight.diff

 This is for comment #19; it allows to switch highlighting. Firstly,
 it adds a dialog (Options > Highlight options) where you can
 precisely select what to highlight

 [ ] Global syntax highlighting

 [ ] Tab highlighting (those <------> markers, which, btw, can get
 very ugly if you have lots of code)

 [ ] Whitespace highlighting (dots at the end-of-line, and, if tab
 highlighting is disabled, anywhere on the line)

 One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2,
 for the latter two, I added Ctrl-V as a hotkey which cycles through
 the possibilities. My personal preference is to have Tab highlight
 OFF and Whitespace highlight ON.

 (file #16003)
         Jan Engelhardt <hirogen2>
 Fri 29 Feb 2008 07:16:33 PM UTC, comment #19:

 Oh, god... I just updated my Debian box, and I now run MC
 4.6.2-pre1 (as outputted by mcedit --version). It appears that this
 patch is included in this version of mcedit. I really dislike it.
 Besides suffering from the 'cursor disappearing' thingy, I just
 think its ugly. But that's my humble opinion :)
 How can I disable it? The patches attached to this report don't
 seem to make a new configurable parameter available in the
 configuration dialogs.
         Jurrie Overgoor <leadpumper>
 Tue 04 Sep 2007 05:29:40 AM UTC, comment #18:

 Pavel, I applied your patch to vte-0.16.8. It works.
         Andrew Borodin <a_borodin>
 Mon 03 Sep 2007 01:15:42 PM UTC, comment #17:

 Ok. I tracked the "bug" to vte_terminal_determine_colors() in the
 vte package. To request brighter colors one forces the terminal
 into "bold mode". It seems that in this mode vte allows only the
 foreground color to be bright. In vte's terms a bright color is the
 same color as the normal one but with a special flag set. So what
 happens is that when the time comes for the cursor to blink vte
 switches the current forground color with the current background
 color and vice versa... As I said above
 both colors are indentified in the same way but one has a special
 flag, however vte uses this flag to brighten the foreground color
 so at the end we end up as if nothing happened. It's hard to say
 whether this is the desired behaviour .. I'll attach a simple patch
 which changes vte to do what seems more logically correct... and
 I'll open a report in gnome's bugzilla.

 (file #13873)
         Pavel Tsekov <ptsekov>
 Project Administrator
 Fri 31 Aug 2007 04:19:43 PM UTC, comment #16:

 IMO, this must be a bug in gnome-terminal. It doesn't behave
 properly if one uses both the bright and normal colors as the
 background and foreground of the same cell. I changed the
 the definition of "editwhitespace" to "brightred,red" and the
 cursor is not displayed in this case as well. I also changed the
 color for brightblue in my gnome-terminal profile to a different
 color but no matter the cursor wasnt displayed. I'll see if they
 have a bugreport in their bugzilla.
         Pavel Tsekov <ptsekov>
 Project Administrator
 Fri 31 Aug 2007 09:28:17 AM UTC, comment #15:

 This may be a bug in gnome-terminal as well... I am also using
 gnome-terminal and no matter the color scheme the cursor is
 invisible. I'll investigate further...
         Pavel Tsekov <ptsekov>
 Project Administrator
 Fri 31 Aug 2007 06:07:28 AM UTC, comment #14:

 Oswald, you are right. This effect is depending on terminal
 emulation program and color scheme.

 In linux console, cursor is visible every time. The color of cursor
 is changed to light blue in tab and trailing space positions, but
 cursor is visible.

 The same is in xterm under X. xterm doesn't have any non-default
 cursor settings.

 In gnome-terminal and multi-gnome-terminal, which I use, cursor
 changes its color and becomes invisible. ("Green on black" color
 scheme and "Linux console" palette are used in both those programs.)

 Is it possible to make the same cursor color in positions of
 visualized tab an training space as in positions of other symbols?
         Andrew Borodin <a_borodin>
 Thu 30 Aug 2007 12:58:35 PM UTC, comment #13:

 that's weird ... i see no such effect (little surprisingly). though
 with some terminals/color combinations it becomes light blue, too,
 and thus hardly visible, but i don't think we can do much about
 that.
         Oswald Buddenhagen <ossi>
 Thu 30 Aug 2007 12:39:39 PM UTC, comment #12:

 Yep. As I said - i'll be fixing the patch... I prefer to have it in
 CVS even if it has minor glitches. In the meantime if you find any
 other problems with it - please, feel free to report them.
         Pavel Tsekov <ptsekov>
 Project Administrator
 Thu 30 Aug 2007 12:29:20 PM UTC, comment #11:

 Cursor in TAB and trailing space position is disappeared. This is
 very uncomfortable.
         Andrew Borodin <a_borodin>
 Mon 27 Aug 2007 12:08:04 PM UTC, comment #10:

 The patch is in CVS now. I've commited mcedit-visible-ws-v2.diff
 with no changes whatsoever ... I'll be making changes to it as
 discussed in this bugreport in the next few weeks.
         Pavel Tsekov <ptsekov>
 Project Administrator
 Thu 09 Aug 2007 08:53:35 PM UTC, comment #9:

 i considered making all whitespace visible, but somehow found it
 pointless and even counterproductive for my use cases.
 for linefeeds, i really see no use case ...
 regarding the use of special characters, this is not doable without
 utter hackery. mc is restricted to the abstract char set provided
 by ncurses/slang, which unfortunately does not provide these chars.
         Oswald Buddenhagen <ossi>
 Thu 09 Aug 2007 08:28:12 PM UTC, comment #8:

 This mcedit-visible-ws-v2.diff works great with mc-4.6.1
 What a pity it is not inside mc by default. The light blue color is
 great - it shows invisible characters but not disturbs
 reading/editing.

 There is one little thing I would like to see:
 make tabs, all spaces and carriage returns visible like in OpenOffice/M$
 Word.

 This means that:
 -all spaces are visible as dots ···· (unicode 00B7) (not only
 trailing but all - this is comfortable when hunting for
 double/multi spaces between words).
 -tabs are visible as arrows → (unicode 2192) (somethhing like -> mc
 uses semigraphics so can draw arrows too)
 -carriage returns are visible as reversed P character ¶ (unicode
 00B6)
 (I know this is poor description but just run OO Writer or Word to
 see how these formating characters are marked).

 I really would like to see this patch in mc as default. It is very
 helpful and allows to keep .conf files clean.
         Zbigniew Luszpinski <mr_zbiggy>
 Sun 05 Feb 2006 04:51:56 PM UTC, comment #7:

 it just occurred to me, that i don't want two separate shortcuts
 for toggling these options. two separate persistent options in the
 config dialog are ok, but there should be only one "quick toggle"
 shortcut (ctrl-w) that disables both at once, and is not saved
 anywhere.
 i suppose the envisioned ctrl-s shortcut for toggling syntax
 highlighting should be non-persistent as well.
         Oswald Buddenhagen <ossi>
 Mon 30 Jan 2006 05:16:22 PM UTC, comment #6:

 Single patch is OK.
         Pavel Tsekov <ptsekov>
 Project Administrator
 Mon 30 Jan 2006 04:33:20 PM UTC, comment #5:

 ok, here's a patch which allows enabling visible trailing
 whitespace and visible tabs independently. i'm not eager to split
 it into two patches; they are too much related.
 i just threw in the options as variables right above the relevant
 function - i'd prefer you wrapping this into proper configurability
 (options in the edit config dialog and keyboard accels) yourself,
 as i'd have to research how to do it first. :}
         Oswald Buddenhagen <ossi>
 Mon 30 Jan 2006 04:19:36 PM UTC, comment #4:

 ok, i changed my mind - i have a strong opinion now. :)
 i think it's right that trailing tabs should not prevent preceeding
 spaces from being marked as trailing: if trailing whitespace
 removal is implemented, all these chars will be equally killed away.
         Oswald Buddenhagen <ossi>
 Mon 30 Jan 2006 03:53:54 PM UTC, comment #3:

 I did try it and have been playing with it for a while. This patch
 adds (1) visible trailing spaces and (2) visible tabs. In fact I
 prefer to think of it as two separate patches. As you suggested on
 the list it should be enhanced so that the user can switch this
 functionality on and off via a fast key. I would add that the user
 should be allowed to enable (1) without enabling (2) and vice versa.
         Pavel Tsekov <ptsekov>
 Project Administrator
 Mon 30 Jan 2006 03:35:14 PM UTC, comment #2:

 well, tabs should stay tabs. masking them away in this special case
 would just lead to surprises.
 not sure about your example. it's true that it looks a bit weird.
 otoh, such whitespace is plainly broken, so it should look broken.
 :) also, if you change it, suddenly chars in the middle of a line
 will vanish/appear if you (append past/remove up to) the trailing
 tabs. it depends on whether one wants to get the static or the
 dynamic case nicer.
 the patch is really simple, so give it a try. after all, i have no
 particular opinion on this matter - i need to highlight trailing
 whitespace only to annihilate any occurrences of it anyway. :-)=)
         Oswald Buddenhagen <ossi>
 Mon 30 Jan 2006 03:09:00 PM UTC, comment #1:

 How about considering the trailing tabs a trailing whitespace too
 and marking all the traling whitespace with just a dot ?

 Now if a have a like like this:

 int func()<space><space><space><space><tab><tab>

 i get

 int func() <><------><------>

 This is pretty inconsistent and annoying (IMO).
         Pavel Tsekov <ptsekov>
 Project Administrator
 Sat 21 May 2005 07:25:17 PM UTC, original submission:

 visible tabs help putting the tabs where you want them,
 particularly when trying to stay consistent with the style of text
 written by somebody else.
 making trailing whitespace visible helps avoiding it in undesired
 places.

 here is a patch that accomplishes this. it is missing an option to
 disable this feature, so i post this as a wish instead of as a
 patch.

 i wanted the visibility to be as subtle as possible. therefore just
 changing the background color (see leading tabs in Makefile
 highlite) was no option. so i paint tabs as excerpts of <------>
 and spaces as dots. to make it really subtle, i paint it bright
 blue on dark blue (the regular background) - this is hardly
 visible, unless you are looking for it. i know of no way to make it
 equally subtle on monochrome displays,
 so the feature is disabled alltogether there.
 the whitespace becomes invisible when the text is selected, as
 there is no possibility to merge colors. it'd be nice to fix this
 generally.
 the highlite color is not defined by syntax highlighting, but by an
 extra palette entry. i think this makes sense.
 this feature overrides other colors that might be defined for
 whitespace, like the red background of tabs in Makefiles. the block
 in #if 0 would preserve the color of already highlighted
 whitespace, but it's a too broad criterion. i don't think ignoring
 this fact is a problem, as you can recognize the tabs anyway
 (obviously).
 note, that you can't just copy such text from the terminal, as the
 pseudo-whitespace chars will show up in the copy. therefore a
 hotkey to switch it off quickly would be useful. otoh, a) the
 problem that this feature is disabled in selected blocks is an
 advantage in this context and b) by copying, you would be
 destroying the original whitespace anyway.
 }}}

--

-- 
Ticket URL: <http://www.midnight-commander.org/ticket/113#comment:1>
Midnight Commander <www.midnight-commander.org>
Midnight Development Center