all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@IRO.UMontreal.CA>,
	"'Simon Law'" <sfllaw@sfllaw.ca>
Cc: 'Chong Yidong' <cyd@gnu.org>, 11520@debbugs.gnu.org
Subject: bug#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-mode
Date: Wed, 18 Jul 2012 06:55:36 -0700	[thread overview]
Message-ID: <23B93A33CBB6419F9DA18F520F1A9759@us.oracle.com> (raw)
In-Reply-To: <jwv7gu12sp2.fsf-monnier+gnus-read-ephemeral-bug@gnu.org>

> I don't much like delete-selection-mode because of its 
> implementation strategy (using a pre-command-hook along with
> symbol properties, as opposed to modifying the commands
> themselves).  I can fully understand why it was done this
> way, but I'd be happy to see it changed, along the
> same lines as what we did for the shift-select-mode.

FWIW, I am not enthused by that prospect.

> AFAICT, of the various `delete-selection' properties, `kill' is only
> used for `open-line' (for no good reason) and could be eliminated.
> `supersede' is only used by command which should obey
> `delete-active-region' or close enough, `yank' is only used 
> for commands which end up calling `yank' (so adding code to the
> `yank' command would cover them), and t is used for commands
> which end up calling `self-insert-command' (with a few minor
> exceptions like open-line).

Delete-selection mode is not only for use by end users out of the box with
vanilla Emacs.  It is especially designed to be easy to use to adapt code,
modes, and general interactive behavior, for both users and other libraries.

In this respect it is similar to the general programming functionality provided
by thingatpt.el.  It would be short-sighted to look only to how the existing
code uses thing-at-point features and ignore how they can be (are designed to
be) used more generally.  Same with delete-selection mode.

When will Emacs Dev stop looking only to the existing vanilla code that is
distributed to determine the "only" uses of some existing functionality.  That
last paragraph of yours is a classic: feature A seems only to be used for X,Y,Z
in the Emacs code, so let's simplify things by amputating the feature and
hard-coding its uses into the existing code.

The design of delete-selection mode is for its potential uses, not just its
existing uses in the current code that you maintain.  Such proposed amputation
is like looking at how the character `(' is actually used in one file and
proposing to change the possibility to use it more generally, limiting it to its
uses in that one file.

Just one opinion - from a longtime delete-selection mode user and someone who
has also used it in programming.  (Likewise thing at point.)






  reply	other threads:[~2012-07-18 13:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-19 20:07 bug#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-mode Simon Law
2012-05-19 22:41 ` bug#11520: Workaround Simon Law
2012-05-20 14:54 ` bug#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-mode Stefan Monnier
2012-05-20 16:31   ` Drew Adams
2012-05-21  4:19     ` Simon Law
2012-06-11 21:24       ` Simon Law
2012-07-14  5:23 ` Chong Yidong
2012-07-14  6:42   ` Simon Law
2012-07-15 14:39     ` Chong Yidong
2012-07-15 16:33       ` Simon Law
2012-07-18 12:13         ` Stefan Monnier
2012-07-18 13:55           ` Drew Adams [this message]
2012-10-08 22:25         ` Stefan Monnier
2012-10-21 23:12           ` Simon Law
2012-10-22 12:46             ` Stefan Monnier
2012-10-23  1:07               ` Simon Law
2012-10-23 15:10                 ` Stefan Monnier
     [not found]                   ` <b47bddfc-e35c-4ab2-8f4f-3e0a51bec33c@default>
2014-08-18 15:21                     ` Stefan Monnier
     [not found]                 ` <<jwvboft8hsz.fsf-monnier+emacs@gnu.org>
2014-07-24 17:34                   ` Drew Adams

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23B93A33CBB6419F9DA18F520F1A9759@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=11520@debbugs.gnu.org \
    --cc=cyd@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=sfllaw@sfllaw.ca \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.