unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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






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