Re: visual-region-mode?

[hw]

address@hidden (Charles A. Roelli) writes:

>> From: hw <address@hidden>
>> Date: Fri, 21 Sep 2018 22:28:53 +0200
>>
>> > There would be a way to "fortify" the region, if you had another
>> > binding for toggling whether the region is active or not.
>> 
>> Without t-m-m, the region can not become active.
>
> Yes, but since we have commands that offer behavior specific to active
> regions, we have the so-called "temporary transient mark mode" --
> which is a hack to get around this problem.  I'd rather have a way to
> explicitly activate/deactivate the region.

I'm not sure this is a distinct mode; it seems more like the region is
activated regardless of t-m-m being enabled or not and gets somehow
disabled eventually.

It seems activate-mark enables the region.

>> >> With t-m-m disabled, the region can not be activated, so why would I try
>> >> to do that?  My function is ignorant of t-m-m anyway.
>> >> 
>> >> Why would I disable t-m-m only to ask to temporarily enable it?
>> >
>> > That's how the current implementation is designed: the region is
>> > considered "active" when both "mark-active" is non-nil /and/ "t-m-m"
>> > is on.
>> 
>> That doesn't explain why I would disable t-m-m.
>
> No, it explains why you would temporarily enable it after disabling it
> permanently.

Why would I disable it permanently?  I wouldn't have highlighting, there
would be no way to fortify the region --- which is a requirement because
it can not really be disabled due to a fundamental design flaw --- and I
would have to narrow the buffer all the time to do something with a
region and to widen it afterwards.

That would just be ridiculously awkward and inconvenient.

>> Perhaps there is a way to disable the highlighting.  I haven't found out
>> how something is highlighted.
>
> It's possible to disable the highlighting by customizing the "region"
> face.

Well, that's not really a way to disable it, but it could be used as a
workaround.  So nothing speaks against having t-m-m enabled, and lots of
things speak for it.

>> > and without the region randomly deactivating itself after certain
>> > commands as it does with "t-m-m" switched on.
>> 
>> [...]
>>
>> Are you referring to commands deactivating the region?  
>
> Yes.  See the doc of "t-m-m":
>
>             The mark is "deactivated" by changing the buffer,
> and after certain other operations that set the mark but whose
> main purpose is something else--for example, incremental search,
> M-<, and M->.

So this doesn't happen randomly but intentionally --- and you could
re-activate the region if you still want to do something with it.


>>                                                        That could be
>> configurable, though I'm not sure how useful it is to indefinitely do
>> something with a region until it is explicitly deactivated.  
>
> That's how the region works with "t-m-m" off: you can always invoke a
> sequence of commands that use the region, without having to think
> about whether it's active.

Yes, and that's a design flaw because it means that the software makes
mistakes of users worse rather than protecting them from them.  Why
would anyone do stuff with random contents of a buffer, be it by
accident or otherwise?

> I'd like to be able to carry this behavior over to commands that
> require an active region for certain things, like M-% does for
> replacing inside a region.

I guess the right, or consistent, way to do that might be to write more
antagonistic functions that imply "region", like `query-replace-region'.

Why don't you make a selection when you want to do something with one?
With t-m-m enabled, that automatically activates the region, and it is
much better than doing stuff with random parts of the buffer.

Other than that, I wonder what would go wrong if you made a key binding
to a function that toggles `use-region-p' which you use before and
perhaps after calling functions you want to have a different behaviour.
Maybe `query-replace-region' could make use of that.

>> > Highlighting the region could be a separate mode.
>> 
>> Highlighting the region all the time is probably not very useful.
>
> Yes, but the user knows best, IMO.  The default would still be the
> same behavior as it is now.

Maybe, maybe not ...

>> >> Are there any disadvantages of having t-m-m enabled that would overcome
>> >> all the advantages of having it disabled?
>> >
>> > Not sure I understand this.
>> 
>> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
>> it?
>> 
>> I can see it for someone who doesn't like the highlighting, so if it was
>> configurable --- and it is amazing that is isn't --- whether to
>> highlight the region when it's active or not, everyone who dislikes the
>> highlighting could have t-m-m enabled.  I would remove having it
>> disabled entirely from Emacs because there is no point in that and only
>> complication.
>
> I think the main point of contention is C-x C-x: it activates the mark
> by default, which is irritating when you're using the mark for
> navigation.

Yeah that is messed up.

> Even if you disable the highlighting of the region, certain commands
> will behave differently in response to the region being active.

That doesn't really make sense.  Having t-m-m enabled is the default,
and there is no point and no sense in disabling it.  So don't disable
it, and your problems do not exist.

Of course, functions implying "region" don't make sense when t-m-m is
enabled: t-m-m already implies "region" in the sense of "selection",
somewhat overcoming the fundamental design flaw of "the region" and the
idea of doing stuff randomly with parts of buffers.  The functions
implying "region" are merely children of this design flaw because they
were only invented because nobody wants to narrow and widen their
buffers to do something with parts of them.

> You've already posted an improved version of C-x C-x that does not

I wouldn't call it "improved", only "different": it depends on what one
wants to happen.

> activate the mark by default: I think that is the right way to go, as
> well as a new command for explicitly activating/deactivating the mark.
> With these two fixes, much of the contention surrounding "t-m-m"
> should go.

Well, my fine keyboard broke, so I got out the Unicomp with 122 keys and
made more key bindings:


(global-set-key "\C-x\C-x" 'my-exchange-point-and-mark)
(global-set-key (kbd "<C-f1>")
                (lambda ()
                  "Toggle the activeness of the region."
                  (interactive)
                  (if mark-active (deactivate-mark)
                    (activate-mark t))))
(global-set-key [C-f2] 'my-exchange-point-and-mark)
(global-set-key [C-f3] 'previous-buffer)
(global-set-key [C-f5] 'next-buffer)


Those are actual keys, i. e. I press only one key for them.  It's rather
convenient.  (The key caps are labeled Print, Help, Record and Play.)

Unfortunately, it seems Unicomp is the only manufacturer still making
really good keyboards, and the only one for 122 keys ...  (The fine
keyboard started working again the next day after I banged it a little,
but I really like having more keys.)


On a side note, why is the function that activates the region called
activate-mark and not activate-region?  Is there some purpose or
distinction involved we don't know about?

> [...]
> Btw, I'm culling most of the CC list since it seems no longer relevant.

I don't know who/what created this list; I suspect it might have been
gnus.