From: Drew Adams <drew.adams@oracle.com>
To: Alexandre Oberlin <alxobr@gmail.com>, help-gnu-emacs@gnu.org
Subject: RE: Replacing huge hidden selection when pasting text
Date: Sat, 2 Jan 2016 18:11:44 -0800 (PST) [thread overview]
Message-ID: <65217859-5975-46aa-920c-fc846f5caad3@default> (raw)
In-Reply-To: <70837df3-23f5-416b-8e0a-b9f105f7a40c@googlegroups.com>
> > Apologies for not following this thread. But offhand I'd say that
> > there's your problem right there: you enable `delete-selection-mode'
> > but you disable `transient-mark-mode'. That should be a no-no.
Apparently I should not have been so cavalier with that last
sentence, which I meant somewhat tongue-in-cheek, but instead I
should have said something like this: You might not want to do that.
> Oh my dear, I managed to hit a no-no! But if it's a no-no why is it possible
> in the first place? Why ain't there a single warning? Where are emacs's no-
> nos listed? Where is the checkbox and message saying "I agree not to do any
> emacs no-no, even if I don't know what they are"? Are you serious?
>
> You can't ask all Emacs users to be expert in its ever changing
> configuration rules. Don't you think they might have some other work to do?
> Enabling delete-selection-mode and disabling transient-mark-mode is nothing
> more than what an average user unsatisfied with the default behavior would
> try at first in order to get a "Windows notepad" like behavior regarding
> selection and overwriting. This is not rocket science is it?
>
> However, I must repeat that the problem is not really here, since the
> program often functions correctly with the above settings. All I can
> conclude by now is that all users of Emacs today must be aware of an
> unpublished list of no-nos which allow the program to function erratically.
>
> I am sure you will gain loads of Windows users with that kind of philosophy.
Sheesh. Guess I should have stayed out of the thread.
I thought to help, but apparently the info I provided just
aggravated you.
"No-no" was kidding on my part. I meant to suggest that
`delete-selection-mode' was designed from the outset to use
`transient-mark-mode', and that if you turn the latter off
then you might find that the result is, well, behavior that
you didn't expect. Maybe.
Why is it possible to, so to speak, shoot yourself in the
foot this way? Emacs has no special tamper-proof covering,
and it comes with no guarantees. Part of the aim of Emacs
is to be open. And that includes open to experimentation
and using its code any way you like. Emacs even opens its
innards to ordinary end users who might want to peer in.
Emacs typically tells you what it does and how it works,
especially if you know how to ask it. And it does try
to prevent typical use from accidentally deleting data.
And in some cases that means, yes, warning users.
(BTW, I don't think this is true: "There isn't even a
warning when saving a file which has shrunk a lot, like
there once was." I've seen such warnings in recent Emacs
versions. If you can reproduce this problem, please consider
filing a bug report: `M-x report-emacs-bug'. At least to
me, that sounds like it would be a bug.)
If you want to turn d-s-mode on and t-m-mode off then you can
certainly do that. Go for it. The doc string tells you that
d-s-mode turns t-m-mode on, but it does not say you can't turn
it off.
Some users might even prefer whatever behavior that results
in. Dunno. And if you do not then you are free to change the
resulting behavior to whatever you like. The source code is
there for you to play with, or you can just code up your
own toy from scratch. No problem. Emacs invites, and even
encourages, fiddling, by all of its users, at whatever level
of interest or expertise.
And perhaps the d-s-mode doc should explicitly say that it
turns t-m-mode on BECAUSE that way you can see what will it
will delete. And perhaps it should explicitly say that you
probably do not want to turn t-m-mode off when d-s-mode is
on. Dunno. You seem to think it should, so maybe consider
suggesting such a doc change: `M-x report-emacs-bug'.
> You can't ask all Emacs users to be expert in its ever changing
> configuration rules.
If you mean by that that it is not too polite for Emacs to
change the rules often and without explanation, then I
certainly agree that that should be a no-no. (Oops, there I
go again.)
Emacs sometimes changes more than I, as one user, want, or
in ways that I am not crazy about. But overall, Emacs change
has been pretty conservative. And I, for one, happen to agree
with a conservative approach to changing Emacs configuration.
Changes in Emacs behavior, especially changes in default
behavior, are always documented (or should always be) in the
"NEWS" that is available with each Emacs release. You can
consult the NEWS using `C-h N'. If you don't do it first
thing when you change to a new Emacs version then you might
at least want to do it when you think you notice a change in
default behavior. (Just a suggestion - not a no-no not to
do so.)
I will just mention, wrt changes in d-s-mode and t-m-mode:
1. Both d-s-mode and t-m-mode have been around for a _very_
long time.
2. They both remain essentially as they were from the outset.
3. But there have been some changes, specifically (a) turning
on t-m-mode (but not d-s-mode) by default and (b) the
introduction of a "temporary t-m-mode", in particular for
those who prefer to turn t-m-mode off.
(FWIW, I use d-s-mode, and I've argued for years that it
be turned on by default.)
4. Even the change to turn on t-m-mode by default was the
result of long discussions by lots of people (and open to
anyone) over many years. Lots of reasoned arguments were
debated.
This is to say that, at least in this case, change in the
default Emacs behavior ("configuration change") was not
discussed by only a few or decided precipitously or
carelessly.
The founder of Emacs was the ultimate decider for this
change, and he was a participant in the discussion. He
also has the user-oriented reflex to remind those who are
now deciding Emacs stuff to please consider polling the
users before making important "configuration" changes.
(And I, for one, am glad that he does.)
If you want "to get a 'Windows notepad' like behavior
regarding selection and overwriting", then I think just
turning on d-s-mode comes pretty close. Nothing that I
know of comes closer out of the box.
And know, in case you are interested, that you can customize
the d-s-m behavior for any particular commands by putting a
particular value of property `delete-selection' on their
symbols.
For example, if you have your own command `yank-it' that
yanks something, and you want d-s-mode to understand that
your command is a yank so that it lets you yank whatever
is already copied (to the kill-ring) rather than just
yanking the very region that is currently selected, then
you would do this:
(put 'yank-it 'delete-selection 'yank)
Here's a suggestion, if you think that something useful for
users could be added to the d-s-mode or the t-m-mode doc:
Suggest a doc improvement as an enhancement request. It's
easy to do that: `M-x report-emacs-bug'.
HTH.
next prev parent reply other threads:[~2016-01-03 2:11 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-24 1:01 Replacing huge hidden selection when pasting text Alexandre Oberlin
2015-12-24 1:37 ` Drew Adams
2015-12-24 13:27 ` Alexandre Oberlin
2015-12-24 23:04 ` Stefan Monnier
2015-12-25 1:18 ` Pascal J. Bourguignon
[not found] ` <mailman.529.1451006347.843.help-gnu-emacs@gnu.org>
2016-01-02 21:40 ` Alexandre Oberlin
2016-01-02 22:03 ` Marcin Borkowski
[not found] ` <mailman.1550.1451772215.843.help-gnu-emacs@gnu.org>
2016-01-02 22:28 ` Alexandre Oberlin
2016-01-02 23:04 ` Drew Adams
[not found] ` <mailman.1551.1451775915.843.help-gnu-emacs@gnu.org>
2016-01-03 0:11 ` Alexandre Oberlin
2016-01-03 0:28 ` Michael Heerdegen
[not found] ` <mailman.1554.1451780942.843.help-gnu-emacs@gnu.org>
2016-01-03 0:41 ` Alexandre Oberlin
2016-01-03 1:07 ` Michael Heerdegen
2016-01-03 2:10 ` Robert Thorpe
2016-01-03 2:11 ` Drew Adams [this message]
2016-01-03 2:25 ` Michael Heerdegen
2016-01-03 3:10 ` Drew Adams
2016-01-03 3:21 ` Drew Adams
2016-01-03 4:09 ` Yuri Khan
2016-01-03 5:08 ` Random832
[not found] ` <mailman.1572.1451797753.843.help-gnu-emacs@gnu.org>
2016-01-13 17:13 ` Alexandre Oberlin
2016-01-14 14:07 ` Stefan Monnier
[not found] ` <mailman.2334.1452780465.843.help-gnu-emacs@gnu.org>
2016-01-14 15:35 ` Alexandre Oberlin
2016-01-14 16:11 ` Kaushal Modi
2016-01-14 17:20 ` Eli Zaretskii
2016-01-14 16:36 ` Michael Heerdegen
2016-01-14 16:41 ` Eli Zaretskii
[not found] ` <mailman.2341.1452787916.843.help-gnu-emacs@gnu.org>
2016-01-14 16:45 ` Alexandre Oberlin
2016-01-14 17:05 ` Kaushal Modi
2016-01-14 19:37 ` Stefan Monnier
[not found] ` <mailman.2359.1452800411.843.help-gnu-emacs@gnu.org>
2016-01-14 23:41 ` Alexandre Oberlin
[not found] ` <mailman.1570.1451794187.843.help-gnu-emacs@gnu.org>
2016-01-13 16:42 ` Alexandre Oberlin
2016-01-13 17:54 ` Yuri Khan
[not found] ` <mailman.2302.1452707668.843.help-gnu-emacs@gnu.org>
2016-01-14 13:57 ` Alexandre Oberlin
[not found] ` <mailman.1564.1451787927.843.help-gnu-emacs@gnu.org>
2016-01-13 17:26 ` Alexandre Oberlin
[not found] ` <mailman.528.1450998293.843.help-gnu-emacs@gnu.org>
2016-01-14 14:00 ` Alexandre Oberlin
2016-01-14 15:02 ` Stefan Monnier
2015-12-24 5:48 ` Pascal J. Bourguignon
2015-12-24 14:40 ` Andreas Röhler
2015-12-27 22:15 ` Robert Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65217859-5975-46aa-920c-fc846f5caad3@default \
--to=drew.adams@oracle.com \
--cc=alxobr@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).