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

Previous Next

Full log

View this message in rfc822 format

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

>> 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).
> This would mean two keystrokes to delete a word, right?

Yes, at least.  Maybe you can amortize it so it's only N+1 for N words.

> It's an idea, but I still believe that many users would appreciate
> binding single keystrokes to the functions I suggested.

Yes, that's where we disagree.

> (defun comment-line-or-region ()
>   "Comment line or region."
>   (interactive)
>   (require 'newcomment)
>   (if (and mark-active transient-mark-mode)
>       (comment-region
>        (pos-at-beginning-of-line (line-number-at-pos (region-beginning)))
>        (pos-at-end-of-line (line-number-at-pos (region-end))))
>     (comment-region (line-beginning-position)(line-end-position))))

A perfect example of the kind of performance bug that comes up when you
think in terms of lines, as encouraged by pos-at-beginning/end-of-line.
The above should be:

 (defun comment-line-or-region ()
   "Comment line or region."
   (interactive)
   (require 'newcomment)
   (if (and mark-active transient-mark-mode)
       (comment-region
        (save-excursion (goto-char (region-beginning)) (line-beginning-position))
        (save-excursion (goto-char (region-end)) (line-end-position)))
     (comment-region (line-beginning-position) (line-end-position))))

line-number-at-pos is also a "function to avoid", just as bad as
goto-line.  Your code will walk over the whole buffer 4 times (twice to
compute the line-number at region beg and end, then twice to find the
beg/end of those 2 lines).

>>> `delete-all-blank-lines'
>> 
>> 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.

> This is definitely an idea, making better use of the default value of the
> regexp. But do you really mean flush all empty lines, or just the empty
> lines below the point? The idea behind `delete-all-blank-lines' is to really
> delete all empty lines, without moving the point, in one keystroke. I could
> probably edit `flush-lines' to do exactly that, although it operates only on
> text after the point for non-default regexps.

I don't think the position-preservation is important enough to warrant
a different command.  So do C-SPC M-< before and C-u C-SPC afterwards if
you want to preserve point.  Or try to provide some way for flush-lines
to operate on the whole buffer, without having to move point.


        Stefan

Previous Next

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