23.0.60; whitespace.el mishap

23.0.60; whitespace.el mishap

[Michael Welsh Duggan]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Given the c buffer:

int main()
{
    if (1) {
        x = foo;
    }
    return 0;
}


`M-x whitespace-cleanup' will result in:

int main()
{
    if (1) {
        x= foo;
    }
    return 0;
}

This is because `whitespace-indentation-regexp' includes a trailing
"[^\n\t]", which matches the x.  After `re-search-forward' of
`whitespace-cleanup-region' the point is now after the `x'.  In order
for the subsequent `delete-horizontal-space' to work, a 
(forward-char -1) should probably be done, before the
`current-indentation' call.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/home/mwd/share/emacs/23.0.60/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu, GTK+ Version 2.10.4)
 of 2008-02-05 on maru.green.cert.org
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--prefix=/home/mwd' '--without-toolkit-scroll-bars' '--with-gif=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-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-compression-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n <escape> > C-w C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-e C-b C-b 
C-b C-b C-b SPC C-x C-s C-b C-b SPC C-x C-s C-f C-d 
C-x C-s C-a C-SPC C-n <switch-frame> q C-x 4 b <return> 
C-p C-SPC C-n M-x M-p <return> <switch-frame> SPC <switch-frame> 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC q <switch-frame> C-p C-p C-e C-p 
C-e <return> <tab> ( f o r w a r d - c j h a <backspace> 
<backspace> <backspace> h a r SPC - 1 ) C-x C-s C-u 
C-M-x <switch-frame> C-_ C-n <backspace> C-p C-a C-SPC 
C-n M-x M-p <return> <switch-frame> SPC C-_ <switch-frame> 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
<switch-frame> C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
<switch-frame> M-x r e p o r t - e m a c s - 0 <backspace> 
b <tab> <return>

Recent messages:
Result: nil

Result: nil
 [2 times]
Result: #<marker at 236 in fooo.c>

Result: #<marker in no buffer>

Result: #<marker in no buffer>


-- 
Michael Welsh Duggan
(mwd@cert.org)

Re: 23.0.60; whitespace.el mishap

[Rajesh Vaidheeswarran]

I'll check out the bug. Thanks for the report.

But, I'm a bit confused. Does this crash emacs?

rv

Michael Welsh Duggan wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> Given the c buffer:
>
> int main()
> {
>     if (1) {
>         x = foo;
>     }
>     return 0;
> }
>
>
> `M-x whitespace-cleanup' will result in:
>
> int main()
> {
>     if (1) {
>         x= foo;
>     }
>     return 0;
> }
>
> This is because `whitespace-indentation-regexp' includes a trailing
> "[^\n\t]", which matches the x.  After `re-search-forward' of
> `whitespace-cleanup-region' the point is now after the `x'.  In order
> for the subsequent `delete-horizontal-space' to work, a 
> (forward-char -1) should probably be done, before the
> `current-indentation' call.
>
>
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /home/mwd/share/emacs/23.0.60/etc/DEBUG for instructions.
>
>
> In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu, GTK+ Version 2.10.4)
>  of 2008-02-05 on maru.green.cert.org
> Windowing system distributor `The X.Org Foundation', version 11.0.70101000
> configured using `configure  '--prefix=/home/mwd' '--without-toolkit-scroll-bars' '--with-gif=no''
>
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   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.UTF-8
>   value of $XMODIFIERS: @im=none
>   locale-coding-system: utf-8-unix
>   default-enable-multibyte-characters: t
>
> Major mode: C/l
>
> Minor modes in effect:
>   shell-dirtrack-mode: t
>   display-time-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   menu-bar-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-compression-mode: t
>   line-number-mode: t
>   abbrev-mode: t
>
> Recent input:
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n <escape> > C-w C-p C-p C-p C-p C-p C-p 
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-e C-b C-b 
> C-b C-b C-b SPC C-x C-s C-b C-b SPC C-x C-s C-f C-d 
> C-x C-s C-a C-SPC C-n <switch-frame> q C-x 4 b <return> 
> C-p C-SPC C-n M-x M-p <return> <switch-frame> SPC <switch-frame> 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC q <switch-frame> C-p C-p C-e C-p 
> C-e <return> <tab> ( f o r w a r d - c j h a <backspace> 
> <backspace> <backspace> h a r SPC - 1 ) C-x C-s C-u 
> C-M-x <switch-frame> C-_ C-n <backspace> C-p C-a C-SPC 
> C-n M-x M-p <return> <switch-frame> SPC C-_ <switch-frame> 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> <switch-frame> C-p C-p C-p C-p C-p C-p C-p C-p C-p 
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
> <switch-frame> M-x r e p o r t - e m a c s - 0 <backspace> 
> b <tab> <return>
>
> Recent messages:
> Result: nil
>
> Result: nil
>  [2 times]
> Result: #<marker at 236 in fooo.c>
>
> Result: #<marker in no buffer>
>
> Result: #<marker in no buffer>
>
>
>   

Re: 23.0.60; whitespace.el mishap

[Michael Welsh Duggan]

Rajesh Vaidheeswarran <rv@gnu.org> writes:

> I'll check out the bug. Thanks for the report.
>
> But, I'm a bit confused. Does this crash emacs?

No, sorry.  I was in a rush and forgot to elide the crash portion of the
default bug reporting error message.

> Michael Welsh Duggan wrote:
>> Please describe exactly what actions triggered the bug
>> and the precise symptoms of the bug:
>>
>> Given the c buffer:
>>
>> int main()
>> {
>>     if (1) {
>>         x = foo;
>>     }
>>     return 0;
>> }
>>
>>
>> `M-x whitespace-cleanup' will result in:
>>
>> int main()
>> {
>>     if (1) {
>>         x= foo;
>>     }
>>     return 0;
>> }
>>
>> This is because `whitespace-indentation-regexp' includes a trailing
>> "[^\n\t]", which matches the x.  After `re-search-forward' of
>> `whitespace-cleanup-region' the point is now after the `x'.  In order
>> for the subsequent `delete-horizontal-space' to work, a
>> (forward-char -1) should probably be done, before the
>> `current-indentation' call.
>>
>> In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu, GTK+ Version 2.10.4)
>>  of 2008-02-05 on maru.green.cert.org
>> Windowing system distributor `The X.Org Foundation', version 11.0.70101000
>> configured using `configure  '--prefix=/home/mwd' '--without-toolkit-scroll-bars' '--with-gif=no''
>>
>> Important settings:
>>   value of $LC_ALL: nil
>>   value of $LC_COLLATE: nil
>>   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.UTF-8
>>   value of $XMODIFIERS: @im=none
>>   locale-coding-system: utf-8-unix
>>   default-enable-multibyte-characters: t
>>
>> Major mode: C/l
>>
>> Minor modes in effect:
>>   shell-dirtrack-mode: t
>>   display-time-mode: t
>>   tooltip-mode: t
>>   mouse-wheel-mode: t
>>   menu-bar-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-compression-mode: t
>>   line-number-mode: t
>>   abbrev-mode: t
>>
>> Recent input:
>> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
>> C-n C-n C-n <escape> > C-w C-p C-p C-p C-p C-p C-p 
>> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-e C-b C-b 
>> C-b C-b C-b SPC C-x C-s C-b C-b SPC C-x C-s C-f C-d 
>> C-x C-s C-a C-SPC C-n <switch-frame> q C-x 4 b <return> C-p C-SPC
>> C-n M-x M-p <return> <switch-frame> SPC <switch-frame> SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC q <switch-frame> C-p C-p
>> C-e C-p 
>> C-e <return> <tab> ( f o r w a r d - c j h a <backspace> <backspace>
>> <backspace> h a r SPC - 1 ) C-x C-s C-u 
>> C-M-x <switch-frame> C-_ C-n <backspace> C-p C-a C-SPC C-n M-x M-p
>> <return> <switch-frame> SPC C-_ <switch-frame> SPC SPC SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
>> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
>> SPC <switch-frame> C-p C-p C-p C-p C-p C-p C-p C-p C-p 
>> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
>> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
>> <switch-frame> M-x r e p o r t - e m a c s - 0 <backspace> b <tab>
>> <return>
>>
>> Recent messages:
>> Result: nil
>>
>> Result: nil
>>  [2 times]
>> Result: #<marker at 236 in fooo.c>
>>
>> Result: #<marker in no buffer>
>>
>> Result: #<marker in no buffer>
>>
>>
>>   
>

-- 
Michael Welsh Duggan
(mwd@cert.org)

Re: 23.0.60; whitespace.el mishap

[Rajesh Vaidheeswarran]

Michael Welsh Duggan wrote:
> Rajesh Vaidheeswarran <rv@gnu.org> writes:
>
>   
>> I'll check out the bug. Thanks for the report.
>>
>> But, I'm a bit confused. Does this crash emacs?
>>     
>
> No, sorry.

That's good. However, I'm unable to reproduce it on the installed emacs 
in fencepost.

GNU Emacs 22.1.1 (x86_64-pc-linux-gnu) of 2008-01-22 on osmium, modified 
by Ubuntu

So, I figured I'd build a version from sources, and I seem to be having 
trouble building it

% make
Your tree does not include the compiled Lisp files.
You need to do `make bootstrap' to build Emacs.
make: *** [maybe_bootstrap] Error 1
% make bootstrap
(cd src;      make  mostlyclean)
make[1]: Entering directory `/srv/data/home/r/rv/homes/fsf/emacs-build/src'
make[1]: *** No rule to make target `mostlyclean'.  Stop.
make[1]: Leaving directory `/srv/data/home/r/rv/homes/fsf/emacs-build/src'
make: *** [bootstrap-clean-before-fast] Error 2

So, can you help me and do a couple of things...

1. I could not know from your mail if your example had been munged or 
not by the mail client. Can you send me the example with spaces and tabs 
marked <s> and <t>, i.e., query-replace ' ' with <s> and tab with <t>

2. If you have access to fencepost, can you please repeat this test on 
emacs 22 installed there?

Thanks
rv

Re: 23.0.60; whitespace.el mishap

[Glenn Morris]

Rajesh Vaidheeswarran wrote:

> That's good. However, I'm unable to reproduce it on the installed emacs 
> in fencepost.

In case you're confused, the whitespace.el in question is not the one
you wrote (as far as I can tell). Someone recently renamed that one to
old-whitespace.el and installed a new one, which seems like a recipe
for exactly this kind of confusion. This "whitespace.el" is only in
the Emacs CVS trunk (I think).

Re: 23.0.60; whitespace.el mishap

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>> That's good. However, I'm unable to reproduce it on the installed emacs 
>> in fencepost.
>
> In case you're confused, the whitespace.el in question is not the one
> you wrote (as far as I can tell). Someone recently renamed that one to
> old-whitespace.el and installed a new one, which seems like a recipe
> for exactly this kind of confusion. This "whitespace.el" is only in
> the Emacs CVS trunk (I think).

I gather that Richard wanted the new functionality to use the
"whitespace" name, which makes some sense, but it seems seems to have
been done rather clumsily in some cases.  E.g. the new
"whitespace-buffer" command seems completely different than the old
"whitespace-buffer" command, and really there seems no good reason for
it.  [It's more or less a mode, but isn't called "...-mode", doesn't
follow emacs mode conventions well, e.g., it doesn't togglex, and
there's _also_ "whitespace-mode" which offers different, but related,
functionality...]

-miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: 23.0.60; whitespace.el mishap

[Rajesh Vaidheeswarran]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Yes, I am now really confused. Looks like I missed the booting out of the
whitespace.el that I wrote. I did see that the whitespace-buffer was
behaving differently, but chalked it up to me being tired late at night.

So, I guess, at this point, someone else is responsible for fixing this.

rv

On Feb 7, 2008 1:03 AM, Miles Bader <miles.bader@necel.com> wrote:

> Glenn Morris <rgm@gnu.org> writes:
> >> That's good. However, I'm unable to reproduce it on the installed emacs
> >> in fencepost.
> >
> > In case you're confused, the whitespace.el in question is not the one
> > you wrote (as far as I can tell). Someone recently renamed that one to
> > old-whitespace.el and installed a new one, which seems like a recipe
> > for exactly this kind of confusion. This "whitespace.el" is only in
> > the Emacs CVS trunk (I think).
>
> I gather that Richard wanted the new functionality to use the
> "whitespace" name, which makes some sense, but it seems seems to have
> been done rather clumsily in some cases.  E.g. the new
> "whitespace-buffer" command seems completely different than the old
> "whitespace-buffer" command, and really there seems no good reason for
> it.  [It's more or less a mode, but isn't called "...-mode", doesn't
> follow emacs mode conventions well, e.g., it doesn't togglex, and
> there's _also_ "whitespace-mode" which offers different, but related,
> functionality...]
>
> -miles
>
> --
> My books focus on timeless truths.  -- Donald Knuth
>

[-- Attachment #2: Type: text/html, Size: 2005 bytes --]

Re: 23.0.60; whitespace.el mishap

[Richard Stallman]

    I gather that Richard wanted the new functionality to use the
    "whitespace" name, which makes some sense, but it seems seems to have
    been done rather clumsily in some cases.  E.g. the new
    "whitespace-buffer" command seems completely different than the old
    "whitespace-buffer" command, and really there seems no good reason for
    it.

Vinicius, can you fix up these wrinkles?

Re: 23.0.60; whitespace.el mishap

[Vinicius Jose Latorre]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

>    I gather that Richard wanted the new functionality to use the
>    "whitespace" name, which makes some sense, but it seems seems to have
>    been done rather clumsily in some cases.  E.g. the new
>    "whitespace-buffer" command seems completely different than the old
>    "whitespace-buffer" command, and really there seems no good reason for
>    it.
>
> Vinicius, can you fix up these wrinkles?



Yes, I can when I return back to my city.

[-- Attachment #2: Type: text/html, Size: 778 bytes --]

Re: 23.0.60; whitespace.el mishap

[Miles Bader]

Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:
> Well, indeed the old whitespace-buffer had reported
> where the bogus whitespace had happened.
>
> Instead of reporting, the new whitespace-mode
> displays visually the bogus whitespace.
>
> Is it ok if the new whitespace-buffer is removed?
>
> Maybe a better alternative should be to create a
> whitespace-report command which reports like the old
> whitespace-buffer.

My personal opinion is that the old whitespace mode was pretty wacky,
and had lots of unneeded features and features which didn't follow Emacs
conventions.  It doesn't seem necessary to me to _exactly_ preserve the
interface (maybe some def-obsolete-alias could be used in some case),
just keep those commands which were actually useful, and maybe try to
make them follow emacs conventions better.

E.g., how about:

  + `suspicious-whitespace-mode' -- highlights only "suspicious"
    whitespace, i.e., that which probably should be removed. This is
    sort of like the old "whitespace-buffer" command, but implemented as
    a proper mode, or like your "whitespace-mode", but only highlights
    suspicious whitespace.  [dunno about the term "suspicious", but you
    know what I mean]

  + `cleanup-whitespace' -- removes suspicious whitespace [same
    definition as suspicious-whitespace-mode]

-Miles

-- 
Defenceless, adj. Unable to attack.

Re: 23.0.60; whitespace.el mishap

[Vinicius Jose Latorre]

>     I gather that Richard wanted the new functionality to use the
>     "whitespace" name, which makes some sense, but it seems seems to have
>     been done rather clumsily in some cases.  E.g. the new
>     "whitespace-buffer" command seems completely different than the old
>     "whitespace-buffer" command, and really there seems no good reason for
>     it.
>
> Vinicius, can you fix up these wrinkles?
>   

Well, indeed the old whitespace-buffer had reported
where the bogus whitespace had happened.

Instead of reporting, the new whitespace-mode
displays visually the bogus whitespace.

Is it ok if the new whitespace-buffer is removed?

Maybe a better alternative should be to create a
whitespace-report command which reports like the old
whitespace-buffer.

Opinions...

Re: 23.0.60; whitespace.el mishap

[Vinicius Jose Latorre]

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> Given the c buffer:
>
> int main()
> {
>     if (1) {
>         x = foo;
>     }
>     return 0;
> }
>
>
> `M-x whitespace-cleanup' will result in:
>
> int main()
> {
>     if (1) {
>         x= foo;
>     }
>     return 0;
> }
>
> This is because `whitespace-indentation-regexp' includes a trailing
> "[^\n\t]", which matches the x.  After `re-search-forward' of
> `whitespace-cleanup-region' the point is now after the `x'.  In order
> for the subsequent `delete-horizontal-space' to work, a 
> (forward-char -1) should probably be done, before the
> `current-indentation' call.
>   

Yes, I can reproduce the problem and I'll send a fix sooner.

Re: 23.0.60; whitespace.el mishap

[Vinicius Jose Latorre]

>> Well, indeed the old whitespace-buffer had reported
>> where the bogus whitespace had happened.
>>
>> Instead of reporting, the new whitespace-mode
>> displays visually the bogus whitespace.
>>
>> Is it ok if the new whitespace-buffer is removed?
>>
>> Maybe a better alternative should be to create a
>> whitespace-report command which reports like the old
>> whitespace-buffer.

One point in favor of using a report function is that a
report gives you all the bogus whitespace line instead of
you having to run the whole buffer to see if there are
some bogus whitespace.


> My personal opinion is that the old whitespace mode was pretty wacky,
> and had lots of unneeded features and features which didn't follow Emacs
> conventions. It doesn't seem necessary to me to _exactly_ preserve the
> interface (maybe some def-obsolete-alias could be used in some case),
> just keep those commands which were actually useful, and maybe try to
> make them follow emacs conventions better.

Could you elaborate better this point,
whose functionalities should be kept
(via def-obsolete-alias) or not?


> E.g., how about:
>
> + `suspicious-whitespace-mode' -- highlights only "suspicious"
> whitespace, i.e., that which probably should be removed. This is
> sort of like the old "whitespace-buffer" command, but implemented as
> a proper mode, or like your "whitespace-mode", but only highlights
> suspicious whitespace. [dunno about the term "suspicious", but you
> know what I mean]
>
> + `cleanup-whitespace' -- removes suspicious whitespace [same
> definition as suspicious-whitespace-mode]

Well, the new whitespace.el uses a symbol list
(whitespace-chars variable) to select which kind
of whitespaces are visualized.

Some symbols (empty, indentation, trailing,
space-before-tab, space-after-tab) represents
the "suspicious" (or bogus) whitespaces.

Here are the "suspicious" whitespaces:

empty -- empty lines at beginning/end of buffer.

indentation -- 8 or more SPACEs at beginning of line.

trailing -- SPACEs or TABs at end of line.

space-before-tab -- SPACEs before TAB.

space-after-tab -- 8 or more SPACEs after TAB.

The whitespace-cleanup function already removes
the "suspicious" whitespaces.

Maybe the symbols above (the "suspicious" one)
should be renamed to, for example:

    suspicious-empty, suspicious-indentation,...

Or:

    bogus-empty, bogus-indentation,...

Or whatever other suitable name.

Re: 23.0.60; whitespace.el mishap

[Richard Stallman]

    Well, indeed the old whitespace-buffer had reported
    where the bogus whitespace had happened.

    Instead of reporting, the new whitespace-mode
    displays visually the bogus whitespace.

Ok, we know what the old whitespace-buffer does.
And we know what the new whitespace-mode does.

    Is it ok if the new whitespace-buffer is removed?

What does the new whitespace-buffer do?  How does it differ
from whitespace-mode?

Can you make it provide the features of the old whitespace-buffer?

Re: 23.0.60; whitespace.el mishap

[Richard Stallman]

      It doesn't seem necessary to me to _exactly_ preserve the
    interface (maybe some def-obsolete-alias could be used in some case),
    just keep those commands which were actually useful, and maybe try to
    make them follow emacs conventions better.

I agree.

Re: 23.0.60; whitespace.el mishap

[Vinicius Jose Latorre]

>     Well, indeed the old whitespace-buffer had reported
>     where the bogus whitespace had happened.
>
>     Instead of reporting, the new whitespace-mode
>     displays visually the bogus whitespace.
>
> Ok, we know what the old whitespace-buffer does.
> And we know what the new whitespace-mode does.
>
>     Is it ok if the new whitespace-buffer is removed?
>
> What does the new whitespace-buffer do?  How does it differ
> from whitespace-mode?
>   

The new whitespace-buffer only force whitespace-chars to contain
the symbols to visualize the "bogus" whitespaces.
It seems that the new whitespace-buffer is not so useful.

The old whitespace-buffer highlights the "bogus" whitespaces
(via text properties) and generates a report in a buffer,
if there is any "bogus" whitespace.

Now, whitespace-mode and global-whitespace-mode highlights
all whitespaces including the "bogus" one, if the user specifies
in the whitespace-chars variable.

> Can you make it provide the features of the old whitespace-buffer?
>   

Yes, I think that is missing the "bogus" report
(via a new whitespace-report command).

Re: 23.0.60; whitespace.el mishap

[Rajesh Vaidheeswarran]

Miles Bader wrote:
> Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:
>   
>> Well, indeed the old whitespace-buffer had reported
>> where the bogus whitespace had happened.
>>
>> Instead of reporting, the new whitespace-mode
>> displays visually the bogus whitespace.
>>
>> Is it ok if the new whitespace-buffer is removed?
>>
>> Maybe a better alternative should be to create a
>> whitespace-report command which reports like the old
>> whitespace-buffer.
>>     
>
> My personal opinion is that the old whitespace mode was pretty wacky,
>   

Miles, that's a matter of opinion, and this is your opinion. I just beg 
to differ, as do the 150-200 people who I wrote this for.


> and had lots of unneeded features and features which didn't follow Emacs
> conventions.  It doesn't seem necessary to me to _exactly_ preserve the
>   

No one stopped you from either filing bugs against it, or better still 
"fixing" it. That's pretty much all I have to state on this thread.


> interface (maybe some def-obsolete-alias could be used in some case),
> just keep those commands which were actually useful, and maybe try to
> make them follow emacs conventions better.
>   

> E.g., how about:
>
>   + `suspicious-whitespace-mode' -- highlights only "suspicious"
>     whitespace, i.e., that which probably should be removed. This is
>     sort of like the old "whitespace-buffer" command, but implemented as
>     a proper mode, or like your "whitespace-mode", but only highlights
>     suspicious whitespace.  [dunno about the term "suspicious", but you
>     know what I mean]
>
>   + `cleanup-whitespace' -- removes suspicious whitespace [same
>     definition as suspicious-whitespace-mode]
>
> -Miles
>
>   

Re: 23.0.60; whitespace.el mishap

[Miles Bader]

Rajesh Vaidheeswarran <rv@gnu.org> writes:
> Miles, that's a matter of opinion, and this is your opinion. I just beg
> to differ, as do the 150-200 people who I wrote this for.

They're certainly welcome to participate in this thread.  If someone has
particular needs which we aren't anticipating, it helps to know about
them.

>> and had lots of unneeded features and features which didn't follow Emacs
>> conventions.  It doesn't seem necessary to me to _exactly_ preserve the
>
> No one stopped you from either filing bugs against it, or better still
> "fixing" it. That's pretty much all I have to state on this thread.

And indeed, that's what's being done now.

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: 23.0.60; whitespace.el mishap

[Rajesh Vaidheeswarran]

Miles Bader wrote:
>>> and had lots of unneeded features and features which didn't follow Emacs
>>> conventions.  It doesn't seem necessary to me to _exactly_ preserve the
>>>       
>> No one stopped you from either filing bugs against it, or better still
>> "fixing" it. That's pretty much all I have to state on this thread.
>>     
>
> And indeed, that's what's being done now.
>   

That's unfortunately not the case. The original library was moved to 
old-whitespace and a new library was put in place.. Fixing, to me, would 
mean that the fixes go into what was considered broken.

Re: 23.0.60; whitespace.el mishap

[Vinicius Jose Latorre]

I've just installed a fix in CVS trunk.


Michael Welsh Duggan wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> Given the c buffer:
>
> int main()
> {
>     if (1) {
>         x = foo;
>     }
>     return 0;
> }
>
>
> `M-x whitespace-cleanup' will result in:
>
> int main()
> {
>     if (1) {
>         x= foo;
>     }
>     return 0;
> }
>
> This is because `whitespace-indentation-regexp' includes a trailing
> "[^\n\t]", which matches the x.  After `re-search-forward' of
> `whitespace-cleanup-region' the point is now after the `x'.  In order
> for the subsequent `delete-horizontal-space' to work, a 
> (forward-char -1) should probably be done, before the
> `current-indentation' call.
>
>
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /home/mwd/share/emacs/23.0.60/etc/DEBUG for instructions.
>
>
> In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu, GTK+ Version 2.10.4)
>  of 2008-02-05 on maru.green.cert.org
> Windowing system distributor `The X.Org Foundation', version 11.0.70101000
> configured using `configure  '--prefix=/home/mwd' '--without-toolkit-scroll-bars' '--with-gif=no''
>
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   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.UTF-8
>   value of $XMODIFIERS: @im=none
>   locale-coding-system: utf-8-unix
>   default-enable-multibyte-characters: t
>
> Major mode: C/l
>
> Minor modes in effect:
>   shell-dirtrack-mode: t
>   display-time-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   menu-bar-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-compression-mode: t
>   line-number-mode: t
>   abbrev-mode: t
>
> Recent input:
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n <escape> > C-w C-p C-p C-p C-p C-p C-p 
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-e C-b C-b 
> C-b C-b C-b SPC C-x C-s C-b C-b SPC C-x C-s C-f C-d 
> C-x C-s C-a C-SPC C-n <switch-frame> q C-x 4 b <return> 
> C-p C-SPC C-n M-x M-p <return> <switch-frame> SPC <switch-frame> 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC q <switch-frame> C-p C-p C-e C-p 
> C-e <return> <tab> ( f o r w a r d - c j h a <backspace> 
> <backspace> <backspace> h a r SPC - 1 ) C-x C-s C-u 
> C-M-x <switch-frame> C-_ C-n <backspace> C-p C-a C-SPC 
> C-n M-x M-p <return> <switch-frame> SPC C-_ <switch-frame> 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> <switch-frame> C-p C-p C-p C-p C-p C-p C-p C-p C-p 
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
> <switch-frame> M-x r e p o r t - e m a c s - 0 <backspace> 
> b <tab> <return>
>
> Recent messages:
> Result: nil
>
> Result: nil
>  [2 times]
> Result: #<marker at 236 in fooo.c>
>
> Result: #<marker in no buffer>
>
> Result: #<marker in no buffer>
>