[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-m
bug#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-mode
Wed, 18 Jul 2012 06:55:36 -0700
> 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.)