| 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... |
| | 13 | I noticed I cannot just use the Unicode characters (like p->ch = |
| | 14 | 0xB7), as that does not take into account terminals that are not in |
| | 15 | UTF-8. But the fix is simple enough (p->ch = SLsmg_Is_Unicode ? 0xB7 : "."). |
| | 16 | |
| | 17 | BTW, I also implemented the MS Word-style "tabs", i.e. printing a |
| | 18 | right-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 |
| | 20 | tab mechanism, but IMHO this should all be made configurable once |
| | 21 | the maintainers decide to wake up and give me some sort of ok... |
| 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 |
| | 71 | very ugly if you have lots of code) |
| | 72 | |
| | 73 | [ ] Whitespace highlighting (dots at the end-of-line, and, if tab |
| | 74 | highlighting is disabled, anywhere on the line) |
| | 75 | |
| | 76 | One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2, |
| | 77 | for the latter two, I added Ctrl-V as a hotkey which cycles through |
| | 78 | the possibilities. My personal preference is to have Tab highlight |
| | 79 | OFF and Whitespace highlight ON. |
| 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. |
| | 85 | Oh, god... I just updated my Debian box, and I now run MC |
| | 86 | 4.6.2-pre1 (as outputted by mcedit --version). It appears that this |
| | 87 | patch is included in this version of mcedit. I really dislike it. |
| | 88 | Besides suffering from the 'cursor disappearing' thingy, I just |
| | 89 | think its ugly. But that's my humble opinion :) |
| | 90 | How can I disable it? The patches attached to this report don't |
| | 91 | seem to make a new configurable parameter available in the |
| | 92 | configuration dialogs. |
| 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. |
| | 100 | Ok. I tracked the "bug" to vte_terminal_determine_colors() in the |
| | 101 | vte package. To request brighter colors one forces the terminal |
| | 102 | into "bold mode". It seems that in this mode vte allows only the |
| | 103 | foreground color to be bright. In vte's terms a bright color is the |
| | 104 | same color as the normal one but with a special flag set. So what |
| | 105 | happens is that when the time comes for the cursor to blink vte |
| | 106 | switches the current forground color with the current background |
| | 107 | color and vice versa... As I said above |
| | 108 | both colors are indentified in the same way but one has a special |
| | 109 | flag, however vte uses this flag to brighten the foreground color |
| | 110 | so at the end we end up as if nothing happened. It's hard to say |
| | 111 | whether this is the desired behaviour .. I'll attach a simple patch |
| | 112 | which changes vte to do what seems more logically correct... and |
| | 113 | I'll open a report in gnome's bugzilla. |
| 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. |
| | 120 | IMO, this must be a bug in gnome-terminal. It doesn't behave |
| | 121 | properly if one uses both the bright and normal colors as the |
| | 122 | background and foreground of the same cell. I changed the |
| | 123 | the definition of "editwhitespace" to "brightred,red" and the |
| | 124 | cursor is not displayed in this case as well. I also changed the |
| | 125 | color for brightblue in my gnome-terminal profile to a different |
| | 126 | color but no matter the cursor wasnt displayed. I'll see if they |
| | 127 | have a bugreport in their bugzilla. |
| 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? |
| | 139 | Oswald, you are right. This effect is depending on terminal |
| | 140 | emulation program and color scheme. |
| | 141 | |
| | 142 | In linux console, cursor is visible every time. The color of cursor |
| | 143 | is changed to light blue in tab and trailing space positions, but |
| | 144 | cursor is visible. |
| | 145 | |
| | 146 | The same is in xterm under X. xterm doesn't have any non-default |
| | 147 | cursor settings. |
| | 148 | |
| | 149 | In gnome-terminal and multi-gnome-terminal, which I use, cursor |
| | 150 | changes its color and becomes invisible. ("Green on black" color |
| | 151 | scheme and "Linux console" palette are used in both those programs.) |
| | 152 | |
| | 153 | Is it possible to make the same cursor color in positions of |
| | 154 | visualized tab an training space as in positions of other symbols? |
| 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 |
| | 203 | trailing but all - this is comfortable when hunting for |
| | 204 | double/multi spaces between words). |
| | 205 | -tabs are visible as arrows → (unicode 2192) (somethhing like -> mc |
| | 206 | uses semigraphics so can draw arrows too) |
| | 207 | -carriage returns are visible as reversed P character ¶ (unicode |
| | 208 | 00B6) |
| | 209 | (I know this is poor description but just run OO Writer or Word to |
| | 210 | see how these formating characters are marked). |
| | 211 | |
| | 212 | I really would like to see this patch in mc as default. It is very |
| | 213 | helpful and allows to keep .conf files clean. |
| 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. |
| | 217 | it just occurred to me, that i don't want two separate shortcuts |
| | 218 | for toggling these options. two separate persistent options in the |
| | 219 | config dialog are ok, but there should be only one "quick toggle" |
| | 220 | shortcut (ctrl-w) that disables both at once, and is not saved |
| | 221 | anywhere. |
| | 222 | i suppose the envisioned ctrl-s shortcut for toggling syntax |
| | 223 | highlighting should be non-persistent as well. |
| 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. :} |
| | 232 | ok, here's a patch which allows enabling visible trailing |
| | 233 | whitespace and visible tabs independently. i'm not eager to split |
| | 234 | it into two patches; they are too much related. |
| | 235 | i just threw in the options as variables right above the relevant |
| | 236 | function - i'd prefer you wrapping this into proper configurability |
| | 237 | (options in the edit config dialog and keyboard accels) yourself, |
| | 238 | as i'd have to research how to do it first. :} |
| 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. :-)=) |
| | 259 | well, tabs should stay tabs. masking them away in this special case |
| | 260 | would just lead to surprises. |
| | 261 | not sure about your example. it's true that it looks a bit weird. |
| | 262 | otoh, such whitespace is plainly broken, so it should look broken. |
| | 263 | :) also, if you change it, suddenly chars in the middle of a line |
| | 264 | will vanish/appear if you (append past/remove up to) the trailing |
| | 265 | tabs. it depends on whether one wants to get the static or the |
| | 266 | dynamic case nicer. |
| | 267 | the patch is really simple, so give it a try. after all, i have no |
| | 268 | particular opinion on this matter - i need to highlight trailing |
| | 269 | whitespace only to annihilate any occurrences of it anyway. :-)=) |
| 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, |
| | 289 | visible tabs help putting the tabs where you want them, |
| | 290 | particularly when trying to stay consistent with the style of text |
| | 291 | written by somebody else. |
| | 292 | making trailing whitespace visible helps avoiding it in undesired |
| | 293 | places. |
| | 294 | |
| | 295 | here is a patch that accomplishes this. it is missing an option to |
| | 296 | disable this feature, so i post this as a wish instead of as a |
| | 297 | patch. |
| | 298 | |
| | 299 | i wanted the visibility to be as subtle as possible. therefore just |
| | 300 | changing the background color (see leading tabs in Makefile |
| | 301 | highlite) was no option. so i paint tabs as excerpts of <------> |
| | 302 | and spaces as dots. to make it really subtle, i paint it bright |
| | 303 | blue on dark blue (the regular background) - this is hardly |
| | 304 | visible, unless you are looking for it. i know of no way to make it |
| | 305 | equally subtle on monochrome displays, |
| 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. |
| | 307 | the whitespace becomes invisible when the text is selected, as |
| | 308 | there is no possibility to merge colors. it'd be nice to fix this |
| | 309 | generally. |
| | 310 | the highlite color is not defined by syntax highlighting, but by an |
| | 311 | extra palette entry. i think this makes sense. |
| | 312 | this feature overrides other colors that might be defined for |
| | 313 | whitespace, like the red background of tabs in Makefiles. the block |
| | 314 | in #if 0 would preserve the color of already highlighted |
| | 315 | whitespace, but it's a too broad criterion. i don't think ignoring |
| | 316 | this fact is a problem, as you can recognize the tabs anyway |
| | 317 | (obviously). |
| | 318 | note, that you can't just copy such text from the terminal, as the |
| | 319 | pseudo-whitespace chars will show up in the copy. therefore a |
| | 320 | hotkey to switch it off quickly would be useful. otoh, a) the |
| | 321 | problem that this feature is disabled in selected blocks is an |
| | 322 | advantage in this context and b) by copying, you would be |
| | 323 | destroying the original whitespace anyway. |
