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?
The text-modes/whitespace*.el situation needs a bit of cleanup as it
is. IMO this patch just allows the mess to spread to core.
Also, this function is too inflexible IMO. See Andreas's comments.
I wrote the documentation entry myself; it needs to be reviewed.
I couldn't find a section on whitespace to reference, so I just said
"spaces and tabs". Pedantically it removes the regexp \s-, skipping
formfeeds. How much detail should I go into?
diff --git a/lisp/simple.el b/lisp/simple.el
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -329,6 +329,23 @@
(insert ? ))
(delete-region (point) (progn (skip-chars-forward " \t") (point))))
+(defun delete-trailing-whitespace ()
+ "Delete all the trailing whitespace across the current buffer.
+All whitespace after the last non-whitespace character in a line is deleted.
+This respects narrowing, created by \\[narrow-to-region] and friends.
+A formfeed is not considered whitespace by this function."
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.
Jeff Sparkes later writes:
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".
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'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?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta