all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
To: Miles Bader <miles@gnu.org>
Cc: rgm@gnu.org, mwd@cert.org, rms@gnu.org, rv@gnu.org,
	emacs-pretest-bug@gnu.org
Subject: Re: 23.0.60; whitespace.el mishap
Date: Sat, 16 Feb 2008 17:47:32 -0300	[thread overview]
Message-ID: <47B74BE4.8080605@ig.com.br> (raw)
In-Reply-To: <87y79lvbxn.fsf@catnip.gol.com>


>> 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.





  reply	other threads:[~2008-02-16 20:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-05 21:33 23.0.60; whitespace.el mishap Michael Welsh Duggan
2008-02-06  4:53 ` Rajesh Vaidheeswarran
2008-02-06 14:33   ` Michael Welsh Duggan
2008-02-07  3:35     ` Rajesh Vaidheeswarran
2008-02-07  5:07       ` Glenn Morris
2008-02-07  6:03         ` Miles Bader
2008-02-07 15:27           ` Rajesh Vaidheeswarran
2008-02-08  4:15           ` Richard Stallman
2008-02-08 12:04             ` Vinicius Jose Latorre
2008-02-16  3:28             ` Vinicius Jose Latorre
2008-02-16  3:04               ` Miles Bader
2008-02-16 20:47                 ` Vinicius Jose Latorre [this message]
2008-02-17 13:22                 ` Richard Stallman
2008-02-20  4:24                 ` Rajesh Vaidheeswarran
2008-02-20  4:27                   ` Miles Bader
2008-02-20  4:41                     ` Rajesh Vaidheeswarran
2008-02-17 13:22               ` Richard Stallman
2008-02-17 14:40                 ` Vinicius Jose Latorre
2008-02-16  3:32 ` Vinicius Jose Latorre
2008-03-01 19:00 ` Vinicius Jose Latorre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47B74BE4.8080605@ig.com.br \
    --to=viniciusjl@ig.com.br \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=miles@gnu.org \
    --cc=mwd@cert.org \
    --cc=rgm@gnu.org \
    --cc=rms@gnu.org \
    --cc=rv@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.