bug#2887: Suggestions for simple.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

The Emacs manual is already "too large" to contain all the info we want
to put in it, so mentioning such things is unlikely.
But it's probably a good idea to add those commands to misc.el.
Then the EmacsWiki can mention them.

> My commands that call pos-at-*-of-line work faster than I can blink my
> eyes, but I understand your concern.

Try them on 200MB buffers.

> To optimize the speed the functions would probably need to be
> implemented in C code, but that's beyond my programming
> capabilities.

The core loop is in goto-line and is already written in C.

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

The point is to force them to use goto-line explicitly, so as to
hopefully make the cost more obvious.

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

I tend to use C-s for that (as well as for movement).  But I understand
that other people have other habits.

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

Feel free to provide a patch for it (tho, since we're in the pretest,
there's no hurry: it won't be installed right now).

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

I understand the problem, yes.  I just don't know it enough to
understand which kind of solution is more handy.  The few times I've had
such a thing, I just did M-% C-q C-m RET RET !.  For such rare
occurrences, anything more specialized would be useless because
I wouldn't remember it.  Obviously, if it happens commonly to you,
you'll want another solution.

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

It might, but I'm not sure it'd be such a big deal.  The docstring
explicitly mentions that a form-feed is not considered as whitespace by
this function, so that might be taken to mean that "every other
whitespace-like chars" (such as C-m) would be considered as whitespace.

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

What bindings do you use?

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

As mentioned, simple.el is preloaded, so anything we add to it increases
the size of Emacs for everyone, whether they use it or not.

> Allow me to propose the following bindings that are
> undefined in Emacs 22.3.1:

There's a good reason why they're undefined: most of those keys can't be
pressed under a tty.


        Stefan