From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@jurta.org>
Cc: 13312@debbugs.gnu.org
Subject: bug#13312: 24.3.50; delete selection mode not killing on overwrite
Date: Sat, 19 Oct 2013 10:42:44 -0700 (PDT) [thread overview]
Message-ID: <aa957cd4-d3b8-4f1f-822b-4e2253bd6bd6@default> (raw)
In-Reply-To: <87vc0tfcn6.fsf@mail.jurta.org>
> Ah, I thought this is a new bug report from you.
;-)
> But I still can't find a link to the associate StackOverflow question.
http://stackoverflow.com/questions/14076480/how-to-kill-text-when-overwriting-in-delete-selection-mode
> What I wanted to suggest is to add more self-inserting commands
> to delsel like `insert-char' and `quoted-insert'. I guess
> they don't need the same `self-insert-uses-region-functions'
> like the currently existing `self-insert-iso' doesn't use that.
Sounds like a more general discussion.
Please consider moving that and the rest of the discussion to a
separate bug report or emacs-devel. It doesn't seem like it is
limited to this bug.
My request was to move this bug back to Normal from Wish List.
If someone would also look into fixing it, that would be great.
> But when you want put `kill' as the `delete-selection' property
> then it's better to use this code:
> (put 'self-insert-command 'delete-selection
> (lambda ()
> (and (not (run-hook-with-args-until-success
> 'self-insert-uses-region-functions))
> 'kill)))
Maybe so, but that is not at all what the `delete-selection-mode'
doc & comments tell users. If this is a new requirement/guideline,
then it needs to be documented.
But I wonder why this must now be so. In the past, a user could
just put `kill' as the property. The code does not seem so clean now.
One of the benefits of the `delsel.el' design (and yes, along with
those benefits come also some disadvantages) is its simplicity for
users.
This seems to go against that. Is it really necessary? Isn't
there another way to accomplish the same thing (whatever that is),
so we can keep the simple and clean design for users?
What was the reason for introducing
`self-insert-uses-region-functions'? It seems it was only for
`electric-pair-mode'. IIRC, I wasn't too happy with that hack when
it was done. Now it seems to be dirtying (complicating) `delsel.el'.
Isn't there a better way?
But again, we should probably be discussing this elsewhere, since
it does not seem to be only about this bug.
> It currently doesn't work properly because `kill-region' overwrites
> the value of `this-command'. This is a bug that can be fixed
> by this patch that also fixes overwrite-mode for `kill' and
> puts `delete-selection' on more commands:
Sorry, I cannot judge now whether this DTRT. But again, this seems
to reach beyond this bug. (Let me know if I'm missing something
and this is really specific to this bug.)
I would like to see, if possible, a simpler `delsel.el', rather than
a more complicated one - from the user's perspective, at least, if
not necessarily the implementation. Users should be able to `put'
a single, understandable symbol as the `delete-selection' property
value. They should not need to fiddle with obscure lambda forms (or
symbols whose names are not simple to understand). Symbol `kill' is
simple - it says that you want the region to be killed.
This simplicity was the case before (`delsel.el' is old and simple).
Someone introduced `electric-pair-mode', and then someone else
complained about its interaction with `delete-selection-mode'. The
fix for that should not have involved screwing `delete-selection-mode',
as seems to be the case so far.
next prev parent reply other threads:[~2013-10-19 17:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-30 23:58 bug#13312: 24.3.50; delete selection mode not killing on overwrite Tony Day
2012-12-31 1:29 ` Glenn Morris
2013-01-01 0:06 ` Tony Day
2013-01-03 17:10 ` Stefan Monnier
2013-10-19 14:44 ` Drew Adams
2013-10-19 15:28 ` Juri Linkov
2013-10-19 15:37 ` Drew Adams
2013-10-19 16:28 ` Juri Linkov
2013-10-19 17:42 ` Drew Adams [this message]
2013-10-19 21:08 ` Juri Linkov
2013-10-19 21:18 ` Drew Adams
2013-12-11 1:11 ` Juri Linkov
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=aa957cd4-d3b8-4f1f-822b-4e2253bd6bd6@default \
--to=drew.adams@oracle.com \
--cc=13312@debbugs.gnu.org \
--cc=juri@jurta.org \
/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).