| 9 | | Discussion: |
| 10 | | {{{ |
| 11 | | Sun 06 Jul 2008 04:12:04 PM UTC, comment #24: |
| 12 | | |
| 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... |
| 22 | | |
| 23 | | (file #16007) |
| 24 | | Jan Engelhardt <hirogen2> |
| 25 | | Sun 06 Jul 2008 01:24:09 PM UTC, comment #23: |
| 26 | | |
| 27 | | Patch #4 -- cedit-symbol-prefs.diff |
| 28 | | |
| 29 | | This 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. |
| 32 | | |
| 33 | | (file #16006) |
| 34 | | Jan Engelhardt <hirogen2> |
| 35 | | Sun 06 Jul 2008 01:21:22 PM UTC, comment #22: |
| 36 | | |
| 37 | | Patch #3 -- cedit-fix-whitespace.diff |
| 38 | | |
| 39 | | We definitely need to set MOD_WHITESPACE or the space between tab |
| 40 | | stops is drawn with some random color. |
| 41 | | |
| 42 | | (file #16005) |
| 43 | | Jan Engelhardt <hirogen2> |
| 44 | | Sun 06 Jul 2008 01:19:54 PM UTC, comment #21: |
| 45 | | |
| 46 | | Patch #2 -- cedit-eol-mark.diff |
| 47 | | |
| 48 | | This patch implements comment #8's suggestion to use ¶ as an EOL |
| 49 | | marker. It can be toggled using the Options>Highlight options |
| 50 | | dialog, or, of course, by editing ~/.mc/config directly. |
| 51 | | |
| 52 | | (file #16004) |
| 53 | | Jan Engelhardt <hirogen2> |
| 54 | | Sun 06 Jul 2008 01:17:43 PM UTC, comment #20: |
| 55 | | |
| 56 | | Ok since nobody replied here are some patches of my own. |
| 57 | | They require that mc(edit) has COMPLETE support for UTF-8!, which |
| 58 | | is not the case in the mc source distribution. The openSUSE |
| 59 | | .src.rpm has the required utf8 bits. Will try to make them submit |
| 60 | | theirs. |
| 61 | | |
| 62 | | Patch #1 -- cedit-configurable-highlight.diff |
| 63 | | |
| 64 | | This is for comment #19; it allows to switch highlighting. Firstly, |
| 65 | | it adds a dialog (Options > Highlight options) where you can |
| 66 | | precisely select what to highlight |
| 67 | | |
| 68 | | [ ] Global syntax highlighting |
| 69 | | |
| 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. |
| 80 | | |
| 81 | | (file #16003) |
| 82 | | Jan Engelhardt <hirogen2> |
| 83 | | Fri 29 Feb 2008 07:16:33 PM UTC, comment #19: |
| 84 | | |
| 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. |
| 93 | | Jurrie Overgoor <leadpumper> |
| 94 | | Tue 04 Sep 2007 05:29:40 AM UTC, comment #18: |
| 95 | | |
| 96 | | Pavel, I applied your patch to vte-0.16.8. It works. |
| 97 | | Andrew Borodin <a_borodin> |
| 98 | | Mon 03 Sep 2007 01:15:42 PM UTC, comment #17: |
| 99 | | |
| 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. |
| 114 | | |
| 115 | | (file #13873) |
| 116 | | Pavel Tsekov <ptsekov> |
| 117 | | Project Administrator |
| 118 | | Fri 31 Aug 2007 04:19:43 PM UTC, comment #16: |
| 119 | | |
| 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. |
| 128 | | Pavel Tsekov <ptsekov> |
| 129 | | Project Administrator |
| 130 | | Fri 31 Aug 2007 09:28:17 AM UTC, comment #15: |
| 131 | | |
| 132 | | This may be a bug in gnome-terminal as well... I am also using |
| 133 | | gnome-terminal and no matter the color scheme the cursor is |
| 134 | | invisible. I'll investigate further... |
| 135 | | Pavel Tsekov <ptsekov> |
| 136 | | Project Administrator |
| 137 | | Fri 31 Aug 2007 06:07:28 AM UTC, comment #14: |
| 138 | | |
| 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? |
| 155 | | Andrew Borodin <a_borodin> |
| 156 | | Thu 30 Aug 2007 12:58:35 PM UTC, comment #13: |
| 157 | | |
| 158 | | that's weird ... i see no such effect (little surprisingly). though |
| 159 | | with some terminals/color combinations it becomes light blue, too, |
| 160 | | and thus hardly visible, but i don't think we can do much about |
| 161 | | that. |
| 162 | | Oswald Buddenhagen <ossi> |
| 163 | | Thu 30 Aug 2007 12:39:39 PM UTC, comment #12: |
| 164 | | |
| 165 | | Yep. As I said - i'll be fixing the patch... I prefer to have it in |
| 166 | | CVS even if it has minor glitches. In the meantime if you find any |
| 167 | | other problems with it - please, feel free to report them. |
| 168 | | Pavel Tsekov <ptsekov> |
| 169 | | Project Administrator |
| 170 | | Thu 30 Aug 2007 12:29:20 PM UTC, comment #11: |
| 171 | | |
| 172 | | Cursor in TAB and trailing space position is disappeared. This is |
| 173 | | very uncomfortable. |
| 174 | | Andrew Borodin <a_borodin> |
| 175 | | Mon 27 Aug 2007 12:08:04 PM UTC, comment #10: |
| 176 | | |
| 177 | | The patch is in CVS now. I've commited mcedit-visible-ws-v2.diff |
| 178 | | with no changes whatsoever ... I'll be making changes to it as |
| 179 | | discussed in this bugreport in the next few weeks. |
| 180 | | Pavel Tsekov <ptsekov> |
| 181 | | Project Administrator |
| 182 | | Thu 09 Aug 2007 08:53:35 PM UTC, comment #9: |
| 183 | | |
| 184 | | i considered making all whitespace visible, but somehow found it |
| 185 | | pointless and even counterproductive for my use cases. |
| 186 | | for linefeeds, i really see no use case ... |
| 187 | | regarding the use of special characters, this is not doable without |
| 188 | | utter hackery. mc is restricted to the abstract char set provided |
| 189 | | by ncurses/slang, which unfortunately does not provide these chars. |
| 190 | | Oswald Buddenhagen <ossi> |
| 191 | | Thu 09 Aug 2007 08:28:12 PM UTC, comment #8: |
| 192 | | |
| 193 | | This mcedit-visible-ws-v2.diff works great with mc-4.6.1 |
| 194 | | What a pity it is not inside mc by default. The light blue color is |
| 195 | | great - it shows invisible characters but not disturbs |
| 196 | | reading/editing. |
| 197 | | |
| 198 | | There is one little thing I would like to see: |
| 199 | | make tabs, all spaces and carriage returns visible like in OpenOffice/M$ Word. |
| 200 | | |
| 201 | | This means that: |
| 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. |
| 214 | | Zbigniew Luszpinski <mr_zbiggy> |
| 215 | | Sun 05 Feb 2006 04:51:56 PM UTC, comment #7: |
| 216 | | |
| 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. |
| 224 | | Oswald Buddenhagen <ossi> |
| 225 | | Mon 30 Jan 2006 05:16:22 PM UTC, comment #6: |
| 226 | | |
| 227 | | Single patch is OK. |
| 228 | | Pavel Tsekov <ptsekov> |
| 229 | | Project Administrator |
| 230 | | Mon 30 Jan 2006 04:33:20 PM UTC, comment #5: |
| 231 | | |
| 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. :} |
| 239 | | Oswald Buddenhagen <ossi> |
| 240 | | Mon 30 Jan 2006 04:19:36 PM UTC, comment #4: |
| 241 | | |
| 242 | | ok, i changed my mind - i have a strong opinion now. :) |
| 243 | | i think it's right that trailing tabs should not prevent preceeding |
| 244 | | spaces from being marked as trailing: if trailing whitespace |
| 245 | | removal is implemented, all these chars will be equally killed away. |
| 246 | | Oswald Buddenhagen <ossi> |
| 247 | | Mon 30 Jan 2006 03:53:54 PM UTC, comment #3: |
| 248 | | |
| 249 | | I did try it and have been playing with it for a while. This patch |
| 250 | | adds (1) visible trailing spaces and (2) visible tabs. In fact I |
| 251 | | prefer to think of it as two separate patches. As you suggested on |
| 252 | | the list it should be enhanced so that the user can switch this |
| 253 | | functionality on and off via a fast key. I would add that the user |
| 254 | | should be allowed to enable (1) without enabling (2) and vice versa. |
| 255 | | Pavel Tsekov <ptsekov> |
| 256 | | Project Administrator |
| 257 | | Mon 30 Jan 2006 03:35:14 PM UTC, comment #2: |
| 258 | | |
| 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. :-)=) |
| 270 | | Oswald Buddenhagen <ossi> |
| 271 | | Mon 30 Jan 2006 03:09:00 PM UTC, comment #1: |
| 272 | | |
| 273 | | How about considering the trailing tabs a trailing whitespace too |
| 274 | | and marking all the traling whitespace with just a dot ? |
| 275 | | |
| 276 | | Now if a have a like like this: |
| 277 | | |
| 278 | | int func()<space><space><space><space><tab><tab> |
| 279 | | |
| 280 | | i get |
| 281 | | |
| 282 | | int func() <><------><------> |
| 283 | | |
| 284 | | This is pretty inconsistent and annoying (IMO). |
| 285 | | Pavel Tsekov <ptsekov> |
| 286 | | Project Administrator |
| 287 | | Sat 21 May 2005 07:25:17 PM UTC, original submission: |
| 288 | | |
| | 9 | Original submission: |
| | 10 | {{{ |
| | 47 | |
| | 48 | Comment 1 by Pavel Tsekov <ptsekov> at Mon 30 Jan 2006 03:09:00 PM UTC: |
| | 49 | {{{ |
| | 50 | How about considering the trailing tabs a trailing whitespace too |
| | 51 | and marking all the traling whitespace with just a dot ? |
| | 52 | |
| | 53 | Now if a have a like like this: |
| | 54 | |
| | 55 | int func()<space><space><space><space><tab><tab> |
| | 56 | |
| | 57 | i get |
| | 58 | |
| | 59 | int func() <><------><------> |
| | 60 | |
| | 61 | This is pretty inconsistent and annoying (IMO). |
| | 62 | }}} |
| | 63 | |
| | 64 | Comment 2 by Oswald Buddenhagen <ossi> at Mon 30 Jan 2006 03:35:14 PM UTC: |
| | 65 | {{{ |
| | 66 | well, tabs should stay tabs. masking them away in this special case |
| | 67 | would just lead to surprises. |
| | 68 | not sure about your example. it's true that it looks a bit weird. |
| | 69 | otoh, such whitespace is plainly broken, so it should look broken. |
| | 70 | :) also, if you change it, suddenly chars in the middle of a line |
| | 71 | will vanish/appear if you (append past/remove up to) the trailing |
| | 72 | tabs. it depends on whether one wants to get the static or the |
| | 73 | dynamic case nicer. |
| | 74 | the patch is really simple, so give it a try. after all, i have no |
| | 75 | particular opinion on this matter - i need to highlight trailing |
| | 76 | whitespace only to annihilate any occurrences of it anyway. :-)=) |
| | 77 | }}} |
| | 78 | |
| | 79 | Comment 3 by Pavel Tsekov <ptsekov> at Mon 30 Jan 2006 03:53:54 PM UTC: |
| | 80 | {{{ |
| | 81 | I did try it and have been playing with it for a while. This patch |
| | 82 | adds (1) visible trailing spaces and (2) visible tabs. In fact I |
| | 83 | prefer to think of it as two separate patches. As you suggested on |
| | 84 | the list it should be enhanced so that the user can switch this |
| | 85 | functionality on and off via a fast key. I would add that the user |
| | 86 | should be allowed to enable (1) without enabling (2) and vice versa. |
| | 87 | }}} |
| | 88 | |
| | 89 | Comment 4 by Oswald Buddenhagen <ossi> at Mon 30 Jan 2006 04:19:36 PM UTC: |
| | 90 | {{{ |
| | 91 | ok, i changed my mind - i have a strong opinion now. :) |
| | 92 | i think it's right that trailing tabs should not prevent preceeding |
| | 93 | spaces from being marked as trailing: if trailing whitespace |
| | 94 | removal is implemented, all these chars will be equally killed away. |
| | 95 | }}} |
| | 96 | |
| | 97 | Comment 5 by Oswald Buddenhagen <ossi> at Mon 30 Jan 2006 04:33:20 PM UTC: |
| | 98 | {{{ |
| | 99 | ok, here's a patch which allows enabling visible trailing |
| | 100 | whitespace and visible tabs independently. i'm not eager to split |
| | 101 | it into two patches; they are too much related. |
| | 102 | i just threw in the options as variables right above the relevant |
| | 103 | function - i'd prefer you wrapping this into proper configurability |
| | 104 | (options in the edit config dialog and keyboard accels) yourself, |
| | 105 | as i'd have to research how to do it first. :} |
| | 106 | }}} |
| | 107 | |
| | 108 | Comment 6 by Pavel Tsekov <ptsekov> at Mon 30 Jan 2006 05:16:22 PM UTC: |
| | 109 | {{{ |
| | 110 | Single patch is OK. |
| | 111 | }}} |
| | 112 | |
| | 113 | Comment 7 by Oswald Buddenhagen <ossi> at Sun 05 Feb 2006 04:51:56 PM UTC: |
| | 114 | {{{ |
| | 115 | it just occurred to me, that i don't want two separate shortcuts |
| | 116 | for toggling these options. two separate persistent options in the |
| | 117 | config dialog are ok, but there should be only one "quick toggle" |
| | 118 | shortcut (ctrl-w) that disables both at once, and is not saved |
| | 119 | anywhere. |
| | 120 | i suppose the envisioned ctrl-s shortcut for toggling syntax |
| | 121 | highlighting should be non-persistent as well. |
| | 122 | }}} |
| | 123 | |
| | 124 | Comment 8 by Zbigniew Luszpinski <mr_zbiggy> at Thu 09 Aug 2007 08:28:12 PM UTC: |
| | 125 | {{{ |
| | 126 | This mcedit-visible-ws-v2.diff works great with mc-4.6.1 |
| | 127 | What a pity it is not inside mc by default. The light blue color is |
| | 128 | great - it shows invisible characters but not disturbs |
| | 129 | reading/editing. |
| | 130 | |
| | 131 | There is one little thing I would like to see: |
| | 132 | make tabs, all spaces and carriage returns visible like in OpenOffice/M$ Word. |
| | 133 | |
| | 134 | This means that: |
| | 135 | -all spaces are visible as dots ···· (unicode 00B7) (not only |
| | 136 | trailing but all - this is comfortable when hunting for |
| | 137 | double/multi spaces between words). |
| | 138 | -tabs are visible as arrows → (unicode 2192) (somethhing like -> mc |
| | 139 | uses semigraphics so can draw arrows too) |
| | 140 | -carriage returns are visible as reversed P character ¶ (unicode |
| | 141 | 00B6) |
| | 142 | (I know this is poor description but just run OO Writer or Word to |
| | 143 | see how these formating characters are marked). |
| | 144 | |
| | 145 | I really would like to see this patch in mc as default. It is very |
| | 146 | helpful and allows to keep .conf files clean. |
| | 147 | }}} |
| | 148 | |
| | 149 | Comment 9 by Oswald Buddenhagen <ossi> at Thu 09 Aug 2007 08:53:35 PM UTC: |
| | 150 | {{{ |
| | 151 | i considered making all whitespace visible, but somehow found it |
| | 152 | pointless and even counterproductive for my use cases. |
| | 153 | for linefeeds, i really see no use case ... |
| | 154 | regarding the use of special characters, this is not doable without |
| | 155 | utter hackery. mc is restricted to the abstract char set provided |
| | 156 | by ncurses/slang, which unfortunately does not provide these chars. |
| | 157 | }}} |
| | 158 | |
| | 159 | Comment 10 by Pavel Tsekov <ptsekov> at Mon 27 Aug 2007 12:08:04 PM UTC: |
| | 160 | {{{ |
| | 161 | The patch is in CVS now. I've commited mcedit-visible-ws-v2.diff |
| | 162 | with no changes whatsoever ... I'll be making changes to it as |
| | 163 | discussed in this bugreport in the next few weeks. |
| | 164 | }}} |
| | 165 | |
| | 166 | Comment 11 by Andrew Borodin <a_borodin> at Thu 30 Aug 2007 12:29:20 PM UTC: |
| | 167 | {{{ |
| | 168 | Cursor in TAB and trailing space position is disappeared. This is |
| | 169 | very uncomfortable. |
| | 170 | }}} |
| | 171 | |
| | 172 | Comment 12 by Pavel Tsekov <ptsekov> at Thu 30 Aug 2007 12:39:39 PM UTC: |
| | 173 | {{{ |
| | 174 | Yep. As I said - i'll be fixing the patch... I prefer to have it in |
| | 175 | CVS even if it has minor glitches. In the meantime if you find any |
| | 176 | other problems with it - please, feel free to report them. |
| | 177 | }}} |
| | 178 | |
| | 179 | Comment 13 by Oswald Buddenhagen <ossi> at Thu 30 Aug 2007 12:58:35 PM UTC: |
| | 180 | {{{ |
| | 181 | that's weird ... i see no such effect (little surprisingly). though |
| | 182 | with some terminals/color combinations it becomes light blue, too, |
| | 183 | and thus hardly visible, but i don't think we can do much about |
| | 184 | that. |
| | 185 | }}} |
| | 186 | |
| | 187 | Comment 14 by Andrew Borodin <a_borodin> at Fri 31 Aug 2007 06:07:28 AM UTC: |
| | 188 | {{{ |
| | 189 | Oswald, you are right. This effect is depending on terminal |
| | 190 | emulation program and color scheme. |
| | 191 | |
| | 192 | In linux console, cursor is visible every time. The color of cursor |
| | 193 | is changed to light blue in tab and trailing space positions, but |
| | 194 | cursor is visible. |
| | 195 | |
| | 196 | The same is in xterm under X. xterm doesn't have any non-default |
| | 197 | cursor settings. |
| | 198 | |
| | 199 | In gnome-terminal and multi-gnome-terminal, which I use, cursor |
| | 200 | changes its color and becomes invisible. ("Green on black" color |
| | 201 | scheme and "Linux console" palette are used in both those programs.) |
| | 202 | |
| | 203 | Is it possible to make the same cursor color in positions of |
| | 204 | visualized tab an training space as in positions of other symbols? |
| | 205 | }}} |
| | 206 | |
| | 207 | Comment 15 by Pavel Tsekov <ptsekov> at Fri 31 Aug 2007 09:28:17 AM UTC: |
| | 208 | {{{ |
| | 209 | This may be a bug in gnome-terminal as well... I am also using |
| | 210 | gnome-terminal and no matter the color scheme the cursor is |
| | 211 | invisible. I'll investigate further... |
| | 212 | }}} |
| | 213 | |
| | 214 | Comment 16 by Pavel Tsekov <ptsekov> at Fri 31 Aug 2007 04:19:43 PM UTC: |
| | 215 | {{{ |
| | 216 | IMO, this must be a bug in gnome-terminal. It doesn't behave |
| | 217 | properly if one uses both the bright and normal colors as the |
| | 218 | background and foreground of the same cell. I changed the |
| | 219 | the definition of "editwhitespace" to "brightred,red" and the |
| | 220 | cursor is not displayed in this case as well. I also changed the |
| | 221 | color for brightblue in my gnome-terminal profile to a different |
| | 222 | color but no matter the cursor wasnt displayed. I'll see if they |
| | 223 | have a bugreport in their bugzilla. |
| | 224 | }}} |
| | 225 | |
| | 226 | Comment 17 by Pavel Tsekov <ptsekov> at Mon 03 Sep 2007 01:15:42 PM UTC: |
| | 227 | {{{ |
| | 228 | Ok. I tracked the "bug" to vte_terminal_determine_colors() in the |
| | 229 | vte package. To request brighter colors one forces the terminal |
| | 230 | into "bold mode". It seems that in this mode vte allows only the |
| | 231 | foreground color to be bright. In vte's terms a bright color is the |
| | 232 | same color as the normal one but with a special flag set. So what |
| | 233 | happens is that when the time comes for the cursor to blink vte |
| | 234 | switches the current forground color with the current background |
| | 235 | color and vice versa... As I said above |
| | 236 | both colors are indentified in the same way but one has a special |
| | 237 | flag, however vte uses this flag to brighten the foreground color |
| | 238 | so at the end we end up as if nothing happened. It's hard to say |
| | 239 | whether this is the desired behaviour .. I'll attach a simple patch |
| | 240 | which changes vte to do what seems more logically correct... and |
| | 241 | I'll open a report in gnome's bugzilla. |
| | 242 | |
| | 243 | (file #13873) |
| | 244 | }}} |
| | 245 | |
| | 246 | Comment 18 by Andrew Borodin <a_borodin> at Tue 04 Sep 2007 05:29:40 AM UTC: |
| | 247 | {{{ |
| | 248 | Pavel, I applied your patch to vte-0.16.8. It works. |
| | 249 | }}} |
| | 250 | |
| | 251 | Comment 19 by Jurrie Overgoor <leadpumper> at Fri 29 Feb 2008 07:16:33 PM UTC: |
| | 252 | {{{ |
| | 253 | Oh, god... I just updated my Debian box, and I now run MC |
| | 254 | 4.6.2-pre1 (as outputted by mcedit --version). It appears that this |
| | 255 | patch is included in this version of mcedit. I really dislike it. |
| | 256 | Besides suffering from the 'cursor disappearing' thingy, I just |
| | 257 | think its ugly. But that's my humble opinion :) |
| | 258 | How can I disable it? The patches attached to this report don't |
| | 259 | seem to make a new configurable parameter available in the |
| | 260 | configuration dialogs. |
| | 261 | }}} |
| | 262 | |
| | 263 | Comment 20 by Jan Engelhardt <hirogen2> at Sun 06 Jul 2008 01:17:43 PM UTC: |
| | 264 | {{{ |
| | 265 | Ok since nobody replied here are some patches of my own. |
| | 266 | They require that mc(edit) has COMPLETE support for UTF-8!, which |
| | 267 | is not the case in the mc source distribution. The openSUSE |
| | 268 | .src.rpm has the required utf8 bits. Will try to make them submit |
| | 269 | theirs. |
| | 270 | |
| | 271 | Patch #1 -- cedit-configurable-highlight.diff |
| | 272 | |
| | 273 | This is for comment #19; it allows to switch highlighting. Firstly, |
| | 274 | it adds a dialog (Options > Highlight options) where you can |
| | 275 | precisely select what to highlight |
| | 276 | |
| | 277 | [ ] Global syntax highlighting |
| | 278 | |
| | 279 | [ ] Tab highlighting (those <------> markers, which, btw, can get |
| | 280 | very ugly if you have lots of code) |
| | 281 | |
| | 282 | [ ] Whitespace highlighting (dots at the end-of-line, and, if tab |
| | 283 | highlighting is disabled, anywhere on the line) |
| | 284 | |
| | 285 | One can already toggle Syntax highlighting with Ctrl-S in mc 4.6.2, |
| | 286 | for the latter two, I added Ctrl-V as a hotkey which cycles through |
| | 287 | the possibilities. My personal preference is to have Tab highlight |
| | 288 | OFF and Whitespace highlight ON. |
| | 289 | |
| | 290 | (file #16003) |
| | 291 | }}} |
| | 292 | |
| | 293 | Comment 21 by Jan Engelhardt <hirogen2> at Sun 06 Jul 2008 01:19:54 PM UTC: |
| | 294 | {{{ |
| | 295 | Patch #2 -- cedit-eol-mark.diff |
| | 296 | |
| | 297 | This patch implements comment #8's suggestion to use ¶ as an EOL |
| | 298 | marker. It can be toggled using the Options>Highlight options |
| | 299 | dialog, or, of course, by editing ~/.mc/config directly. |
| | 300 | |
| | 301 | (file #16004) |
| | 302 | }}} |
| | 303 | |
| | 304 | Comment 22 by Jan Engelhardt <hirogen2> at Sun 06 Jul 2008 01:21:22 PM UTC: |
| | 305 | {{{ |
| | 306 | Patch #3 -- cedit-fix-whitespace.diff |
| | 307 | |
| | 308 | We definitely need to set MOD_WHITESPACE or the space between tab |
| | 309 | stops is drawn with some random color. |
| | 310 | |
| | 311 | (file #16005) |
| | 312 | }}} |
| | 313 | |
| | 314 | Comment 23 by Jan Engelhardt <hirogen2> at Sun 06 Jul 2008 01:24:09 PM UTC: |
| | 315 | {{{ |
| | 316 | Patch #4 -- cedit-symbol-prefs.diff |
| | 317 | |
| | 318 | This patch changes the space fill character to some Unicode dot (·) |
| | 319 | [this one is also available on the text console], and makes the |
| | 320 | <------> tab filler into the Unicode ◀──────▶ too. |
| | 321 | |
| | 322 | (file #16006) |
| | 323 | }}} |
| | 324 | |
| | 325 | Comment 24 by Jan Engelhardt <hirogen2> at Sun 06 Jul 2008 04:12:04 PM UTC: |
| | 326 | {{{ |
| | 327 | I noticed I cannot just use the Unicode characters (like p->ch = |
| | 328 | 0xB7), as that does not take into account terminals that are not in |
| | 329 | UTF-8. But the fix is simple enough (p->ch = SLsmg_Is_Unicode ? 0xB7 : "."). |
| | 330 | |
| | 331 | BTW, I also implemented the MS Word-style "tabs", i.e. printing a |
| | 332 | right-arrow in the middle of a tab. I sort of prefer it over the |
| | 333 | "<---->" tabs. It is a patch that currently replaces the existing |
| | 334 | tab mechanism, but IMHO this should all be made configurable once |
| | 335 | the maintainers decide to wake up and give me some sort of ok... |
| | 336 | |
| | 337 | (file #16007) |
| | 338 | }}} |