[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#2887: Suggestions for simple.el
From: |
Stefan Monnier |
Subject: |
bug#2887: Suggestions for simple.el |
Date: |
Sat, 18 Apr 2009 23:14:27 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
>> 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
- bug#2887: Suggestions for simple.el, (continued)
- bug#2887: Suggestions for simple.el, Stefan Monnier, 2009/04/07
- bug#2887: Suggestions for simple.el, Drew Adams, 2009/04/07
- bug#2887: Suggestions for simple.el, Chong Yidong, 2009/04/07
- bug#2887: Suggestions for simple.el, Drew Adams, 2009/04/07
- bug#2887: Suggestions for simple.el, Stefan Monnier, 2009/04/07
- bug#2887: Suggestions for simple.el, Stefan Monnier, 2009/04/07
- bug#2887: Suggestions for simple.el, Arni Magnusson, 2009/04/17
- bug#2887: Suggestions for simple.el, Stefan Monnier, 2009/04/18
- bug#2887: Suggestions for simple.el, Arni Magnusson, 2009/04/18
- bug#2887: Suggestions for simple.el, Arni Magnusson, 2009/04/18
- bug#2887: Suggestions for simple.el,
Stefan Monnier <=
- bug#2887: Suggestions for simple.el, Arni Magnusson, 2009/04/19