[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: delete-selection-mode

From: Drew Adams
Subject: RE: delete-selection-mode
Date: Fri, 19 Mar 2010 16:59:23 -0700

> >> This discussion was started as a response to requests from 
> >> beginners. Enabling `delete-selection-mode' by default was
> >> proposed as a way to satisfy them.  But if we change the
> >> default, we don't have to use `delete-selection-mode'.
> >> We could use something different for this
> >> purpose if it is more suitabe.
> >
> > Thank you.
> >
> > Let's finish with the original proposal, at least, to get 
> > that out of the way one way or the other. Depending on that
> > decision, we can always consider other changes.
> >
> > Given d-s-mode _as it is_, do people think it should be 
> > enabled by default? That's the question.
> >
> > If the consensus is strong enough that in its current form 
> > it should not become the default, fine. But let's at least
> > give Juri's proposal a clear judgment.
> No, that's not what I meant.
> Even though I referred to delete-selection-mode, that's only because
> it is the mode that currently implements the necessary functionality.
> Often moving some functionality into the core requires 
> redesigning its API.
> For instance, implementing shift-arrows required adding a new option
> shift-select-mode instead of enabling the equivalent functionality
> from an existing package like s-region.el or pc-select.el.

Then I think we've already effectively moved on, saying that d-s-mode as is is
not quite the right default. And you seem (like me) to agree with Richard that
"We could use something different for this purpose." 

Finding a new behavior for the default is one thing. Changing d-s-mode itself is
another. I object to the second. I have no objection to the first, even if that
new behavior ends up being similar in some ways to d-s-mode.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]