bug#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-mode

[Simon Law <sfllaw@sfllaw.ca>]

On Sun, May 20, 2012 at 12:31 PM, Drew Adams <drew.adams@oracle.com> wrote:
> But as you say, Stefan, a pre-command approach like d-s knows nothing about what
> might be expected to happen after the command is done.
>
> It could be possible to let `e-p' know what `d-s' has already done, but I do not
> see how it is possible/practical to let `d-s' know what `e-p' will do.  We could
> make `d-s' aware that `e-p' mode is turned on, and we could even try to let it
> know exactly what `e-p' mode does (not a very modular approach, but perhaps
> doable).
>
> But knowing that, `d-s' would have to not only test for `self-insert-command'
> but also test the character to be inserted.  We would end up, I'm afraid,
> duplicating nearly all of the `e-p' logic inside `d-s'.  (But perhaps I don't
> understand well what you had in mind.)
>
> Anyway, that mismatch (pre-command control vs post) is I guess the problem here.
> If so, it might be seen to be more general than `d-s' vs `e-p'.

It seems to me that delete-selection-mode already knows about four
types of commands: 'yank, 'supercede, 'kill, and non-nil. It looks
like it could take a function, which will inhibit
delete-selection-mode if it returns nil, or return any of the other
commands. This way, electric-pair-mode can register its own behaviour
with delete-selection-mode when it's activated.

-- 
Cheers,
Simon - http://ca.linkedin.com/in/sfllaw/