"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
QUERY
Jeff Sparkes writes:
> I copied the delete-trailing-whitespace from
> emacs23/lisp/simple.el.
What does this do that text-modes/whitespace.el doesn't? And why does
it need to be in core, when we've already got delete-horizontal-space?
I had a local whitespace.el, so I didn't find the one in text-mode with
find-library. It's not in the manual either, since it's not in core.
The main reason I did it was GNU Emacs compatibility; it was something
I had in my .emacs.
As for a use case, it happens when I'm writing C code and insert blank
lines with C-o, and then move off the line with C-n.
AFAIK all killing commands in core XEmacs respect narrowing. IMO it
goes without saying. I would phrase the above as
Delete all trailing whitespace (except linebreaks) in the current buffer.
Trailing is whitespace after the last non-whitespace character in a line.
> diff --git a/man/xemacs/killing.texi b/man/xemacs/killing.texi
> --- a/man/xemacs/killing.texi
> +++ b/man/xemacs/killing.texi
> @@ -99,6 +99,12 @@
> the next line by deleting a newline and all surrounding spaces, possibly
> leaving a single space. @xref{Indentation,M-^}.
>
> +@findex delete-trailing-whitespace
> + @code{delete-trailing-whitespace} deletes spaces and tabs at the end
> +of all of the lines in the current buffer or region
> +(@pxref{Narrowing}). This command does not remove formfeed
> +characters.
> +
In the manual, "...deletes whitespace (all characters matching
@code{\s-} except linebreaks from the end of all lines in the visible
portion of the buffer. Linebreaks are newline (LF, ASCII 0x0A) and
formfeed (FF, ASCII 0x0C)" is fine, I think. Note that the "region"
is quite different from the visible portion of the buffer; it is the
portion of the buffer between point and mark. The word you meant is
"restriction", but in most places it's idiomatically used like
"affecting the buffer or the restriction, if one is in effect" which
is kind of clunky IMO.
That why I wanted an opinion on the manual entry. I knew mine wasn't
good enough.
Jeff Sparkes later writes:
> And it gets more complicated with Unicode whitespace:
>
http://en.wikipedia.org/wiki/Whitespace_character#Unicode
It would be nice and more efficient to do this with "Unicode inside",
but it's not absolutely necessary. We do have some access to the
Unicode character database courtesy of Aidan, IIRC.
> I'd like to include for sure.
(make-char 'latin-iso8859-1 32)
IIRC. But that definitely has to be optional, as people often use
that character to mean "I really want this space right here".
I shouldn't have brought it up; I knew it was complicated.
fill-paragraph et. al. don't handle it either. Non-breaking space is in
ISO-8859-1 so it isn't just a unicode issue.
> Do syntax-tables support Unicode?
Of course, but only the subset covered by Mule encoding. I don't
think most of the huge variety of Unicode spaces are available, for
one thing.
> Not in XEmacs, but apparently in Emacs. Unicode has bunch of different
> sized spaces! And punctuation. For XEmacs, We'd probably have to wait
> until we use only unicode internally. Doing syntax for all possible
> charsets is a lot of work.
Not really. Write a program to convert Mule characters to Unicode
with char-to-unicode, look them up in the database, and construct an
appropriate syntax table.
I was unclear here. XEmacs doesn't add the unicode characters to the
initial syntax table. I just did a C-hs in a UTF-8 buffer.
> I'm going to go with the Emacs definition, and avoid the higher levels
> of correctness.
I still don't see the point of dong this at all. Is there code that
calls that function?
I just wanted compatibility with GNU Emacs. It was even bug compatible.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta