bug#4177: 23.1; whitespace-mode and typing spaces

bug#4177: 23.1; whitespace-mode and typing spaces

[Chong Yidong]

Hi Vinicius,

Could you take a look at the bug report #4177?  Thanks.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4177

bug#4177: 23.1; whitespace-mode and typing spaces

[Vinicius Jose Latorre]

Hi Eli,


All problems you had pointed out are due to the way whitespace uses 
font-lock.

I'll try to modified the font-lock programming using some functions 
(plus regular
expressions) instead of only regular expressions.

BTW, you said you are using quiet colors, could you send me back these 
colors?

 > `whitespace-mode' is generally very useful, but there are some
 > annoyances:
 >
 > * Unlike `show-trailing-whitespace', spaces at the end of a line are
 >   shown even if the cursor is right after them.  This means that just
 >   typing some text is flashing the highlights on and off (I'm sure
 >   that this would be extremely unpleasant if I wouldn't have chosen a
 >   very quiet color for that...).
 >
 > * In a similar way, if you type some stuff on a first line, then hit
 >   enter a few times, the whole empty part is highlighted (if empty
 >   line at the bob/eob are highlighted).  This is similar because in
 >   this case it is also likely that more text will eventually be
 >   entered.
 >
 > * There is another problems with highlighting the initial/final
 >   segment of empty lines -- looks like it's the problem of using
 >   font-lock with a multi-line pattern, which means that it's not
 >   dealing with it gracefully (eg, adding a line will un-highlight only
 >   the line right next to it).  Together with the last point, this
 >   means that if you do something like this (in a fresh buffer):
 >
 >     foo RET RET RET RET bar RET
 >
 >
 >   you're left with the middle highlighted.


Thanks for your report,


Vinicius

bug#4177: 23.1; whitespace-mode and typing spaces

[Eli Barzilay]

On Sep 13, Vinicius Jose Latorre wrote:
> Hi Eli,
> 
> All problems you had pointed out are due to the way whitespace uses
> font-lock.

Yes, I did say that it looks like problems that result of using
font-lock with a multi-line pattern.  I know that they're not working
great.  But it might be easy to resolve this by manually triggering a
re-fontification of the affected area -- for example, when you type
some non-whitespace, and you know that the current point is inside an
area of whitespace at the beginning of the buffer, then you re-fontify
from the point until the next non-whitespace character.


> I'll try to modified the font-lock programming using some functions
> (plus regular expressions) instead of only regular expressions.

... But what I described might be difficult, and it sounds like a bad
hack.  It's of course better if you know of a way to persuade
font-lock to work a little better.

(The highlights of whitespace at the buffer edges is the thing that
bugs me most about this.  There's also the problem of typing space at
the end of the line with the cursor following it -- the space
highlight being bogus because I'm going to type more stuff now.)


> BTW, you said you are using quiet colors, could you send me back
> these colors?

Well, it's just some shades of gray, that are not noisy enough to make
me twitch.  The thing is that I want to know about bad spaces and
tabs, but I do have to go through files that have lots of them and
often files that I cannot modify.  So the more festive colors are fine
if I only ever edit my code...

Below are my colors -- it's using my own syntax for determining
background colors but it should be obvious.  The first value is what I
use normally since my Emacs is white-on-black, the second is for uses
with the usual black-on-white.

   (trailing-whitespace         */gray20 */gray80)
   (whitespace-line             */gray20 */gray80)
   (whitespace-empty            */gray20 */gray80)
   (whitespace-trailing         */gray20 */gray80)
   (whitespace-space            */gray20 */gray80)
   (whitespace-hspace           */gray20 */gray80)
   (whitespace-tab              */gray20 */gray80)
   (whitespace-indentation      */h220   */hdd0)
   (whitespace-space-after-tab  */h220   */hdd0)
   (whitespace-space-before-tab */h440   */hbb0)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

bug#4177: 23.1; whitespace-mode and typing spaces

[Vinicius Jose Latorre]

Hi Eli,


I've just committed whitespace v12.0 in CVS.

This version fixes the problems you have pointed out.

Now the trailing spaces are not highlighted while point is at end of 
line.  Also the spaces at beginning of buffer are not highlighted while 
point is at beginning of buffer; and the spaces at end of buffer are not 
highlighted while point is at end of buffer.


Thanks for your report,


Vinicius


>> Hi Eli,
>>
>> All problems you had pointed out are due to the way whitespace uses
>> font-lock.
>>     
>
> Yes, I did say that it looks like problems that result of using
> font-lock with a multi-line pattern.  I know that they're not working
> great.  But it might be easy to resolve this by manually triggering a
> re-fontification of the affected area -- for example, when you type
> some non-whitespace, and you know that the current point is inside an
> area of whitespace at the beginning of the buffer, then you re-fontify
> from the point until the next non-whitespace character.
>
>
>   
>> I'll try to modified the font-lock programming using some functions
>> (plus regular expressions) instead of only regular expressions.
>>     
>
> ... But what I described might be difficult, and it sounds like a bad
> hack.  It's of course better if you know of a way to persuade
> font-lock to work a little better.
>
> (The highlights of whitespace at the buffer edges is the thing that
> bugs me most about this.  There's also the problem of typing space at
> the end of the line with the cursor following it -- the space
> highlight being bogus because I'm going to type more stuff now.)
>
>
>   
>> BTW, you said you are using quiet colors, could you send me back
>> these colors?
>>     
>
> Well, it's just some shades of gray, that are not noisy enough to make
> me twitch.  The thing is that I want to know about bad spaces and
> tabs, but I do have to go through files that have lots of them and
> often files that I cannot modify.  So the more festive colors are fine
> if I only ever edit my code...
>
> Below are my colors -- it's using my own syntax for determining
> background colors but it should be obvious.  The first value is what I
> use normally since my Emacs is white-on-black, the second is for uses
> with the usual black-on-white.
>
>    (trailing-whitespace         */gray20 */gray80)
>    (whitespace-line             */gray20 */gray80)
>    (whitespace-empty            */gray20 */gray80)
>    (whitespace-trailing         */gray20 */gray80)
>    (whitespace-space            */gray20 */gray80)
>    (whitespace-hspace           */gray20 */gray80)
>    (whitespace-tab              */gray20 */gray80)
>    (whitespace-indentation      */h220   */hdd0)
>    (whitespace-space-after-tab  */h220   */hdd0)
>    (whitespace-space-before-tab */h440   */hbb0)
>   

bug#4177: 23.1; whitespace-mode and typing spaces

[Eli Barzilay]

`whitespace-mode' is generally very useful, but there are some
annoyances:

* Unlike `show-trailing-whitespace', spaces at the end of a line are
  shown even if the cursor is right after them.  This means that just
  typing some text is flashing the highlights on and off (I'm sure
  that this would be extremely unpleasant if I wouldn't have chosen a
  very quiet color for that...).

* In a similar way, if you type some stuff on a first line, then hit
  enter a few times, the whole empty part is highlighted (if empty
  line at the bob/eob are highlighted).  This is similar because in
  this case it is also likely that more text will eventually be
  entered.

* There is another problems with highlighting the initial/final
  segment of empty lines -- looks like it's the problem of using
  font-lock with a multi-line pattern, which means that it's not
  dealing with it gracefully (eg, adding a line will un-highlight only
  the line right next to it).  Together with the last point, this
  means that if you do something like this (in a fresh buffer):

    foo RET RET RET RET bar RET

  you're left with the middle highlighted.




In GNU Emacs 23.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.14)
 of 2009-08-01 on winooski.ccs.neu.edu
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--prefix=/home/eli/bin/local/emacs-dir''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  whitespace-mode: t
  cua-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<up> <M-left> <left> <left> <M-S-right> <S-insert> 
<right> <S-end> <S-delete> M-\ <up> <end> <return> 
<S-insert> <down> <down> <home> <S-end> <delete> <delete> 
<up> <up> <f2> <end> <home> <tab> ; <tab> <f2> <f1> 
~ <C-S-left> <C-S-left> <C-S-left> o l d <tab> 2 <tab> 
e x <tab> e d i <tab> <C-S-left> <delete> <C-S-left> 
<delete> i n c <tab> e d i <tab> <return> C-s t u r 
n - o n <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <up> <C-left> <right> <left> C-h f s 
h o w - t r a i <tab> C-g C-h v s h o w - t r <tab> 
<tab> <tab> <tab> <return> <down> <down> <up> <C-left> 
<return> <C-tab> <C-f10> <C-up> <C-up> <C-up> <C-up> 
<C-up> <down> <down> <down> <C-left> <C-left> C-s C-w 
C-w C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s 
C-s C-s C-s C-s C-s C-s C-s C-s C-s <C-S-left> <C-S-left> 
<C-insert> <S-f9> <S-insert> <end> SPC * g z <home> 
<delete> z <return> <C-tab> <C-tab> <f12> <C-S-f12> 
<down> <down> <next> <next> <next> <up> <up> <up> <up> 
<down> <C-home> <C-end> <up> <up> <up> <return> <C-home> 
C-s w h i c h SPC s <C-down> <C-down> <f12> <next> 
<next> <next> <next> <next> <next> <next> <home> <right> 
<right> <right> <right> <right> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <next> <next> <next> 
<next> C-s p o i n t C-s C-s C-s C-s C-s C-s C-s <M-up> 
<down> <down> <down> <down> <M-left> <C-up> <C-up> 
<C-up> <up> <M-left> <left> <M-right> C-s C-s C-s C-s 
C-s C-s <M-down> <S-tab> <C-f10> <S-tab> <up> <up> 
<M-left> <M-S-right> <C-insert> M-x <up> <up> <ret
urn>

Recent messages:
Type "q" to quit, <next> to scroll help.
uncompressing frame.el.gz...done
Mark saved where search started
Grep finished with no matches found
Using truncated lines.
End of buffer
Mark set [3 times]
uncompressing whitespace.el.gz...done
Mark set
Mark saved where search started [3 times]