GNU bug report logs - #2887
Suggestions for simple.el

Previous Next

Full log

Message #92 received at 2887 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Arni Magnusson <arnima <at> hafro.is>
Cc: 2887 <at> debbugs.gnu.org
Subject: Re: bug#2887: Suggestions for simple.el
Date: Sat, 18 Apr 2009 15:32:27 -0400

> `backward-delete-word'
> `delete-word'

> I think Emacs should provide a simple way for beginning users to have
> C-backspace and C-delete behave like they would expect, i.e. leaving
> the clipboard intact.  There are different ways to provide this, using
> a variable and/or functions.  Users should not need to write their own
> functions for something this fundamental.

I think the difference between these and the standard commands is too
small to deserve a separate command.  There are plenty of ways to get
around the problem of "kill when I only want delete" (typically, doing
the kill after the C-y, or using M-y, ...).

I would only consider some general "kill-next-kill" feature which would
allow to turn any killing command into a deleting one
(e.g. a kill-next-kill command which would cause the subsequent
commands's effect on the kill-ring to be cancelled).

> `kill-line-or-region'

> C-k should probably be bound to this function. This would be appreciated by
> many `transient-mark-mode' users. I haven't used Emacs without
> transient-mark-mode', but don't those people still want C-w bound to
> kill-region'?

Yes, we couldn't really get rid of C-w, I think, but users of
transient-mark-mode could use that key for other things.

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

> These are admittedly simple tricks of lesser importance, but anyone trying
> out the existing `transpose-lines' will read its documentation twice and try
> to master pulling lines up or down, before giving up. I find myself using
> these almost every day, with code, data, and config files.

I don't find transpose-lines very useful, so I might accept a proposal
that makes it more useful, but not one that adds yet more refinements.

> `pos-at-beginning-of-line'
> `pos-at-end-of-line'

> You're right, it's best to avoid `goto-line'. I have reimplemented these
> functions (see attachment) to improve the speed. I think they bridge an
> obvious gap in Emacs Lisp, making it considerably easier to read and write
> functions that operate on buffer text.

The reimplementation doesn't change anything: its performance will still
suck on large files.  It's just fundamentally an operation that is slow
and that we should generally avoid, so I don't want to add yet more ways
(additionally to goto-line) to do that.

The "obvious gap" that you talk about is only "obvious" if you think in
terms of lines, which is almost always the wrong way to think about the
text in Emacs.

> `zap-back-to-char'
> `zap-up-to-char'

> I believe these more useful than the existing `zap-to-char', which often
> deletes the beginning of that important location, an opening brace or
> the like.

Maybe a better approach would be to add config var to zap-to-char
whether it also zaps the char or not.  In any case, I'd rather wait for
other people to support this option, since I have no idea how common
it is.

> `delete-trailing-white'

>> I think [ \t\r] is a good default, and if we introduce a config var (which
>> I'm not sure is worth the trouble), there's no reason to keep the special
>> treatment of formfeed.

> I agree that hardwiring [ \t\r] works fastest and is easy to use and
> maintain. Attached is my proposed upgrade of this function, where cleaned
> lines are counted.

Thanks.  We'll consider using it for Emacs-23.2.

> `delete-all-blank-lines'

> Vertical analog to `delete-trailing-white', which I use about as
> often. Anyone trying out the existing `delete-blank-lines' will wonder
> whether there is a keybinding to delete all blank lines, instead of just
> around the point.

Can someone figure out a way to tweak flush-lines such that it can be
used for that purpose without having to jump through as many hooks?
Maybe we can just say that if you call flush-lines with an empty
argument (which currently would flush *all* lines) it will flush all
empty lines.

> `delete-indentation-nospace'
> Similar to `delete-indentation' but leaves no space between the joined
> lines. I find myself using these almost every day, with prose, code, data,
> and config files. I have bound the two functions to neighboring keybindings.

Here again, I'm not sure the difference is worth the trouble.
I'd rather make fixup-whitespace customizable so you can specify when to
keep a space and when not to.  You can then customize it to never keep
a space, and then use M-^ for delete-indentation-nospace and M-^ SPC
when you do want a space.

> `downcase-word-or-region'
> `upcase-word-or-region'

> M-l and M-u could be bound to this function. This would be appreciated by
> many `transient-mark-mode' users.

Yes, I think it would be a good change.

> I haven't used Emacs without transient-mark-mode', but don't those
> people still want C-x C-l and C-x  C-u bound to `downcase-region' and
> `upcase-region'?

It's possible, but it's less sure than with C-w because those commands
are used much less frequently, so it might be OK to just tell people to
use C-u C-x C-x M-u instead of C-x C-u.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.