[Top][All Lists]

[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: Sat, 15 Sep 2018 22:31:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

> [...]
>> >> Then how come I can't even see where the mark is, let alone the region?
>> >> Why is that not displayed?
>> > Because this was tried and found counter-productive.
>> It would be very helpful and not counter productive at all.
> Please, I'm am telling you what others found by experience.

So transient-mark-mode is counter productive --- strange that it did
become the default.  Unfortunately, it wasn't implemented with
consistency and not all the way through.

>> >> When highlighting screws up your syntax highlighting, maybe a different
>> >> way of highlighting could help.  Even only marking the fringes of lines
>> >> that are selected would be better than nothing.
>> > I prefer nothing, thanks.  Would you want to make my preferred way of
>> > working impossible?
>> No, it only doesn't make any sense to pretend that there is a selection
>> when there is actually none.
> This may be your main problem.  The concept of "selection" doesn't really
> exist in Emacs as such.  So your desire for there either positively to be
> a selection or not be a selection at any given time doesn't really make
> sense.

It makes perfect sense, and it's how I'm using Emacs.  What doesn't make
sense is these hidden regions, the impossibility of making a
navigational aid visible, the ability to do stuff with selections
without them being selected and the messing up of navigational things
with making selections.

> In Emacs there is point and (usually) mark, which delimit the
> region.  If you want to regard the region as being "the selection", you
> can, but if you try to extend that to "there always being a selection",
> you run into conceptual trouble.  That's what I think has been happening,
> here.

So you see how the concept of regions doesn't make sense and could use
an overhaul.

>> It gets even worse when Emacs pretends that there is a selection when
>> there is actually none only because the user once had to set a mark
>> somewhere to make a selection and would have to kill the whole buffer
>> to get rid of the mark and thus the pretended selection.
> In Emacs there is the region, as I said.

Pretending, or just assuming, that there is a selection when there is
none is a bad idea.

Imagine I select a line, copy it, move to another place and paste it.
Emacs assumes that there is a selection I can do stuff with, like
copying and deleting or narrowing the buffer to it.  If I make a mistake
and press the wrong key, Emacs acts on this assumption and messes up my
file.  That's a design flaw.  This isn't useful for navigation, either,
because when I yank, Emacs randomly sets the mark somewhere else.  So if
I wanted to go back to from where I copied the line, I'd be better off
to have set a bookmark or a register first.  I could press C-x C-x and
get the copy of the line I just created selected, and that's useless
because I already copied that line.

This pretending/assuming is not useful for anything but making mistakes

> [...]
>> >> > There are many advantages to having transient-mark-mode disabled:
>> >> > primarily simplicity, and the severe reduction in the modal
>> >> > behaviour (in the sense of key sequences doing different things in
>> >> > things like vi's insert mode and command mode).  And I'm not happy
>> >> > having my font-locking splatted by the region's highlighting.
>> >> Any simplicity here is no more than a deceptive apparition.
>> > :-)  No, the simplicity is real.
>> There is no simplicity.
> I'm telling you my experience, I'm not making things up.  Why do you
> think I disable transient-mark-mode in my Emacs, then?

I think it's because you dislike any other highlighting than what you
already have so badly that you make things hard for yourself by not
being able to see what you have selected and by forcing yourself to
having to go to lengths when you need to limit functions to a selection.

I don't understand why you need to read the part you have selected for
the few seconds it takes to do something with it in perfect
highlighting.  You could simply read it first and then select it.  You
don't need to read it while you make a selection, but you could finally
see what you're working with.

> [ .... ]
>> None of the options would do what I want, and making an extension that
>> does what I want isn't really an option, either.
> Enabling transient-mark-mode and setting mark-even-if-inactive to nil
> gives you what you've said you want, I think.

Partly --- it still doesn't decouple the mark from making selections so
it could be used for navigation.

What it seems to do is to require the selection to be highlighted when
you want to do something with it.  It's description is a bit weird:

| Non-nil means you can use the mark even when inactive.
| This option makes a difference in Transient Mark mode.
| When the option is non-nil, deactivation of the mark
| turns off region highlighting, but commands that use the mark
| behave as if the mark were still active.

What does 'using the mark' refer to?  I'm not using the mark, it's for
navigation and can not be used for that while it is broken by being
coupled to making selections.

The description doesn't say what it means when mark-even-if-inactive is
nil, and the 3rd sentence kinda repeats what the first one said, but it
doesn't seem to be true.  Query-replace definitely doesn't behave as if
the region were still active when mark-even-if-inactive is non-nil.

Maybe this is better:

| This option makes a difference in Transient Mark mode.  When the value
| is nil, doing something with a hidden region is not possible.  When
| the option is non-nil, commands that do something with a hidden region
| work as if transient-mark-mode was disabled.

I don't know what effect it has on active regions and what it does when
transient mark mode is disabled, though.

>> Again, this stuff needs an overhaul.
> I don't think you've managed to persuade anybody, certainly not me (yet).

Well, you got an example above with mark-even-if-inactive:  What does it
actually mean, and how is all this supposed to make sense?

What sense does it make that mark-even-if-inactive is non-nil by default
with transient-mark-mode enabled being the default?  It should be nil by
default because that would make a lot more sense.

> Why are you using Emacs at all?  You seem to dislike its core concepts
> and methods fairly strongly.

That some things don't make sense doesn't mean I dislike Emacs.  I like
it very much, and I think it might be good if it had more users, so I'm
pointing out what doesn't make sense so things can be improved upon.

It was suggested to make delete-selection-mode the default because it
seems likely that new users might expect the behaviour it provides.  I'm
going a bit further by saying that making and working with selections
could use an overhaul because there are so many inconsistent things
involved and that it all doesn't make much sense once you start thinking
about it --- and before that is sorted out, changing the default to be
d-s-m enabled doesn't seem a good idea.

> There are other editors available, some of which will more closely
> approximate the way you want to handle selections.  Why are you
> sticking with Emacs?

Which one would be a better alternative?

reply via email to

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