emacs-devel
[Top][All Lists]
Advanced

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

Re: delete-selection-mode as default


From: hw
Subject: Re: delete-selection-mode as default
Date: Mon, 17 Sep 2018 21:57:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Elias MÃ¥rtenson <address@hidden> writes:

> On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <address@hidden> wrote:
>
>>
>> <sigh> The region is simply a portion of your buffer.  What you're
>> suggesting is epistemologically incoherent.  It's "if I don't like always
>> to have a portion of my buffer do I have an alternative?".  No, Emacs
>> can't support such nonsense.  Sorry.
>
>
> It seems to me that the desires of hw could be fulfilled by simply
> disabling the mark whenever the region becomes inactive.
>
> It does sound like something I would never want to use, but it does seem
> like what is being suggested.

Yes and no:  With mark-even-if-inactive set to nil, it is not so
relevant for me that the mark be disabled.

That leaves the option of not disabling it, in which case it might be
useful to use the mark for navigation.  To do that, I only need to put a
command that changes point and mark on C-x C-x, as Eli suggested.  I
never used that, but that doesn't mean it can't be useful when it is not
involved with making selections because it's easier to press C-spc than
to set a register or a bookmark.

It also leaves the issue of persistent selections.  Yuri and Drew said
that it would be a huge amount of work, and Yuri explained how the
appeal of persistent selections may be limited when multiple buffers and
windows get involved.  I'd still like having that, but it doesn't really
provide additional functionality other than the possibility of multiple
persistent selections per buffer which I never missed --- and apparently
can already have with zones, as Drew suggested.

The region still won't make any sense to me, and it doesn't need to.


What new users might want or expect and what might make sense to them is
another question.



reply via email to

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