Changes between Initial Version and Version 1 of Ticket #113


Ignore:
Timestamp:
01/02/09 22:03:04 (10 years ago)
Author:
slavazanko
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #113 – Description

    initial v1  
    1111Sun 06 Jul 2008 04:12:04 PM UTC, comment #24: 
    1212 
    13 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 : "."). 
    14  
    15 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... 
     13I noticed I cannot just use the Unicode characters (like p->ch =  
     140xB7), as that does not take into account terminals that are not in  
     15UTF-8. But the fix is simple enough (p->ch = SLsmg_Is_Unicode ? 0xB7 : "."). 
     16 
     17BTW, I also implemented the MS Word-style "tabs", i.e. printing a  
     18right-arrow in the middle of a tab. I sort of prefer it over the  
     19"<---->" tabs. It is a patch that currently replaces the existing  
     20tab mechanism, but IMHO this should all be made configurable once  
     21the maintainers decide to wake up and give me some sort of ok... 
    1622 
    1723(file #16007) 
     
    2127Patch #4 -- cedit-symbol-prefs.diff 
    2228 
    23 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. 
     29This patch changes the space fill character to some Unicode dot (·)  
     30[this one is also available on the text console], and makes the  
     31<------> tab filler into the Unicode ◀──────▶ too. 
    2432 
    2533(file #16006) 
     
    2937Patch #3 -- cedit-fix-whitespace.diff 
    3038 
    31 We definitely need to set MOD_WHITESPACE or the space between tab stops is drawn with some random color. 
     39We definitely need to set MOD_WHITESPACE or the space between tab  
     40stops is drawn with some random color. 
    3241 
    3342(file #16005) 
     
    3746Patch #2 -- cedit-eol-mark.diff 
    3847 
    39 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. 
     48This patch implements comment #8's suggestion to use ¶ as an EOL  
     49marker. It can be toggled using the Options>Highlight options  
     50dialog, or, of course, by editing ~/.mc/config directly. 
    4051 
    4152(file #16004) 
     
    4455 
    4556Ok since nobody replied here are some patches of my own. 
    46 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. 
     57They require that mc(edit) has COMPLETE support for UTF-8!, which  
     58is not the case in the mc source distribution. The openSUSE  
     59.src.rpm has the required utf8 bits. Will try to make them submit  
     60theirs. 
    4761 
    4862Patch #1 -- cedit-configurable-highlight.diff 
    4963 
    50 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 
     64This is for comment #19; it allows to switch highlighting. Firstly,  
     65it adds a dialog (Options > Highlight options) where you can  
     66precisely select what to highlight 
    5167 
    5268[ ] Global syntax highlighting 
    5369 
    54 [ ] Tab highlighting (those <------> markers, which, btw, can get very ugly if you have lots of code) 
    55  
    56 [ ] Whitespace highlighting (dots at the end-of-line, and, if tab highlighting is disabled, anywhere on the line) 
    57  
    58 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. 
     70[ ] Tab highlighting (those <------> markers, which, btw, can get  
     71very ugly if you have lots of code) 
     72 
     73[ ] Whitespace highlighting (dots at the end-of-line, and, if tab  
     74highlighting is disabled, anywhere on the line) 
     75 
     76One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2,  
     77for the latter two, I added Ctrl-V as a hotkey which cycles through  
     78the possibilities. My personal preference is to have Tab highlight  
     79OFF and Whitespace highlight ON. 
    5980 
    6081(file #16003) 
     
    6283Fri 29 Feb 2008 07:16:33 PM UTC, comment #19: 
    6384 
    64 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 :) 
    65 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. 
     85Oh, god... I just updated my Debian box, and I now run MC  
     864.6.2-pre1 (as outputted by mcedit --version). It appears that this  
     87patch is included in this version of mcedit. I really dislike it.  
     88Besides suffering from the 'cursor disappearing' thingy, I just  
     89think its ugly. But that's my humble opinion :) 
     90How can I disable it? The patches attached to this report don't  
     91seem to make a new configurable parameter available in the  
     92configuration dialogs. 
    6693        Jurrie Overgoor <leadpumper> 
    6794Tue 04 Sep 2007 05:29:40 AM UTC, comment #18: 
     
    7198Mon 03 Sep 2007 01:15:42 PM UTC, comment #17: 
    7299 
    73 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 
    74 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. 
     100Ok. I tracked the "bug" to vte_terminal_determine_colors() in the  
     101vte package. To request brighter colors one forces the terminal  
     102into "bold mode". It seems that in this mode vte allows only the  
     103foreground color to be bright. In vte's terms a bright color is the  
     104same color as the normal one but with a special flag set. So what  
     105happens is that when the time comes for the cursor to blink vte  
     106switches the current forground color with the current background  
     107color and vice versa... As I said above 
     108both colors are indentified in the same way but one has a special  
     109flag, however vte uses this flag to brighten the foreground color  
     110so at the end we end up as if nothing happened. It's hard to say  
     111whether this is the desired behaviour .. I'll attach a simple patch  
     112which changes vte to do what seems more logically correct... and  
     113I'll open a report in gnome's bugzilla. 
    75114 
    76115(file #13873) 
     
    79118Fri 31 Aug 2007 04:19:43 PM UTC, comment #16: 
    80119 
    81 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 
    82 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. 
     120IMO, this must be a bug in gnome-terminal. It doesn't behave  
     121properly if one uses both the bright and normal colors as the  
     122background and foreground of the same cell. I changed the 
     123the definition of "editwhitespace" to "brightred,red" and the  
     124cursor is not displayed in this case as well. I also changed the  
     125color for brightblue in my gnome-terminal profile to a different  
     126color but no matter the cursor wasnt displayed. I'll see if they  
     127have a bugreport in their bugzilla. 
    83128        Pavel Tsekov <ptsekov> 
    84129Project Administrator 
    85130Fri 31 Aug 2007 09:28:17 AM UTC, comment #15: 
    86131 
    87 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... 
     132This may be a bug in gnome-terminal as well... I am also using  
     133gnome-terminal and no matter the color scheme the cursor is  
     134invisible. I'll investigate further... 
    88135        Pavel Tsekov <ptsekov> 
    89136Project Administrator 
    90137Fri 31 Aug 2007 06:07:28 AM UTC, comment #14: 
    91138 
    92 Oswald, you are right. This effect is depending on terminal emulation program and color scheme. 
    93  
    94 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. 
    95  
    96 The same is in xterm under X. xterm doesn't have any non-default cursor settings. 
    97  
    98 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.) 
    99  
    100 Is it possible to make the same cursor color in positions of visualized tab an training space as in positions of other symbols? 
     139Oswald, you are right. This effect is depending on terminal  
     140emulation program and color scheme. 
     141 
     142In linux console, cursor is visible every time. The color of cursor  
     143is changed to light blue in tab and trailing space positions, but  
     144cursor is visible. 
     145 
     146The same is in xterm under X. xterm doesn't have any non-default  
     147cursor settings. 
     148 
     149In gnome-terminal and multi-gnome-terminal, which I use, cursor  
     150changes its color and becomes invisible. ("Green on black" color  
     151scheme and "Linux console" palette are used in both those programs.) 
     152 
     153Is it possible to make the same cursor color in positions of  
     154visualized tab an training space as in positions of other symbols? 
    101155        Andrew Borodin <a_borodin> 
    102156Thu 30 Aug 2007 12:58:35 PM UTC, comment #13: 
    103157 
    104 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. 
     158that's weird ... i see no such effect (little surprisingly). though  
     159with some terminals/color combinations it becomes light blue, too,  
     160and thus hardly visible, but i don't think we can do much about  
     161that. 
    105162        Oswald Buddenhagen <ossi> 
    106163Thu 30 Aug 2007 12:39:39 PM UTC, comment #12: 
    107164 
    108 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. 
     165Yep. As I said - i'll be fixing the patch... I prefer to have it in  
     166CVS even if it has minor glitches. In the meantime if you find any  
     167other problems with it - please, feel free to report them. 
    109168        Pavel Tsekov <ptsekov> 
    110169Project Administrator 
    111170Thu 30 Aug 2007 12:29:20 PM UTC, comment #11: 
    112171 
    113 Cursor in TAB and trailing space position is disappeared. This is very uncomfortable. 
     172Cursor in TAB and trailing space position is disappeared. This is  
     173very uncomfortable. 
    114174        Andrew Borodin <a_borodin> 
    115175Mon 27 Aug 2007 12:08:04 PM UTC, comment #10: 
    116176 
    117 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. 
     177The patch is in CVS now. I've commited mcedit-visible-ws-v2.diff  
     178with no changes whatsoever ... I'll be making changes to it as  
     179discussed in this bugreport in the next few weeks. 
    118180        Pavel Tsekov <ptsekov> 
    119181Project Administrator 
    120182Thu 09 Aug 2007 08:53:35 PM UTC, comment #9: 
    121183 
    122 i considered making all whitespace visible, but somehow found it pointless and even counterproductive for my use cases. 
     184i considered making all whitespace visible, but somehow found it  
     185pointless and even counterproductive for my use cases. 
    123186for linefeeds, i really see no use case ... 
    124 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. 
     187regarding the use of special characters, this is not doable without  
     188utter hackery. mc is restricted to the abstract char set provided  
     189by ncurses/slang, which unfortunately does not provide these chars. 
    125190        Oswald Buddenhagen <ossi> 
    126191Thu 09 Aug 2007 08:28:12 PM UTC, comment #8: 
    127192 
    128193This mcedit-visible-ws-v2.diff works great with mc-4.6.1 
    129 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. 
     194What a pity it is not inside mc by default. The light blue color is  
     195great - it shows invisible characters but not disturbs  
     196reading/editing. 
    130197 
    131198There is one little thing I would like to see: 
     
    133200 
    134201This means that: 
    135 -all spaces are visible as dots ···· (unicode 00B7) (not only trailing but all - this is comfortable when hunting for double/multi spaces between words). 
    136 -tabs are visible as arrows → (unicode 2192) (somethhing like -> mc uses semigraphics so can draw arrows too) 
    137 -carriage returns are visible as reversed P character ¶ (unicode 00B6) 
    138 (I know this is poor description but just run OO Writer or Word to see how these formating characters are marked). 
    139  
    140 I really would like to see this patch in mc as default. It is very helpful and allows to keep .conf files clean. 
     202-all spaces are visible as dots ···· (unicode 00B7) (not only  
     203trailing but all - this is comfortable when hunting for  
     204double/multi spaces between words). 
     205-tabs are visible as arrows → (unicode 2192) (somethhing like -> mc  
     206uses semigraphics so can draw arrows too) 
     207-carriage returns are visible as reversed P character ¶ (unicode  
     20800B6) 
     209(I know this is poor description but just run OO Writer or Word to  
     210see how these formating characters are marked). 
     211 
     212I really would like to see this patch in mc as default. It is very  
     213helpful and allows to keep .conf files clean. 
    141214        Zbigniew Luszpinski <mr_zbiggy> 
    142215Sun 05 Feb 2006 04:51:56 PM UTC, comment #7: 
    143216 
    144 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. 
    145 i suppose the envisioned ctrl-s shortcut for toggling syntax highlighting should be non-persistent as well. 
     217it just occurred to me, that i don't want two separate shortcuts  
     218for toggling these options. two separate persistent options in the  
     219config dialog are ok, but there should be only one "quick toggle"  
     220shortcut (ctrl-w) that disables both at once, and is not saved  
     221anywhere. 
     222i suppose the envisioned ctrl-s shortcut for toggling syntax  
     223highlighting should be non-persistent as well. 
    146224        Oswald Buddenhagen <ossi> 
    147225Mon 30 Jan 2006 05:16:22 PM UTC, comment #6: 
     
    152230Mon 30 Jan 2006 04:33:20 PM UTC, comment #5: 
    153231 
    154 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. 
    155 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. :} 
     232ok, here's a patch which allows enabling visible trailing  
     233whitespace and visible tabs independently. i'm not eager to split  
     234it into two patches; they are too much related. 
     235i just threw in the options as variables right above the relevant  
     236function - i'd prefer you wrapping this into proper configurability  
     237(options in the edit config dialog and keyboard accels) yourself,  
     238as i'd have to research how to do it first. :} 
    156239        Oswald Buddenhagen <ossi> 
    157240Mon 30 Jan 2006 04:19:36 PM UTC, comment #4: 
    158241 
    159242ok, i changed my mind - i have a strong opinion now. :) 
    160 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. 
     243i think it's right that trailing tabs should not prevent preceeding  
     244spaces from being marked as trailing: if trailing whitespace  
     245removal is implemented, all these chars will be equally killed away. 
    161246        Oswald Buddenhagen <ossi> 
    162247Mon 30 Jan 2006 03:53:54 PM UTC, comment #3: 
    163248 
    164249I did try it and have been playing with it for a while. This patch 
    165 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. 
     250adds (1) visible trailing spaces and (2) visible tabs. In fact I  
     251prefer to think of it as two separate patches. As you suggested on  
     252the list it should be enhanced so that the user can switch this  
     253functionality on and off via a fast key. I would add that the user  
     254should be allowed to enable (1) without enabling (2) and vice versa. 
    166255        Pavel Tsekov <ptsekov> 
    167256Project Administrator 
    168257Mon 30 Jan 2006 03:35:14 PM UTC, comment #2: 
    169258 
    170 well, tabs should stay tabs. masking them away in this special case would just lead to surprises. 
    171 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. 
    172 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. :-)=) 
     259well, tabs should stay tabs. masking them away in this special case  
     260would just lead to surprises. 
     261not sure about your example. it's true that it looks a bit weird.  
     262otoh, such whitespace is plainly broken, so it should look broken.  
     263:) also, if you change it, suddenly chars in the middle of a line  
     264will vanish/appear if you (append past/remove up to) the trailing  
     265tabs. it depends on whether one wants to get the static or the  
     266dynamic case nicer. 
     267the patch is really simple, so give it a try. after all, i have no  
     268particular opinion on this matter - i need to highlight trailing  
     269whitespace only to annihilate any occurrences of it anyway. :-)=) 
    173270        Oswald Buddenhagen <ossi> 
    174271Mon 30 Jan 2006 03:09:00 PM UTC, comment #1: 
    175272 
    176 How about considering the trailing tabs a trailing whitespace too and marking all the traling whitespace with just a dot ? 
     273How about considering the trailing tabs a trailing whitespace too  
     274and marking all the traling whitespace with just a dot ? 
    177275 
    178276Now if a have a like like this: 
     
    189287Sat 21 May 2005 07:25:17 PM UTC, original submission: 
    190288 
    191 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. 
    192 making trailing whitespace visible helps avoiding it in undesired places. 
    193  
    194 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. 
    195  
    196 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, 
     289visible tabs help putting the tabs where you want them,  
     290particularly when trying to stay consistent with the style of text  
     291written by somebody else. 
     292making trailing whitespace visible helps avoiding it in undesired  
     293places. 
     294 
     295here is a patch that accomplishes this. it is missing an option to  
     296disable this feature, so i post this as a wish instead of as a  
     297patch. 
     298 
     299i wanted the visibility to be as subtle as possible. therefore just  
     300changing the background color (see leading tabs in Makefile  
     301highlite) was no option. so i paint tabs as excerpts of <------>  
     302and spaces as dots. to make it really subtle, i paint it bright  
     303blue on dark blue (the regular background) - this is hardly  
     304visible, unless you are looking for it. i know of no way to make it  
     305equally subtle on monochrome displays, 
    197306so the feature is disabled alltogether there. 
    198 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. 
    199 the highlite color is not defined by syntax highlighting, but by an extra palette entry. i think this makes sense. 
    200 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). 
    201 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.  
     307the whitespace becomes invisible when the text is selected, as  
     308there is no possibility to merge colors. it'd be nice to fix this  
     309generally. 
     310the highlite color is not defined by syntax highlighting, but by an  
     311extra palette entry. i think this makes sense. 
     312this feature overrides other colors that might be defined for  
     313whitespace, like the red background of tabs in Makefiles. the block  
     314in #if 0 would preserve the color of already highlighted  
     315whitespace, but it's a too broad criterion. i don't think ignoring  
     316this fact is a problem, as you can recognize the tabs anyway  
     317(obviously). 
     318note, that you can't just copy such text from the terminal, as the  
     319pseudo-whitespace chars will show up in the copy. therefore a  
     320hotkey to switch it off quickly would be useful. otoh, a) the  
     321problem that this feature is disabled in selected blocks is an  
     322advantage in this context and b) by copying, you would be  
     323destroying the original whitespace anyway.  
    202324}}}