I copied the delete-trailing-whitespace from emacs23/lisp/simple.el. 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?

while I'm following that rationale not to delete formfeeds: user might do still different considerations. What about a customizable chars-list specifying what as whitespace should be considered? Indicating chars in a list is much easier than changing syntax for most of users IMO.

> + (save-match-data > + (if (looking-at ".*\f") > + (goto-char (match-end 0)))) It might mean: whitespaces followed by a formfeed will be preserved. Seems not reasonable.

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: > 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". > 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?

> as it happens `whitespace-trailing-regexp' already exists, Not in XEmacs core or packages as far as I can tell,

horrible name for a core variable, although it's easy to see why it would arise as an internal variable of the "whitespace" library. > what about that form: If that's from GNU Emacs,

it still runs into the fact that this is redundant.

less sophisticated form, simply treating formfeed as non-whitespace: (while (search-forward #r"[ \t]$" nil t) (delete-horizontal-space)) This should typically be good enough,

On the gripping hand, a much more powerful form is already implemented in whitespace.el, and for most XEmacs users is as far away as M-x whitespace-global-mode (it's autoloaded from an installed package). IMO, if one wants specific tweaks not already in whitespace.el, it's better to propose improvements to whitespace.el that benefit those users too, not additions that for 99% of actual usage duplicate existing functionality of XEmacs, and will mostly likely never be used by whitespace.el users. If people really want this function in core, I won't veto it. But it's a bad idea IMO for the reasons I've given