bug#2887: Suggestions for simple.el

[Stefan Monnier]

> `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?
- why is this important for *kill-word, but not for all the other
  kill operations?
- 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.

> `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.

> `pull-line-down'
> `pull-line-up'

> Users can move lines up and down more effectively thank with
> `transpose-lines'.

Can you summarize the difference?

> `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.

> `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.

> `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.

> `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.

> `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?

> `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.

> `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.

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


        Stefan