bug#2887: Suggestions for simple.el

[Arni Magnusson]

Thank you, Stefan, for the insightful comments. We're discussing quite a
few things at once, but I'll try to be concise:

>> `backward-delete-word'
>> `delete-word'
>
>> Users can delete words while leaving the kill-ring unchanged. For
>> example, the user has copied a table from somewhere and is now
>> deleting some words before yanking the table where it belongs. It
>> would be frustrating for the user to yank and see recently deleted
>> words instead of the table.
>
> Which leads to the following questions:
>
> - is it really that important given that the user could get the same
>   result by yanking first and deleting the words afterwards?

The default behavior of practically all editors is to delete words without
altering the clipboard. The principle of least surprise says Emacs should
at least make it easy for users to bind C-backspace to
`backward-delete-word' and C-delete to `delete-word', if that's the
behavior they prefer.

> - why is this important for *kill-word, but not for all the other kill
>   operations?

Because deleting words is probably the most common deletion, after
deleting characters. It would frustrate many more users if `delete-char'
would alter the kill ring.

> - the most important one: who's going to do M-x delete-word rather
>   than work around the problem some other way? I.e. such a command is
>   basically useless unless it's bound to a key, so the problem is not
>   so much the command as it is to find a key for it.

The Emacs manual and the documentation of `kill-word' and
`backward-kill-word' could mention that some users may prefer binding
C-backspace to `backward-delete-word' and C-delete to `delete-word'.



>> `kill-line-or-region'
>
>> Users can bind C-k to kill lines and regions (do what I mean), as an
>> alternative to the default C-k and C-w setup.
>
> That might be OK. Many people who'd like it, might prefer to just use
> some variant of delete-selection-mode, tho.

Again, the important distinction between killing and deleting. Even in
`delete-selection-mode', the `kill-line-or-region' command is useful for
yanking the text later.



>> `pull-line-down'
>> `pull-line-up'
>
>> Users can move lines up and down more effectively thank with
>> `transpose-lines'.
>
> Can you summarize the difference?

To move a line 3 down, call `pull-line-down' 3 times or with a numerical
argument of 3. Likewise with `pull-line-up'. Most Emacs users would
probably do this by killing and yanking, but it's considerably quicker
using the pull-line-* commands. The `transpose-lines' command may be
useful in some circumstances, but not in the tasks described above.



>> `pos-at-beginning-of-line'
>> `pos-at-end-of-line'
>
>> Useful when writing a variety of editing functions. Should be in
>> simple.el for the same resons as `line-beginning-position' and
>> `line-end-position' are there.
>
> Actually, line-*-position are in the C code (and if they were written
> in Lisp, they should be in subr.el rather than in simple.el). The
> problem with pos-at-*-of-line is that goto-line is costly, so Elisp
> generally shouldn't encourage its use.

My commands that call pos-at-*-of-line work faster than I can blink my
eyes, but I understand your concern. To optimize the speed the functions
would probably need to be implemented in C code, but that's beyond my
programming capabilities. Still, if I'm not mistaken, Emacs Lisp
programmers would have to use something just as expensive to perform this
task, so pos-at-*-of-line would save them some typing and thinking.


>> `zap-back-to-char'
>> `zap-up-to-char'
>
>> Zapping is typically to delete garbage until some important location.
>> The existing `zap-to-char' often deletes the beginning of that
>> important location, an opening brace or the like.
>
> I never use zap-to-char, so I'll let other people judge if that can be
> useful.

It's a common task to delete everything between the point and another
location. Zapping is best if that location contains a somewhat rare
character, usually some kind of symbol or parenthesis. In my experience
the character itself should usually not be deleted as well.



>> `clean-trails'
>
>> Like `delete-trailing-white', but reports how many lines were
>> cleaned, and deletes ^M as well. Many programs and programmers write
>> files with trailing spaces and ^M glyphs. It's nice to be able to
>> clean those and get body count in one keystroke.
>
> The report of number of lines cleaned sounds like a good addition to
> delete-trailing-whitespace. Not sure about ^M since I basically never
> bumped into it (or rather I always handle it via eol-conversion), but
> if it's useful, it would also be beter to incorporate it into
> delete-trailing-whitespace than create a new command for it.

Yes, it would be a nice improvement to upgrade the
`delete-trailing-whitespace' command so it counts cleaned lines.

Files with mixed Unix/Dos line endings are sometimes created when people
using different OS's work together on a project. Many programs choke on
input files that contain mixed Unix/Dos line endings, often without
helpful error messages.

If the Emacs maintainers decide to make `delete-trailing-whitespace' also
delete trailing ^M in mixed line-ending files, it would make me (and
presumably many other users) happy, but it might create a
backwards-compatibility issue.

Adding an &optional ctrl-M flag to `delete-trailing-whitespace' (non-nil
to remove trailing ^M as well) would not enable to users to bind a simple
keystroke to do that. What I propose is a separate function
`delete-trailing-whitespace-M' that removes both trailing whitespace and
trailing ^M in files with mixed line endings. A bulky solution, but I
think users will appreciate it.



>> `delete-all-blank-lines'
>
>> It's often useful to get rid of extra vertical spacing in source
>> code, output files, etc., sometimes undoing after enjoying the
>> squeezed view. Without this command, it would take a lot of
>> keystrokes to delete all blank lines while retaining the cursor
>> buffer position.
>
> I've never needed such a command, so again, I'll let other people
> judge if it is sufficiently generally useful to find its way in Emacs.

It's often a good way to get an overview of code that is vertically
stretched. I remove all comments (one keystroke) and all blank lines
(another keystroke), absorb the information and undo. I also use it on
certain program input files where blank lines would be problematic.



>> `delete-indentation-nospace'
>
>> The `delete-indentation' command is very useful, but it often creates
>> an unwanted space. Users will probably bind this command to a
>> keystroke close to the `delete-indentation' keystroke.
>
> delete-indentation tries to guess when spaces are wanted. Maybe we
> could improve the guess instead?

These functions are used in a wide variety of situations (text, code,
data), making guesswork practically hopeless. I use `delete-indentation'
and `delete-indentation-nospace' a lot, and I'm not sure which one I use
more frequently.



>> `goto-longest-line'
>
>> Users can find out the maximum width (columns) of a text file, to
>> check the coding style or for some other reason. Sometimes it's
>> easiest to call "wc -L" via `shell-command' or
>> `dired-do-shell-command', but `goto-longest-line' will often be
>> quicker and moves the cursor to the longest line, for closer
>> examination.
>
>> I remember when I wrote this command I thought about implementing a
>> separate non-interactive function called `longest-line' that would
>> just return the line number. Then `goto-longest-line' would call
>> `longest-line' to do the calculations, and other functions might call
>> `longest-line' with some other purpose than moving the cursor to it.
>> I would be happy to contribute a two-function implementation instead,
>> since `longest-line' might be useful for many users.
>
> There's no point not moving to the line, even if used from Elisp
> (since it's just as easy to wrap the call in a save-excursion if
> needed), so the command works as well from Lisp.

Good call, one function it is.



>> `downcase-word-or-region'
>> `upcase-word-or-region'
>
>> Users can bind M-l and M-u to downcase/upcase words or regions (do
>> what I mean), as an alternative to the default C-x C-l, C-x C-u, M-l,
>> and M-u setup.
>
> That sounds OK.

Great.



> This said, I think those new commands, unbound to any key, shouldn't
> be placed in simple.el (which is preloaded) but into some other file.
> I'm tempted to say "misc.el", where we could stuff any number of
> "commands that users might like, but for which we couldn't come up
> with a good key-binding".

I would slip them into simple.el, since they load very fast and rhyme with
what's already there. Allow me to propose the following bindings that are
undefined in Emacs 22.3.1:

C-x C-backspace  backward-delete-word
C-x C-delete     delete-word
C-;              kill-line-or-region
M-n              pull-line-down
M-p              pull-line-up
C-,              zap-back-to-char
C-.              zap-up-to-char
C-'              clean-trails
C-"              delete-all-blank-lines
M-&              delete-indentation-nospace
C-=              goto-longest-line
M-down           downcase-word-or-region
M-up             upcase-word-or-region