From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Arni Magnusson <arnima@hafro.is>
Cc: 2887@emacsbugs.donarmstrong.com
Subject: bug#2887: Suggestions for simple.el
Date: Sat, 18 Apr 2009 23:14:27 -0400 [thread overview]
Message-ID: <jwvzledxs6x.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <alpine.LFD.0.9999.0904182215020.16457@localhost.localdomain> (Arni Magnusson's message of "Sun, 19 Apr 2009 01:13:05 +0000 (GMT)")
>> 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
next prev parent reply other threads:[~2009-04-19 3:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-04 13:32 bug#2887: Suggestions for simple.el Arni Magnusson
2009-04-04 14:21 ` Stefan Monnier
2009-04-04 23:35 ` Arni Magnusson
2009-04-05 3:27 ` Stefan Monnier
2009-04-05 14:26 ` Leo
2009-04-05 20:17 ` Arni Magnusson
2009-04-05 21:59 ` Lennart Borgman
2009-04-06 2:14 ` Stefan Monnier
2009-04-06 3:02 ` Drew Adams
2009-04-07 2:46 ` Arni Magnusson
2009-04-07 14:02 ` Stefan Monnier
2009-04-07 16:09 ` Drew Adams
[not found] ` <008701c9b79b$41f3f250$0200a8c0@us.oracle.com>
2009-04-07 17:18 ` Stefan Monnier
2009-04-07 17:22 ` Chong Yidong
[not found] ` <87iqlg4bwl.fsf@cyd.mit.edu>
2009-04-07 17:26 ` Drew Adams
2009-04-07 21:43 ` Stefan Monnier
2009-04-18 0:08 ` Arni Magnusson
2009-04-18 19:32 ` Stefan Monnier
2009-04-19 1:13 ` Arni Magnusson
2009-04-19 1:40 ` Arni Magnusson
2009-04-19 3:14 ` Stefan Monnier [this message]
2009-04-19 13:41 ` Arni Magnusson
2020-09-19 21:50 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvzledxs6x.fsf-monnier+emacsbugreports@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=2887@emacsbugs.donarmstrong.com \
--cc=arnima@hafro.is \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).