Re: visual-region-mode?

[hw <hw@adminart.net>]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Wed, 19 Sep 2018 03:45:23 +0200
>>
>> >> Having clarified which operations can be used with a region doesn't mean
>> >> that working with a region can be efficiently done.
>> >
>> > It does for me.  For example, see the output of M-x -region TAB.  By
>> > just knowing a smidgeon of these commands, you can work very
>> > efficiently with a region, with all the documentation and help Emacs
>> > provides.
>> 
>> That's like saying it doesn't matter how inefficient a procedure is if
>> you only have some instructions to perform it.
>
> When these instructions are so simple, they cannot help being
> efficient.

Simple instructions can be very inefficient, for example by leaving out
important information, by oversimplifying things or by trying to dumb
things down.  Look at the products Ubiquity makes, they are extremely
good examples for oversimplified instructions which make their otherwise
great products extremely inefficient whenever you need instructions.

Another example are simple instructions for your portable generator
which don't make it efficient to power your home (or anything else) with
it.  They would only make it obvious that the complexity or lack thereof
of instructions has nothing to do with how efficient something is.

> But if you reject the main building block they use (the
> region, active or not), then it makes sense that you find them
> inefficient.

Rejecting the region or not is entirely unrelated to that clarifying
operations to work with it doesn't magically make something efficient.
Besides, there are many examples showing that the operations aren't
clarified much.

>> > If we somehow "disarm" the region by default (as you have
>> > suggested), the use of all these commands would be less efficient.
>> 
>> That was Elis idea, and it doesn't refer to commands implying "region"
>> but, IIUC, to how to deal with that users might sometimes want to delete
>> a region by inserting characters and sometimes not.
>
> Ok.
>
>> Well, I have delete-active-region and mark-even-if-inactive set to nil
>> and am testing this:
>> 
>> 
>> (defun my-exchange-point-and-mark (&optional arg)
>>   "Put the mark where point is now, and point where the mark is
>> now.  With a prefix argument, toggle the activeness of the
>> region.
>> 
>> This function itself is ignorant of `transient-mark-mode'."
>>   (interactive "P")
>>   (let ((omark (marker-position (mark-marker))))
>>     (if (null omark)
>>         (user-error "No mark set in this buffer"))
>>     (set-marker (mark-marker) (point))
>>     (goto-char omark))
>>   (if arg
>>       (if mark-active (deactivate-mark)
>> 	(activate-mark t))))
>> 
>> 
>> Now I have the region fortified and am able to use the mark for
>> navigation without making (or unmaking) a selection from the region
>> unless I actually want to.
>
> Ok.  If you decided to turn "t-m-m" off, though, how would you use
> "my-exchange-point-and-mark" to ever activate the mark again? In
> order for the region to be considered active, "t-m-m" has to enabled
> (if only temporarily), hence the current wrangling in
> "exchange-point-and-mark" to turn it on temporarily when the user asks
> for it.

With t-m-m disabled, there is no way to fortify the region, and there is
no highlighting.  Why would I disable it?

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?

Are there any disadvantages of having t-m-m enabled that would overcome
all the advantages of having it disabled?