From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Replacing huge hidden selection when pasting text Date: Sat, 2 Jan 2016 18:11:44 -0800 (PST) Message-ID: <65217859-5975-46aa-920c-fc846f5caad3@default> References: <5da6a556-646f-42ba-9bae-f5bf4387f09e@googlegroups.com> <84da4496-944e-4192-ac09-b5bfc0992f3f@googlegroups.com> <70837df3-23f5-416b-8e0a-b9f105f7a40c@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1451787140 13858 80.91.229.3 (3 Jan 2016 02:12:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 02:12:20 +0000 (UTC) To: Alexandre Oberlin , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jan 03 03:12:09 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aFY9Q-0000vw-FQ for geh-help-gnu-emacs@m.gmane.org; Sun, 03 Jan 2016 03:12:08 +0100 Original-Received: from localhost ([::1]:40286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFY9P-0003Kz-MD for geh-help-gnu-emacs@m.gmane.org; Sat, 02 Jan 2016 21:12:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFY9E-0003KG-AX for help-gnu-emacs@gnu.org; Sat, 02 Jan 2016 21:11:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFY9A-0007t9-7x for help-gnu-emacs@gnu.org; Sat, 02 Jan 2016 21:11:56 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:18623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFY9A-0007sQ-0K for help-gnu-emacs@gnu.org; Sat, 02 Jan 2016 21:11:52 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u032BkVZ021780 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 Jan 2016 02:11:47 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u032Bk57031831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 Jan 2016 02:11:46 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u032Bk3K030106; Sun, 3 Jan 2016 02:11:46 GMT In-Reply-To: <70837df3-23f5-416b-8e0a-b9f105f7a40c@googlegroups.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:108589 Archived-At: > > 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 possi= ble > in the first place? Why ain't there a single warning? Where are emacs's n= o- > nos listed? Where is the checkbox and message saying "I agree not to do a= ny > emacs no-no, even if I don't know what they are"? Are you serious? >=20 > 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 d= o? > Enabling delete-selection-mode and disabling transient-mark-mode is nothi= ng > more than what an average user unsatisfied with the default behavior woul= d > try at first in order to get a "Windows notepad" like behavior regarding > selection and overwriting. This is not rocket science is it? >=20 > 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 erraticall= y. >=20 > I am sure you will gain loads of Windows users with that kind of philosop= hy. 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.