Re: [Q] copy delete-trailing-whitespace from Emacs 23.

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?