* Re: delete-selection-mode as default (WAS: Some developement questions) @ 2018-09-07 0:32 Noam Postavsky 2018-09-07 0:35 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 245+ messages in thread From: Noam Postavsky @ 2018-09-07 0:32 UTC (permalink / raw) To: Drew Adams; +Cc: hw, Eli Zaretskii, Phillip Lord, spacibba, Emacs developers >> > > > we should turn on `delete-selection-mode' by default. >> > > >> > > I don't think we can, because it gets in the way when editing code. >> > >> > How so? It doesn't get in my way. Quite the contrary - I appreciate >> > it for editing code. Please give a recipe >> >> Type "C-x C-x", then some letter: puff! the whole region is gone. >> This could be okay in text modes, but in code buffers users generally >> don't replace regions with single letters. I don't understand why a user who is okay with replacing the region with a single letter in text mode, would all of sudden dislike the idea in a code buffer. Or, conversely, why a user who dislikes replacing the region with a single letter in code buffers, would suddenly be happly about it in a text buffer. > It's equivalent to your doing this without `delete-selection-mode': > C-x C-x M-w, then some letter I guess you meant C-w there. > I see zero difference between editing code and editing plain prose, > in this regard. In both cases the selection can be replaced by typing, As mentioned above, I agree with this. > and that's a plus, not a minus. Maybe. My feeling from using non-Emacs editors (gasp!), is that the main use of this sort of thing is rather for replacing the selection by pasting, not so about much typing. Or, for when some feature inserts some default text, it highlights that text, indicating to the user that they may replace it by typing (i.e., it's rare that a user-created selection is deleted by typing). ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 0:32 delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky @ 2018-09-07 0:35 ` Drew Adams 2018-09-07 6:47 ` Eli Zaretskii 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-07 0:35 UTC (permalink / raw) To: Noam Postavsky Cc: hw, Eli Zaretskii, Phillip Lord, spacibba, Emacs developers > > It's equivalent to your doing this without `delete-selection-mode': > > C-x C-x M-w, then some letter > > I guess you meant C-w there. Yes, sorry; my bad. > > I see zero difference between editing code and editing plain prose, > > in this regard. In both cases the selection can be replaced by typing, > > As mentioned above, I agree with this. > > > and that's a plus, not a minus. > > Maybe. My feeling from using non-Emacs editors (gasp!), is that the > main use of this sort of thing is rather for replacing the selection > by pasting, not so about much typing. Or, for when some feature > inserts some default text, it highlights that text, indicating to the > user that they may replace it by typing (i.e., it's rare that a > user-created selection is deleted by typing). Yes, those are useful use cases. But so is typing to replace, I think. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 0:32 delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 2018-09-07 0:35 ` Drew Adams @ 2018-09-07 6:47 ` Eli Zaretskii 2018-09-07 9:18 ` delete-selection-mode as default hw ` (5 more replies) 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2 siblings, 6 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-07 6:47 UTC (permalink / raw) To: Noam Postavsky; +Cc: hw, spacibba, phillip.lord, drew.adams, emacs-devel > From: Noam Postavsky <npostavs@gmail.com> > Date: Thu, 6 Sep 2018 20:32:54 -0400 > Cc: Eli Zaretskii <eliz@gnu.org>, hw <hw@adminart.net>, spacibba@aol.com, > Emacs developers <emacs-devel@gnu.org>, Phillip Lord <phillip.lord@russet.org.uk> > > >> Type "C-x C-x", then some letter: puff! the whole region is gone. > >> This could be okay in text modes, but in code buffers users generally > >> don't replace regions with single letters. > > I don't understand why a user who is okay with replacing the region > with a single letter in text mode, would all of sudden dislike the > idea in a code buffer. Because in text editing, it is a frequent use case that you want to replace a region of text with some other long text; and also I find myself in the need of doing "C-x C-x" much less frequently when I'm editing text. By contrast, in coding, most changes are of a much smaller size, and "C-x C-x" is a very frequent command, due to the need to look at other portions of the code. > Maybe. My feeling from using non-Emacs editors (gasp!), is that the > main use of this sort of thing is rather for replacing the selection > by pasting, not so about much typing. Or, for when some feature > inserts some default text, it highlights that text, indicating to the > user that they may replace it by typing (i.e., it's rare that a > user-created selection is deleted by typing). It is exactly these features that get in the way when I write code. It means I must click the mouse or do some cursor motion or C-g after yanking, otherwise typing something will nuke the text just yanked. Feel free to start a user poll, though: if it turns out I'm the only one who thinks delete-selection-mode is inappropriate in programming modes, we can make it the default; I can easily turn it off in my configuration. Though I would urge people to actually try this in programming modes before responding, and in any case the poll should request to provide the major modes used with the responses. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 6:47 ` Eli Zaretskii @ 2018-09-07 9:18 ` hw 2018-09-07 13:16 ` Clément Pit-Claudel 2018-09-07 9:40 ` delete-selection-mode as default (WAS: Some developement questions) Phil Sainty ` (4 subsequent siblings) 5 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-07 9:18 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, emacs-devel, Noam Postavsky, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: > [...] > Feel free to start a user poll, though: if it turns out I'm the only > one who thinks delete-selection-mode is inappropriate in programming > modes, we can make it the default; I can easily turn it off in my > configuration. Though I would urge people to actually try this in > programming modes before responding, and in any case the poll should > request to provide the major modes used with the responses. When a selection is active, why would anyone assume that typing an arbitrary letter is supposed to replace the entire selection, or to disable it? Allowing that to happen is simply a design flaw, or an oversight. And if that was allowed, it would be a case-specific decision whether the selection should be replaced or disabled, not a general one decidable by a default. I would vote for a "strict-mode", or "static-selection-mode", meaning that when a selection is active, typing an arbitrary letter makes Emacs beep and otherwise do nothing. It is always an accident when I type an arbitrary letter while a selection is active, and it only makes the accident worse when the selection is replaced, or disabled and the letter is entered into the buffer. Either I want to do something with a selection or not. There is no in-between. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 9:18 ` delete-selection-mode as default hw @ 2018-09-07 13:16 ` Clément Pit-Claudel 2018-09-07 13:28 ` Robert Pluim ` (2 more replies) 0 siblings, 3 replies; 245+ messages in thread From: Clément Pit-Claudel @ 2018-09-07 13:16 UTC (permalink / raw) To: emacs-devel On 2018-09-07 05:18, hw wrote: > When a selection is active, why would anyone assume that typing an > arbitrary letter is supposed to replace the entire selection, or to > disable it? Out of experience, mostly. When almost every other program you use besides Emacs behaves that way, it's easy to assume that Emacs will behave the same way. > Allowing that to happen is simply a design flaw, or an > oversight. I prefer to think of it as a very convenient feature. For example, as I typed this email, I first wrote "as I composed" instead of "as I typed", pressed Control+Shift+Left Arrow, and pressed "typed". Similarly, I had first written "I call it" instead of "I prefer to think of it", and the way I changed one into the other was to select "call it" and type "prefer to think of it as". This select, then type to replace behavior is the norm in most programs I use outside Emacs, and it doesn't sound like a design flaw to me. Of course, Emacs' default behavior can be very convenient too, and it's good that it can do both. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:16 ` Clément Pit-Claudel @ 2018-09-07 13:28 ` Robert Pluim 2018-09-07 13:47 ` Dmitry Gutov 2018-09-07 13:50 ` Eli Zaretskii 2018-09-07 14:39 ` hw 2018-09-08 5:14 ` Richard Stallman 2 siblings, 2 replies; 245+ messages in thread From: Robert Pluim @ 2018-09-07 13:28 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel Clément Pit-Claudel <cpitclaudel@gmail.com> writes: > On 2018-09-07 05:18, hw wrote: >> When a selection is active, why would anyone assume that typing an >> arbitrary letter is supposed to replace the entire selection, or to >> disable it? > > Out of experience, mostly. When almost every other program you use > besides Emacs behaves that way, it's easy to assume that Emacs will > behave the same way. > >> Allowing that to happen is simply a design flaw, or an >> oversight. > > I prefer to think of it as a very convenient feature. For example, as > I typed this email, I first wrote "as I composed" instead of "as I > typed", pressed Control+Shift+Left Arrow, and pressed "typed". > Similarly, I had first written "I call it" instead of "I prefer to > think of it", and the way I changed one into the other was to select > "call it" and type "prefer to think of it as". Neither of those require 'replace selected' behaviour, since you could easily use M-DEL instead. It could be useful when you need to replace a word far away from point, although personally Iʼll use isearch to get there, not the mouse. > This select, then type to replace behavior is the norm in most > programs I use outside Emacs, and it doesn't sound like a design flaw > to me. Of course, Emacs' default behavior can be very convenient too, > and it's good that it can do both. Agreed. Robert ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:28 ` Robert Pluim @ 2018-09-07 13:47 ` Dmitry Gutov 2018-09-07 13:50 ` Eli Zaretskii 1 sibling, 0 replies; 245+ messages in thread From: Dmitry Gutov @ 2018-09-07 13:47 UTC (permalink / raw) To: emacs-devel On 9/7/18 4:28 PM, Robert Pluim wrote: > Neither of those require 'replace selected' behaviour, since you could > easily use M-DEL instead. That implies one always replaces one word at a time. Which is not the case for me. Personally, one of the reasons delete-selection-mode is handy is that while we have a handy key binding for 'kill-region', we don't have one for 'delete-region'. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:28 ` Robert Pluim 2018-09-07 13:47 ` Dmitry Gutov @ 2018-09-07 13:50 ` Eli Zaretskii 2018-09-07 14:16 ` Robert Pluim 2018-09-07 14:22 ` Stefan Monnier 1 sibling, 2 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-07 13:50 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel > From: Robert Pluim <rpluim@gmail.com> > Date: Fri, 07 Sep 2018 15:28:31 +0200 > Cc: emacs-devel@gnu.org > > > I prefer to think of it as a very convenient feature. For example, as > > I typed this email, I first wrote "as I composed" instead of "as I > > typed", pressed Control+Shift+Left Arrow, and pressed "typed". > > Similarly, I had first written "I call it" instead of "I prefer to > > think of it", and the way I changed one into the other was to select > > "call it" and type "prefer to think of it as". > > Neither of those require 'replace selected' behaviour, since you could > easily use M-DEL instead. In Emacs, yes. Let's not assume everybody here uses only Emacs for each and every editing job. So I'm with Clément on this one. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:50 ` Eli Zaretskii @ 2018-09-07 14:16 ` Robert Pluim 2018-09-07 16:02 ` Drew Adams 2018-09-07 14:22 ` Stefan Monnier 1 sibling, 1 reply; 245+ messages in thread From: Robert Pluim @ 2018-09-07 14:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Robert Pluim <rpluim@gmail.com> >> Date: Fri, 07 Sep 2018 15:28:31 +0200 >> Cc: emacs-devel@gnu.org >> >> > I prefer to think of it as a very convenient feature. For example, as >> > I typed this email, I first wrote "as I composed" instead of "as I >> > typed", pressed Control+Shift+Left Arrow, and pressed "typed". >> > Similarly, I had first written "I call it" instead of "I prefer to >> > think of it", and the way I changed one into the other was to select >> > "call it" and type "prefer to think of it as". >> >> Neither of those require 'replace selected' behaviour, since you could >> easily use M-DEL instead. > > In Emacs, yes. Let's not assume everybody here uses only Emacs for > each and every editing job. I try to, and then get very annoyed when other programs do things differently (Iʼm looking at you here, Firefox URL bar). > So I'm with Clément on this one. I wasn't picking a side, nor do I think we should pick one for anyone else. Robert ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-07 14:16 ` Robert Pluim @ 2018-09-07 16:02 ` Drew Adams 2018-09-07 17:08 ` Robert Pluim 0 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-07 16:02 UTC (permalink / raw) To: Robert Pluim, Eli Zaretskii; +Cc: emacs-devel > I wasn't picking a side, nor do I think we should pick one for anyone > else. It's about the choice of a _default_ behavior. Currently one particular choice was made. It's possible to choose a different one instead. In any case the choice of the default behavior picks the behavior for everyone - but only the default behavior. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 16:02 ` Drew Adams @ 2018-09-07 17:08 ` Robert Pluim 2018-09-07 20:28 ` Jostein Kjønigsen 0 siblings, 1 reply; 245+ messages in thread From: Robert Pluim @ 2018-09-07 17:08 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, emacs-devel Drew Adams <drew.adams@oracle.com> writes: >> I wasn't picking a side, nor do I think we should pick one for anyone >> else. > > It's about the choice of a _default_ behavior. Currently one particular > choice was made. It's possible to choose a different one instead. In > any case the choice of the default behavior picks the behavior for > everyone - but only the default behavior. Right. I meant that I donʼt think we should change the default behaviour, but I won't scream if we do since I can always put it back. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 17:08 ` Robert Pluim @ 2018-09-07 20:28 ` Jostein Kjønigsen 0 siblings, 0 replies; 245+ messages in thread From: Jostein Kjønigsen @ 2018-09-07 20:28 UTC (permalink / raw) To: emacs-devel, Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 1884 bytes --] I realize Eli is a Emacs-vetaran and his opinion holds a lot of weight here. That said.... > When a selection is active, why would anyone assume that typing an > arbitrary letter is supposed to replace the entire selection, or to > disable it? Because that's what users expect after this having been the default interaction model for all applications for more than 3 decades. I realize Emacs is older than that, but trying to pretend that the outside world haven't established a set of conventions people have come to expect is pretty much being the ostrich sticking your head in the sand. Adhering to the conventions the user expect is user-friendly. We should do that by default when it doesn't introduce needless complexity (like arguably enabling cua-mode would). That still leaves the option for power users, like yourself, to customize the behaviour in non-conventional ways which you find powerful. I mean... I -love- paredit. It's amazing. But it clearly should not be the *default* for editing LISP files, unless we want to throw new-comers away before they've managed to say hello. All in all, I vote for this change. -- Regards Jostein Kjønigsen jostein@kjonigsen.net 🍵 jostein@gmail.com https://jostein.kjonigsen.net On Fri, Sep 7, 2018, at 7:08 PM, Robert Pluim wrote: > Drew Adams <drew.adams@oracle.com> writes: > >>> I wasn't picking a side, nor do I think we should pick one for >>> anyone>>> else. >> >> It's about the choice of a __default__ behavior. Currently one >> particular>> choice was made. It's possible to choose a different one instead. In>> any case the choice of the default behavior picks the behavior for >> everyone - but only the default behavior. > > Right. I meant that I donʼt think we should change the default > behaviour, but I won't scream if we do since I can always put it back.> [-- Attachment #2: Type: text/html, Size: 2952 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:50 ` Eli Zaretskii 2018-09-07 14:16 ` Robert Pluim @ 2018-09-07 14:22 ` Stefan Monnier 2018-09-08 23:11 ` Juri Linkov 2018-09-16 23:34 ` Juri Linkov 1 sibling, 2 replies; 245+ messages in thread From: Stefan Monnier @ 2018-09-07 14:22 UTC (permalink / raw) To: emacs-devel FWIW, while I personally don't use delete-selection-mode, I wouldn't object to enabling it by default (I'd probably disable it in my .emacs, but I'd first try to keep it enabled to see if I can change my habits). But before that I'd appreciate if we could improve its implementation so it doesn't rely on pre-command-hook. Stefan Eli Zaretskii <eliz@gnu.org> writes: >> From: Robert Pluim <rpluim@gmail.com> >> Date: Fri, 07 Sep 2018 15:28:31 +0200 >> Cc: emacs-devel@gnu.org >> >> > I prefer to think of it as a very convenient feature. For example, as >> > I typed this email, I first wrote "as I composed" instead of "as I >> > typed", pressed Control+Shift+Left Arrow, and pressed "typed". >> > Similarly, I had first written "I call it" instead of "I prefer to >> > think of it", and the way I changed one into the other was to select >> > "call it" and type "prefer to think of it as". >> >> Neither of those require 'replace selected' behaviour, since you could >> easily use M-DEL instead. > > In Emacs, yes. Let's not assume everybody here uses only Emacs for > each and every editing job. > > So I'm with Clément on this one. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 14:22 ` Stefan Monnier @ 2018-09-08 23:11 ` Juri Linkov 2018-09-09 5:49 ` Eli Zaretskii 2018-09-09 14:22 ` Drew Adams 2018-09-16 23:34 ` Juri Linkov 1 sibling, 2 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-08 23:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > FWIW, while I personally don't use delete-selection-mode, I wouldn't > object to enabling it by default (I'd probably disable it in my .emacs, > but I'd first try to keep it enabled to see if I can change my habits). > > But before that I'd appreciate if we could improve its implementation so > it doesn't rely on pre-command-hook. Incidentally, yesterday I discovered a case when Wdired breaks delete-selection-mode. Selecting a file name in Wdired and starting to type its new name to completely replace an old name with a new one signals the error "No file on this line", then removes delete-selection-pre-hook from pre-command-hook while leaving delete-selection-mode still active, so delete-selection-mode becomes completely broken - it doesn't replace the selection anymore. I had to disable and then enable delete-selection-mode again to get delete-selection-pre-hook back to pre-command-hook. The error that removes delete-selection-pre-hook from pre-command-hook logged in *Messages* is: Error in pre-command-hook (delete-selection-pre-hook): (error "No file on this line") so relying on pre-command-hook is indeed the d-s-m's weak point. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 23:11 ` Juri Linkov @ 2018-09-09 5:49 ` Eli Zaretskii 2018-09-09 16:16 ` Juri Linkov 2018-09-09 14:22 ` Drew Adams 1 sibling, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-09 5:49 UTC (permalink / raw) To: Juri Linkov; +Cc: monnier, emacs-devel > From: Juri Linkov <juri@linkov.net> > Date: Sun, 09 Sep 2018 02:11:18 +0300 > Cc: emacs-devel@gnu.org > > Incidentally, yesterday I discovered a case when Wdired breaks > delete-selection-mode. Selecting a file name in Wdired and starting > to type its new name to completely replace an old name with a new one > signals the error "No file on this line", then removes > delete-selection-pre-hook from pre-command-hook while leaving > delete-selection-mode still active, so delete-selection-mode becomes > completely broken - it doesn't replace the selection anymore. In what version of Emacs did you see that? We recently fixed bug#32173, and the above sounds like something similar. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 5:49 ` Eli Zaretskii @ 2018-09-09 16:16 ` Juri Linkov 0 siblings, 0 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-09 16:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel >> Incidentally, yesterday I discovered a case when Wdired breaks >> delete-selection-mode. Selecting a file name in Wdired and starting >> to type its new name to completely replace an old name with a new one >> signals the error "No file on this line", then removes >> delete-selection-pre-hook from pre-command-hook while leaving >> delete-selection-mode still active, so delete-selection-mode becomes >> completely broken - it doesn't replace the selection anymore. > > In what version of Emacs did you see that? > > We recently fixed bug#32173, and the above sounds like something > similar. Thanks for the reference, I can confirm it's caused by changes in bug#32173 a month ago. I reported a new bug#32673, but maybe it can be merged with the already archived bug#32173. This bug is a clear indication that delete-selection-mode needs to be moved to simple.el where it will fit near shift-select-mode and transient-mark-mode. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-08 23:11 ` Juri Linkov 2018-09-09 5:49 ` Eli Zaretskii @ 2018-09-09 14:22 ` Drew Adams 1 sibling, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-09 14:22 UTC (permalink / raw) To: Juri Linkov, Stefan Monnier; +Cc: emacs-devel > > FWIW, while I personally don't use delete-selection-mode, I wouldn't > > object to enabling it by default (I'd probably disable it in my .emacs, > > but I'd first try to keep it enabled to see if I can change my habits). > > > > But before that I'd appreciate if we could improve its implementation so > > it doesn't rely on pre-command-hook. > > Incidentally, yesterday I discovered a case when Wdired breaks > delete-selection-mode. Selecting a file name in Wdired and starting > to type its new name to completely replace an old name with a new one > signals the error "No file on this line", then removes > delete-selection-pre-hook from pre-command-hook while leaving > delete-selection-mode still active, so delete-selection-mode becomes > completely broken - it doesn't replace the selection anymore. > > I had to disable and then enable delete-selection-mode again > to get delete-selection-pre-hook back to pre-command-hook. > > The error that removes delete-selection-pre-hook from pre-command-hook > logged in *Messages* is: > > Error in pre-command-hook (delete-selection-pre-hook): (error "No file on this > line") I don't see that at all. What recipe did you use, in what Emacs release? 1. emacs -Q 2. Turn on d-s-m 3. Dired in some buffer 4. C-x C-q ; enable Wdired 5. Select a complete file name 6. Type to replace that name with another name 7. C-x C-q ; disable Wdired At no point did Emacs raise an error. In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 built on CIRROCUMULUS Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor 'Microsoft Corp.', version 10.0.16299 ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 14:22 ` Stefan Monnier 2018-09-08 23:11 ` Juri Linkov @ 2018-09-16 23:34 ` Juri Linkov 2018-09-17 0:36 ` Drew Adams 1 sibling, 1 reply; 245+ messages in thread From: Juri Linkov @ 2018-09-16 23:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > But before that I'd appreciate if we could improve its implementation so > it doesn't rely on pre-command-hook. Reimplementing delete-selection-mode to be more like shift-select-mode will also require to get rid of putting 'delete-selection props on command symbols, and like shift-translated commands have a `^' character in the `interactive' spec, delete-selection-mode might require a separate character. Hopefully, these types of commands are mutual exclusive, so their disjoint sets won't cause conflicting interactive specs. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-16 23:34 ` Juri Linkov @ 2018-09-17 0:36 ` Drew Adams 2018-09-17 22:37 ` Juri Linkov 0 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-17 0:36 UTC (permalink / raw) To: Juri Linkov, Stefan Monnier; +Cc: emacs-devel > Reimplementing delete-selection-mode to be more like shift-select-mode > will also require to get rid of putting 'delete-selection props on > command symbols, and like shift-translated commands have a `^' character > in the `interactive' spec, delete-selection-mode might require a separate > character. Hopefully, these types of commands are mutual exclusive, > so their disjoint sets won't cause conflicting interactive specs. Shift selection and `interactive' `^' have nothing whatsoever to do with `delete-selection-mode'. D-s-m does not care how the text was selected. And it works fine together with Shift selection. It's not clear what you mean by making d-s-m "more like shift-select-mode". But in any case I disagree with such an incompatible change for d-s-m. If you want something different from d-s-m (e.g. "more like shift-select-mode) then please come up with a new mode for that. Please don't change the longstanding, simple, and elegant d-s-m design, which includes the ability to define the d-s-m behavior for a particular command by putting a property on the command symbol. This thread should really be about whether d-s-m should be turned on by default. If you want something different from d-s-m then, by all means, please implement it - but using a new mode name. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 0:36 ` Drew Adams @ 2018-09-17 22:37 ` Juri Linkov 2018-09-17 23:12 ` Drew Adams 2018-09-19 6:53 ` Jostein Kjønigsen 0 siblings, 2 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-17 22:37 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, emacs-devel > This thread should really be about whether d-s-m > should be turned on by default. If you want something > different from d-s-m then, by all means, please > implement it - but using a new mode name. It can not be turned on by default without reimplementation because of bug#32673 so in fact you are voting against turning it on by default. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-17 22:37 ` Juri Linkov @ 2018-09-17 23:12 ` Drew Adams 2018-09-17 23:21 ` Juri Linkov 2018-09-19 6:53 ` Jostein Kjønigsen 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-17 23:12 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel > > This thread should really be about whether d-s-m > > should be turned on by default. If you want something > > different from d-s-m then, by all means, please > > implement it - but using a new mode name. > > It can not be turned on by default without reimplementation because of > bug#32673 so in fact you are voting against turning it on by default. Wasn't that bug introduced by particular changes trying to fix bug #32173? #32173 says that those changes "break d-s-m", by inappropriately turning d-s-m off. Just don't do that. It's not a problem with d-s-m itself, AFAICT. Regardless. If you think d-s-m can't be turned on by default then don't turn it on by default. But please don't mess with it. Worse than not turning it on by default (who really cares that much?) is ruining it, giving it an incompatible design. It doesn't need a makeover. Please just leave it alone. We can wait another 30 years for someone to reconsider turning it on by default (I won't be here, but I think it will happen). I didn't really expect it to happen now. Maybe in another decade or two... ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 23:12 ` Drew Adams @ 2018-09-17 23:21 ` Juri Linkov 2018-09-17 23:36 ` Drew Adams 0 siblings, 1 reply; 245+ messages in thread From: Juri Linkov @ 2018-09-17 23:21 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, emacs-devel > Wasn't that bug introduced by particular changes trying to fix > bug #32173? #32173 says that those changes "break d-s-m", > by inappropriately turning d-s-m off. Just don't do that. It's not > a problem with d-s-m itself, AFAICT. This bug was caused by the fundamental flaw in its current implementation. > Regardless. If you think d-s-m can't be turned on by default > then don't turn it on by default. But please don't mess with it. > > Worse than not turning it on by default (who really cares that > much?) is ruining it, giving it an incompatible design. It doesn't > need a makeover. Please just leave it alone. Its reimplementation could have a different name: not delete-selection-mode, but e.g. delete-select-mode (like handle-shift-selection vs shift-select-mode). ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-17 23:21 ` Juri Linkov @ 2018-09-17 23:36 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-17 23:36 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel > This bug was caused by the fundamental flaw in its current implementation. I don't see a fundamental flaw in d-s-m. I see a bug in Wdired. > Its reimplementation could have a different name: not delete-selection-mode, > but e.g. delete-select-mode (like handle-shift-selection vs shift-select-mode). Create a new mode for what you want, please. It's not about "reimplementing" `delete-selection-mode'. Call your new mode whatever you want. But IMO "delete-select-mode" is not a great name. Besides sowing confusion (obviously) with `delete-selection-mode', "delete-select" is meaningless/contradictory or at best unclear. `shift-select-mode' is OK as a name because it uses the Shift key to select. It doesn't require an existing selection. `delete-selection-mode' also makes sense, because it deletes a selection - selected text. The selection must exist - the text must have been selected - before it can be deleted. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 22:37 ` Juri Linkov 2018-09-17 23:12 ` Drew Adams @ 2018-09-19 6:53 ` Jostein Kjønigsen 2018-09-19 22:44 ` Juri Linkov 1 sibling, 1 reply; 245+ messages in thread From: Jostein Kjønigsen @ 2018-09-19 6:53 UTC (permalink / raw) To: Juri Linkov, Drew Adams; +Cc: Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 728 bytes --] On Tue, Sep 18, 2018, at 12:37 AM, Juri Linkov wrote: >> This thread should really be about whether d-s-m >> should be turned on by default. If you want something >> different from d-s-m then, by all means, please >> implement it - but using a new mode name. > > It can not be turned on by default without reimplementation because of> bug#32673 so in fact you are voting against turning it on by default.> As far as I can see, a patch for that bug was pushed to master almost a week ago, so I fail to see how that is a relevant argument now. See commit: 755fa346eba212b4650c8541023bb78e1658d77b. -- Regards Jostein Kjønigsen jostein@kjonigsen.net 🍵 jostein@gmail.com https://jostein.kjonigsen.net [-- Attachment #2: Type: text/html, Size: 1634 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-19 6:53 ` Jostein Kjønigsen @ 2018-09-19 22:44 ` Juri Linkov 0 siblings, 0 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-19 22:44 UTC (permalink / raw) To: Jostein Kjønigsen; +Cc: jostein, Stefan Monnier, Drew Adams, emacs-devel >>> This thread should really be about whether d-s-m >>> should be turned on by default. If you want something >>> different from d-s-m then, by all means, please >>> implement it - but using a new mode name. >> >> It can not be turned on by default without reimplementation because of >> bug#32673 so in fact you are voting against turning it on by default.> > > As far as I can see, a patch for that bug was pushed to master almost a > week ago, so I fail to see how that is a relevant argument now. The problem is that the current implementation of delete-selection-mode is so fragile that any error signal in the hook will break it easily. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:16 ` Clément Pit-Claudel 2018-09-07 13:28 ` Robert Pluim @ 2018-09-07 14:39 ` hw 2018-09-07 16:27 ` Drew Adams 2018-09-08 17:37 ` Clément Pit-Claudel 2018-09-08 5:14 ` Richard Stallman 2 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-07 14:39 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel Clément Pit-Claudel <cpitclaudel@gmail.com> writes: > On 2018-09-07 05:18, hw wrote: >> When a selection is active, why would anyone assume that typing an >> arbitrary letter is supposed to replace the entire selection, or to >> disable it? > > Out of experience, mostly. When almost every other program you use > besides Emacs behaves that way, it's easy to assume that Emacs will > behave the same way. It's not my experience because when I want a selection deleted, I delete it. If it gets deleted otherwise, that's a mistake or maybe even a bug when no undo is available. >> Allowing that to happen is simply a design flaw, or an >> oversight. > > I prefer to think of it as a very convenient feature. For example, as > I typed this email, I first wrote "as I composed" instead of "as I > typed", pressed Control+Shift+Left Arrow, and pressed "typed". > Similarly, I had first written "I call it" instead of "I prefer to > think of it", and the way I changed one into the other was to select > "call it" and type "prefer to think of it as". > > This select, then type to replace behavior is the norm in most > programs I use outside Emacs, and it doesn't sound like a design flaw > to me. I call it a design flaw because if whoever made it this way had given any thought to it, it would at least be customizable --- and, as said, because when I want a selection deleted or to be unselected, I delete it or unselect it, and having a selection randomly disappear like by tying letters means making a mistake worse. Software supporting users in making mistakes and making the mistakes even worse suffers from design flaws unless doing so is the very purpose of the software. I suspect that one important reason for the dangerous and careless dealing with selections you find in many other programs is that the developers couldn't be bothered to find a better way. The behaviour is inconsistant, too: insert a frame into a text document with Libreoffice, keep the frame selected and type something. Surprise! This obviously hasn't been thought through, and the behaviour LO shows here is a design flaw. > Of course, Emacs' default behavior can be very convenient too, > and it's good that it can do both. right Maybe the default should be changed, as well as Alt-left and Alt-right should go backward and forward in info history. But then Emacs would default to supporting users in making mistakes and make them worse. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-07 14:39 ` hw @ 2018-09-07 16:27 ` Drew Adams 2018-09-08 17:37 ` Clément Pit-Claudel 1 sibling, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-07 16:27 UTC (permalink / raw) To: hw, Clément Pit-Claudel; +Cc: emacs-devel > I call it a design flaw because if whoever made it this way had given > any thought to it, it would at least be customizable Actually, beyond being customizable by configuring it to be on or off by default, it is customizable (but not just by using Customize), in a fine-grained way. You can easily configure the behavior to use for any given command, by putting a particular `delete-selection' property value on its symbol. These are the possible `delete-selection' property values: * `yank' - For commands that do a yank. Ensures that the region about to be deleted is not yanked. * `supersede' - Delete the active region and ignore the current command: the command just deletes the region. * `kill' - `kill-region' is used on the selection, rather than `delete-region'. (Text selected with the mouse is typically yankable anyway.) * anything else non-nil - Deletes the active region prior to executing the command, which inserts replacement text. This is the usual case. Commands that insert text but do not have property `delete-selection' (or commands for which it's value is nil) do not delete the selection. For example: ;; Don't let `insert-char' delete the selection. (put 'insert-char 'delete-selection nil) More typically is the case where a library defines a new editing command that it wants to make susceptible to `delete-selection-mode'. For example: ;; Let delete-selection mode delete the region. (put 'icicle-delete-char 'delete-selection 'supersede) Simple, elegant command-specific behavior. Trivial to configure - for both users and libraries. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 14:39 ` hw 2018-09-07 16:27 ` Drew Adams @ 2018-09-08 17:37 ` Clément Pit-Claudel 2018-09-09 5:15 ` hw 1 sibling, 1 reply; 245+ messages in thread From: Clément Pit-Claudel @ 2018-09-08 17:37 UTC (permalink / raw) To: hw; +Cc: emacs-devel On 2018-09-07 10:39, hw wrote: >> On 2018-09-07 05:18, hw wrote: >>> When a selection is active, why would anyone assume that typing >>> an arbitrary letter is supposed to replace the entire selection, >>> or to disable it? >> Out of experience, mostly. When almost every other program you >> use besides Emacs behaves that way, it's easy to assume that Emacs >> will behave the same way. > It's not my experience because when I want a selection deleted, I > delete it. If it gets deleted otherwise, that's a mistake or maybe > even a bug when no undo is available. You seem to be conflating experience and desirable behavior. > I call it a design flaw because if whoever made it this way had > given any thought to it, it would at least be customizable Fortunately, some of those who "made it that way" did think about it :) For example, Microsoft Word has an option called "Typing Replaces Selected Text." Unfortunately, I couldn't find a similar setting in OpenOffice, nor in LibreOffice. Gtk entries and textviews do not seem to provide a similar setting, either, but I wouldn't assume that they didn't give any thought to it. > Software supporting users in making mistakes and making the mistakes > even worse suffers from design flaws unless doing so is the very > purpose of the software. I'm having trouble following the reasoning. > I suspect that one important reason for the dangerous and careless > dealing with selections you find in many other programs is that the > developers couldn't be bothered to find a better way. I understand that feeling, but I don't see much to support it. From the same observations, you could just as well conclude that no one cared enough about the behavior offered by Emacs to send patches to OpenOffice, Gtk, or many of the other libre IDEs and text editors. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 17:37 ` Clément Pit-Claudel @ 2018-09-09 5:15 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-09 5:15 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel Clément Pit-Claudel <cpitclaudel@gmail.com> writes: > On 2018-09-07 10:39, hw wrote: >>> On 2018-09-07 05:18, hw wrote: >>>> When a selection is active, why would anyone assume that typing >>>> an arbitrary letter is supposed to replace the entire selection, >>>> or to disable it? > >>> Out of experience, mostly. When almost every other program you >>> use besides Emacs behaves that way, it's easy to assume that Emacs >>> will behave the same way. > >> It's not my experience because when I want a selection deleted, I >> delete it. If it gets deleted otherwise, that's a mistake or maybe >> even a bug when no undo is available. > > You seem to be conflating experience and desirable behavior. You could say that --- as long as I don't press the wrong key, I'm getting desirable behaviour. >> I call it a design flaw because if whoever made it this way had >> given any thought to it, it would at least be customizable > > Fortunately, some of those who "made it that way" did think about it > :) For example, Microsoft Word has an option called "Typing Replaces > Selected Text." That's a good thing. > Unfortunately, I couldn't find a similar setting in OpenOffice, nor in > LibreOffice. Gtk entries and textviews do not seem to provide a > similar setting, either, but I wouldn't assume that they didn't give > any thought to it. Why not? >> Software supporting users in making mistakes and making the mistakes >> even worse suffers from design flaws unless doing so is the very >> purpose of the software. > > I'm having trouble following the reasoning. Hm, let my try to explain: The reasoning assumes that one important benefit of software is the possibility to prevent mistakes, for example by validating the input made by a user and by questioning or rejecting it when it is suspicious. You can design software such that it provides this benefit and such that it does not. You can also design software such that it makes it more likely that mistakes happen and such that it makes the effects of mistakes worse. In case it was not your intention to design your software so that it makes it more likely that mistakes will happen, or that it makes mistakes worse, but your software does that, your software has a design flaw. As for selections, this means that you can make your software so that not every random keystroke makes them disappear, or you can make your software so that the selection basically disappears with every random keystroke. Since random, accidental keystrokes sometimes happen, your software --- assuming its purpose is not to make mistakes worse --- has a greater benefit to the user and no design flaw when it protects the user from such mistakes by not letting the selection disappear. It can't very well protect the user from random, accidental keystrokes, but it can make the mistake worse by making the selection disappear when they occur. If it does that, it has a design flaw. Of course, there can be a problem when the user does not want to be protected, or when it becomes troublesome to use the software because it is overprotective. In case of Emacs, a user can make a setting that makes the effect of mistakes worse. Some users are asking to make this the default while others are against it. >> I suspect that one important reason for the dangerous and careless >> dealing with selections you find in many other programs is that the >> developers couldn't be bothered to find a better way. > > I understand that feeling, but I don't see much to support it. From > the same observations, you could just as well conclude that no one > cared enough about the behavior offered by Emacs to send patches to > OpenOffice, Gtk, or many of the other libre IDEs and text editors. I don't understand how multiple possible reasons for the impossibility of bothering the developers would not all the more support the suspicion that they couldn't be bothered. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 13:16 ` Clément Pit-Claudel 2018-09-07 13:28 ` Robert Pluim 2018-09-07 14:39 ` hw @ 2018-09-08 5:14 ` Richard Stallman 2018-09-08 11:32 ` Elias Mårtenson 2 siblings, 1 reply; 245+ messages in thread From: Richard Stallman @ 2018-09-08 5:14 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I find it a screw that Backspace deletes a highlighted region. It is never what I want -- I always want to delete one character backwards. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 5:14 ` Richard Stallman @ 2018-09-08 11:32 ` Elias Mårtenson 2018-09-08 14:01 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 245+ messages in thread From: Elias Mårtenson @ 2018-09-08 11:32 UTC (permalink / raw) To: Richard Stallman; +Cc: cpitclaudel, emacs-devel [-- Attachment #1: Type: text/plain, Size: 614 bytes --] On Sat, 8 Sep 2018, 13:17 Richard Stallman, <rms@gnu.org> wrote: > > I find it a screw that Backspace deletes a highlighted region. It is > never what I want -- I always want to delete one character backwards. > I believe that the whole idea of active regions was a mistake, and even though it can be disabled, some Emacs code these days assume it's on to the extent that 1) it misbehaves when it's off, and 2) it gets turned on automatically when it's loaded (I'm looking at you, company-mode). Without active regions, there would never be an expectation that backspace deletes anything but one character. > [-- Attachment #2: Type: text/html, Size: 1139 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 11:32 ` Elias Mårtenson @ 2018-09-08 14:01 ` Eli Zaretskii 2018-09-08 15:52 ` hw 2018-09-08 18:16 ` delete-selection-mode as default Dmitry Gutov 2 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-08 14:01 UTC (permalink / raw) To: Elias Mårtenson; +Cc: cpitclaudel, rms, emacs-devel > From: Elias Mårtenson <lokedhs@gmail.com> > Date: Sat, 8 Sep 2018 19:32:24 +0800 > Cc: cpitclaudel@gmail.com, emacs-devel <emacs-devel@gnu.org> > > some Emacs code these days assume [active regions are enabled] to > the extent that 1) it misbehaves when it's off, and 2) it gets > turned on automatically when it's loaded (I'm looking at you, > company-mode). Please be sure to report those cases as bugs. Thanks. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 11:32 ` Elias Mårtenson 2018-09-08 14:01 ` Eli Zaretskii @ 2018-09-08 15:52 ` hw 2018-09-08 19:31 ` Charles A. Roelli 2018-09-08 18:16 ` delete-selection-mode as default Dmitry Gutov 2 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-08 15:52 UTC (permalink / raw) To: Elias Mårtenson; +Cc: cpitclaudel, Richard Stallman, emacs-devel Elias Mårtenson <lokedhs@gmail.com> writes: > Without active regions, there would never be an expectation that backspace > deletes anything but one character. How come it wasn't distinguished between the concept of a region being active and the visual aid of marking a region? What's with the inconsistency that functions like query-replace are /limited/ to the region while others, like backward-delete-char, are /extended/ to the region when it is active? I think for the strict-selection-mode I'd prefer, it would help to disable transient-mark-mode. But how can I see what I have selected? It would even be possible to leave the visual markers active while the user is doing something else if transient-mark-mode didn't insist on the region being active when it's visually highlighted. It would only need a key binding to stop marking a region. I'd appreciate it if I didn't need to always do something with a region immediately and could leave it highlighted, or leave several regions highlighted at the same time. It seems transient-mark-mode started as a good idea and has evolved into a very special weirdness which now attracts other weirdnesses, like dangerous selection modes. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 15:52 ` hw @ 2018-09-08 19:31 ` Charles A. Roelli 2018-09-09 3:19 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-09-08 19:31 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Cc: Richard Stallman <rms@gnu.org>, cpitclaudel@gmail.com, > emacs-devel <emacs-devel@gnu.org> > Date: Sat, 08 Sep 2018 17:52:07 +0200 > > Elias Mårtenson <lokedhs@gmail.com> writes: > > > Without active regions, there would never be an expectation that backspace > > deletes anything but one character. > > How come it wasn't distinguished between the concept of a region being > active and the visual aid of marking a region? Separating these two concepts could be useful, but Emacs would then need some other way of showing the user that a region is active, like a mode line indicator. We would then also need bindings for activating and deactivating the region, and for turning the visual aid on and off. > [...] > > I think for the strict-selection-mode I'd prefer, it would help to > disable transient-mark-mode. But how can I see what I have selected? The most common answer to that is to use "C-u C-x C-x", which temporarily activates the region (thus highlighting it) and exchanges the point and the mark. But there is no command to turn on the highlighting of the region directly. > It would even be possible to leave the visual markers active while the > user is doing something else if transient-mark-mode didn't insist on the > region being active when it's visually highlighted. I'd like this too. > It would only need > a key binding to stop marking a region. I'd appreciate it if I didn't > need to always do something with a region immediately and could leave it > highlighted, or leave several regions highlighted at the same time. For a second region, use the secondary selection. We don't yet have keyboard bindings for its commands, unfortunately, though Drew's package "second-sel" suggests C-M-y: https://www.emacswiki.org/emacs/SecondarySelection#second-sel.el ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-08 19:31 ` Charles A. Roelli @ 2018-09-09 3:19 ` Drew Adams 2018-09-09 6:08 ` Richard Stallman 2018-09-10 11:52 ` visual-region-mode? (was: delete-selection-mode as default) hw 2 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-09 3:19 UTC (permalink / raw) To: charles, hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > For a second region, use the secondary selection. We don't yet have > keyboard bindings for its commands, unfortunately, though Drew's > package "second-sel" suggests C-M-y: For some reason I tend to use the secondary selection quite a lot. I think that most users never use it. For what it does I prefer it over using a string register, generally. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 19:31 ` Charles A. Roelli 2018-09-09 3:19 ` Drew Adams @ 2018-09-09 6:08 ` Richard Stallman 2018-09-09 14:48 ` Drew Adams 2018-09-10 7:52 ` hw 2018-09-10 11:52 ` visual-region-mode? (was: delete-selection-mode as default) hw 2 siblings, 2 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-09 6:08 UTC (permalink / raw) To: Charles A. Roelli; +Cc: hw, cpitclaudel, lokedhs, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > How come it wasn't distinguished between the concept of a region being > > active and the visual aid of marking a region? > Separating these two concepts could be useful, but Emacs would then > need some other way of showing the user that a region is active, like > a mode line indicator. We could have another minor mode to control whether Backspace deletes an active region. That would solve the problem for me. We would still have the issue of what the default should be. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-09 6:08 ` Richard Stallman @ 2018-09-09 14:48 ` Drew Adams 2018-09-10 11:50 ` hw 2018-09-10 7:52 ` hw 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-09 14:48 UTC (permalink / raw) To: rms, charles; +Cc: hw, cpitclaudel, lokedhs, emacs-devel > > > How come it wasn't distinguished between the concept of a region being > > > active and the visual aid of marking a region? > > > Separating these two concepts could be useful, but Emacs would then > > need some other way of showing the user that a region is active, like > > a mode line indicator. > > We could have another minor mode to control whether Backspace deletes > an active region. That would solve the problem for me. We would still > have the issue of what the default should be. 1. The behavior you object to here does not come from `d-s-m'. (I guess you realize that, since you see the behavior and you don't turn on `d-s-m'.) It comes from option `delete-active-region': ----8<------ delete-active-region is a variable defined in `simple.el'. Its value is t Documentation: Whether single-char deletion commands delete an active region. This has an effect only if Transient Mark mode is enabled, and affects `delete-forward-char' and `delete-backward-char', though not `delete-char'. If the value is the symbol `kill', the active region is killed instead of deleted. You can customize this variable. This variable was introduced, or its default value was changed, in version 24.1 of Emacs. ----8<------ So you don't need another mode, to get what you want; just customize that option. 2. Wrt `d-s-m', you can easily configure `d-s-m' to do what you want for any given command. For example, if you were seeing the behavior that you dislike here because `d-s-m' was turned on (and not because of `delete-active-region') then you could just tell `d-s-m' not to do anything for the command that you have bound to <backspace>. All you need to do, to make `d-s-m' do nothing for a given command, is to set the `delete-section' property on that command's symbol to nil. E.g., if `d-s-m' was the culprit in the behavior you object to here, and if <backspace> was bound to `delete-backward-char', then you would just do this: (put 'delete-backward-char 'delete-selection nil) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 14:48 ` Drew Adams @ 2018-09-10 11:50 ` hw 2018-09-11 4:25 ` Richard Stallman 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-10 11:50 UTC (permalink / raw) To: Drew Adams; +Cc: lokedhs, cpitclaudel, charles, rms, emacs-devel Drew Adams <drew.adams@oracle.com> writes: > [...] > ----8<------ > delete-active-region is a variable defined in `simple.el'. > Its value is t Thank you! This brings it closer to the "static-selection-mode" I prefer :) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 11:50 ` hw @ 2018-09-11 4:25 ` Richard Stallman 0 siblings, 0 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-11 4:25 UTC (permalink / raw) To: hw; +Cc: lokedhs, cpitclaudel, charles, drew.adams, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] ELi and I, the Emacs maintainers, are both opposed to making delete-selection-mode the default. Please don't do that. The stated aim of that change is to cater to newcomers at the expense of experienced users. That is a clumsy and unhelpful approach. If we think about it, maybe we can cater better to all users. See my other message for one specific idea. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 6:08 ` Richard Stallman 2018-09-09 14:48 ` Drew Adams @ 2018-09-10 7:52 ` hw 1 sibling, 0 replies; 245+ messages in thread From: hw @ 2018-09-10 7:52 UTC (permalink / raw) To: Richard Stallman; +Cc: lokedhs, cpitclaudel, Charles A. Roelli, emacs-devel Richard Stallman <rms@gnu.org> writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > How come it wasn't distinguished between the concept of a region being > > > active and the visual aid of marking a region? > > > Separating these two concepts could be useful, but Emacs would then > > need some other way of showing the user that a region is active, like > > a mode line indicator. > > We could have another minor mode to control whether Backspace deletes > an active region. That would solve the problem for me. We would still > have the issue of what the default should be. I think the whole concept of regions could use an overhaul. The next mode after the one saving backspace from deleting regions might make it so that delete deletes regions because it should work in consistency with backspace when the backspace mode is not enabled. ^ permalink raw reply [flat|nested] 245+ messages in thread
* visual-region-mode? (was: delete-selection-mode as default) 2018-09-08 19:31 ` Charles A. Roelli 2018-09-09 3:19 ` Drew Adams 2018-09-09 6:08 ` Richard Stallman @ 2018-09-10 11:52 ` hw 2018-09-10 20:02 ` Charles A. Roelli 2 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-10 11:52 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Cc: Richard Stallman <rms@gnu.org>, cpitclaudel@gmail.com, >> emacs-devel <emacs-devel@gnu.org> >> Date: Sat, 08 Sep 2018 17:52:07 +0200 >> >> Elias Mårtenson <lokedhs@gmail.com> writes: >> >> > Without active regions, there would never be an expectation that backspace >> > deletes anything but one character. >> >> How come it wasn't distinguished between the concept of a region being >> active and the visual aid of marking a region? > > Separating these two concepts could be useful, > but Emacs would then need some other way of showing the user that a > region is active, Whether regions can be active or not, and whether "active" means that they limit or extend operations to themselves, or both, might depend on settings and doesn't necessarily need to be shown all the time. > like a mode line indicator. Such a mode line indicator would need to show which regions are active when there several and in which way each one of them is active because there are multiple ways of being active. Perhaps it could generally show if any region is active and change when point is within a region to show more of its details. > We would then also need bindings for activating and deactivating the > region, and for turning the visual aid on and off. Another C-spc after starting to mark a region might do to end the marking. What would the advantage of hidden regions be? When something is within a region, it should be highlighted, and when it is no longer highlighted, it should no longer be within a region. Are these hidden regions a remnant of technical limitations that made it advisable not to highlight the selection? Perhaps region selections could be remembered in registers to make it easier to re-create them once they were disabled to suppress the highlighting. >> [...] >> >> I think for the strict-selection-mode I'd prefer, it would help to >> disable transient-mark-mode. But how can I see what I have selected? > > The most common answer to that is to use "C-u C-x C-x", which > temporarily activates the region (thus highlighting it) and exchanges > the point and the mark. But there is no command to turn on the > highlighting of the region directly. Doesn't that enable transient-mark-mode? If I wanted t-m-m, I could just leave it enabled to begin with. I tried with t-m-m disabled, and I don't see what the point of having it disabled is. Regions are not protected any better, and I'd have to be stupid to select a region to do something I want to affect the whole buffer. >> It would even be possible to leave the visual markers active while the >> user is doing something else if transient-mark-mode didn't insist on the >> region being active when it's visually highlighted. > > I'd like this too. It could be accompanied by a region-mode in which nothing can be done to and with anything outside of the regions. >> It would only need >> a key binding to stop marking a region. I'd appreciate it if I didn't >> need to always do something with a region immediately and could leave it >> highlighted, or leave several regions highlighted at the same time. > > For a second region, use the secondary selection. We don't yet have > keyboard bindings for its commands, unfortunately, though Drew's > package "second-sel" suggests C-M-y: > > https://www.emacswiki.org/emacs/SecondarySelection#second-sel.el Isn't is easier to use registers instead? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? (was: delete-selection-mode as default) 2018-09-10 11:52 ` visual-region-mode? (was: delete-selection-mode as default) hw @ 2018-09-10 20:02 ` Charles A. Roelli 2018-09-11 5:43 ` Yuri Khan 2018-09-11 21:56 ` visual-region-mode? hw 0 siblings, 2 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-09-10 20:02 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Date: Mon, 10 Sep 2018 13:52:06 +0200 > > >> How come it wasn't distinguished between the concept of a region being > >> active and the visual aid of marking a region? > > > > Separating these two concepts could be useful, > > but Emacs would then need some other way of showing the user that a > > region is active, > > Whether regions can be active or not, and whether "active" means that > they limit or extend operations to themselves, or both, might depend on > settings and doesn't necessarily need to be shown all the time. Yes. Ultimately the choice should be left to the user. > > like a mode line indicator. > > Such a mode line indicator would need to show which regions are active > when there several and in which way each one of them is active because > there are multiple ways of being active. Can you say how there can be multiple regions active, and how there can be "multiple ways of being active"? The region is normally defined as "the text between point and mark", for one, and whether the mark is active depends on the value of the buffer-local variable 'mark-active'. > Perhaps it could generally show if any region is active and change when > point is within a region to show more of its details. Point always delimits the region, so I'm not sure what more details we could show about it. > > We would then also need bindings for activating and deactivating the > > region, and for turning the visual aid on and off. > > Another C-spc after starting to mark a region might do to end the > marking. C-SPC (without a prefix argument) always pushes a mark, so it always alters the region (unless point is already at the mark). C-u C-SPC sets point where the mark is, and pops the mark ring, effectively restoring the previous region. We should keep this behavior. > What would the advantage of hidden regions be? When something is within > a region, it should be highlighted, and when it is no longer > highlighted, it should no longer be within a region. Again, in Emacs, as long there is a mark in the current buffer, there is always a "region". The user might want it highlighted for various reasons, possibly not covered by the current implementation, where Emacs highlights the region only when 'mark-active' is non-nil. > Are these hidden regions a remnant of technical limitations that made it > advisable not to highlight the selection? No, they stem from convenience. For example, typing C-M-a in a source code buffer moves point to the beginning of the current defun, pushing a mark where point was. Afterwards, typing C-u C-SPC restores point and mark (i.e. the region) to where they were before you typed C-M-a. During editing this is very helpful. Highlighting the region at any of these steps might be helpful for the user, but Emacs can't know exactly when -- which is one argument for allowing to toggle the highlighting dynamically as necessary, independently of whether the mark is ever "active". > Perhaps region selections could be remembered in registers to make it > easier to re-create them once they were disabled to suppress the > highlighting. As seen above, use of C-u C-SPC effectively restores the region at some previous point in editing. Certainly, it would be nice to have some register key to push (cons (point-marker) (mark-marker)) into a register to come back to it later. Until we have that, "C-x 4 c C-x n n C-x r SPC <register>" also works, via an indirect buffer, though it's a mouthful. > >> I think for the strict-selection-mode I'd prefer, it would help to > >> disable transient-mark-mode. But how can I see what I have selected? > > > > The most common answer to that is to use "C-u C-x C-x", which > > temporarily activates the region (thus highlighting it) and exchanges > > the point and the mark. But there is no command to turn on the > > highlighting of the region directly. > > Doesn't that enable transient-mark-mode? If I wanted t-m-m, I could > just leave it enabled to begin with. Yes, it is enabled temporarily. > I tried with t-m-m disabled, and I don't see what the point of having it > disabled is. Regions are not protected any better, and I'd have to be > stupid to select a region to do something I want to affect the whole > buffer. With t-m-m off, you can make use of the mark without randomly activating it and causing certain commands to respond differently. However, there are tradeoffs: commands like "query-replace" will do their work on the region only when the mark is "active", so to use that capability, you need "C-u C-x C-x" to temporarily activate the mark. > >> It would even be possible to leave the visual markers active while the > >> user is doing something else if transient-mark-mode didn't insist on the > >> region being active when it's visually highlighted. > > > > I'd like this too. > > It could be accompanied by a region-mode in which nothing can be done to > and with anything outside of the regions. Working on a specific region can often be done conveniently from an indirect buffer, as in the earlier example. > >> It would only need > >> a key binding to stop marking a region. I'd appreciate it if I didn't > >> need to always do something with a region immediately and could leave it > >> highlighted, or leave several regions highlighted at the same time. > > > > For a second region, use the secondary selection. We don't yet have > > keyboard bindings for its commands, unfortunately, though Drew's > > package "second-sel" suggests C-M-y: > > > > https://www.emacswiki.org/emacs/SecondarySelection#second-sel.el > > Isn't is easier to use registers instead? It might be. I use both, but for different purposes. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? (was: delete-selection-mode as default) 2018-09-10 20:02 ` Charles A. Roelli @ 2018-09-11 5:43 ` Yuri Khan 2018-09-11 18:25 ` Charles A. Roelli 2018-09-16 22:55 ` visual-region-mode? Juri Linkov 2018-09-11 21:56 ` visual-region-mode? hw 1 sibling, 2 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-11 5:43 UTC (permalink / raw) To: charles Cc: hw, Clément Pit-Claudel, Elias Mårtenson, rms, Emacs developers On Tue, Sep 11, 2018 at 3:01 AM Charles A. Roelli <charles@aurox.ch> wrote: > Can you say how there can be multiple regions active, and how there > can be "multiple ways of being active"? The region is normally > defined as "the text between point and mark", for one, and whether the > mark is active depends on the value of the buffer-local variable > 'mark-active'. By the way, this definition of region is flawed. The mark is buffer-local, while the point is buffer-and-window-local. Display a buffer B in windows X and Y, mark a region in window X, then switch to window Y. Suddenly, an entirely unrelated fragment of text is highlighted as region. A consistent definition of a persistent region would make it an interval between two buffer-local markers, both of which are distinct from the point. A consistent definition of a transient region would make the mark also buffer-and-window-local, so that buffer B in windows X and Y could have completely independently marked regions. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? (was: delete-selection-mode as default) 2018-09-11 5:43 ` Yuri Khan @ 2018-09-11 18:25 ` Charles A. Roelli 2018-09-12 5:12 ` Yuri Khan 2018-09-16 22:55 ` visual-region-mode? Juri Linkov 1 sibling, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-11 18:25 UTC (permalink / raw) To: Yuri Khan; +Cc: hw, cpitclaudel, lokedhs, rms, emacs-devel > From: Yuri Khan <yurivkhan@gmail.com> > Date: Tue, 11 Sep 2018 12:43:16 +0700 > > > Can you say how there can be multiple regions active, and how there > > can be "multiple ways of being active"? The region is normally > > defined as "the text between point and mark", for one, and whether the > > mark is active depends on the value of the buffer-local variable > > 'mark-active'. > > [...] > > A consistent definition of a transient region would make the mark also > buffer-and-window-local, so that buffer B in windows X and Y could > have completely independently marked regions. In that case, pushing a mark in window X, then switching to window Y and popping the mark would not necessarily place point where the mark was pushed in window X, since window Y might have its own mark. That could be surprising behavior. The handling of the mark-ring would also be complicated. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? (was: delete-selection-mode as default) 2018-09-11 18:25 ` Charles A. Roelli @ 2018-09-12 5:12 ` Yuri Khan 2018-09-12 6:59 ` visual-region-mode? Andreas Schwab 2018-09-12 18:31 ` visual-region-mode? (was: delete-selection-mode as default) Charles A. Roelli 0 siblings, 2 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-12 5:12 UTC (permalink / raw) To: charles Cc: hw, Clément Pit-Claudel, Elias Mårtenson, rms, Emacs developers On Wed, Sep 12, 2018 at 1:24 AM Charles A. Roelli <charles@aurox.ch> wrote: > > A consistent definition of a transient region would make the mark also > > buffer-and-window-local, so that buffer B in windows X and Y could > > have completely independently marked regions. > > In that case, pushing a mark in window X, then switching to window Y > and popping the mark would not necessarily place point where the mark > was pushed in window X, since window Y might have its own mark. That > could be surprising behavior. The handling of the mark-ring would > also be complicated. I thought about it some more. We have a notion of mark that is somewhat overloaded. On the one hand, there is the mark ring and the global mark ring whose purpose in life is to help the user navigate back to positions they visited earlier. On the other hand, the mark is used as one of the two delimiters of the region. It seems to me these two uses of the mark are mutually disjoint, and it might be a better model if they were decoupled. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-12 5:12 ` Yuri Khan @ 2018-09-12 6:59 ` Andreas Schwab 2018-09-12 7:12 ` visual-region-mode? Yuri Khan 2018-09-12 18:31 ` visual-region-mode? (was: delete-selection-mode as default) Charles A. Roelli 1 sibling, 1 reply; 245+ messages in thread From: Andreas Schwab @ 2018-09-12 6:59 UTC (permalink / raw) To: Yuri Khan Cc: hw, Clément Pit-Claudel, charles, rms, Elias Mårtenson, Emacs developers On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote: > It seems to me these two uses of the mark are mutually disjoint, and > it might be a better model if they were decoupled. There is already bookmark to handle marks independent of the region. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-12 6:59 ` visual-region-mode? Andreas Schwab @ 2018-09-12 7:12 ` Yuri Khan 2018-09-12 7:44 ` visual-region-mode? Andreas Schwab 0 siblings, 1 reply; 245+ messages in thread From: Yuri Khan @ 2018-09-12 7:12 UTC (permalink / raw) To: Andreas Schwab Cc: hw, Clément Pit-Claudel, charles, rms, Elias Mårtenson, Emacs developers On Wed, Sep 12, 2018 at 1:59 PM Andreas Schwab <schwab@suse.de> wrote: > > On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote: > > > It seems to me these two uses of the mark are mutually disjoint, and > > it might be a better model if they were decoupled. > > There is already bookmark to handle marks independent of the region. How are bookmarks relevant here? They add a way of navigating other than by popping the mark ring, but they do not eliminate the interdependency between the region and the mark ring. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-12 7:12 ` visual-region-mode? Yuri Khan @ 2018-09-12 7:44 ` Andreas Schwab 0 siblings, 0 replies; 245+ messages in thread From: Andreas Schwab @ 2018-09-12 7:44 UTC (permalink / raw) To: Yuri Khan Cc: hw, Clément Pit-Claudel, charles, rms, Elias Mårtenson, Emacs developers On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote: > On Wed, Sep 12, 2018 at 1:59 PM Andreas Schwab <schwab@suse.de> wrote: >> >> On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote: >> >> > It seems to me these two uses of the mark are mutually disjoint, and >> > it might be a better model if they were decoupled. >> >> There is already bookmark to handle marks independent of the region. > > How are bookmarks relevant here? They are the better model you are looking for. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? (was: delete-selection-mode as default) 2018-09-12 5:12 ` Yuri Khan 2018-09-12 6:59 ` visual-region-mode? Andreas Schwab @ 2018-09-12 18:31 ` Charles A. Roelli 1 sibling, 0 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-09-12 18:31 UTC (permalink / raw) To: Yuri Khan; +Cc: hw, cpitclaudel, lokedhs, rms, emacs-devel > From: Yuri Khan <yurivkhan@gmail.com> > Date: Wed, 12 Sep 2018 12:12:26 +0700 > > > > A consistent definition of a transient region would make the mark also > > > buffer-and-window-local, so that buffer B in windows X and Y could > > > have completely independently marked regions. > > > > In that case, pushing a mark in window X, then switching to window Y > > and popping the mark would not necessarily place point where the mark > > was pushed in window X, since window Y might have its own mark. That > > could be surprising behavior. The handling of the mark-ring would > > also be complicated. > > I thought about it some more. > > We have a notion of mark that is somewhat overloaded. On the one hand, > there is the mark ring and the global mark ring whose purpose in life > is to help the user navigate back to positions they visited earlier. > On the other hand, the mark is used as one of the two delimiters of > the region. > > It seems to me these two uses of the mark are mutually disjoint, and > it might be a better model if they were decoupled. The mark ring and the region are even more tightly coupled: C-u C-SPC not only jumps to the mark, it also sets the mark from the most recent mark on the mark ring, effectively restoring the previous region. It could be called the "region ring". And since it so happens that the boundaries of "regions" are often places of interest to the user, maybe it makes good sense to combine these two uses of the mark as delimiter of the region, and the mark as a navigational buoy. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-11 5:43 ` Yuri Khan 2018-09-11 18:25 ` Charles A. Roelli @ 2018-09-16 22:55 ` Juri Linkov 1 sibling, 0 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-16 22:55 UTC (permalink / raw) To: Yuri Khan Cc: hw, Clément Pit-Claudel, charles, rms, Elias Mårtenson, Emacs developers > By the way, this definition of region is flawed. > > The mark is buffer-local, while the point is buffer-and-window-local. > Display a buffer B in windows X and Y, mark a region in window X, then > switch to window Y. Suddenly, an entirely unrelated fragment of text > is highlighted as region. > > A consistent definition of a persistent region would make it an > interval between two buffer-local markers, both of which are distinct > from the point. > > A consistent definition of a transient region would make the mark also > buffer-and-window-local, so that buffer B in windows X and Y could > have completely independently marked regions. Yes, this is an annoying problem. As a workaround, it's easy to make the mark buffer-and-window-local with this simple code: (defvar-local mark-active-window nil) (add-hook 'activate-mark-hook (lambda () (setq mark-active-window (selected-window)))) (add-hook 'deactivate-mark-hook (lambda () (setq mark-active-window nil))) (defun redisplay--update-mark-active-window (window) (when mark-active-window (setq mark-active (eq mark-active-window window)))) (add-to-list 'pre-redisplay-functions #'redisplay--update-mark-active-window) I'm not sure if a new customizable option is necessary to define the preferable behavior like with the option `highlight-nonselected-windows'. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-10 20:02 ` Charles A. Roelli 2018-09-11 5:43 ` Yuri Khan @ 2018-09-11 21:56 ` hw 2018-09-12 19:47 ` visual-region-mode? Charles A. Roelli 2018-09-12 20:27 ` visual-region-mode? Juri Linkov 1 sibling, 2 replies; 245+ messages in thread From: hw @ 2018-09-11 21:56 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Date: Mon, 10 Sep 2018 13:52:06 +0200 >> >> >> How come it wasn't distinguished between the concept of a region being >> >> active and the visual aid of marking a region? >> > >> > Separating these two concepts could be useful, >> > but Emacs would then need some other way of showing the user that a >> > region is active, >> >> Whether regions can be active or not, and whether "active" means that >> they limit or extend operations to themselves, or both, might depend on >> settings and doesn't necessarily need to be shown all the time. > > Yes. Ultimately the choice should be left to the user. > >> > like a mode line indicator. >> >> Such a mode line indicator would need to show which regions are active >> when there several and in which way each one of them is active because >> there are multiple ways of being active. > > Can you say how there can be multiple regions active, and how there > can be "multiple ways of being active"? The region is normally > defined as "the text between point and mark", for one, and whether the > mark is active depends on the value of the buffer-local variable > 'mark-active'. I don't think there can currently be multiple regions at the same time. That doesn't mean this couldn't be implemented. There are multiple ways for a region to be active because there are at least three ways in which the activeness of a region can have an influence on functions/commands. Active can mean: + limit commands to a region (like query-replace) + extend commands to a region (like backward-delete-char) + both of the above (I don't have a good example) The first one was probably the original intention, the second one seems like a bug. The last one is probably questionable. You may see delete-selection-mode as an example in that otherwise harmless keystrokes suddenly operate on a whole region. I can understand the original intention. I don't understand how disabling transient-mark-mode could have an advantage --- unless, for some reason, you have a bad habit of abusing the mark for naviation --- and I don't understand why regions are not always highlighted regardless if are active or not. That means that something not highlighted as such is not a region. As to the definition of the region: I've never seen it that way. The region is what is currently highlighted. I don't use and don't like hidden regions. They are a design flaw because when I press C-w, something of unknown extend is being deleted, and when press M-w, something of unknown extend is being copied and replaces what I kept on the clipboard. These hidden regions always make me feel uneasy. It's like you're being forced to walk around with a loaded gun, safety off, once you only even touched the trigger without firing a shot because that sets a mark. The only way to get rid of this gun is to kill the buffer --- or is there another way? I expect the mark to be forgotten, or at least to disappear, right away after doing something with a region. As to multiple regions, it might be nice to have them. >> Perhaps it could generally show if any region is active and change when >> point is within a region to show more of its details. > > Point always delimits the region, so I'm not sure what more details we > could show about it. That would be different if there were multiple regions. >> > We would then also need bindings for activating and deactivating the >> > region, and for turning the visual aid on and off. >> >> Another C-spc after starting to mark a region might do to end the >> marking. > > C-SPC (without a prefix argument) always pushes a mark, so it always > alters the region (unless point is already at the mark). C-u C-SPC > sets point where the mark is, and pops the mark ring, effectively > restoring the previous region. We should keep this behavior. How am I supposed to know where a mark was? Why would I try to confuse myself with C-u C-spc? In which way is the position of the mark adjusted so that it sticks with the same contents of the buffer, which it would need to do to be of any use? I expect the mark to be gone once I used the region. >> What would the advantage of hidden regions be? When something is within >> a region, it should be highlighted, and when it is no longer >> highlighted, it should no longer be within a region. > > Again, in Emacs, as long there is a mark in the current buffer, there > is always a "region". How would that make sense? I expect the mark to be gone once I used the region. > The user might want it highlighted for various reasons, possibly not > covered by the current implementation, where Emacs highlights the > region only when 'mark-active' is non-nil. Yes, and that leads to misunderstandings, like d-s-m. It doesn't make any sense to claim that there is a region when there is none highlighted and only creates the inconsistency that an arbitrary part of a buffer can be deleted or copied, accidentally or intentionally, i. e. that something can be done with a region while the region is not active and nothing should possibly be done with it. >> Are these hidden regions a remnant of technical limitations that made it >> advisable not to highlight the selection? > > No, they stem from convenience. For example, typing C-M-a in a source That key binding only works when you can use Alt instead of ESC. > code buffer moves point to the beginning of the current defun, pushing > a mark where point was. Afterwards, typing C-u C-SPC restores point > and mark (i.e. the region) to where they were before you typed > C-M-a. During editing this is very helpful. This is only sometimes helpful, provided that the Alt key works. When it doesn't, you'd have to bind the function to another key. All in all, even with the Alt key working, these key bindings are so awkward that I would never use this. It's far easier to just scroll up and to use bookmarks or registers. > Highlighting the region at any of these steps might be helpful for the > user, but Emacs can't know exactly when -- which is one argument for > allowing to toggle the highlighting dynamically as necessary, > independently of whether the mark is ever "active". This is a problem of navigating source code (or other files) and has nothing to do with regions or highlighting. Or what has navigating between a current location and the beginning of a function to do with selecting and highlighting parts of the contents of a buffer in order to copy or to delete them, or to do something with them like query-replace? >> Perhaps region selections could be remembered in registers to make it >> easier to re-create them once they were disabled to suppress the >> highlighting. > > As seen above, use of C-u C-SPC effectively restores the region at > some previous point in editing. That I move around in a file as I see fit while reading or editing it doesn't have anything to do with regions I might select to do something with. I might highlight a selection to make parts of source code stick out as a reminder because they need to be fixed or worked upon in some particular order. I could use registers and/or bookmarks instead, but it would be much more convenient to use highlighting and perhaps to be able to jump through the selections. Why would I want a region I have selected and highlighted to become undone when I move around? > Certainly, it would be nice to have some register key to push (cons > (point-marker) (mark-marker)) into a register to come back to it > later. Until we have that, "C-x 4 c C-x n n C-x r SPC <register>" > also works, via an indirect buffer, though it's a mouthful. yeah >> >> I think for the strict-selection-mode I'd prefer, it would help to >> >> disable transient-mark-mode. But how can I see what I have selected? >> > >> > The most common answer to that is to use "C-u C-x C-x", which >> > temporarily activates the region (thus highlighting it) and exchanges >> > the point and the mark. But there is no command to turn on the >> > highlighting of the region directly. >> >> Doesn't that enable transient-mark-mode? If I wanted t-m-m, I could >> just leave it enabled to begin with. > > Yes, it is enabled temporarily. Then what's the use of disabling t-m-m? >> I tried with t-m-m disabled, and I don't see what the point of having it >> disabled is. Regions are not protected any better, and I'd have to be >> stupid to select a region to do something I want to affect the whole >> buffer. > > With t-m-m off, you can make use of the mark without randomly > activating it and causing certain commands to respond differently. The mark is only for setting the begin of a selection, nothing else. I expect it to be gone once I did something with the selection. It doesn't even matter to me if there is a mark. All I do is start selecting somewhere and when it's selected, I do something with it, and that's all there is to it. Don't mix up a mark for navigational purposes with making and highlighting selections. > However, there are tradeoffs: commands like "query-replace" will do > their work on the region only when the mark is "active", so to use > that capability, you need "C-u C-x C-x" to temporarily activate the > mark. I'm really never using the mark. When I want to do a query-replace limited to a selection, I make the selection and then do the query-replace. With t-m-m disabled, I can't limit the query-replace to a selection, so it's only a disadvantage to have it disabled --- and the other disadvantage is that I can never see what I have selected. >> >> It would even be possible to leave the visual markers active while the >> >> user is doing something else if transient-mark-mode didn't insist on the >> >> region being active when it's visually highlighted. >> > >> > I'd like this too. >> >> It could be accompanied by a region-mode in which nothing can be done to >> and with anything outside of the regions. > > Working on a specific region can often be done conveniently from an > indirect buffer, as in the earlier example. It's quite inconvenient because with that, the source tends to occupy both frames I have on screen because I'd narrow the indirect buffer to what I'm working on --- which is already another inconvenience --- and need the other frame to look up things I can't see in the indirect buffer because it's narrowed. I've given up on it, it's just too awkward. As for doing other things, like replacing text in multiple parts of a buffer, is that something that could be usefully done with indirect buffers? With multiple regions, I'd highlight some parts of the buffer, do the replacement limited to these parts and would be done with it. I'd be able to see all of the buffer while doing this. Indirect buffers still hold all of the text, so instead of marking what I want to work with, I'd have to narrow out what I'm not working with, and IIRC, it's not possible to narrow a buffer "the other way round" so that the parts I want to work with remain and all the rest of the buffer is narrowed away. So maybe you see how I'm saying that the concept of regions could use an overhaul and how a visual-region-mode could be useful :) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-11 21:56 ` visual-region-mode? hw @ 2018-09-12 19:47 ` Charles A. Roelli 2018-09-12 20:40 ` visual-region-mode? Drew Adams ` (2 more replies) 2018-09-12 20:27 ` visual-region-mode? Juri Linkov 1 sibling, 3 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-09-12 19:47 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Date: Tue, 11 Sep 2018 23:56:11 +0200 > > [...] > > As to the definition of the region: I've never seen it that way. The > region is what is currently highlighted. I don't use and don't like > hidden regions. They are a design flaw because when I press C-w, > something of unknown extend is being deleted, and when press M-w, > something of unknown extend is being copied and replaces what I kept on > the clipboard. > > These hidden regions always make me feel uneasy. It's like you're being > forced to walk around with a loaded gun, safety off, once you only even > touched the trigger without firing a shot because that sets a mark. The > only way to get rid of this gun is to kill the buffer --- or is there > another way? This is where Emacs differs from other programs, I suppose. It's optimized for efficient use, even when the result can be a surprise to the user. Otherwise, in this case, C-w and M-w would do nothing with no "active region". > > C-SPC (without a prefix argument) always pushes a mark, so it always > > alters the region (unless point is already at the mark). C-u C-SPC > > sets point where the mark is, and pops the mark ring, effectively > > restoring the previous region. We should keep this behavior. > > How am I supposed to know where a mark was? Why would I try to confuse > myself with C-u C-spc? In which way is the position of the mark > adjusted so that it sticks with the same contents of the buffer, which > it would need to do to be of any use? Various commands set the mark, as documented in the manual. When you use them, normally a message appears in the echo area saying "Mark set". The mark is a standard Emacs marker, as described in (info "(elisp) Markers"): A “marker” is a Lisp object used to specify a position in a buffer relative to the surrounding text. A marker changes its offset from the beginning of the buffer automatically whenever text is inserted or deleted, so that it stays with the two characters on either side of it. > >> What would the advantage of hidden regions be? When something is within > >> a region, it should be highlighted, and when it is no longer > >> highlighted, it should no longer be within a region. > > > > Again, in Emacs, as long there is a mark in the current buffer, there > > is always a "region". > > How would that make sense? I expect the mark to be gone once I used the > region. That's what transient-mark-mode tries to implement, I think. > > The user might want it highlighted for various reasons, possibly not > > covered by the current implementation, where Emacs highlights the > > region only when 'mark-active' is non-nil. > > Yes, and that leads to misunderstandings, like d-s-m. It doesn't make > any sense to claim that there is a region when there is none highlighted > and only creates the inconsistency that an arbitrary part of a buffer > can be deleted or copied, accidentally or intentionally, i. e. that > something can be done with a region while the region is not active and > nothing should possibly be done with it. Again, that seems like the intention behind transient-mark-mode. But the implementation is, then, in a way incomplete: C-w still kills the region, no matter whether it is active or not, in transient-mark-mode. > >> Are these hidden regions a remnant of technical limitations that made it > >> advisable not to highlight the selection? > > > > No, they stem from convenience. For example, typing C-M-a in a source > > That key binding only works when you can use Alt instead of ESC. Does ESC C-a not work for you? Or C-[ C-a? > > code buffer moves point to the beginning of the current defun, pushing > > a mark where point was. Afterwards, typing C-u C-SPC restores point > > and mark (i.e. the region) to where they were before you typed > > C-M-a. During editing this is very helpful. > > This is only sometimes helpful, provided that the Alt key works. When > it doesn't, you'd have to bind the function to another key. All in all, > even with the Alt key working, these key bindings are so awkward that I > would never use this. It's far easier to just scroll up and to use > bookmarks or registers. Yes, these work too. > > Highlighting the region at any of these steps might be helpful for the > > user, but Emacs can't know exactly when -- which is one argument for > > allowing to toggle the highlighting dynamically as necessary, > > independently of whether the mark is ever "active". > > This is a problem of navigating source code (or other files) and has > nothing to do with regions or highlighting. > > Or what has navigating between a current location and the beginning of a > function to do with selecting and highlighting parts of the contents of > a buffer in order to copy or to delete them, or to do something with > them like query-replace? The places where the mark has been set are places of interest to the user for some reason or another -- that's all. > > As seen above, use of C-u C-SPC effectively restores the region at > > some previous point in editing. > > That I move around in a file as I see fit while reading or editing it > doesn't have anything to do with regions I might select to do something > with. I might highlight a selection to make parts of source code stick > out as a reminder because they need to be fixed or worked upon in some > particular order. I could use registers and/or bookmarks instead, but > it would be much more convenient to use highlighting and perhaps to be > able to jump through the selections. This would be a good use case for registers storing regions, I think. The mark ring is a useful tool, but it does not give easy, random access to all previous selections. We need a bug report for this. > The mark is only for setting the begin of a selection, nothing else. I > expect it to be gone once I did something with the selection. > > It doesn't even matter to me if there is a mark. All I do is start > selecting somewhere and when it's selected, I do something with it, and > that's all there is to it. > > Don't mix up a mark for navigational purposes with making and > highlighting selections. It's probably feasible to add a "type" field to the mark, indicating where it came from (i.e., if it was set explicitly by the user, by a certain command, from a mouse selection, ...). Then we could offer commands that jump between previous selections, or between previous marks set by the user for navigation. > > Working on a specific region can often be done conveniently from an > > indirect buffer, as in the earlier example. > > It's quite inconvenient because with that, the source tends to occupy > both frames I have on screen because I'd narrow the indirect buffer to > what I'm working on --- which is already another inconvenience --- and > need the other frame to look up things I can't see in the indirect > buffer because it's narrowed. I've given up on it, it's just too > awkward. > > As for doing other things, like replacing text in multiple parts of a > buffer, is that something that could be usefully done with indirect > buffers? With multiple regions, I'd highlight some parts of the buffer, > do the replacement limited to these parts and would be done with it. > I'd be able to see all of the buffer while doing this. Not possible yet, I think (at least, without making N indirect buffers for the N regions and running the replacement command in all of them). But if we had some way to record the "type" of a previous mark (as above), then we could offer a command to replace, for example, the last N "active regions" in the buffer. I think that might fit the bill. > Indirect buffers still hold all of the text, so instead of marking what > I want to work with, I'd have to narrow out what I'm not working with, > and IIRC, it's not possible to narrow a buffer "the other way round" so > that the parts I want to work with remain and all the rest of the buffer > is narrowed away. I don't think that's possible yet. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: visual-region-mode? 2018-09-12 19:47 ` visual-region-mode? Charles A. Roelli @ 2018-09-12 20:40 ` Drew Adams 2018-09-12 20:50 ` visual-region-mode? Juri Linkov 2018-09-13 4:00 ` visual-region-mode? hw 2 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-12 20:40 UTC (permalink / raw) To: charles, hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > > That I move around in a file as I see fit while reading or editing it > > doesn't have anything to do with regions I might select to do something > > with. I might highlight a selection to make parts of source code stick > > out as a reminder because they need to be fixed or worked upon in some > > particular order. I could use registers and/or bookmarks instead, but > > it would be much more convenient to use highlighting and perhaps to be > > able to jump through the selections. With Bookmark+ you can use (temporary or persistent) bookmarks, and they can highlight their locations in various ways. You can also bookmark a region and have it activated when you later jump to it. You can navigate among the bookmarks in various ways, including cycling. You can create bookmarks without bothering to name them - automatic naming based on a template (e.g. with buffer position). With library `zones.el' you can define a list of multiple regions (zones) in the same buffer or in a mix of buffers. You can cycle among them, activating each in turn. You can move among them as multiple narrowings. You can highlight and unhighlight them. You can persist them as bookmarks. > It's probably feasible to add a "type" field to the mark, indicating > where it came from (i.e., if it was set explicitly by the user, by a > certain command, from a mouse selection, ...). Then we could offer > commands that jump between previous selections, or between previous > marks set by the user for navigation. A zone has a start and end (like a region). It can also have an ID. It can also have any Lisp values as additional data. > > As for doing other things, like replacing text in multiple parts of a > > buffer, is that something that could be usefully done with indirect > > buffers? With multiple regions, I'd highlight some parts of the buffer, > > do the replacement limited to these parts and would be done with it. > > I'd be able to see all of the buffer while doing this. > > Not possible yet, I think (at least, without making N indirect buffers > for the N regions and running the replacement command in all of them). > But if we had some way to record the "type" of a previous mark (as > above), then we could offer a command to replace, for example, the > last N "active regions" in the buffer. I think that might fit the > bill. You can add the region to a current list of zones (`C-x n a'). Then cycle among them, activating each in turn (`C-x n r'); and do query-replace or other actions on each one. > > Indirect buffers still hold all of the text, so instead of marking what > > I want to work with, I'd have to narrow out what I'm not working with, > > and IIRC, it's not possible to narrow a buffer "the other way round" so > > that the parts I want to work with remain and all the rest of the buffer > > is narrowed away. > > I don't think that's possible yet. You can make a list of zones that is the complement of another list of zones. If you also use library `isearch-prop.el' then you can make a list of zones or its complement invisible, you can search the zones or their complement. You can add text properties to the zones. When searching you can dim the complement of the zones being searched, and you can toggle to search the complement instead (and dim the original zones). ---- https://www.emacswiki.org/emacs/download/zones.el https://www.emacswiki.org/emacs/download/isearch-prop.el https://www.emacswiki.org/emacs/BookmarkPlus ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-12 19:47 ` visual-region-mode? Charles A. Roelli 2018-09-12 20:40 ` visual-region-mode? Drew Adams @ 2018-09-12 20:50 ` Juri Linkov 2018-09-13 4:01 ` visual-region-mode? hw 2018-09-13 4:00 ` visual-region-mode? hw 2 siblings, 1 reply; 245+ messages in thread From: Juri Linkov @ 2018-09-12 20:50 UTC (permalink / raw) To: Charles A. Roelli; +Cc: hw, cpitclaudel, lokedhs, rms, emacs-devel >> > The user might want it highlighted for various reasons, possibly not >> > covered by the current implementation, where Emacs highlights the >> > region only when 'mark-active' is non-nil. >> >> Yes, and that leads to misunderstandings, like d-s-m. It doesn't make >> any sense to claim that there is a region when there is none highlighted >> and only creates the inconsistency that an arbitrary part of a buffer >> can be deleted or copied, accidentally or intentionally, i. e. that >> something can be done with a region while the region is not active and >> nothing should possibly be done with it. > > Again, that seems like the intention behind transient-mark-mode. But > the implementation is, then, in a way incomplete: C-w still kills the > region, no matter whether it is active or not, in transient-mark-mode. mark-even-if-inactive set to nil is much safer option - it prevents accidental lossage caused by mistakenly typed C-w. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-12 20:50 ` visual-region-mode? Juri Linkov @ 2018-09-13 4:01 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-13 4:01 UTC (permalink / raw) To: Juri Linkov; +Cc: lokedhs, cpitclaudel, Charles A. Roelli, rms, emacs-devel Juri Linkov <juri@linkov.net> writes: > [...] >> Again, that seems like the intention behind transient-mark-mode. But >> the implementation is, then, in a way incomplete: C-w still kills the >> region, no matter whether it is active or not, in transient-mark-mode. > > mark-even-if-inactive set to nil is much safer option - it prevents > accidental lossage caused by mistakenly typed C-w. Thanks, I changed it :) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-12 19:47 ` visual-region-mode? Charles A. Roelli 2018-09-12 20:40 ` visual-region-mode? Drew Adams 2018-09-12 20:50 ` visual-region-mode? Juri Linkov @ 2018-09-13 4:00 ` hw 2018-09-13 17:22 ` visual-region-mode? Alan Mackenzie 2018-09-13 20:42 ` visual-region-mode? Charles A. Roelli 2 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-13 4:00 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Date: Tue, 11 Sep 2018 23:56:11 +0200 >> >> [...] >> >> As to the definition of the region: I've never seen it that way. The >> region is what is currently highlighted. I don't use and don't like >> hidden regions. They are a design flaw because when I press C-w, >> something of unknown extend is being deleted, and when press M-w, >> something of unknown extend is being copied and replaces what I kept on >> the clipboard. >> >> These hidden regions always make me feel uneasy. It's like you're being >> forced to walk around with a loaded gun, safety off, once you only even >> touched the trigger without firing a shot because that sets a mark. The >> only way to get rid of this gun is to kill the buffer --- or is there >> another way? > > This is where Emacs differs from other programs, I suppose. It's > optimized for efficient use, even when the result can be a surprise to > the user. Otherwise, in this case, C-w and M-w would do nothing with > no "active region". What is efficient about hidden regions the way they are? If killing or copying a region didn't happen to be bound to keys that are rather unlikely to get pressed by mistake, the design flaw of being able to do something with a non-highlighted region while transient-mark-mode is enabled might be more obvious. Disabling transient-mark-mode removes the possibility of highlighting regions. What is the purpose of that? >> > C-SPC (without a prefix argument) always pushes a mark, so it always >> > alters the region (unless point is already at the mark). C-u C-SPC >> > sets point where the mark is, and pops the mark ring, effectively >> > restoring the previous region. We should keep this behavior. >> >> How am I supposed to know where a mark was? Why would I try to confuse >> myself with C-u C-spc? In which way is the position of the mark >> adjusted so that it sticks with the same contents of the buffer, which >> it would need to do to be of any use? > > Various commands set the mark, as documented in the manual. When you > use them, normally a message appears in the echo area saying "Mark > set". Yes, and they never told me anything because I don't use the mark for navigation. When I want a region, i. e. a selection, I go where I want it and select what I want. The mark is irrelevant with this kind of usage, and so are these messages. > The mark is a standard Emacs marker, as described in (info > "(elisp) Markers"): > > A “marker” is a Lisp object used to specify a position in a buffer > relative to the surrounding text. A marker changes its offset from the > beginning of the buffer automatically whenever text is inserted or > deleted, so that it stays with the two characters on either side of it. And there is no way to show the mark? >> >> What would the advantage of hidden regions be? When something is within >> >> a region, it should be highlighted, and when it is no longer >> >> highlighted, it should no longer be within a region. >> > >> > Again, in Emacs, as long there is a mark in the current buffer, there >> > is always a "region". >> >> How would that make sense? I expect the mark to be gone once I used the >> region. > > That's what transient-mark-mode tries to implement, I think. It doesn't remove the mark after a highlighted region has been used. The idea was apparently to limit functions to a selection by highlighting a region and then calling it particularly "active". Highlighting and calling a region "active" would not be necessary if functions could otherwise be limited to the region. Combining these three things and not allowing another way to limit functions to the region make a mess. >> > The user might want it highlighted for various reasons, possibly not >> > covered by the current implementation, where Emacs highlights the >> > region only when 'mark-active' is non-nil. >> >> Yes, and that leads to misunderstandings, like d-s-m. It doesn't make >> any sense to claim that there is a region when there is none highlighted >> and only creates the inconsistency that an arbitrary part of a buffer >> can be deleted or copied, accidentally or intentionally, i. e. that >> something can be done with a region while the region is not active and >> nothing should possibly be done with it. > > Again, that seems like the intention behind transient-mark-mode. But > the implementation is, then, in a way incomplete: C-w still kills the > region, no matter whether it is active or not, in transient-mark-mode. Yes, it is an inconsistency. >> >> Are these hidden regions a remnant of technical limitations that made it >> >> advisable not to highlight the selection? >> > >> > No, they stem from convenience. For example, typing C-M-a in a source >> >> That key binding only works when you can use Alt instead of ESC. > > Does ESC C-a not work for you? Or C-[ C-a? ESC C-a works. [ is on AltGr+8. Emacs would have to have all key bindings re-defined to work well with keyboards for different languages, leading to a definition for each language. > [...] >> > Highlighting the region at any of these steps might be helpful for the >> > user, but Emacs can't know exactly when -- which is one argument for >> > allowing to toggle the highlighting dynamically as necessary, >> > independently of whether the mark is ever "active". >> >> This is a problem of navigating source code (or other files) and has >> nothing to do with regions or highlighting. >> >> Or what has navigating between a current location and the beginning of a >> function to do with selecting and highlighting parts of the contents of >> a buffer in order to copy or to delete them, or to do something with >> them like query-replace? > > The places where the mark has been set are places of interest to the > user for some reason or another -- that's all. The only purpose of the mark is to make a selection. After the selection has been used, editing moves on, and the location has become irrelevant. Places of interest are those where navigational aids are being placed, like bookmarks and registers. If it was possible to make a selection without using the mark, I might never use the mark. However, I might get used to using the mark for navigation if it was like a default register that can be easily set and moved back to. The way it currently is is merely dangerous because it may influence hidden and highlighted regions without that being my intention. >> > As seen above, use of C-u C-SPC effectively restores the region at >> > some previous point in editing. >> >> That I move around in a file as I see fit while reading or editing it >> doesn't have anything to do with regions I might select to do something >> with. I might highlight a selection to make parts of source code stick >> out as a reminder because they need to be fixed or worked upon in some >> particular order. I could use registers and/or bookmarks instead, but >> it would be much more convenient to use highlighting and perhaps to be >> able to jump through the selections. > > This would be a good use case for registers storing regions, I think. > The mark ring is a useful tool, but it does not give easy, random > access to all previous selections. We need a bug report for this. A feature request for the possibility of having multiple regions that can be highlighted, first decoupling making selections from navigation, might be an option. I'm not sure if further discussion before making such a request is better because there might be pretty strong resistance against this from everyone used to and using things the way they have been for a long time --- and maybe we're missing something. >> The mark is only for setting the begin of a selection, nothing else. I >> expect it to be gone once I did something with the selection. >> >> It doesn't even matter to me if there is a mark. All I do is start >> selecting somewhere and when it's selected, I do something with it, and >> that's all there is to it. >> >> Don't mix up a mark for navigational purposes with making and >> highlighting selections. > > It's probably feasible to add a "type" field to the mark, indicating > where it came from (i.e., if it was set explicitly by the user, by a > certain command, from a mouse selection, ...). Then we could offer > commands that jump between previous selections, or between previous > marks set by the user for navigation. Why not let the mark be mark and find a way of making selections independently from it? Some people like to make shift-selections. They could be independent from the mark stuff and simply allow to make selections something can be done with. >> > Working on a specific region can often be done conveniently from an >> > indirect buffer, as in the earlier example. >> >> It's quite inconvenient because with that, the source tends to occupy >> both frames I have on screen because I'd narrow the indirect buffer to >> what I'm working on --- which is already another inconvenience --- and >> need the other frame to look up things I can't see in the indirect >> buffer because it's narrowed. I've given up on it, it's just too >> awkward. >> >> As for doing other things, like replacing text in multiple parts of a >> buffer, is that something that could be usefully done with indirect >> buffers? With multiple regions, I'd highlight some parts of the buffer, >> do the replacement limited to these parts and would be done with it. >> I'd be able to see all of the buffer while doing this. > > Not possible yet, I think (at least, without making N indirect buffers > for the N regions and running the replacement command in all of them). Yes, that's what I thought, I'd have to make many indirect buffers. > But if we had some way to record the "type" of a previous mark (as > above), then we could offer a command to replace, for example, the > last N "active regions" in the buffer. I think that might fit the > bill. That would overload the mark even more than it already is. >> Indirect buffers still hold all of the text, so instead of marking what >> I want to work with, I'd have to narrow out what I'm not working with, >> and IIRC, it's not possible to narrow a buffer "the other way round" so >> that the parts I want to work with remain and all the rest of the buffer >> is narrowed away. > > I don't think that's possible yet. Having multiple regions active would make this unnecessary :) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-13 4:00 ` visual-region-mode? hw @ 2018-09-13 17:22 ` Alan Mackenzie 2018-09-13 20:08 ` visual-region-mode? hw 2018-09-13 20:42 ` visual-region-mode? Charles A. Roelli 1 sibling, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-13 17:22 UTC (permalink / raw) To: hw; +Cc: lokedhs, cpitclaudel, Charles A. Roelli, rms, emacs-devel Hello, hw. On Thu, Sep 13, 2018 at 06:00:32 +0200, hw wrote: > charles@aurox.ch (Charles A. Roelli) writes: > >> From: hw <hw@adminart.net> > >> Date: Tue, 11 Sep 2018 23:56:11 +0200 > >> [...] > > This is where Emacs differs from other programs, I suppose. It's > > optimized for efficient use, even when the result can be a surprise to > > the user. Otherwise, in this case, C-w and M-w would do nothing with > > no "active region". > What is efficient about hidden regions the way they are? They don't get in your way. A lot of the time, you won't be conceptualising the buffer portion between mark and point as "the region" - it's just point, and there's mark hanging around somewhere, possibly at somewhere significant. I think at some stage somebody tried having the region constantly highlighted, and it proved annoying, with the highlighting continually moving as you type stuff in, or even just move point. > If killing or copying a region didn't happen to be bound to keys that > are rather unlikely to get pressed by mistake, the design flaw of being > able to do something with a non-highlighted region while > transient-mark-mode is enabled might be more obvious. What seems like a design flaw to you is a feature to somebody else. That's why Emacs is so customisable. As Juri has already pointed out, there's an option you can set so that this "design flaw" won't affect you. I suggest you spending a couple of hours reading through the chapter "The Mark and the Region" (also known simply as "Mark") in the Emacs manual to see if there're any other options which would be useful to you at a non-default setting. > Disabling transient-mark-mode removes the possibility of highlighting > regions. What is the purpose of that? For users who find this highlighting unhelpful. As stated above, it was found in the distant past that constantly highlighting the region was counter-productive. If you disagree with that, then implement an option to have such highlighting. If you genuinely find it useful, then ask for your new option to be incorporated into the Emacs master. You might be surprised just how open the project leadership is to such innovations. > >> > C-SPC (without a prefix argument) always pushes a mark, so it always > >> > alters the region (unless point is already at the mark). C-u C-SPC > >> > sets point where the mark is, and pops the mark ring, effectively > >> > restoring the previous region. We should keep this behavior. > >> How am I supposed to know where a mark was? Why would I try to confuse > >> myself with C-u C-spc? In which way is the position of the mark > >> adjusted so that it sticks with the same contents of the buffer, which > >> it would need to do to be of any use? Mark does get adjusted so that it stays at the "same" position in the buffer, even if you insert or delete text before it. Try it! > > Various commands set the mark, as documented in the manual. When you > > use them, normally a message appears in the echo area saying "Mark > > set". > Yes, and they never told me anything because I don't use the mark for > navigation. An interesting question: why not? The mark is one of the concepts which distinguish Emacs from lesser editors, and with it you can do things like: (i) You search for something, and find it. You want to go back to your starting point. No problem in Emacs! C-u C-<space>. (ii) You're editing something, and you want to read the massive comment that often appears near the beginning of source files. You do M-<, read that comment, then C-u C-<space> to get back to where you were editing. Personally, I use the mark all the time for navigation, and would not want to go back to an editor without one. > When I want a region, i. e. a selection, I go where I want it and > select what I want. The mark is irrelevant with this kind of usage, > and so are these messages. You can ignore both of them, surely, for this kind of usage. [ .... ] > And there is no way to show the mark? Not really, no. Highlighting the region when transient-mark-mode is enabled is sort of a way, but that's not really what you meant. When I use the mark, my subconsciousness retains a map of where the mark is for an appreciable time. I don't need the mark to be visible. I don't think most users do, either. If you want the mark to be visible, implement it. Others might find it useful, too. > >> >> What would the advantage of hidden regions be? When something is within > >> >> a region, it should be highlighted, and when it is no longer > >> >> highlighted, it should no longer be within a region. > >> > Again, in Emacs, as long there is a mark in the current buffer, there > >> > is always a "region". > >> How would that make sense? I expect the mark to be gone once I used the > >> region. > > That's what transient-mark-mode tries to implement, I think. > It doesn't remove the mark after a highlighted region has been used. > The idea was apparently to limit functions to a selection by > highlighting a region and then calling it particularly "active". > Highlighting and calling a region "active" would not be necessary if > functions could otherwise be limited to the region. Combining these > three things and not allowing another way to limit functions to the > region make a mess. There is another way: narrow to the region (e.g. with C-x n n). Standard editing function are then restricted to this portion of the buffer. Useful here is, for example, C-x n d, which narrows to the current source-code function. [ .... ] > Emacs would have to have all key bindings re-defined to work well with > keyboards for different languages, leading to a definition for each > language. That's a bit of an exaggeration. [ .... ] > The only purpose of the mark is to make a selection. No. That's how _your_ use of it is currently restricted. I earnestly recommend you to spend time learning other uses of the mark. It will ease your editing. > After the selection has been used, editing moves on, and the location > has become irrelevant. Places of interest are those where navigational > aids are being placed, like bookmarks and registers. > If it was possible to make a selection without using the mark, I might > never use the mark. However, I might get used to using the mark for > navigation if it was like a default register that can be easily set and > moved back to. The way it currently is is merely dangerous because it > may influence hidden and highlighted regions without that being my > intention. Repeat: in an Emacs buffer there is exactly one region at any time. I can't suppress the feeling that sometime soon, something in your brain is going to click, you're going to shout "Eureka!", and suddenly the Emacs mark will be obvious and natural to you (as it is to so many users). [ .... ] > A feature request for the possibility of having multiple regions that > can be highlighted, first decoupling making selections from navigation, > might be an option. I'm not sure if further discussion before making > such a request is better because there might be pretty strong resistance > against this from everyone used to and using things the way they have > been for a long time --- and maybe we're missing something. There would indeed be resistance. Somehow, you've got to set up a multiple region. That will need key sequences (of which there are very few spare). Then you've got to modify lots of commands to work on a multiple region. Indeed you've got to decide what they will do. This is not a task for the faint-hearted. [ .... ] > Why not let the mark be mark and find a way of making selections > independently from it? Because that would lead to a general loss of convenience in the use of the mark. Still, if you have a solid idea of how this could work (and it would have to be optional), implement it and ask for it to be incorporated into Emacs. [ .... ] > That would overload the mark even more than it already is. I don't agree the mark is overloaded. Using it's several features together is one of the delights of Emacs. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-13 17:22 ` visual-region-mode? Alan Mackenzie @ 2018-09-13 20:08 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-13 20:08 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Charles A. Roelli, cpitclaudel, lokedhs, rms, emacs-devel Alan Mackenzie <acm@muc.de> writes: > Hello, hw. > > On Thu, Sep 13, 2018 at 06:00:32 +0200, hw wrote: >> charles@aurox.ch (Charles A. Roelli) writes: > >> >> From: hw <hw@adminart.net> >> >> Date: Tue, 11 Sep 2018 23:56:11 +0200 > >> >> [...] > >> > This is where Emacs differs from other programs, I suppose. It's >> > optimized for efficient use, even when the result can be a surprise to >> > the user. Otherwise, in this case, C-w and M-w would do nothing with >> > no "active region". > >> What is efficient about hidden regions the way they are? > > They don't get in your way. Of course they do. They're lurking hidden in the background, waiting for me to make a mistake, and are making me feel uneasy all the time. > A lot of the time, you won't be conceptualising the buffer portion > between mark and point as "the region" - it's just point, and there's > mark hanging around somewhere, possibly at somewhere significant. I always know it's lurking. > [...] >> If killing or copying a region didn't happen to be bound to keys that >> are rather unlikely to get pressed by mistake, the design flaw of being >> able to do something with a non-highlighted region while >> transient-mark-mode is enabled might be more obvious. > > What seems like a design flaw to you is a feature to somebody else. No, software has a design flaw when it doesn't protect the user from making mistakes and makes mistakes even worse. For that, it doesn't matter how easy it is to make the mistake. This doesn't have anything to do with features. > That's why Emacs is so customisable. As Juri has already pointed out, > there's an option you can set so that this "design flaw" won't affect > you. I suggest you spending a couple of hours reading through the > chapter "The Mark and the Region" (also known simply as "Mark") in the > Emacs manual to see if there're any other options which would be useful > to you at a non-default setting. I already looked in the manual and was surprised about the lack of options. Maybe I'll find some when I read more. >> Disabling transient-mark-mode removes the possibility of highlighting >> regions. What is the purpose of that? > > For users who find this highlighting unhelpful. That simply doesn't make any sense. > [...] > >> >> > C-SPC (without a prefix argument) always pushes a mark, so it always >> >> > alters the region (unless point is already at the mark). C-u C-SPC >> >> > sets point where the mark is, and pops the mark ring, effectively >> >> > restoring the previous region. We should keep this behavior. > >> >> How am I supposed to know where a mark was? Why would I try to confuse >> >> myself with C-u C-spc? In which way is the position of the mark >> >> adjusted so that it sticks with the same contents of the buffer, which >> >> it would need to do to be of any use? > > Mark does get adjusted so that it stays at the "same" position in the > buffer, even if you insert or delete text before it. Try it! And how do I know where it is? And why text before it and not after it? When you set a mark in the middle of the buffer and delete something at the end, the mark moves towards the end of the buffer. And what happens when you delete a place that contains a mark? >> > Various commands set the mark, as documented in the manual. When you >> > use them, normally a message appears in the echo area saying "Mark >> > set". > >> Yes, and they never told me anything because I don't use the mark for >> navigation. > > An interesting question: why not? The mark is one of the concepts which > distinguish Emacs from lesser editors, and with it you can do things > like: > (i) You search for something, and find it. You want to go back to your > starting point. No problem in Emacs! C-u C-<space>. > (ii) You're editing something, and you want to read the massive comment > that often appears near the beginning of source files. You do M-<, read > that comment, then C-u C-<space> to get back to where you were editing. > > Personally, I use the mark all the time for navigation, and would not > want to go back to an editor without one. The mark is not for navigation, it's for making selections. When I want to select something, I go there and select it. So why would these messages tell me anything and why would I care? I don't even need a mark, I only need to select things. >> When I want a region, i. e. a selection, I go where I want it and >> select what I want. The mark is irrelevant with this kind of usage, >> and so are these messages. > > You can ignore both of them, surely, for this kind of usage. No, the problem is that there is always something lurking hidden in the background --- you call it a region. If I was ignoring that, I might make a mistake and do something with it I don't want to. > [ .... ] > >> And there is no way to show the mark? > > Not really, no. Highlighting the region when transient-mark-mode is > enabled is sort of a way, but that's not really what you meant. > > When I use the mark, my subconsciousness retains a map of where the mark > is for an appreciable time. I don't need the mark to be visible. I > don't think most users do, either. > > If you want the mark to be visible, implement it. Others might find it > useful, too. I don't know how to. I might find it useful to use a mark for navigation, but only when has nothing to do with making selections. >> >> >> What would the advantage of hidden regions be? When something is within >> >> >> a region, it should be highlighted, and when it is no longer >> >> >> highlighted, it should no longer be within a region. > >> >> > Again, in Emacs, as long there is a mark in the current buffer, there >> >> > is always a "region". > >> >> How would that make sense? I expect the mark to be gone once I used the >> >> region. > >> > That's what transient-mark-mode tries to implement, I think. > >> It doesn't remove the mark after a highlighted region has been used. >> The idea was apparently to limit functions to a selection by >> highlighting a region and then calling it particularly "active". > >> Highlighting and calling a region "active" would not be necessary if >> functions could otherwise be limited to the region. Combining these >> three things and not allowing another way to limit functions to the >> region make a mess. > > There is another way: narrow to the region (e.g. with C-x n n). Standard > editing function are then restricted to this portion of the buffer. That is triple work because first I'd have to make a selection, second I'd have to narrow the buffer and third I'd have to widen it again. > Useful here is, for example, C-x n d, which narrows to the current > source-code function. Cases in which operations that need to be limited to a selection are as wide as a whole function almost don't exist. > [ .... ] > >> Emacs would have to have all key bindings re-defined to work well with >> keyboards for different languages, leading to a definition for each >> language. > > That's a bit of an exaggeration. Why? Move one key binding, and there will already be another key binding in the way, so you first have to move that one, etc., and you end up shuffling them all around a great deal until you might find something that reasonably works --- or not. > [ .... ] > >> The only purpose of the mark is to make a selection. > > No. That's how _your_ use of it is currently restricted. I earnestly > recommend you to spend time learning other uses of the mark. It will > ease your editing. I don't have any other uses for it --- actually, I don't have any. Making selections doesn't have anything to do with navigation, and overloading the navigational aid that is called a mark by involving it into making selections is a very bad idea. A constantly changing, hidden selection which is being brought up by that is also a very bad idea. >> After the selection has been used, editing moves on, and the location >> has become irrelevant. Places of interest are those where navigational >> aids are being placed, like bookmarks and registers. > >> If it was possible to make a selection without using the mark, I might >> never use the mark. However, I might get used to using the mark for >> navigation if it was like a default register that can be easily set and >> moved back to. The way it currently is is merely dangerous because it >> may influence hidden and highlighted regions without that being my >> intention. > > Repeat: in an Emacs buffer there is exactly one region at any time. I > can't suppress the feeling that sometime soon, something in your brain is > going to click, you're going to shout "Eureka!", and suddenly the Emacs > mark will be obvious and natural to you (as it is to so many users). I might use it for navigation if it didn't do anything else. Since there is currently no other way to make a selection, I have to use it for making selections. There's nothing obvious about it other than that it is a bad idea. > [ .... ] > >> A feature request for the possibility of having multiple regions that >> can be highlighted, first decoupling making selections from navigation, >> might be an option. I'm not sure if further discussion before making >> such a request is better because there might be pretty strong resistance >> against this from everyone used to and using things the way they have >> been for a long time --- and maybe we're missing something. > > There would indeed be resistance. Somehow, you've got to set up a > multiple region. That will need key sequences (of which there are very > few spare). Then you've got to modify lots of commands to work on a > multiple region. Indeed you've got to decide what they will do. This is > not a task for the faint-hearted. Apparently there are some modes that allow to use multiple selections :) > > [ .... ] > >> Why not let the mark be mark and find a way of making selections >> independently from it? > > Because that would lead to a general loss of convenience in the use of > the mark. It could be used for navigation, how would that make anything less convenient? > Still, if you have a solid idea of how this could work (and it > would have to be optional), implement it and ask for it to be > incorporated into Emacs. I don't know how to implement it. > [ .... ] > >> That would overload the mark even more than it already is. > > I don't agree the mark is overloaded. Using it's several features > together is one of the delights of Emacs. It's no delight at all, it's a bad idea. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-13 4:00 ` visual-region-mode? hw 2018-09-13 17:22 ` visual-region-mode? Alan Mackenzie @ 2018-09-13 20:42 ` Charles A. Roelli 2018-09-15 19:21 ` visual-region-mode? hw 1 sibling, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-13 20:42 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Date: Thu, 13 Sep 2018 06:00:32 +0200 > > What is efficient about hidden regions the way they are? The region has a simple definition, and the commands using the region are well-marked (e.g. "kill-region", "fill-region", "eval-region", ...). > When I want a region, i. e. a selection, I go where I want > it and select what I want. No need, you have the mark already. ;) > And there is no way to show the mark? Besides the ways already mentioned, no. As Alan has suggested, it becomes second nature to keep its position in your head. And if you want to know how far away it is from point (as a reminder), there is the key M-= (or ESC =). > The only purpose of the mark is to make a selection. After the > selection has been used, editing moves on, and the location has become > irrelevant. Sometimes yes, sometimes no. Better to err on the side of caution, than to forget all previous marks (as other programs do). > >> That I move around in a file as I see fit while reading or editing it > >> doesn't have anything to do with regions I might select to do something > >> with. I might highlight a selection to make parts of source code stick > >> out as a reminder because they need to be fixed or worked upon in some > >> particular order. I could use registers and/or bookmarks instead, but > >> it would be much more convenient to use highlighting and perhaps to be > >> able to jump through the selections. > > > > This would be a good use case for registers storing regions, I think. > > The mark ring is a useful tool, but it does not give easy, random > > access to all previous selections. We need a bug report for this. > > A feature request for the possibility of having multiple regions that > can be highlighted, first decoupling making selections from navigation, > might be an option. I'm not sure if further discussion before making > such a request is better because there might be pretty strong resistance > against this from everyone used to and using things the way they have > been for a long time --- and maybe we're missing something. I make a less ambitious suggestion: get registers to store regions (i.e., two markers). Then we can add functions to highlight them, set one of them as the "active region", and otherwise operate on them, either individually or as a set -- a bit like the "zones" Drew has detailed. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-13 20:42 ` visual-region-mode? Charles A. Roelli @ 2018-09-15 19:21 ` hw 2018-09-16 19:31 ` visual-region-mode? Charles A. Roelli 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-15 19:21 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Date: Thu, 13 Sep 2018 06:00:32 +0200 >> >> What is efficient about hidden regions the way they are? > > The region has a simple definition, Someone already pointed out that the definition isn't all that simple. > and the commands using the region > are well-marked (e.g. "kill-region", "fill-region", "eval-region", > ...). How does this make hidden regions efficient? >> When I want a region, i. e. a selection, I go where I want >> it and select what I want. > > No need, you have the mark already. ;) No, I don't. What I select doesn't have anything to do with this mark. >> And there is no way to show the mark? > > Besides the ways already mentioned, no. As Alan has suggested, it > becomes second nature to keep its position in your head. And if you > want to know how far away it is from point (as a reminder), there is > the key M-= (or ESC =). Sure, I'm going to remember the positions of marks in the 25 buffers or so I have open at work in the main Emacs session over months, plus the other 5 or 10 in every minor Emacs session plus the ones I have at home --- as if I had nothing better to do than to burden me with irrelevant stuff like that. I'm simply not using the mark, and it shouldn't be there. The hidden regions they create are a source for errors. Make it so they don't create regions, and the mark might become usable, provided it can be made visible. >> The only purpose of the mark is to make a selection. After the >> selection has been used, editing moves on, and the location has become >> irrelevant. > > Sometimes yes, sometimes no. Better to err on the side of caution, > than to forget all previous marks (as other programs do). Wrong, leaving the mark lurking around to create a hidden region only means to make mistakes a user might make much worse. It is a design flaw. > [...] >> > This would be a good use case for registers storing regions, I think. >> > The mark ring is a useful tool, but it does not give easy, random >> > access to all previous selections. We need a bug report for this. >> >> A feature request for the possibility of having multiple regions that >> can be highlighted, first decoupling making selections from navigation, >> might be an option. I'm not sure if further discussion before making >> such a request is better because there might be pretty strong resistance >> against this from everyone used to and using things the way they have >> been for a long time --- and maybe we're missing something. > > I make a less ambitious suggestion: get registers to store regions > (i.e., two markers). Then we can add functions to highlight them, set > one of them as the "active region", and otherwise operate on them, > either individually or as a set -- a bit like the "zones" Drew has > detailed. Maybe it's better not to use "regions" but "selections". Transient-mark-mode already shows that people don't care about regions but about visible selections. How multiple selections would be implemented wasn't my concern, though. I wouldn't know the best way how to technically do that. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-15 19:21 ` visual-region-mode? hw @ 2018-09-16 19:31 ` Charles A. Roelli 2018-09-17 20:36 ` visual-region-mode? hw 0 siblings, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-16 19:31 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Date: Sat, 15 Sep 2018 21:21:30 +0200 > > > and the commands using the region > > are well-marked (e.g. "kill-region", "fill-region", "eval-region", > > ...). > > How does this make hidden regions efficient? You have a clear set of actions that can work on the region, anytime, no matter whether the region is "hidden", or active and visible, or rectangular. > I'm simply not using the mark, and it shouldn't be there. The hidden > regions they create are a source for errors. Make it so they don't > create regions, and the mark might become usable, provided it can be > made visible. The "hidden regions" can only be a source of error if you type, say, C-w or M-w at random during editing. I don't understand why you would do that, especially in your case if you haven't selected a region beforehand. You could just as well have hit C-/ or C-k, which will also change your buffer. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-16 19:31 ` visual-region-mode? Charles A. Roelli @ 2018-09-17 20:36 ` hw 2018-09-17 22:24 ` visual-region-mode? Drew Adams 2018-09-18 19:22 ` visual-region-mode? Charles A. Roelli 0 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-17 20:36 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Date: Sat, 15 Sep 2018 21:21:30 +0200 >> >> > and the commands using the region >> > are well-marked (e.g. "kill-region", "fill-region", "eval-region", >> > ...). >> >> How does this make hidden regions efficient? > > You have a clear set of actions that can work on the region, anytime, > no matter whether the region is "hidden", or active and visible, or > rectangular. Having clarified which operations can be used with a region doesn't mean that working with a region can be efficiently done. In practise, there is no clear set of operations for regions. Various modes and their options, combined with inconsistencies and weirdness, make it anything but clear what does what under which circumstances. >> I'm simply not using the mark, and it shouldn't be there. The hidden >> regions they create are a source for errors. Make it so they don't >> create regions, and the mark might become usable, provided it can be >> made visible. > > The "hidden regions" can only be a source of error if you type, say, > C-w or M-w at random during editing. What about upcase-region, downcase-region and others that don't come to mind atm? They already clash with transient-mark-mode and are as unsafe as C-w and M-w. Changing mark-even-if-inactive to nil is required to prevent that --- why isn't that the default? > I don't understand why you would do that, Yes, I wouldn't do that intentionally. That these things happen unintentionally is, as I said before, rather unlikely. The hidden regions mean that I always have to consider that they are always there so that I do not make a mistake in the first place. That makes me feel uneasy. It's like having to walk around with a loaded gun all the time: I wouldn't intentionally shoot my feet, and I wouldn't be the first one to accidentally shoot myself if I did. It's just easier to put the gun away and to only get it when I want to use it than it is to exercise perfect gun handling all the time. Do you carry a toolbox around all the time because you are a mechanic, or do you leave it at home when you go to a party where you won't need it? Emacs drags it around to every party because it doesn't know how to let go. If you ask Emacs about it, it'll say it's because it's fundamental. It can be difficult to argue with fundamental. > especially in your case if you haven't selected a region beforehand. You don't need to make a selection for a region you could make a mistake with to always exist once there is a mark somewhere in the buffer. That region always exists all by itself, fundamentally waiting for you to eventually make your mistake. > You could just as well have hit C-/ or C-k, which will also change > your buffer. Yes, there are mistakes users can make the software can not reasonably protect them against. That doesn't mean the software shouldn't protect the users when protecting them is reasonably possible. It also doesn't mean the software should make the mistake worse. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: visual-region-mode? 2018-09-17 20:36 ` visual-region-mode? hw @ 2018-09-17 22:24 ` Drew Adams 2018-09-17 23:11 ` visual-region-mode? hw 2018-09-18 19:22 ` visual-region-mode? Charles A. Roelli 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-17 22:24 UTC (permalink / raw) To: hw, charles; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > The hidden regions mean that I always have to consider that they are > always there so that I do not make a mistake in the first place. That > makes me feel uneasy. To be clear: 1. There is only ever one region per buffer - not regions. 2. Wrt "hidden": The cursor is the point end of the region. It, at least, is always visible, never hidden. The region might not be highlighted, but its text is typically not hidden (invisible). So it would be more accurate for you to speak of the region (singular) not being _highlighted_. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-17 22:24 ` visual-region-mode? Drew Adams @ 2018-09-17 23:11 ` hw 2018-09-18 0:11 ` visual-region-mode? Juri Linkov 2018-09-18 12:32 ` visual-region-mode? Eli Zaretskii 0 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-17 23:11 UTC (permalink / raw) To: Drew Adams; +Cc: lokedhs, cpitclaudel, charles, rms, emacs-devel Drew Adams <drew.adams@oracle.com> writes: >> The hidden regions mean that I always have to consider that they are >> always there so that I do not make a mistake in the first place. That >> makes me feel uneasy. > > To be clear: > > 1. There is only ever one region per buffer - not regions. > > 2. Wrt "hidden": The cursor is the point end of the region. It, at > least, is always visible, never hidden. The region might not be > highlighted, but its text is typically not hidden (invisible). > > So it would be more accurate for you to speak of the region (singular) not being _highlighted_. At least the beginning of the region can be hidden (not on display). The mark is always hidden (invisible). The mark being invisible and the region not highlighted make the region hidden (I can't see what it contains and not really where it is.). That point "marks" the end of the region is an irrelevant technicality, and that point always drags an invisible (imaginary) tail either in front of it or behind it is confusing. It does not contribute to making the region unhidden. Of course, I could use point to imagine something, but I don't want to. The region is just something "hidden", one for each buffer or window, unless highlighted. Being more accurate about it doesn't make me feel less uneasy about it. I still don't understand why the selection (not the region) can not be highlighted when transient-mark-mode is disabled and why the mark can not be indicated. Since we are at it, why doesn't point at least indicate in which direction the imaginary tail goes? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-17 23:11 ` visual-region-mode? hw @ 2018-09-18 0:11 ` Juri Linkov 2018-09-18 12:32 ` visual-region-mode? Eli Zaretskii 1 sibling, 0 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-18 0:11 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, charles, rms, lokedhs, emacs-devel, Drew Adams > The region is just something "hidden", one for each buffer or window, > unless highlighted. Being more accurate about it doesn't make me feel > less uneasy about it. I'm not sure what is worse: "hidden region" or "hidden selection". What you call "hidden region" is undoubtedly dangerous: when you forget you had a mark in the buffer and accidentally call a disastrous command like C-w whose catastrophic consequences may go unnoticed. This happens when the region is not highlighted, so you don't see it. But "hidden selection" that you proposed has the same flaw: when you create a permanent selection, and move point to another part of the buffer, so the selection scrolls off-screen, you don't see it anymore, and might forget it's still active somewhere in the buffer, then accidentally typing C-w will have the same consequences as in case of "hidden region". ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-17 23:11 ` visual-region-mode? hw 2018-09-18 0:11 ` visual-region-mode? Juri Linkov @ 2018-09-18 12:32 ` Eli Zaretskii 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 12:32 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, charles, rms, lokedhs, emacs-devel, drew.adams > From: hw <hw@adminart.net> > Date: Tue, 18 Sep 2018 01:11:47 +0200 > Cc: lokedhs@gmail.com, cpitclaudel@gmail.com, charles@aurox.ch, rms@gnu.org, > emacs-devel@gnu.org > > Since we are at it, why doesn't point at least indicate in which > direction the imaginary tail goes? Because no one has written code to do that, of course. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-17 20:36 ` visual-region-mode? hw 2018-09-17 22:24 ` visual-region-mode? Drew Adams @ 2018-09-18 19:22 ` Charles A. Roelli 2018-09-19 1:45 ` visual-region-mode? hw 1 sibling, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-18 19:22 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Date: Mon, 17 Sep 2018 22:36:30 +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. If we somehow "disarm" the region by default (as you have suggested), the use of all these commands would be less efficient. > > The "hidden regions" can only be a source of error if you type, say, > > C-w or M-w at random during editing. > > What about upcase-region, downcase-region and others that don't come to > mind atm? They already clash with transient-mark-mode and are as unsafe > as C-w and M-w. Changing mark-even-if-inactive to nil is required to > prevent that --- why isn't that the default? These commands are already disabled by default. > The hidden regions mean that I always have to consider that they are > always there so that I do not make a mistake in the first place. That > makes me feel uneasy. What's the worst that could happen? We have so many ways to recover from these sorts of errors: autosaves, backups, VC, diff-buffer-with-file, ... In addition, for buffers that you think should have additional protection against accidental edits, there's "view-mode". ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-18 19:22 ` visual-region-mode? Charles A. Roelli @ 2018-09-19 1:45 ` hw 2018-09-19 19:22 ` visual-region-mode? Charles A. Roelli 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-19 1:45 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Date: Mon, 17 Sep 2018 22:36:30 +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. > 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. >> > The "hidden regions" can only be a source of error if you type, say, >> > C-w or M-w at random during editing. >> >> What about upcase-region, downcase-region and others that don't come to >> mind atm? They already clash with transient-mark-mode and are as unsafe >> as C-w and M-w. Changing mark-even-if-inactive to nil is required to >> prevent that --- why isn't that the default? > > These commands are already disabled by default. Right, I didn't notice. Emacs says they are disabled because they can be confusing. Confusing usually doesn't exactly mean efficient. >> The hidden regions mean that I always have to consider that they are >> always there so that I do not make a mistake in the first place. That >> makes me feel uneasy. > > What's the worst that could happen? We have so many ways to recover > from these sorts of errors: autosaves, backups, VC, > diff-buffer-with-file, ... An accidental downcase-region of a couple lines in a program usually isn't very noticeable unless you look very closely at it, so chances aren't too bad that the problems they may cause only come up when it means that the worst thing does happen. > In addition, for buffers that you think should have additional > protection against accidental edits, there's "view-mode". 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. I just wish the mark was visible and point was indicating the direction of it. View-mode is cool for things not being edited. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-19 1:45 ` visual-region-mode? hw @ 2018-09-19 19:22 ` Charles A. Roelli 2018-09-19 20:04 ` visual-region-mode? hw 0 siblings, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-19 19:22 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > 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. But if you reject the main building block they use (the region, active or not), then it makes sense that you find them inefficient. > > 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. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-19 19:22 ` visual-region-mode? Charles A. Roelli @ 2018-09-19 20:04 ` hw 2018-09-20 18:14 ` visual-region-mode? Charles A. Roelli 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-19 20:04 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel 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? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-19 20:04 ` visual-region-mode? hw @ 2018-09-20 18:14 ` Charles A. Roelli 2018-09-21 20:28 ` visual-region-mode? hw 0 siblings, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-20 18:14 UTC (permalink / raw) To: hw; +Cc: cpitclaudel, lokedhs, rms, emacs-devel > From: hw <hw@adminart.net> > Date: Wed, 19 Sep 2018 22:04:14 +0200 > > Simple instructions can be very inefficient, for example by leaving out > important information, by oversimplifying things or by trying to dumb > things down. Yes, though it's rare to hear such accusations against Emacs. > With t-m-m disabled, there is no way to fortify the region, and there is > no highlighting. Why would I disable it? There would be a way to "fortify" the region, if you had another binding for toggling whether the region is active or not. > 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. Unfortunately, the doc on this is unclear -- at least, "mark-active" needs to clarify that its value is only taken into account with "t-m-m" on: mark-active is a variable defined in ‘buffer.c’. Non-nil means the mark and region are currently active in this buffer. region-active-p is a compiled Lisp function in ‘simple.el’. Return non-nil if Transient Mark mode is enabled and the mark is active. I'd like to be able to "activate" the region with "t-m-m" off to use commands that behave differently when the region is active (like M-%), without the highlighting that "t-m-m" forces, and without the region randomly deactivating itself after certain commands as it does with "t-m-m" switched on. Highlighting the region could be a separate mode. > 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. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-20 18:14 ` visual-region-mode? Charles A. Roelli @ 2018-09-21 20:28 ` hw 2018-09-24 17:42 ` visual-region-mode? Charles A. Roelli ` (2 more replies) 0 siblings, 3 replies; 245+ messages in thread From: hw @ 2018-09-21 20:28 UTC (permalink / raw) To: Charles A. Roelli; +Cc: cpitclaudel, lokedhs, rms, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Date: Wed, 19 Sep 2018 22:04:14 +0200 > > [...] >> With t-m-m disabled, there is no way to fortify the region, and there is >> no highlighting. Why would I disable it? > > 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. >> 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. > [...] > I'd like to be able to "activate" the region with "t-m-m" off to use > commands that behave differently when the region is active (like M-%), > without the highlighting that "t-m-m" forces, Perhaps there is a way to disable the highlighting. I haven't found out how something is highlighted. > and without the region randomly deactivating itself after certain > commands as it does with "t-m-m" switched on. I've never had an issue with the region deactivating itself randomly. Under what circumstances exactly does this happen? Are you referring to commands deactivating the region? 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. What do you plan on doing with it that would require this? > Highlighting the region could be a separate mode. Highlighting the region all the time is probably not very useful. >> 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. Without highlighting, a different indicator could be useful to show whether the region is active or not, like a hint in the mode line. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-21 20:28 ` visual-region-mode? hw @ 2018-09-24 17:42 ` Charles A. Roelli 2018-09-24 18:07 ` visual-region-mode? Yuri Khan 2018-09-26 22:00 ` visual-region-mode? hw 2018-09-24 20:24 ` visual-region-mode? Alan Mackenzie [not found] ` <<m2ftxy3i79.fsf@aurox.ch> 2 siblings, 2 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-09-24 17:42 UTC (permalink / raw) To: hw; +Cc: emacs-devel > From: hw <hw@adminart.net> > 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. > >> 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. > 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. > > 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->. > 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. 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. > > 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. > >> 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. Even if you disable the highlighting of the region, certain commands will behave differently in response to the region being active. You've already posted an improved version of C-x C-x that does not 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. > Without highlighting, a different indicator could be useful to show > whether the region is active or not, like a hint in the mode line. Yes, offering an indicator in the mode line to show whether the region is active would be a good start. Btw, I'm culling most of the CC list since it seems no longer relevant. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-24 17:42 ` visual-region-mode? Charles A. Roelli @ 2018-09-24 18:07 ` Yuri Khan 2018-09-29 11:18 ` visual-region-mode? Charles A. Roelli 2018-09-26 22:00 ` visual-region-mode? hw 1 sibling, 1 reply; 245+ messages in thread From: Yuri Khan @ 2018-09-24 18:07 UTC (permalink / raw) To: charles; +Cc: hw, Emacs developers On Tue, Sep 25, 2018 at 12:41 AM Charles A. Roelli <charles@aurox.ch> wrote: > 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->. FWIW, mark is not deactivated for me by incremental search. $ emacs -Q M-x emacs-version → GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2018-05-29 1. In the *scratch* buffer, move point to the start of the word “buffer”. 2. Select the word “buffer” by holding down Shift and pressing <right> six times. 3. Press C-s for isearch-forward. 4. Search for “text”. 5. Press RET to end incremental search. Observed: “buffer is for text” is highlighted as region. Expected: region is deactivated. 6. Move point using an unshifted arrow key. Observed, expected: region is deactivated. The ability to extend a region using isearch is occasionally useful, but it would probably be better if it only behaved that way if invoked as C-S-s or C-S-r (as a general case of shifted navigation command). (Text terminal users are out of luck with Shift+Ctrl+letter bindings, though.) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-24 18:07 ` visual-region-mode? Yuri Khan @ 2018-09-29 11:18 ` Charles A. Roelli 2018-10-03 13:13 ` visual-region-mode? hw 0 siblings, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-29 11:18 UTC (permalink / raw) To: Yuri Khan; +Cc: hw, emacs-devel > From: Yuri Khan <yurivkhan@gmail.com> > Date: Tue, 25 Sep 2018 01:07:24 +0700 > > On Tue, Sep 25, 2018 at 12:41 AM Charles A. Roelli <charles@aurox.ch> wrote: > > > 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->. > > FWIW, mark is not deactivated for me by incremental search. > > $ emacs -Q > M-x emacs-version > → GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9) > of 2018-05-29 > > 1. In the *scratch* buffer, move point to the start of the word “buffer”. > 2. Select the word “buffer” by holding down Shift and pressing <right> > six times. > 3. Press C-s for isearch-forward. > 4. Search for “text”. > 5. Press RET to end incremental search. > > Observed: “buffer is for text” is highlighted as region. > > Expected: region is deactivated. > > 6. Move point using an unshifted arrow key. > > Observed, expected: region is deactivated. > > > The ability to extend a region using isearch is occasionally useful, > but it would probably be better if it only behaved that way if invoked > as C-S-s or C-S-r (as a general case of shifted navigation command). > (Text terminal users are out of luck with Shift+Ctrl+letter bindings, > though.) Yes, the documentation is wrong here, and probably needs a review. There's more: in your recipe, ISEARCH actually does not set the mark where the search was started (since the region is already active) -- to give the impression that ISEARCH "extends the region". So the documentation here is doubly wrong. The manual tries to explain why ISEARCH sometimes does not push a mark: When you exit the incremental search, it adds the original value of point to the mark ring, without activating the mark; you can thus use ‘C-u C-<SPC>’ or ‘C-x C-x’ to return to where you were before beginning the search. *Note Mark Ring::. (Emacs only does this if the mark was not already active; if the mark was active when you started the search, both 'C-u C-<SPC>' and 'C-x C-x' will go to the mark.) The wording leaves something to be desired. The parenthetical could maybe say: Emacs only pushes the mark if it was not already active; if the mark was active when you started the search, both 'C-u C-<SPC>' and 'C-x C-x' will place point at the other end of the active region, not at the original value of point. Also, isearch.el seems not to have any documentation about any of the mark- or "t-m-m"-related behavior, at all. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-29 11:18 ` visual-region-mode? Charles A. Roelli @ 2018-10-03 13:13 ` hw 2018-10-04 20:20 ` visual-region-mode? Charles A. Roelli 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-10-03 13:13 UTC (permalink / raw) To: Charles A. Roelli; +Cc: Yuri Khan, emacs-devel charles@aurox.ch (Charles A. Roelli) writes: > [...] > The manual tries to explain why ISEARCH sometimes does not push a > mark: > > When you exit the incremental search, it adds the original value of > point to the mark ring, without activating the mark; you can thus use > ‘C-u C-<SPC>’ or ‘C-x C-x’ to return to where you were before beginning > the search. *Note Mark Ring::. (Emacs only does this if the mark was > not already active; if the mark was active when you started the search, > both 'C-u C-<SPC>' and 'C-x C-x' will go to the mark.) > > The wording leaves something to be desired. The parenthetical could > maybe say: > > Emacs only pushes the mark if it was not already active; if the mark > was active when you started the search, both 'C-u C-<SPC>' and 'C-x > C-x' will place point at the other end of the active region, not at > the original value of point. This seems very confusing. Is the region activated or the mark, or both? Isn't the region defined to be the part of the buffer between mark and point? If so, then point is always at one end of the region, active or not, and there is no way to place it somewhere else. IIUC, you can not place point at the other end of the region when there is no mark to exchange it with, and what happens to the mark when you do this when searching incrementally? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-10-03 13:13 ` visual-region-mode? hw @ 2018-10-04 20:20 ` Charles A. Roelli 0 siblings, 0 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-10-04 20:20 UTC (permalink / raw) To: hw; +Cc: yurivkhan, emacs-devel > From: hw <hw@adminart.net> > Cc: Yuri Khan <yurivkhan@gmail.com>, emacs-devel@gnu.org > Date: Wed, 03 Oct 2018 15:13:25 +0200 > > > The wording leaves something to be desired. The parenthetical could > > maybe say: > > > > Emacs only pushes the mark if it was not already active; if the mark > > was active when you started the search, both 'C-u C-<SPC>' and 'C-x > > C-x' will place point at the other end of the active region, not at > > the original value of point. > > This seems very confusing. Is the region activated or the mark, or > both? I've used the two terms interchangeably because they are equivalent. > Isn't the region defined to be the part of the buffer between mark and > point? If so, then point is always at one end of the region, active or > not, and there is no way to place it somewhere else. IIUC, you can not > place point at the other end of the region when there is no mark to > exchange it with, and what happens to the mark when you do this when > searching incrementally? Yes, you can place point at the other end of an active region (that is, at mark). Naturally the active region will change, if that's all you do. Neither C-u C-SPC nor C-x C-x change their behavior when searching incrementally; but ISEARCH changes its behavior based on whether the region is active, and that is what needs better documentation. This kind of oversight makes "t-m-m" unwieldy, harder to customize and unlikely to be a target for patches or improvement. "t-m-m" reaches into many places in Emacs where you might not have expected, and turning it off is a convenient fix that guarantees (almost) no bother from the mode. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-24 17:42 ` visual-region-mode? Charles A. Roelli 2018-09-24 18:07 ` visual-region-mode? Yuri Khan @ 2018-09-26 22:00 ` hw 2018-09-27 21:01 ` visual-region-mode? Charles A. Roelli 1 sibling, 1 reply; 245+ messages in thread From: hw @ 2018-09-26 22:00 UTC (permalink / raw) To: Charles A. Roelli; +Cc: emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> 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. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-26 22:00 ` visual-region-mode? hw @ 2018-09-27 21:01 ` Charles A. Roelli 2018-10-03 13:59 ` visual-region-mode? hw 0 siblings, 1 reply; 245+ messages in thread From: Charles A. Roelli @ 2018-09-27 21:01 UTC (permalink / raw) To: hw; +Cc: emacs-devel > From: hw <hw@adminart.net> > Cc: emacs-devel@gnu.org > Date: Thu, 27 Sep 2018 00:00:42 +0200 > > > 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. For what it's worth, the doc of the variable "transient-mark-mode" says: - The pair (only . OLDVAL) enables Transient Mark mode temporarily. After any subsequent point motion command that is not shift-translated, or any other action that would normally deactivate the mark (e.g. buffer modification), the value of ‘transient-mark-mode’ is set to OLDVAL. > 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. You disable "t-m-m" if you don't want a "transient" mark -- as in, activating and deactivating itself seemingly of its own volition. > >> > 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. Actually, the documentation lacks at least one other case: scrolling that results in point moving, either with the keyboard or with the mouse. That's one of several arbitrary decisions in the design of t-m-m. > > 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. I'd rather tells Emacs when the region is active, than the other way round. > 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. This would be a binding to activate or deactivate the region, I think. No extra command ("query-replace-region") should be necessary. > 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. Narrowing still has its place in everyday editing. > (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.) Neat, let us know how this approach goes. I don't know what key we could allocate to a command that activates or deactivates the region, since there are not free ones left on average keyboards... > 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? People use "active mark" and "active region" interchangeably, AFAIK. (I know I do!) > > [...] > > 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. Those people had responded to this thread earlier, so they ended up on the list automatically. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-27 21:01 ` visual-region-mode? Charles A. Roelli @ 2018-10-03 13:59 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-10-03 13:59 UTC (permalink / raw) To: Charles A. Roelli; +Cc: emacs-devel charles@aurox.ch (Charles A. Roelli) writes: >> From: hw <hw@adminart.net> >> Cc: emacs-devel@gnu.org >> Date: Thu, 27 Sep 2018 00:00:42 +0200 >> >> > 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. > > For what it's worth, the doc of the variable "transient-mark-mode" says: > > - The pair (only . OLDVAL) enables Transient Mark mode > temporarily. After any subsequent point motion command that is > not shift-translated, or any other action that would normally > deactivate the mark (e.g. buffer modification), the value of > ‘transient-mark-mode’ is set to OLDVAL. That sheds some light on the definition of exchange-point-and-mark in simple.el which I didn't fully understand. It either activates the region or deactivates it, i. e. there doesn't seem to be anything temporary about it. "Temporary" only seems to mean that the mode is enabled until the region is deactivated. That doesn't mean that it is actually temporary; it's the very same mode --- or isn't it? >> 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. > > You disable "t-m-m" if you don't want a "transient" mark -- as in, > activating and deactivating itself seemingly of its own volition. That isn't what it does. There are only very few cases where I expect the region to be deactivated and it isn't deactivated, and no cases in which the region is somehow activated all on its own. So why would I disable t-m-m? >> >> > 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. > > Actually, the documentation lacks at least one other case: scrolling > that results in point moving, either with the keyboard or with the > mouse. That's one of several arbitrary decisions in the design of > t-m-m. That shows the fundamental design flaw of Emacs which doesn't allow to separate the region and thus selections from where the cursor is. I don't see how you could blame t-m-m for it. >> > 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. > > I'd rather tells Emacs when the region is active, than the other way > round. So you would rather have a "persistent region", i. e. a selection like joe has? Unfortunately, we can't really have that (unless the zones Drew suggested work in this way), and t-m-m is what comes closest to it. >> 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. > > This would be a binding to activate or deactivate the region, I think. > No extra command ("query-replace-region") should be necessary. It depends on what you prefer: extra commands to do stuff limited to the region, consistent with such commands that already exist, or explicitly activate the region to limit any command to do stuff with it. The latter could be what the temporaryness for t-m-m is supposed to cover. I simply leave t-m-m always enabled and have a key binding to activate the region with when I want to. The region is also fortified, and it does what I want. >> 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. > > Narrowing still has its place in everyday editing. What do you use it for? >> (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.) > > Neat, let us know how this approach goes. So far, it's nice. I need to do some programming to really find out, and it will be a while before I get to that. > I don't know what key we could allocate to a command that activates or > deactivates the region, since there are not free ones left on average > keyboards... That's why I like to have more keys. You could get one of these keyboards, they're awesome. The keyboard is part of customization. Other than that, having C-x C-x changed already helps, and in lack of another key, you could use it with the prefix to toggle the activeness of the region. >> 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? > > People use "active mark" and "active region" interchangeably, AFAIK. > (I know I do!) That's confusing, and you could even have it so that activating the mark creates a persistent selection that isn't disabled after doing something with it while activating the region activates the selection only until you did something with it. >> > [...] >> > 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. > > Those people had responded to this thread earlier, so they ended up on > the list automatically. Hm, that's an interesting feature. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-21 20:28 ` visual-region-mode? hw 2018-09-24 17:42 ` visual-region-mode? Charles A. Roelli @ 2018-09-24 20:24 ` Alan Mackenzie 2018-09-26 18:12 ` visual-region-mode? Charles A. Roelli 2018-09-26 22:45 ` visual-region-mode? hw [not found] ` <<m2ftxy3i79.fsf@aurox.ch> 2 siblings, 2 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-24 20:24 UTC (permalink / raw) To: hw; +Cc: lokedhs, cpitclaudel, Charles A. Roelli, rms, emacs-devel Hello, hw. On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote: > charles@aurox.ch (Charles A. Roelli) writes: > >> From: hw <hw@adminart.net> > >> Date: Wed, 19 Sep 2018 22:04:14 +0200 > >> With t-m-m disabled, there is no way to fortify the region, and there is > >> no highlighting. Why would I disable it? [ .... ] > Disabling t-m-m doesn't make any sense at all. Why would anyone disable > it? For the avoidance of the complexities that dealing with transient-mark-mode involves. > 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. There is a great deal of point. Your last suggestion borders on the offensive, since it suggests that any user whose needs and understanding are different from yours should not be taken into account in plotting the future of Emacs. I do agree with you that transient-mark-mode is a hodge-podge of vaguely related distinct features, mostly badly named, and that was why I argued against it becoming a default setting some years ago. I also agree with you that these distinct features should be capable of being en/disabled independently. These distinct features are (i) the highlighting of the region; (ii) the disablement of commands which need the mark to function; (iii) the "narrowing" of the buffer for certain commands (such as M-%). > Without highlighting, a different indicator could be useful to show > whether the region is active or not, like a hint in the mode line. Yes. I suggest this should be a single character, or at most two characters. Space in the mode line is precious. Maybe "+" could fulfil this role somewhere. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-24 20:24 ` visual-region-mode? Alan Mackenzie @ 2018-09-26 18:12 ` Charles A. Roelli 2018-09-26 22:45 ` visual-region-mode? hw 1 sibling, 0 replies; 245+ messages in thread From: Charles A. Roelli @ 2018-09-26 18:12 UTC (permalink / raw) To: Alan Mackenzie; +Cc: hw, cpitclaudel, lokedhs, rms, emacs-devel > Date: Mon, 24 Sep 2018 20:24:01 +0000 > From: Alan Mackenzie <acm@muc.de> > > > Without highlighting, a different indicator could be useful to show > > whether the region is active or not, like a hint in the mode line. > > Yes. I suggest this should be a single character, or at most two > characters. Space in the mode line is precious. Maybe "+" could fulfil > this role somewhere. Do you think it could also be useful to allow activating the region when t-m-m is off? Here is how that could be different to the current "temporary transient mark mode" activated with C-u C-x C-x: - the command to activate or deactivate the region would have a binding - the region would, by default, never be activated or deactivated by anybody but the user How to highlight the region (and when to do it) would be separately customizable. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-24 20:24 ` visual-region-mode? Alan Mackenzie 2018-09-26 18:12 ` visual-region-mode? Charles A. Roelli @ 2018-09-26 22:45 ` hw 2018-09-27 17:26 ` visual-region-mode? Alan Mackenzie 1 sibling, 1 reply; 245+ messages in thread From: hw @ 2018-09-26 22:45 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Charles A. Roelli, cpitclaudel, lokedhs, rms, emacs-devel Alan Mackenzie <acm@muc.de> writes: > Hello, hw. > > On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote: >> charles@aurox.ch (Charles A. Roelli) writes: > >> >> From: hw <hw@adminart.net> >> >> Date: Wed, 19 Sep 2018 22:04:14 +0200 > >> >> With t-m-m disabled, there is no way to fortify the region, and there is >> >> no highlighting. Why would I disable it? > > [ .... ] > >> Disabling t-m-m doesn't make any sense at all. Why would anyone disable >> it? > > For the avoidance of the complexities that dealing with > transient-mark-mode involves. Which complexities do you mean? >> 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. > > There is a great deal of point. Which is? > Your last suggestion borders on the offensive, since it suggests that > any user whose needs and understanding are different from yours should > not be taken into account in plotting the future of Emacs. It doesn't suggest that; it only suggests to remove functionality that is pointless and unnecessary and, along with it, a great deal of complexity and inconsistency which accompany it. Do you have an example of something that could not be accomplished with transient-mark-mode enabled and only with it disabled? > I do agree with you that transient-mark-mode is a hodge-podge of vaguely > related distinct features, mostly badly named, and that was why I argued > against it becoming a default setting some years ago. I didn't say that t-m-m is a hodge-podge. > I also agree with you that these distinct features should be capable of > being en/disabled independently. These distinct features are (i) the > highlighting of the region; (ii) the disablement of commands which need > the mark to function; Do you mean it should be possible to disable commands that want the region to be active to do something? That would at least need clarification of the intention, i. e. was the intention to limit them to the region, to extend them to the region, or both? --- Commands are already disabled when t-m-m is enabled and mark-even-if-inactive is nil, so why do there need to be more ways to disable them? Not that I, in theory, wouldn't appreciate a way to fortify the region when t-m-m is disabled, but since there is no point in disabling it, I don't see a need for one (But you could disable the mark, see below.) Instead of voting for more ways to disable commands, I might argue to remove the functions that imply "region" because implying to do stuff with a region is unnecessary when t-m-m is enabled because t-m-m means to do anything either with a region or not, depending on whether the region is active or not. What's the point and the advantage of duplicating all commands that can do stuff with the contents of a buffer only because a fundamental design flaw makes it so inefficient to determine whether commands should do their things with the whole buffer or with a part of it by requiring the user to narrow and to widen the buffer in order to make that determination? I don't understand why this wasn't simply overcome by setting the mark to nil. You could have *one* set of commands instead of several, and if you wanted them to do their things with the region, do not have the mark set to nil, and if you want them to work on the whole buffer, just set the mark to nil. You wouldn't need t-m-m then, would you (except for the highlighting)? > (iii) the "narrowing" of the buffer for certain > commands (such as M-%). Is narrowing the buffer sometimes disabled? How do you determine to which parts you want to narrow buffers to without selecting either the relevant parts or the irrelevant parts? >> Without highlighting, a different indicator could be useful to show >> whether the region is active or not, like a hint in the mode line. > > Yes. I suggest this should be a single character, or at most two > characters. Space in the mode line is precious. Maybe "+" could fulfil > this role somewhere. Right, though '+' would make me think that there is more to display while there isn't, like because there isn't enough room for it. Changing the colour of the mode line might work, too. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-26 22:45 ` visual-region-mode? hw @ 2018-09-27 17:26 ` Alan Mackenzie 2018-10-03 15:43 ` visual-region-mode? hw 0 siblings, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-27 17:26 UTC (permalink / raw) To: hw; +Cc: Charles A. Roelli, cpitclaudel, lokedhs, rms, emacs-devel Hello, hw. On Thu, Sep 27, 2018 at 00:45:59 +0200, hw wrote: > Alan Mackenzie <acm@muc.de> writes: > > Hello, hw. > > On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote: > >> charles@aurox.ch (Charles A. Roelli) writes: > >> >> From: hw <hw@adminart.net> > >> >> Date: Wed, 19 Sep 2018 22:04:14 +0200 > >> >> With t-m-m disabled, there is no way to fortify the region, and there is > >> >> no highlighting. Why would I disable it? > > [ .... ] > >> Disabling t-m-m doesn't make any sense at all. Why would anyone disable > >> it? > > For the avoidance of the complexities that dealing with > > transient-mark-mode involves. > Which complexities do you mean? The ones I've outlined in previous posts to you. You've shown no sign in the past of having understood what I've said. So I'll say it one last time. This time please pay attention. The complexity I'm referring to is having "modes" (like vi's insert and command mode) in Emacs where a single command does different things according to the mode. This happens with transient-mark-mode enabled, the two modes being mark "active" and mark not "active". This complexity is avoided by disabling transient-mark-mode. [ .... ] > > Your last suggestion borders on the offensive, since it suggests that > > any user whose needs and understanding are different from yours > > should not be taken into account in plotting the future of Emacs. > It doesn't suggest that; it only suggests to remove functionality that > is pointless and unnecessary and, along with it, a great deal of > complexity and inconsistency which accompany it. You _are_ becoming offensive. Your personal preferences are NOT objective goodness. You have your way of using Emacs, and you should not try to force it onto me. Thankfully, the maintainers of Emacs are not about to remove the choice. > Do you have an example of something that could not be accomplished with > transient-mark-mode enabled and only with it disabled? No, of course not. Any editing result can be achieved with t-m-m either enabled or disabled. If you really were interested in simplicity, you would be advocating abolishing transient-mark-mode completely. Emacs is simpler without it, and still a full-featured editor (as it was in the decades before transient-mark-mode was written). It would make lots of users unhappy, though. > > I do agree with you that transient-mark-mode is a hodge-podge of vaguely > > related distinct features, mostly badly named, and that was why I argued > > against it becoming a default setting some years ago. > I didn't say that t-m-m is a hodge-podge. Sorry, those were my words, not yours. > > I also agree with you that these distinct features should be capable of > > being en/disabled independently. These distinct features are (i) the > > highlighting of the region; (ii) the disablement of commands which need > > the mark to function; > Do you mean it should be possible to disable commands that want the > region to be active to do something? No, I meant precisely what I wrote. I did not mention the region. > That would at least need clarification of the intention, i. e. was the > intention to limit them to the region, to extend them to the region, or > both? With transient-mark-mode disabled, you avoid this complexity. ;-) > --- Commands are already disabled when t-m-m is enabled and > mark-even-if-inactive is nil, so why do there need to be more ways to > disable them? Please read again what I wrote, and concentrate. > Not that I, in theory, wouldn't appreciate a way to fortify the region > .... To WHAT the region? "Fortify" is not Emacs terminology. > .... when t-m-m is disabled, but since there is no point in disabling > it, ... You are simply wrong on this point. I wish you would stop incessantly repeating it. > .... I don't see a need for one (But you could disable the mark, see > below.) > Instead of voting for more ways to disable commands, .... Nobody is advocating this. > .... I might argue to remove the functions that imply "region" because > implying to do stuff with a region is unnecessary when t-m-m is enabled > because t-m-m means to do anything either with a region or not, > depending on whether the region is active or not. You would be better not so to argue. > What's the point and the advantage of duplicating all commands that can > do stuff with the contents of a buffer only because a fundamental design > flaw makes it so inefficient to determine whether commands should do > their things with the whole buffer or with a part of it by requiring the > user to narrow and to widen the buffer in order to make that > determination? Would you please stop insinuating that a feature of Emacs which you happen not to like is a "fundamental design flaw". It is insulting to generations of Emacs developers, and is not true. Your thinking it is based on your lack of a deeper understanding of Emacs' design, purpose and history. > I don't understand why this wasn't simply overcome by setting the mark > to nil. You could have *one* set of commands instead of several, and if > you wanted them to do their things with the region, do not have the mark > set to nil, and if you want them to work on the whole buffer, just set > the mark to nil. You wouldn't need t-m-m then, would you (except for > the highlighting)? Setting the mark to nil at any time would reduce its effectiveness for navigation. > > (iii) the "narrowing" of the buffer for certain > > commands (such as M-%). > Is narrowing the buffer sometimes disabled? No. > How do you determine to which parts you want to narrow buffers to > without selecting either the relevant parts or the irrelevant parts? C-x n n narrow-to-region (after setting mark and moving point); or C-x n d narrow-to-defun; or C-x n p narrow-to-page. And when you're finishied, C-x n w widen. > >> Without highlighting, a different indicator could be useful to show > >> whether the region is active or not, like a hint in the mode line. > > Yes. I suggest this should be a single character, or at most two > > characters. Space in the mode line is precious. Maybe "+" could fulfil > > this role somewhere. > Right, though '+' would make me think that there is more to display > while there isn't, like because there isn't enough room for it. > Changing the colour of the mode line might work, too. I suppose so. Though I'd be more in favour of changing the colour of just a small part of the mode line, to minimise the reduction in readability. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-27 17:26 ` visual-region-mode? Alan Mackenzie @ 2018-10-03 15:43 ` hw 2018-10-03 17:03 ` visual-region-mode? Alan Mackenzie 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-10-03 15:43 UTC (permalink / raw) To: Alan Mackenzie; +Cc: lokedhs, cpitclaudel, Charles A. Roelli, rms, emacs-devel Alan Mackenzie <acm@muc.de> writes: > Hello, hw. > > On Thu, Sep 27, 2018 at 00:45:59 +0200, hw wrote: >> Alan Mackenzie <acm@muc.de> writes: > >> > Hello, hw. > >> > On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote: >> >> charles@aurox.ch (Charles A. Roelli) writes: > >> >> >> From: hw <hw@adminart.net> >> >> >> Date: Wed, 19 Sep 2018 22:04:14 +0200 > >> >> >> With t-m-m disabled, there is no way to fortify the region, and there is >> >> >> no highlighting. Why would I disable it? > >> > [ .... ] > >> >> Disabling t-m-m doesn't make any sense at all. Why would anyone disable >> >> it? > >> > For the avoidance of the complexities that dealing with >> > transient-mark-mode involves. > >> Which complexities do you mean? > > The ones I've outlined in previous posts to you. You've shown no sign in > the past of having understood what I've said. So I'll say it one last > time. This time please pay attention. > > The complexity I'm referring to is having "modes" (like vi's insert and > command mode) in Emacs where a single command does different things > according to the mode. This happens with transient-mark-mode enabled, > the two modes being mark "active" and mark not "active". This complexity > is avoided by disabling transient-mark-mode. I must be blind? Where did you say this before? I'm saying all this complexity is avoided by removing the possibility of having transient-mark-mode disabled, and that there is no need for two different sets of commands when t-m-m is enabled. There is also only advantages of having t-m-m enabled and only disadvantages having it disabled, so why disable it? If you never disable it, you don't need to deal with the complexity, though it remains in the sources until removed. > [ .... ] > >> > Your last suggestion borders on the offensive, since it suggests that >> > any user whose needs and understanding are different from yours >> > should not be taken into account in plotting the future of Emacs. > >> It doesn't suggest that; it only suggests to remove functionality that >> is pointless and unnecessary and, along with it, a great deal of >> complexity and inconsistency which accompany it. > > You _are_ becoming offensive. Your personal preferences are NOT > objective goodness. You have your way of using Emacs, and you should not > try to force it onto me. Thankfully, the maintainers of Emacs are not > about to remove the choice. I didn't say that my preferences are good for everyone and am not trying to force them upon anyone. I'm merely suggesting that something unnecessary could be removed. >> Do you have an example of something that could not be accomplished with >> transient-mark-mode enabled and only with it disabled? > > No, of course not. Any editing result can be achieved with t-m-m either > enabled or disabled. If you really were interested in simplicity, you > would be advocating abolishing transient-mark-mode completely. Emacs is > simpler without it, and still a full-featured editor (as it was in the > decades before transient-mark-mode was written). It would make lots of > users unhappy, though. See above, you don't like the complexity, and you'd rather remove transient-mark-mode than you'd remove the possibility of disabling it. I don't find that offensive, though it seems to me that you have some hate for t-m-m for unknown reasons, and I still don't understand why you would disable and remove it and still don't see any advantages of having it disabled. Nobody has yet shown any advantages of having t-m-m disabled. > [...] >> > I also agree with you that these distinct features should be capable of >> > being en/disabled independently. These distinct features are (i) the >> > highlighting of the region; (ii) the disablement of commands which need >> > the mark to function; > >> Do you mean it should be possible to disable commands that want the >> region to be active to do something? > > No, I meant precisely what I wrote. I did not mention the region. The mark implies region, and why would you want to disable commands that need the mark to function? >> That would at least need clarification of the intention, i. e. was the >> intention to limit them to the region, to extend them to the region, or >> both? > > With transient-mark-mode disabled, you avoid this complexity. ;-) Not really: you would need to narrow or to widen the buffer depending on the intention, and that is way more complicated than making a selection and doing something with it. You could much better avoid this complexity by clarifying the intention of having a selection --- reasonably to the understanding that, for functions, it means to do their thing with the selection, regardless of whether it means to limit or to extend their doing to it. For this, it doesn't matter what t-m-m originally meant. There goes all the complexity out the window. >> --- Commands are already disabled when t-m-m is enabled and >> mark-even-if-inactive is nil, so why do there need to be more ways to >> disable them? > > Please read again what I wrote, and concentrate. see above >> Not that I, in theory, wouldn't appreciate a way to fortify the region >> .... > > To WHAT the region? "Fortify" is not Emacs terminology. Yet Emacs can already fortify the region. If you want to stick with Emacs terminology, how would you ever make any progress? >> .... when t-m-m is disabled, but since there is no point in disabling >> it, ... > > You are simply wrong on this point. I wish you would stop incessantly > repeating it. What would be the point of disabling t-m-m? I wish you could show one. >> .... I don't see a need for one (But you could disable the mark, see >> below.) > >> Instead of voting for more ways to disable commands, .... > > Nobody is advocating this. You want an independent way to disable commands that need the mark to function. Isn't that voting for more ways to disable commands? >> .... I might argue to remove the functions that imply "region" because >> implying to do stuff with a region is unnecessary when t-m-m is enabled >> because t-m-m means to do anything either with a region or not, >> depending on whether the region is active or not. > > You would be better not so to argue. Why not? Does having two sets of functions that do the same thing, once with the selection, once with random parts of the buffer unless you kinda make a selection by narrowing it, reduce complexity? Or does it have some advantages? >> What's the point and the advantage of duplicating all commands that can >> do stuff with the contents of a buffer only because a fundamental design >> flaw makes it so inefficient to determine whether commands should do >> their things with the whole buffer or with a part of it by requiring the >> user to narrow and to widen the buffer in order to make that >> determination? > > Would you please stop insinuating that a feature of Emacs which you > happen not to like is a "fundamental design flaw". It is insulting to > generations of Emacs developers, and is not true. Your thinking it is > based on your lack of a deeper understanding of Emacs' design, purpose > and history. Maybe you can explain to me how it is not a design flaw that navigating and making and having a selection --- or having random parts of a buffer always threatened by mistakes --- are inseparable from each other and how this design flaw is not a fundamental one while Emacs is built upon this. Imagine a hundred years ago a bridge was built from wood which now can not withstand the traffic it would need to carry because the wood simply can't handle the load. It was a design flaw to build it from wood rather than steel, and it's a fundamental design flaw because changing that would mean to build a new bridge. Now I call it a fundamental design flaw --- and you would expect the people who built and maintained the bridge to be insulted? They would probably laugh about it. If they don't, they should. It's still a fundamental design flaw that can not be changed, so what. Duplicating all commands for Emacs that can do something with contents of a buffer still doesn't seem advantageous. >> I don't understand why this wasn't simply overcome by setting the mark >> to nil. You could have *one* set of commands instead of several, and if >> you wanted them to do their things with the region, do not have the mark >> set to nil, and if you want them to work on the whole buffer, just set >> the mark to nil. You wouldn't need t-m-m then, would you (except for >> the highlighting)? > > Setting the mark to nil at any time would reduce its effectiveness for > navigation. There you see the design flaw. >> > (iii) the "narrowing" of the buffer for certain >> > commands (such as M-%). > >> Is narrowing the buffer sometimes disabled? > > No. Why do you need to independently disable it? >> How do you determine to which parts you want to narrow buffers to >> without selecting either the relevant parts or the irrelevant parts? > > C-x n n narrow-to-region (after setting mark and moving point); or > C-x n d narrow-to-defun; or > C-x n p narrow-to-page. > And when you're finishied, > C-x n w widen. That's either: + make a selection and then narrow to it, or + determine whether you are within something that would count as a defun, then determine if all the brackets (or whatever is used) are balanced, then narrow to it, using yet another key binding, or + Who is using pages?, or + do something with the narrowed buffer, then widen it, using yet another key binding This doesn't account for that the units you would narrow to would have to happen the part of the buffer you want to do something with, which is the most unlikely case. You also need to remember four different key bindings. Though it's a valid example, I wouldn't say it's something practical. Instead of all this, you can just make a selection and do something with it, all without any further ado, without having to remember lots of key bindings and without needing to determine first if any of them is currently applicable. You can't do that when t-m-m is disabled, and still you insist on having it disabled. Can't you see how t-m-m reduces complexity, which is what you wanted? And where is the point in disabling it? >> >> Without highlighting, a different indicator could be useful to show >> >> whether the region is active or not, like a hint in the mode line. > >> > Yes. I suggest this should be a single character, or at most two >> > characters. Space in the mode line is precious. Maybe "+" could fulfil >> > this role somewhere. > >> Right, though '+' would make me think that there is more to display >> while there isn't, like because there isn't enough room for it. >> Changing the colour of the mode line might work, too. > > I suppose so. Though I'd be more in favour of changing the colour of > just a small part of the mode line, to minimise the reduction in > readability. That could be optional. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-10-03 15:43 ` visual-region-mode? hw @ 2018-10-03 17:03 ` Alan Mackenzie 0 siblings, 0 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-10-03 17:03 UTC (permalink / raw) To: hw; +Cc: emacs-devel Hello, hw On Wed, Oct 03, 2018 at 17:43:46 +0200, hw wrote: [ .... ] That time has come. For many, many posts you have been deliberately misunderstanding, misconstruing, and twisting plainly expressed views, with the aim of provoking maximum irritation, insulting all of us here, and generally wasting people's time and energy. In short, you are a troll - an anonymous troll. I have finished feeding you, and if it were up to me, I would tell you you are no longer welcome on this list. Cheerio. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<m2ftxy3i79.fsf@aurox.ch>]
* RE: visual-region-mode? [not found] ` <<m2ftxy3i79.fsf@aurox.ch> @ 2018-09-24 20:39 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-24 20:39 UTC (permalink / raw) To: Charles A. Roelli, hw; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2520 bytes --] > > Without highlighting, a different indicator could be useful to show > > whether the region is active or not, like a hint in the mode line. > > Yes, offering an indicator in the mode line to show whether the > region is active would be a good start. FWIW, my library `modeline-posn.el' provides such a mode-line indication. When the region is active, `size-indication-mode' does these things (optionally): * Shows the size of the region (or the shape/size if rectangular), instead of the buffer size. * Shows that the current command acts on the active region or acts specially because the region is active. You can customize the info for the first bullet. Choices for this include (a) the number of chars, (b) the number of bytes, (c) the number of chars and number of lines (or the number of rows and number of columns, if a rectangle is selected), and (d) anything else you might want. Choice (c) is the default (shown in attached screenshot). Option `modelinepos-empty-region-flag' determines whether to show the active-region indication when the active region is empty. Attached screenshot shows the mode-line indication. The red box on the face indicates that the region is active, and it currently has 149 characters. It shows Isearch restricted to the region (an Isearch+ feature). The region changes while searching (because the cursor moves), so the region size (number of chars) also indicates the cursor position relative to the original start of the region. The face used to highlight the `size-indication-mode' part of the mode-line changes to reflect region activation. If the current command did not treat the active region specially then the face in the screenshot would not include the surrounding red box. It would just show the region-face background (by default). (Two faces are used for the size highlighting: one for normal and one to show that the current command acts specially.) Commands use variable `modelinepos-region-acting-on' to control when to show that they act specially on the region. For example, this is how I make `rectangle-mark-mode' turn this indication on and off: (defadvice rectangle-mark-mode (after bind-modelinepos-region-acting-on activate) (setq modelinepos-region-acting-on rectangle-mark-mode modelinepos-rect-p rectangle-mark-mode) (redisplay 'force)) https://www.emacswiki.org/emacs/ModeLinePosition [-- Attachment #2: drew-emacs-modeline-region-isearch.png --] [-- Type: image/png, Size: 9819 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: visual-region-mode? 2018-09-11 21:56 ` visual-region-mode? hw 2018-09-12 19:47 ` visual-region-mode? Charles A. Roelli @ 2018-09-12 20:27 ` Juri Linkov 1 sibling, 0 replies; 245+ messages in thread From: Juri Linkov @ 2018-09-12 20:27 UTC (permalink / raw) To: hw; +Cc: lokedhs, cpitclaudel, Charles A. Roelli, rms, emacs-devel > I don't think there can currently be multiple regions at the same time. Multiple regions are already supported - rectangle region is one implementation of non-contiguous regions. So you can define your own region shape by extending region-extract-function and redisplay-highlight-region-function to e.g. put region boundaries at positions of marks from mark-ring where C-SPC will add more parts to the region. > As for doing other things, like replacing text in multiple parts of a > buffer, is that something that could be usefully done with indirect > buffers? With multiple regions, I'd highlight some parts of the buffer, > do the replacement limited to these parts and would be done with it. > I'd be able to see all of the buffer while doing this. query-replace already supports multiple regions. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 11:32 ` Elias Mårtenson 2018-09-08 14:01 ` Eli Zaretskii 2018-09-08 15:52 ` hw @ 2018-09-08 18:16 ` Dmitry Gutov 2018-09-09 7:42 ` Elias Mårtenson 2 siblings, 1 reply; 245+ messages in thread From: Dmitry Gutov @ 2018-09-08 18:16 UTC (permalink / raw) To: Elias Mårtenson, Richard Stallman; +Cc: cpitclaudel, emacs-devel On 08.09.2018 14:32, Elias Mårtenson wrote: > I believe that the whole idea of active regions was a mistake, and even > though it can be disabled, some Emacs code these days assume it's on to > the extent that 1) it misbehaves when it's off, and 2) it gets turned on > automatically when it's loaded (I'm looking at you, company-mode). What does company-mode have to do with it? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 18:16 ` delete-selection-mode as default Dmitry Gutov @ 2018-09-09 7:42 ` Elias Mårtenson 2018-09-09 14:25 ` Clément Pit-Claudel 0 siblings, 1 reply; 245+ messages in thread From: Elias Mårtenson @ 2018-09-09 7:42 UTC (permalink / raw) To: Dmitry Gutov; +Cc: cpitclaudel, Richard Stallman, emacs-devel [-- Attachment #1: Type: text/plain, Size: 732 bytes --] On Sun, 9 Sep 2018, 02:16 Dmitry Gutov, <dgutov@yandex.ru> wrote: > On 08.09.2018 14:32, Elias Mårtenson wrote: > > > I believe that the whole idea of active regions was a mistake, and even > > though it can be disabled, some Emacs code these days assume it's on to > > the extent that 1) it misbehaves when it's off, and 2) it gets turned on > > automatically when it's loaded (I'm looking at you, company-mode). > > What does company-mode have to do with it? > When I turn it on, I get active regions enabled. However, now that I'm thinking about it, I also turn on Flycheck at the same time, so I might have misplaced the accusation. I will try it again once I'm back on my computer. Regards, Elias > [-- Attachment #2: Type: text/html, Size: 1353 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 7:42 ` Elias Mårtenson @ 2018-09-09 14:25 ` Clément Pit-Claudel 0 siblings, 0 replies; 245+ messages in thread From: Clément Pit-Claudel @ 2018-09-09 14:25 UTC (permalink / raw) To: Elias Mårtenson; +Cc: emacs-devel On 2018-09-09 03:42, Elias Mårtenson wrote: > When I turn it on, I get active regions enabled. However, now that > I'm thinking about it, I also turn on Flycheck at the same time, so I > might have misplaced the accusation. I feel pretty safe on that one :) I just checked, and the sources in flycheck.el do not contain the word "selection". ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 6:47 ` Eli Zaretskii 2018-09-07 9:18 ` delete-selection-mode as default hw @ 2018-09-07 9:40 ` Phil Sainty 2018-09-07 13:41 ` Eli Zaretskii 2018-09-07 15:35 ` Drew Adams 2018-09-07 19:01 ` tomas ` (3 subsequent siblings) 5 siblings, 2 replies; 245+ messages in thread From: Phil Sainty @ 2018-09-07 9:40 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, Noam Postavsky, emacs-devel, drew.adams, phillip.lord *Personally* I dislike `delete-selection-mode'; but FWIW I also don't have a big issue with disabling it in my init file -- at the end of the day it's an easy change to make to get back to the behaviour I prefer. I can't imagine that many users who use the current default behaviour would continue to use the default if the default were *changed*; so either way a sub-set of users will always be forced to set `delete-selection-mode' in their init files -- which means it's a question of whether we're more interested in minimising friction for existing users who still prefer the current default, or for new users who are probably used to the behaviour of other text-editors. I think what I'd be most in favour of would be a new link on the splash screen which invited users to customize some of the most fundamental aspects in which the default Emacs behaviours conflict with the typical behaviour of newer applications with which the user may be more familiar. I think this would be one of those options. CUA mode would be another. This set of options could be added to over time (as and when new user options were added to provide compatibility with the way that other editors and applications work), such that new Emacs users can always have a smoother introduction offered to them, without interfering with the upgrade experience of existing users. Such a feature would be like an improved/interactive alternative to the "Migrating to Emacs" section of the "Emacs Guided Tour" web page. Of course that entails someone spending their time implementing a feature which doesn't benefit them in any way -- because *they* already know how to set all the options in question. User options can belong to multiple groups though, can't they? Perhaps an initial implementation is as simple as identifying such options, adding them to a common group, and linking to that group from the splash screen? On 2018-09-07 18:47, Eli Zaretskii wrote: > Feel free to start a user poll, though: if it turns out I'm the > only one who thinks delete-selection-mode is inappropriate in > programming modes, we can make it the default; I can easily > turn it off in my configuration. Though I would urge people to > actually try this in programming modes before responding, and > in any case the poll should request to provide the major modes > used with the responses. I am quite surprised by the notion that there are users who are using `delete-selection-mode' in some modes and not others?! My instinct is that that would be extremely confusing, so I wouldn't be in favour of any default behaviour where the mode was sometimes on and sometimes off. I think the default should be consistent one way or the other. -Phil ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 9:40 ` delete-selection-mode as default (WAS: Some developement questions) Phil Sainty @ 2018-09-07 13:41 ` Eli Zaretskii 2018-09-08 11:37 ` Phil Sainty 2018-09-07 15:35 ` Drew Adams 1 sibling, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-07 13:41 UTC (permalink / raw) To: Phil Sainty; +Cc: hw, spacibba, npostavs, emacs-devel, drew.adams, phillip.lord > Date: Fri, 07 Sep 2018 21:40:26 +1200 > From: Phil Sainty <psainty@orcon.net.nz> > Cc: Noam Postavsky <npostavs@gmail.com>, hw@adminart.net, spacibba@aol.com, > phillip.lord@russet.org.uk, drew.adams@oracle.com, emacs-devel@gnu.org > > I think what I'd be most in favour of would be a new link on the > splash screen which invited users to customize some of the most > fundamental aspects in which the default Emacs behaviours > conflict with the typical behaviour of newer applications with > which the user may be more familiar. I think this would be one > of those options. CUA mode would be another. Patches to that effect are welcome. > User options can belong to multiple groups though, can't they? > Perhaps an initial implementation is as simple as identifying > such options, adding them to a common group, and linking to that > group from the splash screen? I suggested that in a recent thread, so I'm in favor of identifying these groups. Thanks. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 13:41 ` Eli Zaretskii @ 2018-09-08 11:37 ` Phil Sainty 2018-09-08 14:04 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: Phil Sainty @ 2018-09-08 11:37 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, npostavs, emacs-devel, drew.adams, phillip.lord On 08/09/18 01:41, Eli Zaretskii wrote: >> User options can belong to multiple groups though, can't they? >> Perhaps an initial implementation is as simple as identifying >> such options, adding them to a common group, and linking to that >> group from the splash screen? > > I suggested that in a recent thread, so I'm in favor of identifying > these groups. Oh, very good. I didn't remember it, but perhaps I read that. Were there other particular user options which were mentioned when you first raised this idea? (Do you remember which thread that was?) I feel like this should become a bug report, for tracking purposes. -Phil ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-08 11:37 ` Phil Sainty @ 2018-09-08 14:04 ` Eli Zaretskii 0 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-08 14:04 UTC (permalink / raw) To: Phil Sainty; +Cc: hw, spacibba, npostavs, emacs-devel, drew.adams, phillip.lord > Cc: npostavs@gmail.com, hw@adminart.net, spacibba@aol.com, > phillip.lord@russet.org.uk, drew.adams@oracle.com, emacs-devel@gnu.org > From: Phil Sainty <psainty@orcon.net.nz> > Date: Sat, 8 Sep 2018 23:37:41 +1200 > > On 08/09/18 01:41, Eli Zaretskii wrote: > >> User options can belong to multiple groups though, can't they? > >> Perhaps an initial implementation is as simple as identifying > >> such options, adding them to a common group, and linking to that > >> group from the splash screen? > > > > I suggested that in a recent thread, so I'm in favor of identifying > > these groups. > > Oh, very good. I didn't remember it, but perhaps I read that. > > Were there other particular user options which were mentioned when > you first raised this idea? The idea I described was to do it the other way around: first identify the groups of users, and then come up with the list of options pertinent for each group. > (Do you remember which thread that was?) My message was here: http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00794.html ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 9:40 ` delete-selection-mode as default (WAS: Some developement questions) Phil Sainty 2018-09-07 13:41 ` Eli Zaretskii @ 2018-09-07 15:35 ` Drew Adams 2018-09-07 16:16 ` Yuri Khan 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-07 15:35 UTC (permalink / raw) To: Phil Sainty, Eli Zaretskii Cc: hw, spacibba, emacs-devel, Noam Postavsky, phillip.lord > *Personally* I dislike `delete-selection-mode'; but FWIW I also > don't have a big issue with disabling it in my init file -- at > the end of the day it's an easy change to make to get back to > the behaviour I prefer. > > I can't imagine that many users who use the current default > behaviour would continue to use the default if the default were > *changed*; so either way a sub-set of users will always be forced > to set `delete-selection-mode' in their init files -- which means > it's a question of whether we're more interested in minimising > friction for existing users who still prefer the current default, > or for new users who are probably used to the behaviour of other > text-editors. Exactly the same reasoning was presented in arguments against turning on `transient-mark-mode' by default. That change took decades. I expect that turning on `delete-selection-mode' by default (in effect, the other half of the same general change) will also take decades. I'm convinced it will happen, but perhaps after some of us are long gone. ;-) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 15:35 ` Drew Adams @ 2018-09-07 16:16 ` Yuri Khan 0 siblings, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-07 16:16 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, Phil Sainty, Noam Postavsky, Emacs developers, Eli Zaretskii, Phillip Lord On Fri, Sep 7, 2018 at 10:37 PM Drew Adams <drew.adams@oracle.com> wrote: > Exactly the same reasoning was presented in arguments against > turning on `transient-mark-mode' by default. My experience with other editors says the following three features are closely related. (The terminology varies from editor to editor, of course.) 1a) Region selection is persistent. You can mark a region, then move point outside of it and it stays highlighted and active. 1b) Region selection is transient. As soon as you move point in a way other than extending selection, it is deactivated. 2a) Newly entered text is inserted at point without affecting the selected region, whether or not it is active. Backspace and Delete keys affect the characters before and after point. 2b) Newly entered text replaces the selected region. Backspace and Delete keys delete the selected region. 3a) You select a region by pressing a key (or key combination or sequence), at one end, then moving point to the other end and pressing another key there. 3b) You select a region by moving point with Shift held down. Many “classic” editors had [1a, 2a, 3a]. Most “modern” editors have [1b, 2b, 3b]. These two combinations are consistent and useful. Mixing and matching may feel weird and/or invite mistakes. E.g., mixing 1a with 2b, you can have a persistent region, then move point so that you no longer see the region, so you effectively forget you have an active region. Then, typing new text and having it replace the region is surprising, in a bad way. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 6:47 ` Eli Zaretskii 2018-09-07 9:18 ` delete-selection-mode as default hw 2018-09-07 9:40 ` delete-selection-mode as default (WAS: Some developement questions) Phil Sainty @ 2018-09-07 19:01 ` tomas 2018-09-07 19:23 ` Drew Adams 2018-09-07 20:33 ` delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 2018-09-09 13:45 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie ` (2 subsequent siblings) 5 siblings, 2 replies; 245+ messages in thread From: tomas @ 2018-09-07 19:01 UTC (permalink / raw) To: emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Sep 07, 2018 at 09:47:52AM +0300, Eli Zaretskii wrote: [...] > Feel free to start a user poll, though: if it turns out I'm the only > one who thinks delete-selection-mode is inappropriate in programming > modes [...] This is from a seat far back in the peanut gallery, but no, Eli, you aren't the only one :-) I know this "delete selection on typing" behaviour, and I dislike it with passion. Typical case of "two cultures", I guess. Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAluSyw8ACgkQBcgs9XrR2kYM/QCdGIOa/kwS1QS3eXcsTOBa88B0 TaMAnRfUuD1fveUU2Ng7ZLEoFBxoaSk3 =hoZm -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 19:01 ` tomas @ 2018-09-07 19:23 ` Drew Adams 2018-09-07 20:28 ` tomas 2018-09-07 20:33 ` delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-07 19:23 UTC (permalink / raw) To: tomas, emacs-devel > Typical case of "two cultures", I guess. Really? What two cultures are those? Different default values of `delete-selection-mode'? Or are you trying to suggest some wider difference that is indicated/reflected by that difference? IMHO, this is only about that specific difference. I doubt that you will find meaningful alignment/correlation between views on that question and other views, including other views about editing or Emacs. I wouldn't advise generalizing this to include pro/con mouse, menus, key bindings, GUI, visual lines, fonts, OS,... ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 19:23 ` Drew Adams @ 2018-09-07 20:28 ` tomas 2018-09-08 23:19 ` delete-selection-mode as default Juri Linkov 0 siblings, 1 reply; 245+ messages in thread From: tomas @ 2018-09-07 20:28 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1027 bytes --] On Fri, Sep 07, 2018 at 12:23:07PM -0700, Drew Adams wrote: > > Typical case of "two cultures", I guess. > > Really? What two cultures are those? > > Different default values of `delete-selection-mode'? > Or are you trying to suggest some wider difference > that is indicated/reflected by that difference? I think you are reading too much into what I wrote, but I'm not sure. > IMHO, this is only about that specific difference. I doubt > that you will find meaningful alignment/correlation between > views on that question and other views, including other views > about editing or Emacs. I guess there's some alignment. I always feel awkward when editing in a browser, for example. It reminds me fatally of Notepad, back then. And it's not just selection handling. But hey, everyone swings differently. > I wouldn't advise generalizing this to include pro/con > mouse, menus, key bindings, GUI, visual lines, fonts, OS,... I think it's more subtle, but somehow related, yes. Cheers -- t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 20:28 ` tomas @ 2018-09-08 23:19 ` Juri Linkov 2018-09-09 8:02 ` tomas 0 siblings, 1 reply; 245+ messages in thread From: Juri Linkov @ 2018-09-08 23:19 UTC (permalink / raw) To: tomas; +Cc: emacs-devel >> IMHO, this is only about that specific difference. I doubt >> that you will find meaningful alignment/correlation between >> views on that question and other views, including other views >> about editing or Emacs. > > I guess there's some alignment. I always feel awkward when > editing in a browser, for example. It reminds me fatally > of Notepad, back then. And it's not just selection handling. > > But hey, everyone swings differently. To me, delete-selection-mode is an optimization, it saves keystrokes allowing to type less - I don't need to type DEL to delete an old region before replacing it with new text. Also jumping to the previous mark is easy with C-u C-SPC when there is no need to select the region as C-x C-x does. And I never make a mistake when I see that the region is active to not replace it mistakenly. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 23:19 ` delete-selection-mode as default Juri Linkov @ 2018-09-09 8:02 ` tomas 0 siblings, 0 replies; 245+ messages in thread From: tomas @ 2018-09-09 8:02 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Sep 09, 2018 at 02:19:31AM +0300, Juri Linkov wrote: > >> IMHO, this is only about that specific difference. I doubt > >> that you will find meaningful alignment/correlation between > >> views on that question and other views, including other views > >> about editing or Emacs. > > > > I guess there's some alignment. I always feel awkward when > > editing in a browser, for example. It reminds me fatally > > of Notepad, back then. And it's not just selection handling. > > > > But hey, everyone swings differently. > > To me, delete-selection-mode is an optimization, it saves keystrokes > allowing to type less [...] What most people saying "_my_ way is better" tend to forget is context: you've adapted your micro workflow to your tools and viceversa. So if you say "it saves keystrokes", this is from the (very limited) perspective of *your* context. People preferring "the other" toolset will have planned the whole thing differently, they'll use selection in subtly different ways, etc. etc. All generalizations suck. Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAluU04kACgkQBcgs9XrR2kblDACeKFWoDz3wAx0UTMgzdjEcgDTJ j+gAoIBif240c76e4v0L+QLfyTpW8ADP =/xWu -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 19:01 ` tomas 2018-09-07 19:23 ` Drew Adams @ 2018-09-07 20:33 ` Noam Postavsky 2018-09-07 21:31 ` tomas 1 sibling, 1 reply; 245+ messages in thread From: Noam Postavsky @ 2018-09-07 20:33 UTC (permalink / raw) To: tomas; +Cc: Emacs developers On 7 September 2018 at 15:01, <tomas@tuxteam.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Sep 07, 2018 at 09:47:52AM +0300, Eli Zaretskii wrote: > > [...] > >> Feel free to start a user poll, though: if it turns out I'm the only >> one who thinks delete-selection-mode is inappropriate in programming >> modes [...] > > This is from a seat far back in the peanut gallery, but no, Eli, you > aren't the only one :-) > > I know this "delete selection on typing" behaviour, and I dislike it > with passion. But do you think it's ok for text (non-programming) buffers? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 20:33 ` delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky @ 2018-09-07 21:31 ` tomas 2018-09-10 8:01 ` delete-selection-mode as default Robert Pluim 0 siblings, 1 reply; 245+ messages in thread From: tomas @ 2018-09-07 21:31 UTC (permalink / raw) To: Emacs developers [-- Attachment #1: Type: text/plain, Size: 546 bytes --] On Fri, Sep 07, 2018 at 04:33:11PM -0400, Noam Postavsky wrote: > On 7 September 2018 at 15:01, <tomas@tuxteam.de> wrote: [...] > > I know this "delete selection on typing" behaviour, and I dislike it > > with passion. > > But do you think it's ok for text (non-programming) buffers? In my case (and I _know_ it's very personal, I wouldn't want to impose my taste on anyone!) no: programming and text are more or less equivalent (sometimes I try to mix both). But then, I'm also a "point-to-focus" type =:-o Cheers -- t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-07 21:31 ` tomas @ 2018-09-10 8:01 ` Robert Pluim 2018-09-10 8:09 ` tomas 0 siblings, 1 reply; 245+ messages in thread From: Robert Pluim @ 2018-09-10 8:01 UTC (permalink / raw) To: tomas; +Cc: Emacs developers [-- Attachment #1: Type: text/plain, Size: 623 bytes --] tomas@tuxteam.de writes: > On Fri, Sep 07, 2018 at 04:33:11PM -0400, Noam Postavsky wrote: >> On 7 September 2018 at 15:01, <tomas@tuxteam.de> wrote: > > [...] > >> > I know this "delete selection on typing" behaviour, and I dislike it >> > with passion. >> >> But do you think it's ok for text (non-programming) buffers? > > In my case (and I _know_ it's very personal, I wouldn't want to > impose my taste on anyone!) no: programming and text are more > or less equivalent (sometimes I try to mix both). Typing is typing, indeed. > But then, I'm also a "point-to-focus" type =:-o Heretic! ;-) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 8:01 ` delete-selection-mode as default Robert Pluim @ 2018-09-10 8:09 ` tomas 0 siblings, 0 replies; 245+ messages in thread From: tomas @ 2018-09-10 8:09 UTC (permalink / raw) To: emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Sep 10, 2018 at 10:01:10AM +0200, Robert Pluim wrote: > tomas@tuxteam.de writes: [...] > > But then, I'm also a "point-to-focus" type =:-o > > Heretic! ;-) Yes, we are those for whom the XFlame screen saver was made... ;-) - -- t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAluWJtAACgkQBcgs9XrR2kYqqACcDPWBA10mqHtbm0VDAsG2pVln c2oAn3cn8lR+j5JwJF/LUpoI/jiXxTkM =ZZ46 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 6:47 ` Eli Zaretskii ` (2 preceding siblings ...) 2018-09-07 19:01 ` tomas @ 2018-09-09 13:45 ` Alan Mackenzie 2018-09-09 14:22 ` Clément Pit-Claudel ` (2 more replies) 2018-09-09 20:39 ` delete-selection-mode as default (WAS: Some developement questions) Joost Kremers [not found] ` <<87sh2ih0bp.fsf@fastmail.fm> 5 siblings, 3 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-09 13:45 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, Noam Postavsky, emacs-devel, drew.adams, phillip.lord Hello, Eli. On Fri, Sep 07, 2018 at 09:47:52 +0300, Eli Zaretskii wrote: > Feel free to start a user poll, though: if it turns out I'm the only > one who thinks delete-selection-mode is inappropriate in programming > modes, we can make it the default; I can easily turn it off in my > configuration. Though I would urge people to actually try this in > programming modes before responding, and in any case the poll should > request to provide the major modes used with the responses. No, you're not the only disliker of d-s-mode. I utterly detest it, to the point that Emacs's lack of this feature was one of the things which attracted me to Emacs in the first place. At last, an editing program with a rational, well thought out interface! A thing I hated about these other programs was that I could have spent a long time building up a (highlighted) region in them, only to lose it irretrievably on carelessly typing an arrow key without <shift>. As a result of things like that, I was never able to relax whilst using these programs - I had to remain hyper-alert to avoid the above sort of lossage. I appreciate that Emacs's d-s-mode doesn't suffer all these drawbacks, but it does suffer some of them. I believe delete-selection-mode is objectively bad; deleting/killing potentially large areas of text should not occur as a side effect of something whose main action is smalll (like inserting a single character). As well as being bad UI, it violates the "do one thing and do it well" principle. In the current polling exercise, I would urge those interpreting the responses to take account not merely of the numbers of supporters/detractors but the strength of feeling behind those responses. I've seen several such that strongly dislike d-s-mode, but haven't seen any saying "I utterly detest editors lacking delete-selection-mode". That suggests to me that we should not enable this mode by default. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 13:45 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie @ 2018-09-09 14:22 ` Clément Pit-Claudel 2018-09-09 15:12 ` Drew Adams 2018-09-10 11:42 ` delete-selection-mode as default Filipp Gunbin 2 siblings, 0 replies; 245+ messages in thread From: Clément Pit-Claudel @ 2018-09-09 14:22 UTC (permalink / raw) To: emacs-devel On 2018-09-09 09:45, Alan Mackenzie wrote: > In the current polling exercise, I would urge those interpreting the > responses to take account not merely of the numbers of > supporters/detractors but the strength of feeling behind those responses. Careful with this though. It's easy to misread a moderate response backed by strong feelings and classify it as "don't care too much". > I've seen several such that strongly dislike d-s-mode, but haven't seen > any saying "I utterly detest editors lacking delete-selection-mode". > That suggests to me that we should not enable this mode by default. Here's a different take on the same observation: people who don't like delete-selection-mode seem to care very much, so we can assume they'll make the effort to turn it off. Conversely, people who do like it seem to like it only a little, so we can't assume they'll trouble themselves to find the right setting and toggle it. Hence, it should be enabled by default :) I don't trust user polls much, FWIW. They're heavily biased, and people are not good judges of what makes them productive. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 13:45 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 2018-09-09 14:22 ` Clément Pit-Claudel @ 2018-09-09 15:12 ` Drew Adams 2018-09-10 11:42 ` delete-selection-mode as default Filipp Gunbin 2 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-09 15:12 UTC (permalink / raw) To: Alan Mackenzie, Eli Zaretskii Cc: hw, spacibba, emacs-devel, Noam Postavsky, phillip.lord > No, you're not the only disliker of d-s-mode. I utterly detest it, to > the point that Emacs's lack of this feature was one of the things which > attracted me to Emacs in the first place. At last, an editing program > with a rational, well thought out interface! A thing I hated about these > other programs was that I could have spent a long time building up a > (highlighted) region in them, only to lose it irretrievably on carelessly > typing an arrow key without <shift>. Why "irretrievably"? What happens if you hit `C-w' by mistake? Do you lose the cut text irretrievably? > I appreciate that Emacs's d-s-mode doesn't suffer all these > drawbacks, but it does suffer some of them. > > I believe delete-selection-mode is objectively bad; deleting/killing > potentially large areas of text should not occur as a side effect of > something whose main action is smalll (like inserting a single > character). You conceive of the action in question as being just to insert a character. But if the region is active and d-s-m is on then the action is replace the region with the character. Who controls whether the action is to do one or the other? You do, by activating or not activating the region. Your choice. Nothing requires you to activate the region and then insert the char. You can insert it without activating the region first. With `transient-mark-mode' came the concept and behavior of an active region. Emacs is great by having a region that can be either inactive or active. You can still use an inactive region (as I'm sure you know and do), so perhaps "active" is a bit of a misnomer. The point of activating the region is to act on it. One way of acting on it is to replace it, and when d-s-m is on that can happen by yanking or typing replacement text. Who controls whether the region is active? You do. Who controls whether and how to act on the active region? You do. Who controls whether d-s-m is on or off? You do. If someone wants to complain about a command unnecessarily doing two things ("side effect") then s?he could start by blaming `C-x C-x'. Why does it not only swap point and mark but also activate the region? The answer, no doubt, is that someone (who introduced t-m-m and region "activation") thought that's handy behavior (saves a keystroke). Exactly the same kind of handiness comes from d-s-m performing an implicit `C-w' (for most commands, although that's configurable per command). > As well as being bad UI, it violates the "do one thing and > do it well" principle. Tell that to `C-x C-x' ;-). And to any number of other Emacs commands - maybe most! > In the current polling exercise, I would urge those interpreting the > responses to take account not merely of the numbers of > supporters/detractors but the strength of feeling behind those responses. > I've seen several such that strongly dislike d-s-mode, but haven't seen > any saying "I utterly detest editors lacking delete-selection-mode". > That suggests to me that we should not enable this mode by default. Where's the poll, BTW? I fully expect support for d-s-m to lose the vote at this point (but not in a few decades ;-)), but I support taking a poll. It should of course be a user poll, not just a poll of this mailing list. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 13:45 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 2018-09-09 14:22 ` Clément Pit-Claudel 2018-09-09 15:12 ` Drew Adams @ 2018-09-10 11:42 ` Filipp Gunbin 2 siblings, 0 replies; 245+ messages in thread From: Filipp Gunbin @ 2018-09-10 11:42 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel On 09/09/2018 13:45 +0000, Alan Mackenzie wrote: > Hello, Eli. > > On Fri, Sep 07, 2018 at 09:47:52 +0300, Eli Zaretskii wrote: >> Feel free to start a user poll, though: if it turns out I'm the only >> one who thinks delete-selection-mode is inappropriate in programming >> modes, we can make it the default; I can easily turn it off in my >> configuration. Though I would urge people to actually try this in >> programming modes before responding, and in any case the poll should >> request to provide the major modes used with the responses. > > No, you're not the only disliker of d-s-mode. I utterly detest it, to > the point that Emacs's lack of this feature was one of the things which > attracted me to Emacs in the first place. At last, an editing program > with a rational, well thought out interface! A thing I hated about these > other programs was that I could have spent a long time building up a > (highlighted) region in them, only to lose it irretrievably on carelessly > typing an arrow key without <shift>. As a result of things like that, I > was never able to relax whilst using these programs - I had to remain > hyper-alert to avoid the above sort of lossage. Much the same for me. I think that if we ever make d-s-m on by default, we should add a line or two about it in tutorial. And also about transient-mark-mode (and maybe visual-line-mode). It's especially new users (for whom the tutorial is designed) that might be unaware of different ways of handling selection. They may not like "the old way", but at least they'll know about it. Filipp ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 6:47 ` Eli Zaretskii ` (3 preceding siblings ...) 2018-09-09 13:45 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie @ 2018-09-09 20:39 ` Joost Kremers 2018-09-09 22:24 ` Drew Adams 2018-09-10 7:05 ` delete-selection-mode as default (WAS: Some developement questions) Eli Zaretskii [not found] ` <<87sh2ih0bp.fsf@fastmail.fm> 5 siblings, 2 replies; 245+ messages in thread From: Joost Kremers @ 2018-09-09 20:39 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, Noam Postavsky, emacs-devel, drew.adams, phillip.lord On Fri, Sep 07 2018, Eli Zaretskii wrote: > Feel free to start a user poll, though: if it turns out I'm the > only > one who thinks delete-selection-mode is inappropriate in > programming > modes, we can make it the default; I can easily turn it off in > my > configuration. Though I would urge people to actually try this > in > programming modes before responding, and in any case the poll > should > request to provide the major modes used with the responses. My €0.02: I'd say this thread has already shown that a poll won't be of much help here. Whether you prefer `delete-selection-mode` on or off really depends on your workflow, and de fluminibus operis non est disputandum, to paraphrase a well-known adage. So I'd suggest that any decision regarding the default value of `delete-selection-mode` should not be based on such considerations. Rather, two questions should be considered: a) "Would leaving it off scare away potential new users?" and b) "Would turning it on obscure an option that is potentially useful to at least a subset of new users?" I suspect the answer to both questions is "yes". If you're trying out a new piece of software, any behaviour that differs from what you're used to (after all, what `delete-selection-mode` does is standard behaviour in most software out there and most new users will take it for granted) is off-putting and might lead you to give up, especially if it's not immediately clear why the behaviour is different. On the other hand, if `delete-selection-mode` is on by default, most, if not all, new users will never even consider the possibility that Emacs has the option to disable it and that that might actually fit their workflow better. All in all, despite having `delete-selection-mode` on myself, I think it should be kept off by default, but with a note in the tutorial somewhere that it can be turned on. Or perhaps it could be made such that the first time a new user types a character with an active region, a message pops up saying that Emacs doesn't normally overwrite an active region, with an explanation why and a note that it can be configured to do so if desired. It would be similar to how disabled commands work (though IIUC it couldn't be implemented easily as a disabled command, so adding such a mechanism might not be trivial). -- Joost Kremers Life has its moments ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 20:39 ` delete-selection-mode as default (WAS: Some developement questions) Joost Kremers @ 2018-09-09 22:24 ` Drew Adams 2018-09-10 3:08 ` Phil Sainty ` (3 more replies) 2018-09-10 7:05 ` delete-selection-mode as default (WAS: Some developement questions) Eli Zaretskii 1 sibling, 4 replies; 245+ messages in thread From: Drew Adams @ 2018-09-09 22:24 UTC (permalink / raw) To: Joost Kremers, Eli Zaretskii Cc: hw, spacibba, emacs-devel, Noam Postavsky, phillip.lord I agree that a poll of this list is not a great guide (for this question and many others). > Two questions should be considered: a) "Would leaving it off scare > away potential new users?" and b) "Would turning it on obscure an > option that is potentially useful to at least a subset of new users?" I must have missed what that potentially useful option is. > On the other hand, if `delete-selection-mode` is on by default, > most, if not all, new users will never even consider the > possibility that Emacs has the option to disable it and that > that might actually fit their workflow better. This too hints at some advantage to having it off. The only argument I saw here (unless I've forgotten already) in favor of it being off (by default or not) is that when it is on a user (new or old) can too easily accidentally delete text. (Some added "irretrievably", but I haven't seen that claim supported yet.) That advantage would seem to be something that would most benefit new users, no? But the claim has been that new users are more used to the on, not the off, behavior. So again, what's the advantage to it being off? (It's not a rhetorical question.) Is there really some useful "option" that its being off offers? Does that give you additional choice or control? ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 22:24 ` Drew Adams @ 2018-09-10 3:08 ` Phil Sainty 2018-09-10 3:17 ` Drew Adams 2018-09-10 5:15 ` Bingo ` (2 subsequent siblings) 3 siblings, 1 reply; 245+ messages in thread From: Phil Sainty @ 2018-09-10 3:08 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord On 2018-09-10 10:24, Drew Adams wrote: > The only argument I saw here (unless I've forgotten already) > in favor of it being off (by default or not) is that when it is on > a user (new or old) can too easily accidentally delete text. > > (Some added "irretrievably", but I haven't seen that claim > supported yet.) Undo isn't *necessarily* enabled in all buffers? i.e. `buffer-disable-undo'. That's not so common, but IIRC some buffers are set that way by default? -Phil ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-10 3:08 ` Phil Sainty @ 2018-09-10 3:17 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-10 3:17 UTC (permalink / raw) To: Phil Sainty Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord > > The only argument I saw here (unless I've forgotten already) > > in favor of it being off (by default or not) is that when it is on > > a user (new or old) can too easily accidentally delete text. > > > > (Some added "irretrievably", but I haven't seen that claim > > supported yet.) > > Undo isn't *necessarily* enabled in all buffers? > i.e. `buffer-disable-undo'. > > That's not so common, but IIRC some buffers are set that way by > default? Yes, good point. The same problem will exist for accidental `C-w', but yes. Most delete-selection deletions are kills, so another retrieval possibility is `C-y'. But I'm sure there are cases where text could be lost. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 22:24 ` Drew Adams 2018-09-10 3:08 ` Phil Sainty @ 2018-09-10 5:15 ` Bingo 2018-09-10 13:34 ` delete-selection-mode as default Stefan Monnier 2018-09-10 8:46 ` hw 2018-09-10 18:16 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 3 siblings, 1 reply; 245+ messages in thread From: Bingo @ 2018-09-10 5:15 UTC (permalink / raw) To: Drew Adams Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord On Sun, 9 Sep 2018 15:24:30 -0700 (PDT) Drew Adams <drew.adams@oracle.com> wrote: > So again, what's the advantage to it being off? (It's not a > rhetorical question.) Is there really some useful "option" > that its being off offers? Does that give you additional > choice or control? > Hi Drew, You might be comfortable with Emacs undo. What is your opinion on new users' comfort level with it ? The advantage with d-s-m being off is it leads to less accidental deletions, hence less need to undo. I have 8000 hours of Emacs under my belt and I can manage only evil-mode's simplified undo/redo in spite of its weakness. Emacs should not half-ass the embracing of new users. Either go the full hog - CUA, C-z undo, C-y redo (real redo), C-s save, C-a select all, shift-selection-mode, right-click context menu. Only then there is any hope for the non-manual-readers. If only d-s-m is enabled, and there is an accidental selected text deletion - user would try C-z : which would weirdly vanish their window. After frantically finding the window back, they would try C-y for redo to correct anything this C-z might have done. C-y would paste their accidentally killed selected text at a place where their cursor found itself while they were confused. thanks ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 5:15 ` Bingo @ 2018-09-10 13:34 ` Stefan Monnier 0 siblings, 0 replies; 245+ messages in thread From: Stefan Monnier @ 2018-09-10 13:34 UTC (permalink / raw) To: emacs-devel > Emacs should not half-ass the embracing of new users. Either go the > full hog - CUA, C-z undo, C-y redo (real redo), C-s save, C-a select > all, shift-selection-mode, right-click context menu. Only then there > is any hope for the non-manual-readers. There are two separate issues: 1- what is the best UI (according to us) 2- what we should do for new users As maintainer, I used (1) rather than (2) as my guide to choose the default settings. Whether the best UI has d-s-m enabled or disabled is under discussion. My opinion is that regarding point (1) d-s-m doesn't matter much: both choices are about equally good. So I'd favor enabling it (after fixing its implementation) on the grounds that it's what other UIs do. But just because for this particular choice, I/we end up deciding of the default value based on (2), that doesn't mean that it should be the case for everything else. Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 22:24 ` Drew Adams 2018-09-10 3:08 ` Phil Sainty 2018-09-10 5:15 ` Bingo @ 2018-09-10 8:46 ` hw 2018-09-10 18:16 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 3 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-10 8:46 UTC (permalink / raw) To: Drew Adams Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: > [...] > The only argument I saw here (unless I've forgotten already) > in favor of it being off (by default or not) is that when it is on > a user (new or old) can too easily accidentally delete text. > > (Some added "irretrievably", but I haven't seen that claim > supported yet.) This is a misunderstanding. You need to distinguish between the selection itself and the contents of the selection. The contents usually aren't likely to get lost forever. The selection itself *is* lost irretrievably when you make a movement without holding the key (like Shift or Ctrl) you need to press to select. So far, I've never seen a software that had an undo for this, and it has annoyed me many times. It's another example for the design flaw of making a mistake worse rather than protecting the user from it. > [...] > So again, what's the advantage to it being off? (It's not a > rhetorical question.) Is there really some useful "option" > that its being off offers? Does that give you additional > choice or control? That depends on what you consider as "off". Under "normal" circumstances, "off" seems to mean that backspace deletes a region only when it is active, and that other keystrokes tend to deactivate an active region before they insert themselves into the buffer. That means it's not really off. If it was really off, backspace would not delete a region when it's active, and other keystrokes would neither deactivate an active region, nor insert themselves into the buffer, but they would make Emacs beep. So "really off" would give the user maximum protection against mistakes that could otherwise lead to loosing the selection itself, its contents or both. That is an advantage. The other advantage is that users may be glad to see a behaviour which they end up finding better and might have never discovered if it wasn't the default. When more users appreciate it, they might urge the developers of other software to implement something similar. In any case, the whole concept of regions could use an overhaul. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 22:24 ` Drew Adams ` (2 preceding siblings ...) 2018-09-10 8:46 ` hw @ 2018-09-10 18:16 ` Alan Mackenzie 2018-09-10 18:35 ` Clément Pit-Claudel 2018-09-10 20:36 ` Drew Adams 3 siblings, 2 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-10 18:16 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord Hello, Drew. On Sun, Sep 09, 2018 at 15:24:30 -0700, Drew Adams wrote: > I agree that a poll of this list is not a great guide (for this question > and many others). > > Two questions should be considered: a) "Would leaving it off scare > > away potential new users?" and b) "Would turning it on obscure an > > option that is potentially useful to at least a subset of new users?" > I must have missed what that potentially useful option is. The option is having delete-selection-mode turned off, which is a useful option in itself. Actually, I'm not sure what the use of d-s-mode actually is. I don't recall anyone here advocating it on some intrinsic merits, only "because everybody else does it", which I've never found a convincing argument for anything in Emacs. > > On the other hand, if `delete-selection-mode` is on by default, > > most, if not all, new users will never even consider the > > possibility that Emacs has the option to disable it and that > > that might actually fit their workflow better. > This too hints at some advantage to having it off. > The only argument I saw here (unless I've forgotten already) > in favor of it being off (by default or not) is that when it is on > a user (new or old) can too easily accidentally delete text. > (Some added "irretrievably", but I haven't seen that claim > supported yet.) That was me, the complete phrase was "irretrievably lost" and I carefully outlined what was being lost and where. In summary, it was a carefully and painstakingly constructed region, and what was being lost by a careless movement key without <shift> was the point and mark of the highlighted region, not its contents. Furthermore it was in programs which aren't Emacs. > That advantage would seem to be something that would > most benefit new users, no? But the claim has been that > new users are more used to the on, not the off, behavior. > So again, what's the advantage to it being off? (It's not a > rhetorical question.) Is there really some useful "option" > that its being off offers? Does that give you additional > choice or control? Yes. It enables you to type onto the end of a (highlighted) region without being distracted by first having to do something to remove the highlighting, or more likely without first having to use `undo' to get your region back again, followed by unhighlighting it followed by typing the character you want to append. Personally, it scarcely affects me because I run with transient-mark-mode disabled, but I still occasionally get unwanted highlighting of regions for some reason. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-10 18:16 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie @ 2018-09-10 18:35 ` Clément Pit-Claudel 2018-09-10 19:19 ` Alan Mackenzie 2018-09-10 20:36 ` Drew Adams 1 sibling, 1 reply; 245+ messages in thread From: Clément Pit-Claudel @ 2018-09-10 18:35 UTC (permalink / raw) To: Alan Mackenzie, Drew Adams Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord On 2018-09-10 14:16, Alan Mackenzie wrote: > Actually, I'm not sure what the use of d-s-mode actually is. I > don't recall anyone here advocating it on some intrinsic merits I did, in a previous message :) See below: > On 2018-09-07 05:18, hw wrote: >> When a selection is active, why would anyone assume that typing an >> arbitrary letter is supposed to replace the entire selection, or >> to disable it? > > Out of experience, mostly. When almost every other program you use > besides Emacs behaves that way, it's easy to assume that Emacs will > behave the same way. > >> Allowing that to happen is simply a design flaw, or an oversight. > > I prefer to think of it as a very convenient feature. For example, > as I typed this email, I first wrote "as I composed" instead of "as I > typed", pressed Control+Shift+Left Arrow, and pressed "typed". > Similarly, I had first written "I call it" instead of "I prefer to > think of it", and the way I changed one into the other was to select > "call it" and type "prefer to think of it as". ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-10 18:35 ` Clément Pit-Claudel @ 2018-09-10 19:19 ` Alan Mackenzie 0 siblings, 0 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-10 19:19 UTC (permalink / raw) To: Clément Pit-Claudel Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Hello, Clément. On Mon, Sep 10, 2018 at 14:35:17 -0400, Clément Pit-Claudel wrote: > On 2018-09-10 14:16, Alan Mackenzie wrote: > > Actually, I'm not sure what the use of d-s-mode actually is. I > > don't recall anyone here advocating it on some intrinsic merits > I did, in a previous message :) See below: Acknowledged, thanks. > > On 2018-09-07 05:18, hw wrote: > >> When a selection is active, why would anyone assume that typing an > >> arbitrary letter is supposed to replace the entire selection, or > >> to disable it? > > Out of experience, mostly. When almost every other program you use > > besides Emacs behaves that way, it's easy to assume that Emacs will > > behave the same way. This is the "do it because everybody else does" bit. I don't think it's a sound design principle, particularly for Emacs. > >> Allowing that to happen is simply a design flaw, or an oversight. I agree, because .... > > I prefer to think of it as a very convenient feature. For example, > > as I typed this email, I first wrote "as I composed" instead of "as I > > typed", pressed Control+Shift+Left Arrow, and pressed "typed". > > Similarly, I had first written "I call it" instead of "I prefer to > > think of it", and the way I changed one into the other was to select > > "call it" and type "prefer to think of it as". .... the degree of inconvenience in first having to type C-w, which is predictable and goes easily to the finger memory is minimal, certainly when compared with the shock and pain of having an arbitrary sized region killed without warning. IMAO, anyway. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-10 18:16 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 2018-09-10 18:35 ` Clément Pit-Claudel @ 2018-09-10 20:36 ` Drew Adams 2018-09-11 22:34 ` delete-selection-mode as default hw 2018-09-11 23:30 ` Juri Linkov 1 sibling, 2 replies; 245+ messages in thread From: Drew Adams @ 2018-09-10 20:36 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord > Actually, I'm not sure what the use of d-s-mode actually is. I don't > recall anyone here advocating it on some intrinsic merits, only "because > everybody else does it", which I've never found a convincing argument for > anything in Emacs. Minor convenience. If the region is active then typing or yanking replaces it - no need to use `C-w' first. That's all. Not a big deal either way, IMO (as Stefan has said). When the region is active you can do things to it or with it. Otherwise, there is _no reason to activate it_. If it is active, one of the things you often want to do with it is delete it or replace it. We tend to do that often, and d-s-m mode makes that easier/quicker. Nothing more. Think of overwrite mode (bound to <insert>) versus inserting and having to use `C-d' before or after each char you type. No, of course you wouldn't use `C-d' for each char, but that's the idea. The more often you had to compensate for insertion by deleting what was there beforehand, the more you might find overwrite mode handy. If you often replace selected text then not bothering to use `C-w' first can be handy. Select some text, then type or yank to replace it. > That was me, the complete phrase was "irretrievably lost" and I carefully > outlined what was being lost and where. In summary, it was a carefully > and painstakingly constructed region, and what was being lost by a > careless movement key without <shift> was the point and mark of the > highlighted region, not its contents. Furthermore it was in programs > which aren't Emacs. I see. I never use shift-selection. Dunno whether that's relevant - probably not. > It enables you to type onto the end of a (highlighted) region > without being distracted by first having to do something to remove the > highlighting, Yes. If someone doesn't want to do something to/with the active region then it shouldn't be active. `C-g' deactivates it. In a way, d-s-m or not d-s-m is a bit about C-g versus C-w. Which do you need to use more often, C-w (without d-s-m) or C-g (with d-s-m). That might be one way of looking at the choice people make. > or more likely without first having to use `undo' to get > your region back again, followed by unhighlighting it followed by typing > the character you want to append. You shouldn't be losing the region in the first place. You shouldn't need to undo or unhighlight. If you accidentally activated the region, and you want to deactivate it, C-g should take care of that. I'm guessing this comes back to the `C-x C-x' activation of the region. With that turned off, i.e., with `C-x C-x' just swapping point and mark like it did in the old days, I'm guessing you will never have an active region that bothers you - with or without d-s-m. But that's just a guess. Users should not get an active region when they don't want it, i.e., when they don't want to act on the region. And they should be able to easily get an active region when they do want to act on the region. If we're not yet supporting that well then that's where the improvement should come first, I think. The only time I get an active region when I don't want it is if I activated it thinking I was going to do something with it, and then I changed my mind (so I use C-g). I suspect that things are very different for you, and I suspect it is because of `C-x C-x' activating the region even though you have no intention of acting on it. An active region is perhaps more of a bother than an aid, for someone who never (or rarely) wants to act on it. I feel like region activation by `C-x C-x' was maybe foisted on people who never wanted or expected to do anything with an active region. If so, they've probably been silently tolerating it all these years. And yes, I can see why, if that's the case, they might dread moving to d-s-m. I think we've finally identified the real problem underlying such anxiety as being region activation by `C-x C-x'. Take that away and I think folks who don't want to use d-s-m will be fine. For folks who do want to use d-s-m, region activation by `C-x C-x' is handy. But it's not necessary. In any case, region activation has nothing inherently to do with swapping point and mark. Maybe someone who detests d-s-m could spend a few minutes with it turned on but with `C-x C-x' bound to a command that just swaps point and mark without activating the region. My guess is that if that were the default behavior it might be OK for most people. D-s-m, but without Emacs activating the region each time you use `C-x C-x'. No undesired region activation, so no unexpected d-s-m action. And of course, for someone who really wants to take advantage of d-s-m we still would offer the current, region-activating `C-x C-x' command. But we should also offer a command that just activates the region, nothing more. By default that would be unbound (or at most bound to something other than `C-x C-x'). > Personally, it scarcely affects me because I run with transient-mark-mode > disabled, There you go. That's probably the right thing to do for someone who doesn't want d-s-m behavior. But then do you have to monkey around with temporary t-m-m, or do you just not bother, ever, with having an active region? I'm guessing the latter. > but I still occasionally get unwanted highlighting of regions > for some reason. Probably from accidental temporary t-m-m, would be my guess. (That's something else I never use.) Or maybe from some other commands that activate the region? I think that if t-m-m is off then most commands (e.g. query-replace) do not try to activate the region (which is correct behavior - an active region makes sense only for t-m-m/d-s-m). In sum, having d-s-m + t-m-m both on is good for folks like me. Having them both off is maybe good for folks like you. Having t-m-m on and d-s-m off might not be the best thing. But that's the default behavior. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 20:36 ` Drew Adams @ 2018-09-11 22:34 ` hw 2018-09-12 0:04 ` Drew Adams 2018-09-12 13:16 ` Alan Mackenzie 2018-09-11 23:30 ` Juri Linkov 1 sibling, 2 replies; 245+ messages in thread From: hw @ 2018-09-11 22:34 UTC (permalink / raw) To: Drew Adams Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: > [...] > > Users should not get an active region when they don't > want it, i.e., when they don't want to act on the region. > And they should be able to easily get an active region > when they do want to act on the region. Highlighting regions should be separated from whether they are active or not, and I don't want hidden regions, either. Currently even when a region is not active (it is a hidden region because it is not highlighted), you can do something with it, so users always get an "active" region even when they don't want one. It's only a bit less active than it is when it is highlighted. > [...] > I suspect that things are very different for you, and I > suspect it is because of `C-x C-x' activating the region > even though you have no intention of acting on it. Exchanging point and mark is a purely navigational thing, and somehow the activation and deactivation of hidden(!) regions which may have been modified because point may have moved since a region was selected last time(!) has been mixed into that. That is ill advised. > [...] > I feel like region activation by `C-x C-x' was maybe foisted > on people who never wanted or expected to do anything > with an active region. Do you mean they would rather do things with hidden regions? I never want to do that. > In any case, region activation has nothing inherently to do with > swapping point and mark. Right, so why not separate navigational functions from highlighting and regions? Use point and mark purely for navigation, set a selection-start-marker with C-spc and a selection-end-marker with another C-spc (or whatever key binding is appropriate for it). The region is between these markers, and you can have multiple regions in the same buffer. Do something with a region, and its markers are forgotten unless you use a prefix. Have a key binding to jump around between the regions in a buffer, and you can tell Emacs with which of them you want to do something by moving point into it. If you want to do the same thing with multiple regions, move point into one after another and make them "sticky" for operation, or mark them right after selecting them. That might make a lot of things much simpler, and we wouldn't have to feel uneasy about the hidden regions all the time. > [...] > There you go. That's probably the right thing to do for > someone who doesn't want d-s-m behavior. But then > do you have to monkey around with temporary t-m-m, > or do you just not bother, ever, with having an active > region? I'm guessing the latter. It can make it difficult to do things supposed to be limited to a region. I might disable t-m-m if I could see what I have selected with it disabled and monkey. I never use C-x C-x, so it doesn't make a difference otherwise, which leaves nothing but disadvantages to having t-m-m disabled. > [...] ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-11 22:34 ` delete-selection-mode as default hw @ 2018-09-12 0:04 ` Drew Adams 2018-09-13 2:58 ` hw 2018-09-12 13:16 ` Alan Mackenzie 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-12 0:04 UTC (permalink / raw) To: hw Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, phillip.lord > Highlighting regions should be separated from whether they are active or > not, and I don't want hidden regions, either. There are ways to highlight the region without activating it. You can use one of those (preferably with a different face, if you also sometimes use an active region).. But it's important to highlight the active region. > Currently even when a region is not active (it is a hidden region > because it is not highlighted), you can do something with it, so users > always get an "active" region even when they don't want one. It's only > a bit less active than it is when it is highlighted. The "active region" has a well-defined meaning in Emacs. Don't confuse things by talking about how you can act on the region when it is not active in the usual sense. > > I feel like region activation by `C-x C-x' was maybe foisted > > on people who never wanted or expected to do anything > > with an active region. > > Do you mean they would rather do things with hidden regions? I never > want to do that. Not clear, but it sounds like you do want an active region, in the usual sense, but you want it to be active for only some things, none of which are type/paste to replace/delete. > Use point and mark purely for navigation, set a selection-start-marker > with C-spc and a selection-end-marker with another C-spc (or whatever > key binding is appropriate for it). The region is between these > markers, and you can have multiple regions in the same buffer. Do > something with a region, and its markers are forgotten unless you use a > prefix. Have a key binding to jump around between the regions in a > buffer, and you can tell Emacs with which of them you want to do > something by moving point into it. If you want to do the same thing > with multiple regions, move point into one after another and make them > "sticky" for operation, or mark them right after selecting them. Much of what you describe is available with various libraries, including `zones.el' (https://www.emacswiki.org/emacs/Zones). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 0:04 ` Drew Adams @ 2018-09-13 2:58 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-13 2:58 UTC (permalink / raw) To: Drew Adams Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: >> Highlighting regions should be separated from whether they are active or >> not, and I don't want hidden regions, either. > > There are ways to highlight the region without activating it. > You can use one of those (preferably with a different face, > if you also sometimes use an active region).. I'm not sure if that is very useful unless there are multiple regions. > But it's important to highlight the active region. yes >> Currently even when a region is not active (it is a hidden region >> because it is not highlighted), you can do something with it, so users >> always get an "active" region even when they don't want one. It's only >> a bit less active than it is when it is highlighted. > > The "active region" has a well-defined meaning in Emacs. > Don't confuse things by talking about how you can act on > the region when it is not active in the usual sense. That the meaning of "active region" is well defined doesn't seem to prevent inconsistency and confusion. Are there multiple senses in which a region can be active? ;) >> > I feel like region activation by `C-x C-x' was maybe foisted >> > on people who never wanted or expected to do anything >> > with an active region. >> >> Do you mean they would rather do things with hidden regions? I never >> want to do that. > > Not clear, but it sounds like you do want an active region, in the usual > sense, but you want it to be active for only some things, none of which > are type/paste to replace/delete. What I usually do with a region is stuff with it ... i. e. cut/copy and paste it, and I use it to limit (not extend) the effect of functions like query-replace. I also use indent-region, but that always works with a region --- you could see some inconsistency here, too, because with an active region, only indent would be needed which is limited to a region that is active and otherwise work with the whole buffer. Sometimes I use it for whitespace-cleanup, which is also limited to an active region --- another inconsistency is whitespace-cleanup-region. There may be other things I use regions for that doesn't come to mind atm. It might be wrong to call them regions because it's no more than a selection to me. I select a region when I want one and expect it to be forgotten once I did something with it. I do not want hidden regions lurking invisibly in the background, waiting for me to make a mistake so they can suddenly come out of hiding and bite me. Regions do not have anything to do with navigation, and I don't use them for that. I would prefer consistency and selections to act like I want them to, like no delete-selection-mode, no shift-selection, no deletion of regions by arbitrary keystrokes, no de-activating regions by arbitrary keystrokes ... I don't really care about transient-mark-mode. I enabled it a long time ago because with it enabled, selections get finally highlighted like they should be. When I made a selection, it is only logical that functions are limited to the selection, so this special feature of t-m-m isn't a special feature to me. And how would you limit functions to selections otherwise? Whether functions are limited to a selection doesn't have anything to do with how the selection has been made, i. e. whether with t-m-m enabled or disabled. It also doesn't have anything to do with whether a selection is highlighted or not, but when something is selected, it should be highlighted, and when something isn't highlighted, it shouldn't be selected. There are so things entirely unrelated of each other that I now have lost count. Only Emacs makes a mess of them and even throws navigation into the mess. Extending functions to a selection is yet an entirely different issue. You can only limit functions that otherwise work with the whole buffer to a region, and you can only extend functions that do not work with a whole buffer to a region. Transient-mark-mode is supposed to limit functions, not to extend them. To extend functions, a separate mode may be helpful (like you already have d-s-m). >> Use point and mark purely for navigation, set a selection-start-marker >> with C-spc and a selection-end-marker with another C-spc (or whatever >> key binding is appropriate for it). The region is between these >> markers, and you can have multiple regions in the same buffer. Do >> something with a region, and its markers are forgotten unless you use a >> prefix. Have a key binding to jump around between the regions in a >> buffer, and you can tell Emacs with which of them you want to do >> something by moving point into it. If you want to do the same thing >> with multiple regions, move point into one after another and make them >> "sticky" for operation, or mark them right after selecting them. > > Much of what you describe is available with various libraries, including > `zones.el' (https://www.emacswiki.org/emacs/Zones). ... like you describe in your other post, thanks! I need to look into that. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-11 22:34 ` delete-selection-mode as default hw 2018-09-12 0:04 ` Drew Adams @ 2018-09-12 13:16 ` Alan Mackenzie 2018-09-12 13:41 ` Drew Adams ` (3 more replies) 1 sibling, 4 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-12 13:16 UTC (permalink / raw) To: hw Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Hello, hw. On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: > Drew Adams <drew.adams@oracle.com> writes: > Highlighting regions should be separated from whether they are active > or not, and I don't want hidden regions, either. I do. I want point and mark, and the region between them to be regarded as "the" region. That's it. I currently (almost) have that option. > Currently even when a region is not active (it is a hidden region > because it is not highlighted), you can do something with it, so users > always get an "active" region even when they don't want one. It's only > a bit less active than it is when it is highlighted. As I've pointed out several times in the distant past, the terminology used for things in this part of Emacs is thoroughly suboptimal. A region is never "active"; it never does anything, it is never an agent. For example. > > [...] > > I suspect that things are very different for you, and I > > suspect it is because of `C-x C-x' activating the region > > even though you have no intention of acting on it. > Exchanging point and mark is a purely navigational thing, and somehow > the activation and deactivation of hidden(!) regions .... There's exactly one region, except when there's none (before the mark has been set in a buffer). > .... which may have been modified because point may have moved since a > region was selected last time(!) has been mixed into that. That is ill > advised. No, it's central and essential to how Emacs works. There is ONE region, the part of the buffer between mark and point. Let's not muck around with this. > > I feel like region activation by `C-x C-x' was maybe foisted > > on people who never wanted or expected to do anything > > with an active region. > Do you mean they would rather do things with hidden regions? I never > want to do that. I do. I don't want my region highlighted, ever. > Right, so why not separate navigational functions from highlighting and > regions? > Use point and mark purely for navigation, set a selection-start-marker > with C-spc and a selection-end-marker with another C-spc (or whatever > key binding is appropriate for it). The region is between these > markers, and you can have multiple regions in the same buffer. Do > something with a region, and its markers are forgotten unless you use a > prefix. Have a key binding to jump around between the regions in a > buffer, and you can tell Emacs with which of them you want to do > something by moving point into it. If you want to do the same thing > with multiple regions, move point into one after another and make them > "sticky" for operation, or mark them right after selecting them. > That might make a lot of things much simpler, and we wouldn't have to > feel uneasy about the hidden regions all the time. Simpler? You've got to be kidding! Who really wants to have several regions, and why? I think the times one would want several regions would be so rare as to be pure unjustified complexity. > > [...] > > There you go. That's probably the right thing to do for > > someone who doesn't want d-s-m behavior. But then > > do you have to monkey around with temporary t-m-m, > > or do you just not bother, ever, with having an active > > region? I'm guessing the latter. > It can make it difficult to do things supposed to be limited to a > region. I might disable t-m-m if I could see what I have selected with > it disabled and monkey. Monkey? One of the uses of C-x C-x is to check what is currently in the region. Typically, you'd type it twice, to get back to your starting point. > I never use C-x C-x, so it doesn't make a difference otherwise, which > leaves nothing but disadvantages to having t-m-m disabled. 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. But everybody's different here, with different preferences, likes, hates. It's a mistake (which I've made quite a few times) to assume that "obvious" options in Emacs actually are obvious. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-12 13:16 ` Alan Mackenzie @ 2018-09-12 13:41 ` Drew Adams 2018-09-12 14:53 ` Alan Mackenzie 2018-09-12 15:51 ` Yuri Khan ` (2 subsequent siblings) 3 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-12 13:41 UTC (permalink / raw) To: Alan Mackenzie, hw Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord > > Currently even when a region is not active (it is a hidden region > > because it is not highlighted), you can do something with it, so users > > always get an "active" region even when they don't want one. It's only > > a bit less active than it is when it is highlighted. > > As I've pointed out several times in the distant past, the terminology > used for things in this part of Emacs is thoroughly suboptimal. A region > is never "active"; it never does anything, it is never an agent. For > example. OK. Perhaps a better term for it would have been "activated", not "active". And yes, a region is always activated (or enabled or able to be acted) on, in multiple ways. Someone picked a term for a region being activated for certain kinds of action. Some term for what is meant by that is useful - some term beyond just "highlighted" or "selected". "Active region" is OK, I think. Anyway, it's what we've been using, and I don't think it's awfully confusing, even if it can be a bit misleading. > One of the uses of C-x C-x is to check what is currently in the region. > Typically, you'd type it twice, to get back to your starting point. More exactly, one of the uses of C-x C-x _highlighting_ is that. You want a visual indication of the limits of the region, and perhaps of all of its contents. The other thing that C-x C-x does is activate the region, and in your case you do not need/want that. > 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. Being able to apply some actions to the region (or being unable to do so) is just a thing. It can be limiting, as you suggest. But it can also be handy - depending on the user and what s?he wants to do. Just as `delete-selection-mode' provides essentially an implicit C-w, which can be either a convenience or a bother, depending, so can isolating the region for acting on it, but just highlighting it instead of narrowing to it (so you can still see the surrounding context) be either a convenience or a bother, depending. I like to have (and use) both, at different times: (1) narrowing to the region to act on it and (2) activating the region to act on it. My `isearch+.el' lets me limit Isearch to the active region, for instance, but still see the surrounding context. Do I always use that, instead of narrowing and then searching? No. I do both, at different times. I like having the option to do either. > But everybody's different here, with different preferences, likes, hates. > It's a mistake (which I've made quite a few times) to assume that > "obvious" options in Emacs actually are obvious. 100% agreement on that. And the preferences of the same user can even change over time and as new possibilities arise. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 13:41 ` Drew Adams @ 2018-09-12 14:53 ` Alan Mackenzie 0 siblings, 0 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-12 14:53 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord Hello, Drew. On Wed, Sep 12, 2018 at 06:41:43 -0700, Drew Adams wrote: [ .... ] > > One of the uses of C-x C-x is to check what is currently in the > > region. Typically, you'd type it twice, to get back to your > > starting point. > More exactly, one of the uses of C-x C-x _highlighting_ is that. No, I meant what I wrote. Even without the highlighting, the first C-x C-x takes point to the other end of the region. You thus see where it is. > You want a visual indication of the limits of the region, .... This is exactly what I don't want. This visual indication would get in my way. > .... and perhaps of all of its contents. The other thing that C-x C-x > does is activate the region, and in your case you do not need/want > that. Yes. > > 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. > Being able to apply some actions to the region (or being unable to do > so) is just a thing. It can be limiting, as you suggest. But it can > also be handy - depending on the user and what s?he wants to do. Yes. I was countering hw's assertion that running with transient-mark-mode disabled was not sensible. [ .... ] > > But everybody's different here, with different preferences, likes, > > hates. It's a mistake (which I've made quite a few times) to assume > > that "obvious" options in Emacs actually are obvious. > 100% agreement on that. And the preferences of the same user can even > change over time and as new possibilities arise. Even that, yes. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 13:16 ` Alan Mackenzie 2018-09-12 13:41 ` Drew Adams @ 2018-09-12 15:51 ` Yuri Khan 2018-09-12 15:59 ` Alan Mackenzie 2018-09-13 3:59 ` Elias Mårtenson 2018-09-13 4:16 ` hw 3 siblings, 1 reply; 245+ messages in thread From: Yuri Khan @ 2018-09-12 15:51 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Eli Zaretskii, Drew Adams, Phillip Lord On Wed, Sep 12, 2018 at 8:19 PM Alan Mackenzie <acm@muc.de> wrote: > And I'm not happy having my font-locking > splatted by the region's highlighting. It’s not splatted with careful face customization. Namely, customize the ‘region’ face to not specify :foreground but only :background, a shade or tint very close to but distinct from your normal background. May also need to set :distant-foreground to 'unspecified. Example: my ‘default’ face is :foreground "#b3b3b4" :background "#414042" (light gray on dark gray), and my ‘region’ is :background "#4d4d4f" (slightly lighter but still fairly dark gray). All syntax highlighting faces are still visible against this background. I avoid changing background color alone for syntax highlighting. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 15:51 ` Yuri Khan @ 2018-09-12 15:59 ` Alan Mackenzie 2018-09-12 16:36 ` Yuri Khan 0 siblings, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-12 15:59 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Eli Zaretskii, Drew Adams, Phillip Lord Hello, Yuri. On Wed, Sep 12, 2018 at 22:51:49 +0700, Yuri Khan wrote: > On Wed, Sep 12, 2018 at 8:19 PM Alan Mackenzie <acm@muc.de> wrote: > > And I'm not happy having my font-locking > > splatted by the region's highlighting. > It’s not splatted with careful face customization. Namely, customize > the ‘region’ face to not specify :foreground but only :background, a > shade or tint very close to but distinct from your normal background. > May also need to set :distant-foreground to 'unspecified. Thanks for the suggestion, but... When I said "my font-locking", I meant _MY_ font-locking. I run Emacs on a Linux virtual terminal, which has 16 colours altogether. The only useful thing I could customize the region face to would be a null face, but then I would have no warning of the region becoming "active". Currently the region face is a solid dark blue background, which obliterates all other uses of highlighting on the screen. > Example: my ‘default’ face is :foreground "#b3b3b4" :background > "#414042" (light gray on dark gray), and my ‘region’ is :background > "#4d4d4f" (slightly lighter but still fairly dark gray). All syntax > highlighting faces are still visible against this background. I avoid > changing background color alone for syntax highlighting. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 15:59 ` Alan Mackenzie @ 2018-09-12 16:36 ` Yuri Khan 0 siblings, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-12 16:36 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Eli Zaretskii, Drew Adams, Phillip Lord On Wed, Sep 12, 2018 at 11:02 PM Alan Mackenzie <acm@muc.de> wrote: > Thanks for the suggestion, but... When I said "my font-locking", I > meant _MY_ font-locking. I run Emacs on a Linux virtual terminal, which > has 16 colours altogether. The only useful thing I could customize the > region face to would be a null face, but then I would have no warning of > the region becoming "active". Currently the region face is a solid dark > blue background, which obliterates all other uses of highlighting on the > screen. Well, yes, your setup imposes severe limitations. Even then, I think black normal background and blue region background (or vice versa) would be usable. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 13:16 ` Alan Mackenzie 2018-09-12 13:41 ` Drew Adams 2018-09-12 15:51 ` Yuri Khan @ 2018-09-13 3:59 ` Elias Mårtenson 2018-09-13 4:16 ` hw 3 siblings, 0 replies; 245+ messages in thread From: Elias Mårtenson @ 2018-09-13 3:59 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, joostkremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord [-- Attachment #1: Type: text/plain, Size: 759 bytes --] On Wed, 12 Sep 2018 at 21:20, Alan Mackenzie <acm@muc.de> wrote: On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: > > Drew Adams <drew.adams@oracle.com> writes: > > > Highlighting regions should be separated from whether they are active > > or not, and I don't want hidden regions, either. > > I do. I want point and mark, and the region between them to be regarded > as "the" region. That's it. I currently (almost) have that option. > Thank you for saying this. I agree with you 100%, and the overloading of the region concept into something that does multiple different things while at the same time dismantles the beautiful simplicity and power of the “one region at all times” concept is disheartening to me. Regards, Elias [-- Attachment #2: Type: text/html, Size: 1154 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 13:16 ` Alan Mackenzie ` (2 preceding siblings ...) 2018-09-13 3:59 ` Elias Mårtenson @ 2018-09-13 4:16 ` hw 2018-09-13 17:46 ` Alan Mackenzie 3 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-13 4:16 UTC (permalink / raw) To: Alan Mackenzie Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Alan Mackenzie <acm@muc.de> writes: > Hello, hw. > > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: >> Drew Adams <drew.adams@oracle.com> writes: > >> Highlighting regions should be separated from whether they are active >> or not, and I don't want hidden regions, either. > > I do. I want point and mark, and the region between them to be regarded > as "the" region. That's it. I currently (almost) have that option. How do I get the region highlighted so I can see where it is? >> Currently even when a region is not active (it is a hidden region >> because it is not highlighted), you can do something with it, so users >> always get an "active" region even when they don't want one. It's only >> a bit less active than it is when it is highlighted. > > As I've pointed out several times in the distant past, the terminology > used for things in this part of Emacs is thoroughly suboptimal. A region > is never "active"; it never does anything, it is never an agent. For > example. Maybe "workable" is a better term. >> > [...] >> > I suspect that things are very different for you, and I >> > suspect it is because of `C-x C-x' activating the region >> > even though you have no intention of acting on it. > >> Exchanging point and mark is a purely navigational thing, and somehow >> the activation and deactivation of hidden(!) regions .... > > There's exactly one region, except when there's none (before the mark has > been set in a buffer). There shouldn't be one unless it's highlighted. If highlighted, it depends on how you consider it: multiple regions, or still one region which is non-consecutive. >> .... which may have been modified because point may have moved since a >> region was selected last time(!) has been mixed into that. That is ill >> advised. > > No, it's central and essential to how Emacs works. There is ONE region, > the part of the buffer between mark and point. Let's not muck around > with this. Then how come I can't even see where the mark is, let alone the region? Why is that not displayed? >> > I feel like region activation by `C-x C-x' was maybe foisted >> > on people who never wanted or expected to do anything >> > with an active region. > >> Do you mean they would rather do things with hidden regions? I never >> want to do that. > > I do. I don't want my region highlighted, ever. Why not? 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. How do you limit functions to a part of a buffer when you do not use transient-mark-mode? >> Right, so why not separate navigational functions from highlighting and >> regions? > >> Use point and mark purely for navigation, set a selection-start-marker >> with C-spc and a selection-end-marker with another C-spc (or whatever >> key binding is appropriate for it). The region is between these >> markers, and you can have multiple regions in the same buffer. Do >> something with a region, and its markers are forgotten unless you use a >> prefix. Have a key binding to jump around between the regions in a >> buffer, and you can tell Emacs with which of them you want to do >> something by moving point into it. If you want to do the same thing >> with multiple regions, move point into one after another and make them >> "sticky" for operation, or mark them right after selecting them. > >> That might make a lot of things much simpler, and we wouldn't have to >> feel uneasy about the hidden regions all the time. > > Simpler? You've got to be kidding! Who really wants to have several > regions, and why? I think the times one would want several regions would > be so rare as to be pure unjustified complexity. One reason is visual indication. I can set a register or a bookmark in a buffer and never see it, or I can write 'FIXME:' comments which is silly when I'm working on something so that it's gona be fixed anyway, and hard to see --- or I could highlight the lines I'm concerned about and need to look into. If I could highlight parts, I could go through the source and read it, which I do anyway, highlight the relevant places and have it much easier to move around and to find things and not overlook something. It could be a big relieve because I don't need to remember so much all at the same time because I could just see it highlighted. If it wouldn't screw up regions and do what ever hidden stuff, I might even use the mark for navigation, so navigating would be easier in two ways. >> > [...] >> > There you go. That's probably the right thing to do for >> > someone who doesn't want d-s-m behavior. But then >> > do you have to monkey around with temporary t-m-m, >> > or do you just not bother, ever, with having an active >> > region? I'm guessing the latter. > >> It can make it difficult to do things supposed to be limited to a >> region. I might disable t-m-m if I could see what I have selected with >> it disabled and monkey. > > Monkey? ... around with temporary t-m-m to limit functions to selections. > One of the uses of C-x C-x is to check what is currently in the region. > Typically, you'd type it twice, to get back to your starting point. Why would I? >> I never use C-x C-x, so it doesn't make a difference otherwise, which >> leaves nothing but disadvantages to having t-m-m disabled. > > 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. It's not like I like transient-mark-mode, it's only the least evil. The concept of "the" region and having it all messed up with each other is what's really evil. I want my selection highlighted. I'd also need to have regions and selections decoupled from the navigation. There's no sense in "the" region. I don't need a region to navigate. I don't need a region for a selection. I need to navigate and to select, independently of each other, and I especially don't need "the" lurking hidden region to screw things up for me because it's coupled to everything. > But everybody's different here, with different preferences, likes, hates. > It's a mistake (which I've made quite a few times) to assume that > "obvious" options in Emacs actually are obvious. Is there anything obvious about Emacs? :) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-13 4:16 ` hw @ 2018-09-13 17:46 ` Alan Mackenzie 2018-09-13 20:32 ` hw 0 siblings, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-13 17:46 UTC (permalink / raw) To: hw Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Hello, hw. On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote: > Alan Mackenzie <acm@muc.de> writes: > > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: > >> Drew Adams <drew.adams@oracle.com> writes: > >> Highlighting regions should be separated from whether they are active > >> or not, and I don't want hidden regions, either. > > I do. I want point and mark, and the region between them to be regarded > > as "the" region. That's it. I currently (almost) have that option. > How do I get the region highlighted so I can see where it is? You can't, as far as I'm aware, except by using transient-mark-mode. If you want such a facility, implement it! > > There's exactly one region, except when there's none (before the mark has > > been set in a buffer). > There shouldn't be one unless it's highlighted. If highlighted, it > depends on how you consider it: multiple regions, or still one region > which is non-consecutive. Don't confuse your personal preferences with objective things. We all use Emacs differently, which is why it is so customisable. If you can't customise it to work the way you want, that is likely a bug, which you should feel free to fix. [ .... ] > > No, it [the mark]'s central and essential to how Emacs works. There > > is ONE region, the part of the buffer between mark and point. Let's > > not muck around with this. > 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. > >> Do you mean they would rather do things with hidden regions? I never > >> want to do that. > > I do. I don't want my region highlighted, ever. > Why not? Personal preference. > 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? > How do you limit functions to a part of a buffer when you do not use > transient-mark-mode? By narrowing. C-x n n narrows to the region. C-x n w widens to the entire buffer. C-x n d narrows to the current source code function. Try it! Look it up in the Emacs manual (e.g., with C-i narrowing). [ .... ] > > Who really wants to have several regions, and why? I think the times > > one would want several regions would be so rare as to be pure > > unjustified complexity. > One reason is visual indication. I can set a register or a bookmark in > a buffer and never see it, or I can write 'FIXME:' comments which is > silly when I'm working on something so that it's gona be fixed anyway, > and hard to see --- or I could highlight the lines I'm concerned about > and need to look into. If I could highlight parts, I could go through > the source and read it, which I do anyway, highlight the relevant places > and have it much easier to move around and to find things and not > overlook something. It could be a big relieve because I don't need to > remember so much all at the same time because I could just see it > highlighted. As a matter of interest, you can easily arrange for all occurrences of FIXME: to be highlighted, with hi-lock-mode (look it up in the manual). > If it wouldn't screw up regions and do what ever hidden stuff, I might > even use the mark for navigation, so navigating would be easier in two > ways. I suggest you try this use of the mark anyway. [ .... ] > > Monkey? > ... around with temporary t-m-m to limit functions to selections. Ah! > > One of the uses of C-x C-x is to check what is currently in the region. > > Typically, you'd type it twice, to get back to your starting point. > Why would I? Then you see for sure where mark is. It's an alternative to having the region highlighted, which might work for you, it might not. > >> I never use C-x C-x, so it doesn't make a difference otherwise, which > >> leaves nothing but disadvantages to having t-m-m disabled. > > 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. > It's not like I like transient-mark-mode, it's only the least evil. The > concept of "the" region and having it all messed up with each other is > what's really evil. I dislike transient-mark-mode quite strongly. I have the option to disable it, which I do. You have that option, too. You also have the option to extend Emacs to do what you want. > I want my selection highlighted. I'd also need to have regions and > selections decoupled from the navigation. There's no sense in "the" > region. There's a lot of sense in it. Otherwise, it would have been superseded or extended sometime over the last 40 years of Emacs's existence. > I don't need a region to navigate. I don't need a region for a > selection. I need to navigate and to select, independently of each > other, and I especially don't need "the" lurking hidden region to screw > things up for me because it's coupled to everything. I do. It works smoothly for me, and I never find things "screwing up" for me in the way you're depicting. > > But everybody's different here, with different preferences, likes, hates. > > It's a mistake (which I've made quite a few times) to assume that > > "obvious" options in Emacs actually are obvious. > Is there anything obvious about Emacs? :) Yes, lots of things. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-13 17:46 ` Alan Mackenzie @ 2018-09-13 20:32 ` hw 2018-09-14 10:48 ` Alan Mackenzie 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-13 20:32 UTC (permalink / raw) To: Alan Mackenzie Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Alan Mackenzie <acm@muc.de> writes: > Hello, hw. > > On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote: >> Alan Mackenzie <acm@muc.de> writes: > >> > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: >> >> Drew Adams <drew.adams@oracle.com> writes: > >> >> Highlighting regions should be separated from whether they are active >> >> or not, and I don't want hidden regions, either. > >> > I do. I want point and mark, and the region between them to be regarded >> > as "the" region. That's it. I currently (almost) have that option. > >> How do I get the region highlighted so I can see where it is? > > You can't, as far as I'm aware, except by using transient-mark-mode. If > you want such a facility, implement it! What is the point of being forced to make hidden selections? I don't know how to implement highlighting selections. >> > There's exactly one region, except when there's none (before the mark has >> > been set in a buffer). > >> There shouldn't be one unless it's highlighted. If highlighted, it >> depends on how you consider it: multiple regions, or still one region >> which is non-consecutive. > > Don't confuse your personal preferences with objective things. We all > use Emacs differently, which is why it is so customisable. If you can't > customise it to work the way you want, that is likely a bug, which you > should feel free to fix. Maybe you haven't followed the discussion, which was, amongst other things, about what should be the default for d-s-m. That Emacs is customizable doesn't mean that it could be customized to deal with selections reasonably, and as long as it can't and an overhaul of the idea of "the region" and making selections might be in order, the question for a the default of d-s-m can't very well be answered. I'm merely saying how it should be, as one option, which could be a default or not. > > [ .... ] > >> > No, it [the mark]'s central and essential to how Emacs works. There >> > is ONE region, the part of the buffer between mark and point. Let's >> > not muck around with this. > >> 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. >> >> Do you mean they would rather do things with hidden regions? I never >> >> want to do that. > >> > I do. I don't want my region highlighted, ever. > >> Why not? > > Personal preference. > >> 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. 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. >> How do you limit functions to a part of a buffer when you do not use >> transient-mark-mode? > > By narrowing. C-x n n narrows to the region. C-x n w widens to the > entire buffer. C-x n d narrows to the current source code function. Try > it! Look it up in the Emacs manual (e.g., with C-i narrowing). As said, that's triple work. > [ .... ] > >> > Who really wants to have several regions, and why? I think the times >> > one would want several regions would be so rare as to be pure >> > unjustified complexity. > >> One reason is visual indication. I can set a register or a bookmark in >> a buffer and never see it, or I can write 'FIXME:' comments which is >> silly when I'm working on something so that it's gona be fixed anyway, >> and hard to see --- or I could highlight the lines I'm concerned about >> and need to look into. If I could highlight parts, I could go through >> the source and read it, which I do anyway, highlight the relevant places >> and have it much easier to move around and to find things and not >> overlook something. It could be a big relieve because I don't need to >> remember so much all at the same time because I could just see it >> highlighted. > > As a matter of interest, you can easily arrange for all occurrences of > FIXME: to be highlighted, with hi-lock-mode (look it up in the manual). It still wouldn't highlight a selection. Hi-lock-mode doesn't have anything to do with selections, and how would you limit functions to what is highlighted? >> If it wouldn't screw up regions and do what ever hidden stuff, I might >> even use the mark for navigation, so navigating would be easier in two >> ways. > > I suggest you try this use of the mark anyway. No, why would I? > [...] >> > One of the uses of C-x C-x is to check what is currently in the region. >> > Typically, you'd type it twice, to get back to your starting point. > >> Why would I? > > Then you see for sure where mark is. It's an alternative to having the > region highlighted, which might work for you, it might not. You see it only indirectly, and it changes your position in the buffer, which it shouldn't --- and when transient-mark-mode is enabled, it highlights a part of a buffer as if there was a selection. Nothing of that is what I would want. Why should I even need to do anything to have the mark visible? >> >> I never use C-x C-x, so it doesn't make a difference otherwise, which >> >> leaves nothing but disadvantages to having t-m-m disabled. > >> > 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. >> It's not like I like transient-mark-mode, it's only the least evil. The >> concept of "the" region and having it all messed up with each other is >> what's really evil. > > I dislike transient-mark-mode quite strongly. I have the option to > disable it, which I do. You have that option, too. You also have the > option to extend Emacs to do what you want. None of the options would do what I want, and making an extension that does what I want isn't really an option, either. Again, this stuff needs an overhaul. >> I want my selection highlighted. I'd also need to have regions and >> selections decoupled from the navigation. There's no sense in "the" >> region. > > There's a lot of sense in it. Otherwise, it would have been superseded > or extended sometime over the last 40 years of Emacs's existence. Then where is all that sense? Apparently there were several attempts to change things, or there wouldn't be t-m-m and d-s-m. >> I don't need a region to navigate. I don't need a region for a >> selection. I need to navigate and to select, independently of each >> other, and I especially don't need "the" lurking hidden region to screw >> things up for me because it's coupled to everything. > > I do. It works smoothly for me, and I never find things "screwing up" > for me in the way you're depicting. Lots of things that are bad makeshift workarounds work surprisingly smoothly, and I already said it's unlikely to make the mistake that would reveal the design flaw because it's unlikely to press the keys for it by accident. That doesn't mean it's a good solution. >> > But everybody's different here, with different preferences, likes, hates. >> > It's a mistake (which I've made quite a few times) to assume that >> > "obvious" options in Emacs actually are obvious. > >> Is there anything obvious about Emacs? :) > > Yes, lots of things. Like what? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-13 20:32 ` hw @ 2018-09-14 10:48 ` Alan Mackenzie 2018-09-14 13:41 ` Yuri Khan ` (2 more replies) 0 siblings, 3 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-14 10:48 UTC (permalink / raw) To: hw Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Hello, hw. On Thu, Sep 13, 2018 at 22:32:58 +0200, hw wrote: > Alan Mackenzie <acm@muc.de> writes: > > Hello, hw. > > On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote: > >> Alan Mackenzie <acm@muc.de> writes: > >> > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote: > >> >> Drew Adams <drew.adams@oracle.com> writes: [ .... ] > > Don't confuse your personal preferences with objective things. We > > all use Emacs differently, which is why it is so customisable. If > > you can't customise it to work the way you want, that is likely a > > bug, which you should feel free to fix. > Maybe you haven't followed the discussion, which was, amongst other > things, about what should be the default for d-s-m. That Emacs is > customizable doesn't mean that it could be customized to deal with > selections reasonably, and as long as it can't and an overhaul of the > idea of "the region" and making selections might be in order, the > question for a the default of d-s-m can't very well be answered. [ .... ] > > [ .... ] > >> > No, it [the mark]'s central and essential to how Emacs works. There > >> > is ONE region, the part of the buffer between mark and point. Let's > >> > not muck around with this. > >> 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. > >> 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. 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. > 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. [...] > >> > 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? [ .... ] > 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. > Again, this stuff needs an overhaul. I don't think you've managed to persuade anybody, certainly not me (yet). Why are you using Emacs at all? You seem to dislike its core concepts and methods fairly strongly. 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? [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 10:48 ` Alan Mackenzie @ 2018-09-14 13:41 ` Yuri Khan 2018-09-14 14:03 ` Alan Mackenzie ` (3 more replies) 2018-09-14 14:33 ` Drew Adams 2018-09-15 20:31 ` hw 2 siblings, 4 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-14 13:41 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Eli Zaretskii, Drew Adams, Phillip Lord On Fri, Sep 14, 2018 at 5:52 PM Alan Mackenzie <acm@muc.de> wrote: > Why are you using Emacs at all? You seem to dislike its core concepts > and methods fairly strongly. 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? *The* core concept of Emacs as I understand it is its infinite customizability, and this is pretty much the main reason I stick with it. I dislike the default Emacs keybindings, but that’s not a problem because I can easily redefine them. I consider the default looks of the modeline too cryptic, but that’s not a problem because I can reconfigure it. In my editor, I want tabs, line numbers, visible whitespace, and shift selection. In Emacs, they all are just a few configuration options away. (Okay, no, tabs have to be customized heavily before they are useful for me.) One other thing that I want is that the region be highlighted if and only if it is going to be the target of the next command I give, because I like to look before I leap. It seems transient-mark-mode is intended to give me this by adding the concept of active region and highlighting the region when it is active. However, many commands act on the region even if it is inactive. kill-region and copy-region-as-kill are two such commands. I am sure there are many more, because it is much easier to write: (defun my-command (BEGIN END) (interactive "r") ;; do something between BEGIN and END ) than: (defun my-command (BEGIN END) (interactive (if (use-region-p) (list (min (point) (mark)) (max (point) (mark))) ;; figure out what to do when no region is active ;; * act on the whole buffer ;; * act on the current narrowing ;; * signal an error ;; * do something else sensible (list ?? ??))) ;; do something between BEGIN and END ) With transient-mark-mode being the Emacs default, I’m inclined to consider it a bug that certain commands act on the inactive region when t-m-m is enabled, and possibly a flaw that (interactive "r") makes it so easy to define such commands. I was one of two people here to suggest that it is a bad thing that the mark is used both as a navigation mechanism and as a region delimiter, but, in practice, it would not matter much if the above issue was addressed. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 13:41 ` Yuri Khan @ 2018-09-14 14:03 ` Alan Mackenzie 2018-09-14 15:37 ` Yuri Khan 2018-09-14 14:29 ` Phil Sainty ` (2 subsequent siblings) 3 siblings, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-14 14:03 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Eli Zaretskii, Drew Adams, Phillip Lord Hello, Yuri. On Fri, Sep 14, 2018 at 20:41:46 +0700, Yuri Khan wrote: > On Fri, Sep 14, 2018 at 5:52 PM Alan Mackenzie <acm@muc.de> wrote: [ .... ] > One other thing that I want is that the region be highlighted if and > only if it is going to be the target of the next command I give, > because I like to look before I leap. It seems transient-mark-mode is > intended to give me this by adding the concept of active region and > highlighting the region when it is active. However, many commands act > on the region even if it is inactive. kill-region and > copy-region-as-kill are two such commands. You don't mention setting mark-even-if-inactive to nil. Have you tried this, and if so, what problems still remain with this setting? > I am sure there are many more, ..... [ .... ] > I was one of two people here to suggest that it is a bad thing that > the mark is used both as a navigation mechanism and as a region > delimiter, but, in practice, it would not matter much if the above > issue was addressed. This categorisation of the mark as either for navigation or for a region delimiter, if it happened, would have to be optional. For me, this "double" use is a plus. For example, quite often I do things like M->, C-w to kill from point to EOB. At the same time, I have no use for transient-mark-mode, which I disable. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 14:03 ` Alan Mackenzie @ 2018-09-14 15:37 ` Yuri Khan 0 siblings, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-14 15:37 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Eli Zaretskii, Drew Adams, Phillip Lord On Fri, Sep 14, 2018 at 9:06 PM Alan Mackenzie <acm@muc.de> wrote: > You don't mention setting mark-even-if-inactive to nil. Have you tried > this, and if so, what problems still remain with this setting? Thank you, this looks useful. I saw it mentioned in one of these subthreads but did not realize it was on by default. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 13:41 ` Yuri Khan 2018-09-14 14:03 ` Alan Mackenzie @ 2018-09-14 14:29 ` Phil Sainty 2018-09-14 14:32 ` Phil Sainty 2018-09-14 14:33 ` Eli Zaretskii 2018-09-14 15:15 ` Elias Mårtenson 3 siblings, 1 reply; 245+ messages in thread From: Phil Sainty @ 2018-09-14 14:29 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord On 15/09/18 01:41, Yuri Khan wrote: > I was one of two people here to suggest that it is a bad thing > that the mark is used both as a navigation mechanism and as a > region delimiter I think it's impractical to suggest that all code which acts on the region should be modified to only do so if the region is active. The only approach I can think of is to have the mark forcibly set to nil whenever the region is inactive, so that commands which want to use the region will fail. I suspect that would mean giving up all use of the mark ring too -- but you could implement a custom equivalent for the purposes of navigation. Maybe play with something like this: (defun my-clear-inactive-mark () (unless (region-active-p) (set-mark nil))) (add-hook 'pre-command-hook 'my-clear-inactive-mark) -Phil ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 14:29 ` Phil Sainty @ 2018-09-14 14:32 ` Phil Sainty 0 siblings, 0 replies; 245+ messages in thread From: Phil Sainty @ 2018-09-14 14:32 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord On 15/09/18 02:29, Phil Sainty wrote: > The only approach I can think of is to have the mark forcibly set > to nil whenever the region is inactive, so that commands which > want to use the region will fail. Ah ignore that -- as Alan points out, `mark-even-if-inactive' is implemented and seems to solve this cleanly. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 13:41 ` Yuri Khan 2018-09-14 14:03 ` Alan Mackenzie 2018-09-14 14:29 ` Phil Sainty @ 2018-09-14 14:33 ` Eli Zaretskii 2018-09-14 15:23 ` Drew Adams ` (2 more replies) 2018-09-14 15:15 ` Elias Mårtenson 3 siblings, 3 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-14 14:33 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, drew.adams, phillip.lord > From: Yuri Khan <yurivkhan@gmail.com> > Date: Fri, 14 Sep 2018 20:41:46 +0700 > Cc: hw@adminart.net, spacibba@aol.com, > Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, > Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>, > Phillip Lord <phillip.lord@russet.org.uk> > > *The* core concept of Emacs as I understand it is its infinite > customizability, and this is pretty much the main reason I stick with > it. There are limits to customizing Emacs. Beyond those limits, what you have is the basic ideas on which Emacs is based; if you want to change them, you will have to write a different editor. The region is one such basic idea. If you want it to behave exactly as selections in other editors, you are not talking about Emacs. We can (and do) provide approximations to what other editors do with selections, but they are just that: approximations. So I suggest not to ignore what Alan says, because I think there's a hard nut of truth there, which we should endorse if we want to have a common language. IMO, the basic conundrum of what we have now with transient-mark-mode and delete-selection-mode is that we are trying to cover turf that cannot be covered by a single feature. As result, large groups of users will become unhappy, no matter what we do. The region is currently used for 3 purposes: navigation, invoking commands on a region of text, and delete-selection-mode. (If someone thinks that delete-selection-mode is a variant of "invoking commands on a region of text", they are mistaken, and this long discussion is one proof of that mistake.) It should be clear from this discussion that there are fundamental tensions between these 3 purposes. The first two can be reconciled by using the "active" vs "inactive" region, something we already have. This distinction is needed because an Emacs buffer will almost always have a region, and therefore users need some knob to control whether a command should act on the region or on the entire buffer. (It is possible that we need some new command to "activate" the region, because the current method are IMO unsatisfactory: they require navigation, which is totally gratuitous.) The third use of the region, the one needed for delete-selection-mode, is IMO impossible to reconcile with the other two. Instead of trying to reconcile them with some trick, we should consider introducing a new "state" of the region, which will be activated by a special command, or could be optionally activated by "C-x C-x" etc., given some optional setting. IOW, let the users "arm" the region for delete-selection type of commands, similarly to how they currently "activate" it for the other purpose. Then the user could decide what exactly they want the region to provide, and the basic conundrum is gone. > With transient-mark-mode being the Emacs default, I’m inclined to > consider it a bug that certain commands act on the inactive region > when t-m-m is enabled, and possibly a flaw that (interactive "r") > makes it so easy to define such commands. It's not a bug, it's a feature: commands that make no sense without the region, like "upcase-region", should not need me to activate the region for them to do what I expect them. Other commands, which make sense both when there is and there isn't a region, need an indication of what the user wants them to do, and whether the region is active is that indication. The problem is that we now want to introduce yet another, 3rd meaning of the region, which is not identical to either of the other two. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-14 14:33 ` Eli Zaretskii @ 2018-09-14 15:23 ` Drew Adams 2018-09-14 18:49 ` Eli Zaretskii 2018-09-15 21:20 ` hw 2018-09-15 22:37 ` hw [not found] ` <<874leq799e.fsf@toy.adminart.net> 2 siblings, 2 replies; 245+ messages in thread From: Drew Adams @ 2018-09-14 15:23 UTC (permalink / raw) To: Eli Zaretskii, Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, phillip.lord > The region is currently used for 3 purposes: navigation, invoking > commands on a region of text, and delete-selection-mode. (If someone > thinks that delete-selection-mode is a variant of "invoking commands > on a region of text", they are mistaken, and this long discussion is > one proof of that mistake.) It should be clear from this discussion > that there are fundamental tensions between these 3 purposes. The > first two can be reconciled by using the "active" vs "inactive" > region, something we already have. This distinction is needed because > an Emacs buffer will almost always have a region, and therefore users > need some knob to control whether a command should act on the region > or on the entire buffer. (It is possible that we need some new > command to "activate" the region, because the current method are IMO > unsatisfactory: they require navigation, which is totally gratuitous.) > > The third use of the region, the one needed for delete-selection-mode, > is IMO impossible to reconcile with the other two. Instead of trying > to reconcile them with some trick, we should consider introducing a > new "state" of the region, which will be activated by a special > command, or could be optionally activated by "C-x C-x" etc., given > some optional setting. IOW, let the users "arm" the region for > delete-selection type of commands, similarly to how they currently > "activate" it for the other purpose. Then the user could decide what > exactly they want the region to provide, and the basic conundrum is > gone. `delete-selection-mode' is 5 well-defined behaviors for the active region, carried out when you invoke a command. It's nothing more than that. Which of those 5 behaviors to use depends on the command you invoke when the region is active. Users can trivially control which of the 5 behaviors to use for a given command, just by putting a property on the command symbol. These are the possible property values and associated behaviors: 1. nil: Do nothing (no-op). Same as turning off d-s-m mode for that command. 2. non-nil and not one of the symbols below (default): Delete (do not kill) the active region (`delete-active-region'). Then invoke the command. 3. `kill': Kill the active region (`kill-region'). Then invoke the command. 4. `supersede': Just delete the active region. Do not invoke the command. 5. `yank': Delete the active region, and make sure that the text deleted is not the same as the text that gets yanked. (Used only for a command that yanks.) There's no difficulty "reconciling" d-s-m with the "other uses" of the region that you cite. None whatsoever. You've shown none, AFAICT. No trick is needed. It just works. A user or code can turn d-s-m off anytime. Or turn it off for any given command (#1 above). > Other commands, which make sense both when there is and there > isn't a region, need an indication of what the user wants them to > do, and whether the region is active is that indication. Yes. > The problem is that we now want to introduce yet another, 3rd meaning > of the region, which is not identical to either of the other two. There is no 3rd meaning of the region. There is not even a 2nd meaning. There is one meaning of the region - the text delimited by point and mark. If t-m-m is on then the region can have two states: active or inactive. If the region is active and d-s-m is on then it can be automatically deleted when you invoke a command. That's all. There is nothing complicated or mysterious about d-s-m. If there were - if there were some crazy irreconcilability, then the same would be true of `C-w' and `delete-active-region'. There is also nothing complicated or mysterious about t-m-m. There is also nothing complicated about Emacs behavior when t-m-m and d-s-m are off. Misunderstandings come from mistaken expectations and the fact that different users use Emacs differently. Confusion can come from the fact that there are multiple knobs to control region behavior (and not just two modes, t-m-m and d-s-m), and it's not obvious sometimes that a given knob exists or how the various knobs interact. I do think it would help to have a command that only activates the region. Making `C-x C-x' do double duty is truly one place where confusion can get sown. It should be _able_ to do double duty, for convenience. But users should also be able to only activate the region and only swap point and mark - as separate operations. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 15:23 ` Drew Adams @ 2018-09-14 18:49 ` Eli Zaretskii 2018-09-15 21:20 ` hw 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-14 18:49 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > Date: Fri, 14 Sep 2018 08:23:31 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: acm@muc.de, hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, > npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk > > Users can trivially control which of the 5 behaviors to use for > a given command, just by putting a property on the command > symbol. Putting properties on symbols to change the behavior of a command is not user-level customization. IOW, we are miscommunicating. > There's no difficulty "reconciling" d-s-m with the "other > uses" of the region that you cite. None whatsoever. > You've shown none, AFAICT. No trick is needed. It just > works. This whole thread makes it acutely clear that there is a problem. And your message actually agrees with me towards the end. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 15:23 ` Drew Adams 2018-09-14 18:49 ` Eli Zaretskii @ 2018-09-15 21:20 ` hw 1 sibling, 0 replies; 245+ messages in thread From: hw @ 2018-09-15 21:20 UTC (permalink / raw) To: Drew Adams Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: > [...] > I do think it would help to have a command that only > activates the region. Making `C-x C-x' do double duty is > truly one place where confusion can get sown. It should > be _able_ to do double duty, for convenience. But users > should also be able to only activate the region and only > swap point and mark - as separate operations. If you do that, please make it so that the mark can be made visible. One idea what it could look like would be a box around the character where it is, like the box you get where the point is when the frame is not active. I'd just use different colours. Something to make it visible ... Why aren't we able to see it? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 14:33 ` Eli Zaretskii 2018-09-14 15:23 ` Drew Adams @ 2018-09-15 22:37 ` hw 2018-09-16 0:22 ` Drew Adams 2018-09-16 16:48 ` Eli Zaretskii [not found] ` <<874leq799e.fsf@toy.adminart.net> 2 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-15 22:37 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: > [...] > The region is currently used for 3 purposes: navigation, invoking > commands on a region of text, and delete-selection-mode. You don't need a region for commands to work on, a selection is enough. That would allow to decouple navigation from (making) selections, and the concept of a region becomes obsolete, removing all the entanglement and greatly simplifying things. > (If someone thinks that delete-selection-mode is a variant of > "invoking commands on a region of text", they are mistaken, and this > long discussion is one proof of that mistake.) That's why I said it's misguided in that it is an entirely different idea. > It should be clear from this discussion that there are fundamental > tensions between these 3 purposes. The first two can be reconciled by > using the "active" vs "inactive" region, something we already have. > This distinction is needed because an Emacs buffer will almost always > have a region, and therefore users need some knob to control whether a > command should act on the region or on the entire buffer. (It is > possible that we need some new command to "activate" the region, > because the current method are IMO unsatisfactory: they require > navigation, which is totally gratuitous.) Just use a selection for commands to work on? There's no need to particularly activate a selected part of a buffer; it's kinda what a selection is for. A region is not needed here, either. > The third use of the region, the one needed for delete-selection-mode, > is IMO impossible to reconcile with the other two. I'll leave that aside because it's an entirely different idea which may be served with its own independent implementation. For such an implementation, a region is not needed. Perhaps it could be implemented as an optional feature of selections. > Instead of trying to reconcile them with some trick, we should > consider introducing a new "state" of the region, You mean like a selection? :) Those do not require regions. > which will be activated by a special command, Since a region is obsolete, we could simply use C-spc to start making a selection and another C-spc to finish it. > or could be optionally activated by "C-x C-x" etc., given some > optional setting. That is for navigation. A region is not needed for navigation between two points. You only need the two points, in this case, called mark and point. Just decouple them from selections. Once decoupled, there could be a command to turn the "region" that can be imagined between mark and point into a selection. There is no need for a region here, either. > IOW, let the users "arm" the region for delete-selection type of > commands, similarly to how they currently "activate" it for the other > purpose. Then the user could decide what exactly they want the region > to provide, and the basic conundrum is gone. Users preferring d-s-m could enable the deletion option of selections. Then if they want to delete a selection, they can make one and overwrite it. This doesn't need to be complicated. >> With transient-mark-mode being the Emacs default, I’m inclined to >> consider it a bug that certain commands act on the inactive region >> when t-m-m is enabled, and possibly a flaw that (interactive "r") >> makes it so easy to define such commands. > > It's not a bug, it's a feature: commands that make no sense without > the region, like "upcase-region", should not need me to activate the > region for them to do what I expect them. What when they implicitly and secretly activate something you wanted deactivated and do something you didn't expect? When a selection is required for a command that does something with a selection, the command can not work when there is no selection, and it is a bug when it does so nonetheless, like through Emacs assuming there was a selection when there actually is none (because Emacs lacks the ability to distinguish if something is selected or not because its insistence on obsolete regions gets in the way). It's a clash between transient-mark-mode enabled and disabled. In one case, the behaviour is a bug because the mode suggests that commands doing something must not do it with regions but with selections (active regions); in the other, it's fine because there is always something for commands that do something with something to do what they do because there's always a region, and the second case implies that it is generally fine for software to make mistakes of the users worse rather than protecting them from them. Actually, the second case is merely a slip-up, like driving your car into the wall at full throttle and no seat belts on, either just because you can, or unintentionally. For some reason, only with transient-mark-mode enabled, this becomes obvious because it has been overlooked at least for the unintentional variant. It probably was never wanted even without transient-mark-mode, i. e. the intentional variant. Or why would I want something like upcase-region to suddenly mess up random parts of a buffer? A region is not a selection, it's only a random part of the buffer that has somehow gotten between mark and point, perhaps when mark and point were used for navigation, or when I moved around, or when the mark happened to be set somewhere last time I yanked something, or when the cat stepped over the keyboard while I was pressing Ctrl or when it hit the cursor keys ... > Other commands, which make sense both when there is and there isn't a > region, need an indication of what the user wants them to do, and > whether the region is active is that indication. The indication is whether there is a selection or not. Isn't that the idea behind transient-mark-mode, an idea that made this mode so successful that it became the default? When you do not want to limit a command to a region, you do not need a region, and the region is not needed here. When you want to limit or to extend a command, you can use a selection to limit or extend it to, and you don't need a region, either. > The problem is that we now want to introduce yet another, 3rd meaning > of the region, which is not identical to either of the other two. The problem is the region. It's not needed for anything and keeps getting in the way. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-15 22:37 ` hw @ 2018-09-16 0:22 ` Drew Adams 2018-09-16 3:15 ` hw 2018-09-16 16:48 ` Eli Zaretskii 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-16 0:22 UTC (permalink / raw) To: hw, Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, phillip.lord > You don't need a region for commands to work on, a selection is enough. > > That would allow to decouple navigation from (making) selections, and > the concept of a region becomes obsolete, removing all the entanglement > and greatly simplifying things. In case there are others who, like me, did not completely get this point from Hw, though he touched on it several times - My guess is that that is his main point, and it underlies other things he's touched on. (I could be wrong, and perhaps he will correct me.) I think this is yet another UI approach that is possible. I don't see it as in any way combining well with, or affecting, the behaviors we've been discussing. But it would be possible for someone to implement it, if someone is interested. In a sense, we have this already with the secondary selection. One thing we don't have for the secondary selection are ways to create or extend it other than using the mouse. (I have some ways in my library `second-sel.el', but vanilla Emacs has none, I believe.) That could easily be remedied. The main thing we don't have, out of the box, for use with the secondary selection are ways to do what users outside Emacs often do with a selection: in particular, d-s-m-style things such as type to replace and delete. That behavior too could be added. The main way in which the secondary selection does not fit what users outside Emacs are used to is that it involves the secondary, not the primary selection. What Hw wants is no doubt to be able to use the primary selection in these ways. I mention the secondary selection because it is maybe the closest thing that Emacs has to what Hw is describing, not because using the secondary selection for the kind of behavior he wants is the best approach. What is it about the secondary selection that makes me think that it is like what Hw describes? This: unlike the Emacs region, there is no requirement that either end of the selection be visible, i.e. on the screen, even when you act on it. By contrast, by design the Emacs region always has the cursor end of the region, i.e., point, on the screen. The secondary selection is similar to what you see in many other applications (browsers etc.): you can select text with the mouse, that text stays selected, and so highlighted, even if it is scrolled completely outside the visible area of the "page". And regardless of where it is currently (even offscreen), you can select a different bit of text somewhere instead (removing the previous selection). All of that is very much like how other apps treat the primary selection, I think. Some apps sometimes also let you type-to-replace the selection. Others do not; they make you explicitly use a key to cut the selected text. Dunno whether this comparison helps, but I think it helps me understand better some of what Hw has been saying. (Perhaps this was already obvious to others; dunno.) And maybe it helps Hw understand a bit more about the Emacs behavior, which absolutely requires that the cursor end of the region always be visible in the visible part of the screen. And yes, perhaps that basic Emacs tenet of keeping the cursor visible is partly rooted in the emphasis Emacs gives to the keyboard, and in its origin before the widespread use of pointing devices (mouse). In that context you pretty much always want the insertion point (aka text cursor) to be visible. You are not typically selecting text with a mouse and then acting on it. HTH. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 0:22 ` Drew Adams @ 2018-09-16 3:15 ` hw 2018-09-16 3:34 ` Drew Adams 2018-09-16 8:06 ` Yuri Khan 0 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-16 3:15 UTC (permalink / raw) To: Drew Adams Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: >> You don't need a region for commands to work on, a selection is enough. >> >> That would allow to decouple navigation from (making) selections, and >> the concept of a region becomes obsolete, removing all the entanglement >> and greatly simplifying things. > > In case there are others who, like me, did not completely get this > point from Hw, though he touched on it several times - Imagine Emacs without a region. Mark and point still exist, only there is no region. > [...] > What is it about the secondary selection that makes me > think that it is like what Hw describes? This: unlike the > Emacs region, there is no requirement that either end > of the selection be visible, i.e. on the screen, even when > you act on it. By contrast, by design the Emacs region > always has the cursor end of the region, i.e., point, on > the screen. This would be relevant for multiple selections because some of them might not be visible in a window/on screen. That's something you can't do with the secondary selection. I wasn't even aware that this might be difficult to understand because it is so fundamental with the Emacs region that one end of it is always visible. > [...] > And maybe it helps Hw understand a bit more about the > Emacs behavior, which absolutely requires that the cursor > end of the region always be visible in the visible part of the > screen. I never thought about that before you mentioned it. It seems quite natural when there is only one selection because I have no desire to scroll something off the screen I'm working with right now. Did you ever try joe? I haven't used it in years, but it usually comes with the distribution, so you might be able to try it, too. If you do, C-k h shows help. In joe, you make a selection by pressing C-k b to mark the beginning and C-k k to mark the end of the selection. The selection is called a block in joe. It is highlighted. You can change it any time by setting the marks again. Now you can copy the block with C-k c, meaning the whole block is inserted at point, and the copy is the new selection. The beginning and the end of a block (selection) can both be off screen. You can move around, and the block stays enabled and highlighted (Why can't Emacs do that?). When you delete the block, the block is gone and the start marker is being remembered. You can set a new end marker to create a new block without setting a new start marker. You can probably do more stuff with it, but it doesn't matter here. So there are a few things to note: + start and end marker of a selection do not need to be visible + the selection is entirely independent from navigation + the selection is persistent + the start marker is being remembered after the selection has been used + I can move, type and edit normally without endangering the selection as if it wasn't there And it is what I basically do with selections: I just make them when and where I need them. Only Emacs won't really let me do this because it forces me to drag this dreadful useless region around all the time. On top of that, some functions work with the region by either being limited to it or by being extended to it when it is highlighted while others work with the region when it's not highlighted, and it all depends on various modes and variables until nobody really knows anymore what it all does under what circumstances. Ok, Emacs is a bit more complicated than joe, but seriously? It's not all that different because you make a selection and then do stuff with it. Only Emacs makes this terrible with its inflexible and overloaded paradigm of "the region" which can be hidden, active or both in various ways, and is apparently important to some users even for navigation. But it can't really get much simpler, more obvious, more efficient and easier to use then in joe. Joe also protects my by not having a hidden region all the time, and I'm not going to loose the selection by mistake. Drew won't like it because there is no delete-selection-mode; I like it because there is none (or maybe there is and I don't know about it). > And yes, perhaps that basic Emacs tenet of keeping the > cursor visible is partly rooted in the emphasis Emacs gives > to the keyboard, and in its origin before the widespread > use of pointing devices (mouse). > > In that context you pretty much always want the insertion > point (aka text cursor) to be visible. You are not typically > selecting text with a mouse and then acting on it. The cursor is always visible in joe. That doesn't mean that a selection can not be persistent or that its end must always be visible. This is an Emacs problem because sticking to "the region" makes Emacs inflexible. I can imagine that this inflexibility may have been a reason for abusing the mark for navigation: What else can you do when you have no choice but to always stick to a fake selection ("the region") and aren't free to move around? Later the inflexibility brought someone to create transient-mark-mode, and it couldn't go all the way because Emacs remained tied up by its region. After some more evolution, Emacs is still being held back by its region ... I really hope you have a chance to try out joe, it might make what I'm trying to say much easier to understand. I'm not saying Emacs should be entirely the same as joe, they are too different for that --- only that this is an example of what I'm trying to say which you can try out --- and having it like that in Emacs in an Emacs-compatible way would be really cool. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-16 3:15 ` hw @ 2018-09-16 3:34 ` Drew Adams 2018-09-16 13:48 ` hw 2018-09-16 8:06 ` Yuri Khan 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-16 3:34 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, Eli Zaretskii, phillip.lord > So there are a few things to note: > > + start and end marker of a selection do not need to be visible > + the selection is entirely independent from navigation > + the selection is persistent > + the start marker is being remembered after the selection has been used > + I can move, type and edit normally without endangering the selection > as if it wasn't there Dunno what you mean by the 4th one. (Perhaps you mean that you can navigate back to it?) But all of the others, at least, are true of the secondary selection. That's why I said that I think the sec. sel. is the closest thing Emacs has that corresponds to the behavior you expect. > The cursor is always visible in joe. That doesn't mean that a selection > can not be persistent or that its end must always be visible. This is > an Emacs problem because sticking to "the region" makes Emacs > inflexible. I meant that Emacs always has point as one end of the region, and because (like editors typically) the cursor is always visible on the screen, so the point end of the region is always on screen. There is no association between the secondary selection and point, so the entire sec. sel. can move off screen. And it is "persistent" in the sense I think you mean (as opposed persisting across Emacs sessions). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 3:34 ` Drew Adams @ 2018-09-16 13:48 ` hw 2018-09-16 14:14 ` Alan Mackenzie ` (4 more replies) 0 siblings, 5 replies; 245+ messages in thread From: hw @ 2018-09-16 13:48 UTC (permalink / raw) To: Drew Adams Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: >> So there are a few things to note: >> >> + start and end marker of a selection do not need to be visible >> + the selection is entirely independent from navigation >> + the selection is persistent >> + the start marker is being remembered after the selection has been used >> + I can move, type and edit normally without endangering the selection >> as if it wasn't there > > Dunno what you mean by the 4th one. (Perhaps you mean that > you can navigate back to it?) It means it is much like the mark in Emacs in that is being remembered, but without dragging the region about all the time. You can navigate with both marks. > But all of the others, at least, are true of the secondary selection. > That's why I said that I think the sec. sel. is the closest thing > Emacs has that corresponds to the behavior you expect. > >> The cursor is always visible in joe. That doesn't mean that a selection >> can not be persistent or that its end must always be visible. This is >> an Emacs problem because sticking to "the region" makes Emacs >> inflexible. > > I meant that Emacs always has point as one end of the region, > and because (like editors typically) the cursor is always visible > on the screen, so the point end of the region is always on > screen. > > There is no association between the secondary selection and > point, so the entire sec. sel. can move off screen. And it is > "persistent" in the sense I think you mean (as opposed persisting > across Emacs sessions). Oh, I see what you mean! Emacs has point and (the end of) the region (selection) always entangled with no way to separate them or to disable the region. That is what I dislike so much, and it causes all kinds of issues. The secondary selection doesn't have all these problems, so it's a good example. Can we have a mode or something in which there is no association between point and the end of the region? Or can I just configure that association away? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 13:48 ` hw @ 2018-09-16 14:14 ` Alan Mackenzie 2018-09-17 21:00 ` hw 2018-09-16 15:28 ` Yuri Khan ` (3 subsequent siblings) 4 siblings, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-16 14:14 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, Eli Zaretskii, Drew Adams, phillip.lord Hello, hw. On Sun, Sep 16, 2018 at 15:48:10 +0200, hw wrote: > Oh, I see what you mean! > Emacs has point and (the end of) the region (selection) always entangled > with no way to separate them or to disable the region. You want to disable a portion of your buffer? That doesn't make any sense. > That is what I dislike so much, and it causes all kinds of issues. I do wish you could come to understand what the region is. It would save all sorts of problems for you. The region is not active, never being any sort of agent, and its existence is determined only by commands which operate on it. Point exists and mark exists. When you run a command with "-region" in its name, it operates on the buffer between point and mark. When you're not running such a command, the region has no significance. That's all. You are attributing problems to the region which really aren't there. A section of your buffer is not "always entangled with no way to separate [it]". If you don't want to do anything to the region, don't do it. And if you do something to it by mistake, which won't happen often, use undo. > The secondary selection doesn't have all these problems, so it's a good > example. > Can we have a mode or something in which there is no association between > point and the end of the region? Or can I just configure that > association away? Please learn what the region is. It is just a portion of your buffer. You cannot have point dissociated from some part of your buffer. That doesn't make any sense. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 14:14 ` Alan Mackenzie @ 2018-09-17 21:00 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-17 21:00 UTC (permalink / raw) To: Alan Mackenzie Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, Eli Zaretskii, Drew Adams, phillip.lord Alan Mackenzie <acm@muc.de> writes: > Hello, hw. > > On Sun, Sep 16, 2018 at 15:48:10 +0200, hw wrote: > >> Oh, I see what you mean! > >> Emacs has point and (the end of) the region (selection) always entangled >> with no way to separate them or to disable the region. > > You want to disable a portion of your buffer? That doesn't make any > sense. Portions of a buffer I don't want to do anything with do not need to be selected, active or part of a region. A region is not a portion of a buffer, it's a concept. The contents of a region reside within a buffer. Disabling the region would disable the concept, not its contents. Take a picture of a tree and delete the picture. Does that delete the tree? Should I take pictures of trees I don't care about only to do nothing with them? >> That is what I dislike so much, and it causes all kinds of issues. > > I do wish you could come to understand what the region is. It would save > all sorts of problems for you. The region is not active, When you have transient-mark-mode enabled, the region can be "active". The problem with transient-mark-mode is that even when the region should be disabled because nothing is selected and nothing is highlighted, it remains enabled unless you set mark to nil. > never being any sort of agent, A region can be evaluated. In that way, it as always an agent. If you mean that it doesn't tend to do anything all by itself, well, it doesn't do that, yet if the region didn't exist, it wouldn't be possible for it to do anything in the first place, and it couldn't be evaluated. However, I could argue that the region does something all by itself when transient-mark-mode is enabled, the region is not active and an operation like downcase-region happens because the region kinda activates itself for this unless mark-even-if-inactive is nil. So yes, it certainly has a life of its own, always. > and its existence is determined only by commands which operate on it. It doesn't matter which commands operate on it. It even exists when no commands operate on it, i. e. when it doesn't need to exist. > Point exists and mark exists. When you run a command > with "-region" in its name, it operates on the buffer between point and > mark. When you're not running such a command, the region has no > significance. That's all. The region has always significance while it exists. It can always be operated on. It is a fundamental concept of Emacs. This is important because I don't want to (accidentally) do something with a region only because it always exists. That's why I make a selection. I have transient-mark-mode enabled because I want my selection highlighted. That what I'm doing becomes limited to the region is merely a side-effect, no more. It is somewhat ironic that transient-mark-mode is required to be able to fortify the region against accidental use with mark-even-if-inactive. > You are attributing problems to the region which really aren't there. A > section of your buffer is not "always entangled with no way to separate > [it]". If you don't want to do anything to the region, don't do it. And > if you do something to it by mistake, which won't happen often, use undo. I didn't say that a section of the buffer is entangled. Point and mark are entangled with making selections, with regions and with navigation. >> The secondary selection doesn't have all these problems, so it's a good >> example. > >> Can we have a mode or something in which there is no association between >> point and the end of the region? Or can I just configure that >> association away? > > Please learn what the region is. It is just a portion of your buffer. > You cannot have point dissociated from some part of your buffer. That > doesn't make any sense. Please try out joe. You can see how these things work much easier there. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 13:48 ` hw 2018-09-16 14:14 ` Alan Mackenzie @ 2018-09-16 15:28 ` Yuri Khan 2018-09-16 16:30 ` Drew Adams ` (2 subsequent siblings) 4 siblings, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-16 15:28 UTC (permalink / raw) To: hw Cc: spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord On Sun, Sep 16, 2018 at 8:51 PM hw <hw@adminart.net> wrote: > Emacs has point and (the end of) the region (selection) always entangled > with no way to separate them or to disable the region. That is what I > dislike so much, and it causes all kinds of issues. > > Can we have a mode or something in which there is no association between > point and the end of the region? Or can I just configure that > association away? That would be hard. You’d probably want it to work for all commands, including third-party packages. Pretty much every command that acts on a block will assume it to be between point and mark. And a hypothetical wordstar-like-block-mode would not know if a command accesses point and mark as region boundaries or as a navigation stack. A serious approach to making persistent blocks a reality would probably involve the following: 1. Define a couple of functions, say ‘region-start’ and ‘region-end’. Initially, make them return (min (point) (mark)) and (max (point) (mark)), respectively. 2. Redefine (interactive "r") to use region-start and region-end. 3. Go through every function that uses (point) and (mark) to mean region boundaries, and change them to use region-start and region-end, too. 4. After that, make the behavior of region-start and region-end customizable, and have wordstar-like-mode customize them to return the appropriate marker values. 5. Do something about functions that activate the mark (shift-selection, mark-word, mark-sexp, mark-defun, …) so that they do the right thing to region markers. (No, I’m not going to work on that. But someone who Really Wanted to have a wordstar-like Emacs could try.) ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-16 13:48 ` hw 2018-09-16 14:14 ` Alan Mackenzie 2018-09-16 15:28 ` Yuri Khan @ 2018-09-16 16:30 ` Drew Adams 2018-09-16 16:59 ` Eli Zaretskii [not found] ` <<831s9tidjc.fsf@gnu.org> 4 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-16 16:30 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, Yuri Khan, acm, Eli Zaretskii, phillip.lord > > I meant that Emacs always has point as one end of the region, > > and because (like editors typically) the cursor is always visible > > on the screen, so the point end of the region is always on > > screen. > > > > There is no association between the secondary selection and > > point, so the entire sec. sel. can move off screen. And it is > > "persistent" in the sense I think you mean (as opposed persisting > > across Emacs sessions). > > Oh, I see what you mean! > > Emacs has point and (the end of) the region (selection) always entangled > with no way to separate them or to disable the region. That is what I > dislike so much, and it causes all kinds of issues. > > The secondary selection doesn't have all these problems, so it's a good > example. > > Can we have a mode or something in which there is no association between > point and the end of the region? Or can I just configure that association > away? See Yuri's reply about this question. But no, not the region. That's how the Emacs region is defined. If someone wants to implement such behavior, I'd add, to what Yuri said, that you likely do not want to change all current commands that use the region to use such a selection that is free from point. That likely would not make sense for some such commands. What he describes as a possible approach for adapting the spec (interactive "r"), for instance, might be better handled by using a new interactive code instead. For a different start, I'd suggest maybe starting with the secondary selection. Much of what would be needed is already in `second-sel.el', including being able to (1) set the sec. sel. from the Emacs region (as one way of creating/resetting it) and (2) set the primary selection from the secondary. And you should be able to pretty easily adapt this to just use the primary selection, if needed. `second-sel.el' also includes multiple selections, in this sense: it gives you a ring of secondary selections that works like the `kill-ring'. Yes, you meant also being able to use multiple selections _together_, at once, which is not how the `kill-ring' and `secondary-selection-ring' are used. They're designed for the standard use of `M-y': retrieving a past selection. Though using multiple selections together is not in `second-sel.el', it too should be easy to realize (and the same thing applies to using multiple entries of the `kill-ring' together). You would still want to also implement easily defining multiple selections in the way you describe for MS Windows. In Emacs the thing to be aware of in this context is the use of `C-M-w M-w' to append the selected text to the previous kill, instead of creating a new kill (i.e., a new `kill-ring' entry). There is currently nothing in `second-sel.el' that provides similar behavior for `secondary-selection-ring', but that could easily be added. Also, together with `second-sel.el', library `browse-kill-ring+.el', which extends library `browse-kill-ring.el', lets you use `M-y' at the top level to browse either the `secondary-selection-ring' or the ` kill-ring', or both, to choose a selection to yank. And `M-y' following a yank from either of these rings replaces that yank with the next (or the prefix-argth) ring entry. IOW, it does a `yank-pop' or a `yank-pop-secondary', as appropriate. Actually, `browse-kill-ring+.el' allows for any number of such rings of selections. And they could be adapted for use as sources for commands that use multiple selections together. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 13:48 ` hw ` (2 preceding siblings ...) 2018-09-16 16:30 ` Drew Adams @ 2018-09-16 16:59 ` Eli Zaretskii 2018-09-16 18:20 ` Yuri Khan 2018-09-17 21:22 ` hw [not found] ` <<831s9tidjc.fsf@gnu.org> 4 siblings, 2 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-16 16:59 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: hw <hw@adminart.net> > Date: Sun, 16 Sep 2018 15:48:10 +0200 > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, > emacs-devel@gnu.org, Yuri Khan <yurivkhan@gmail.com>, acm@muc.de, > Eli Zaretskii <eliz@gnu.org>, phillip.lord@russet.org.uk > > Emacs has point and (the end of) the region (selection) always entangled > with no way to separate them or to disable the region. That is what I > dislike so much, and it causes all kinds of issues. It is also why it is so convenient to define the region without using the mouse. With the current way of defining region, you just go to the other end, and you are immediately ready to invoke commands that operate on the region. How do you do that if point is not on one of the edges of the region, except by dragging the mouse? > The secondary selection doesn't have all these problems, so it's a good > example. The secondary selection can only be defined by mouse gestures. And it is not supported by any commands except those which interact with X selections. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 16:59 ` Eli Zaretskii @ 2018-09-16 18:20 ` Yuri Khan 2018-09-16 18:49 ` Eli Zaretskii 2018-09-16 20:17 ` Drew Adams 2018-09-17 21:22 ` hw 1 sibling, 2 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-16 18:20 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Drew Adams, Phillip Lord On Mon, Sep 17, 2018 at 12:00 AM Eli Zaretskii <eliz@gnu.org> wrote: > It is also why it is so convenient to define the region without using > the mouse. With the current way of defining region, you just go to > the other end, and you are immediately ready to invoke commands that > operate on the region. How do you do that if point is not on one of > the edges of the region, except by dragging the mouse? The point of persistent blocks is that you can mark a region and leave it for a while before actually doing something to it. It is not a goal to be able to mark a block somewhere far away without ever leaving your position. So: you move point to one end, press a key (or hold down Shift), move to the other end, press another key (or release Shift), move to the target position, press an action key (C-k c for copy, C-k v for move). All without killing anything. Very pacifistic. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 18:20 ` Yuri Khan @ 2018-09-16 18:49 ` Eli Zaretskii 2018-09-16 20:17 ` Drew Adams 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-16 18:49 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, drew.adams, phillip.lord > From: Yuri Khan <yurivkhan@gmail.com> > Date: Mon, 17 Sep 2018 01:20:19 +0700 > Cc: hw@adminart.net, Drew Adams <drew.adams@oracle.com>, spacibba@aol.com, > Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, > Emacs developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, > Phillip Lord <phillip.lord@russet.org.uk> > > The point of persistent blocks is that you can mark a region and leave > it for a while before actually doing something to it. It is not a goal > to be able to mark a block somewhere far away without ever leaving > your position. > > So: you move point to one end, press a key (or hold down Shift), move > to the other end, press another key (or release Shift), move to the > target position, press an action key (C-k c for copy, C-k v for move). > All without killing anything. Very pacifistic. And how, may I ask, you then indicate which of the "blocks" is to be acted upon by some command? More to the point, what does this feature have to do with delete-selection-mode and transient-mark-mode, and the issues we have with their mix? Or did this discussion wandered away without hope? ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-16 18:20 ` Yuri Khan 2018-09-16 18:49 ` Eli Zaretskii @ 2018-09-16 20:17 ` Drew Adams 1 sibling, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-16 20:17 UTC (permalink / raw) To: Yuri Khan, Eli Zaretskii Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Phillip Lord > > It is also why it is so convenient to define the region without using > > the mouse. With the current way of defining region, you just go to > > the other end, and you are immediately ready to invoke commands that > > operate on the region. How do you do that if point is not on one of > > the edges of the region, except by dragging the mouse? > > The point of persistent blocks is that you can mark a region and leave > it for a while before actually doing something to it. It is not a goal > to be able to mark a block somewhere far away without ever leaving > your position. > > So: you move point to one end, press a key (or hold down Shift), move > to the other end, press another key (or release Shift), move to the > target position, press an action key (C-k c for copy, C-k v for move). > All without killing anything. Very pacifistic. Yes. And that's the kind of behavior we have for the secondary selection. And how you set it interactively (or even by program) is not important to its behavior in this regard. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 16:59 ` Eli Zaretskii 2018-09-16 18:20 ` Yuri Khan @ 2018-09-17 21:22 ` hw 2018-09-18 12:14 ` Eli Zaretskii 1 sibling, 1 reply; 245+ messages in thread From: hw @ 2018-09-17 21:22 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Date: Sun, 16 Sep 2018 15:48:10 +0200 >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, >> emacs-devel@gnu.org, Yuri Khan <yurivkhan@gmail.com>, acm@muc.de, >> Eli Zaretskii <eliz@gnu.org>, phillip.lord@russet.org.uk >> >> Emacs has point and (the end of) the region (selection) always entangled >> with no way to separate them or to disable the region. That is what I >> dislike so much, and it causes all kinds of issues. > > It is also why it is so convenient to define the region without using > the mouse. With the current way of defining region, you just go to > the other end, and you are immediately ready to invoke commands that > operate on the region. How do you do that if point is not on one of > the edges of the region, except by dragging the mouse? Commands limited to the selection can work with the selection without a need to even have the selection displayed on screen. If you want to start making a selection where the cursor currently is, simply use the key binding to set a marker. Otherwise, navigate to where you want to set the marker first. You can use a trackball or not, it's unrelated. To be able to go to the other end of the selection, you first have to make one. There is no going to "the other end" of a region before a selection has been made, and once one has been made, there is no need to do that in order to do something with the selection --- unless operations supposed to do something with the selection don't do that because they start working from where point is rather than from where the start of the selection is. Such operations may need to be fixed. > [...] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 21:22 ` hw @ 2018-09-18 12:14 ` Eli Zaretskii 2018-09-18 23:45 ` hw 0 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 12:14 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: hw <hw@adminart.net> > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Mon, 17 Sep 2018 23:22:04 +0200 > > >> Emacs has point and (the end of) the region (selection) always entangled > >> with no way to separate them or to disable the region. That is what I > >> dislike so much, and it causes all kinds of issues. > > > > It is also why it is so convenient to define the region without using > > the mouse. With the current way of defining region, you just go to > > the other end, and you are immediately ready to invoke commands that > > operate on the region. How do you do that if point is not on one of > > the edges of the region, except by dragging the mouse? > > Commands limited to the selection can work with the selection without a > need to even have the selection displayed on screen. I don't see how this is relevant to the aspect of the Emacs region to which I was referring. > If you want to start making a selection where the cursor currently is, > simply use the key binding to set a marker. Otherwise, navigate to > where you want to set the marker first. You can use a trackball or not, > it's unrelated. How is this different from what we have now? > To be able to go to the other end of the selection, you first have to > make one. That's why Emacs has a lot of commands that mark significant portions of text: word, sentence, paragraph, sexp, etc. Emacs also has a matching set of cursor motion commands. It makes all of that easy. > There is no going to "the other end" of a region before a > selection has been made, and once one has been made, there is no need to > do that in order to do something with the selection Emacs does that the other way around, but the result is no less convenient and efficient. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 12:14 ` Eli Zaretskii @ 2018-09-18 23:45 ` hw 2018-09-19 5:41 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: hw @ 2018-09-18 23:45 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, >> drew.adams@oracle.com, phillip.lord@russet.org.uk >> Date: Mon, 17 Sep 2018 23:22:04 +0200 >> >> >> Emacs has point and (the end of) the region (selection) always entangled >> >> with no way to separate them or to disable the region. That is what I >> >> dislike so much, and it causes all kinds of issues. >> > >> > It is also why it is so convenient to define the region without using >> > the mouse. With the current way of defining region, you just go to >> > the other end, and you are immediately ready to invoke commands that >> > operate on the region. How do you do that if point is not on one of >> > the edges of the region, except by dragging the mouse? >> >> Commands limited to the selection can work with the selection without a >> need to even have the selection displayed on screen. > > I don't see how this is relevant to the aspect of the Emacs region to > which I was referring. It refers to your idea that it would be inconvenient having to use a pointing device to do something with a selection. >> If you want to start making a selection where the cursor currently is, >> simply use the key binding to set a marker. Otherwise, navigate to >> where you want to set the marker first. You can use a trackball or not, >> it's unrelated. > > How is this different from what we have now? If you were referring to a persistent selection, the difference would be that the persistent selection has two markers rather than only one. Still you do not need to use a pointing device. >> To be able to go to the other end of the selection, you first have to >> make one. > > That's why Emacs has a lot of commands that mark significant portions > of text: word, sentence, paragraph, sexp, etc. Emacs also has a > matching set of cursor motion commands. It makes all of that easy. You could even use a pointing device to select something. >> There is no going to "the other end" of a region before a >> selection has been made, and once one has been made, there is no need to >> do that in order to do something with the selection > > Emacs does that the other way around, but the result is no less > convenient and efficient. How do you go to the other end of a selection before it has been made, and why would you? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 23:45 ` hw @ 2018-09-19 5:41 ` Eli Zaretskii 2018-09-19 20:09 ` hw 0 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-19 5:41 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: hw <hw@adminart.net> > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Wed, 19 Sep 2018 01:45:59 +0200 > > >> >> Emacs has point and (the end of) the region (selection) always entangled > >> >> with no way to separate them or to disable the region. That is what I > >> >> dislike so much, and it causes all kinds of issues. > >> > > >> > It is also why it is so convenient to define the region without using > >> > the mouse. With the current way of defining region, you just go to > >> > the other end, and you are immediately ready to invoke commands that > >> > operate on the region. How do you do that if point is not on one of > >> > the edges of the region, except by dragging the mouse? > >> > >> Commands limited to the selection can work with the selection without a > >> need to even have the selection displayed on screen. > > > > I don't see how this is relevant to the aspect of the Emacs region to > > which I was referring. > > It refers to your idea that it would be inconvenient having to use a > pointing device to do something with a selection. In that case, the issue is still there, because the selection had to be created somehow, and that would be possible by mouse only. So the Emacs way is more convenient in many use cases. > You could even use a pointing device to select something. Of course. But it's a distraction to use a pointing device while typing. > >> There is no going to "the other end" of a region before a > >> selection has been made, and once one has been made, there is no need to > >> do that in order to do something with the selection > > > > Emacs does that the other way around, but the result is no less > > convenient and efficient. > > How do you go to the other end of a selection before it has been made, With cursor motion commands, of which Emacs has a lot, for the various meaningful portions of text (word, sentence, paragraph, sexp, etc.). > and why would you? To define the region as appropriate for the command I want to invoke. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-19 5:41 ` Eli Zaretskii @ 2018-09-19 20:09 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-19 20:09 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, >> drew.adams@oracle.com, phillip.lord@russet.org.uk >> Date: Wed, 19 Sep 2018 01:45:59 +0200 >> >> >> >> Emacs has point and (the end of) the region (selection) always entangled >> >> >> with no way to separate them or to disable the region. That is what I >> >> >> dislike so much, and it causes all kinds of issues. >> >> > >> >> > It is also why it is so convenient to define the region without using >> >> > the mouse. With the current way of defining region, you just go to >> >> > the other end, and you are immediately ready to invoke commands that >> >> > operate on the region. How do you do that if point is not on one of >> >> > the edges of the region, except by dragging the mouse? >> >> >> >> Commands limited to the selection can work with the selection without a >> >> need to even have the selection displayed on screen. >> > >> > I don't see how this is relevant to the aspect of the Emacs region to >> > which I was referring. >> >> It refers to your idea that it would be inconvenient having to use a >> pointing device to do something with a selection. > > In that case, the issue is still there, because the selection had to > be created somehow, and that would be possible by mouse only. So the > Emacs way is more convenient in many use cases. You do not need to use the trackball when you want to make a selection in joe. Why would it be required in Emacs? >> You could even use a pointing device to select something. > > Of course. But it's a distraction to use a pointing device while > typing. right >> >> There is no going to "the other end" of a region before a >> >> selection has been made, and once one has been made, there is no need to >> >> do that in order to do something with the selection >> > >> > Emacs does that the other way around, but the result is no less >> > convenient and efficient. >> >> How do you go to the other end of a selection before it has been made, > > With cursor motion commands, of which Emacs has a lot, for the various > meaningful portions of text (word, sentence, paragraph, sexp, etc.). How can these meaningful portions of text be at the end of a selection that hasn't been made yet? >> and why would you? > > To define the region as appropriate for the command I want to invoke. So you go somewhere first and make a selection before you can go to either end of it. ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<831s9tidjc.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<831s9tidjc.fsf@gnu.org> @ 2018-09-16 18:04 ` Drew Adams 2018-09-16 18:17 ` Eli Zaretskii [not found] ` <<83va75gvc8.fsf@gnu.org> [not found] ` <<CAP_d_8VcFjkQQxzgv+XUheE4Q33vNgbuGpGwtv2-dOEBuK7OeQ@mail.gmail.com> 1 sibling, 2 replies; 245+ messages in thread From: Drew Adams @ 2018-09-16 18:04 UTC (permalink / raw) To: Eli Zaretskii, hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > > The secondary selection doesn't have all these problems, > > so it's a good example. > > The secondary selection can only be defined by mouse gestures. In vanilla Emacs, yes. But not if you use `second-sel.el'. You can define (set) it in several ways using the keyboard (suggested keys shown): * Start secondary with `C-x C-M-SPC' (`set-secondary-start'). * End secondary with `C-x C-M-<return>' (`secondary-save-then-kill'). * Set secondary to the region by using a prefix arg with `C-M-y' (`secondary-yank|select|move|swap') The last of these does multiple things, depending on the prefix arg: * None: Yank secondary selection * Zero: Select secondary as region. I.e., put region where secondary is. * > 0: Move secondary to region. * < 0: Swap region and secondary. The last two of these are ways to set the secondary from the region. So just as you can set the region in multiple ways, so can you set the secondary. Each way of setting the region gives you a way to set the secondary. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 18:04 ` Drew Adams @ 2018-09-16 18:17 ` Eli Zaretskii [not found] ` <<83va75gvc8.fsf@gnu.org> 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-16 18:17 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > Date: Sun, 16 Sep 2018 11:04:50 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, > emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, > drew.adams@oracle.com, phillip.lord@russet.org.uk > > > > The secondary selection doesn't have all these problems, > > > so it's a good example. > > > > The secondary selection can only be defined by mouse gestures. > > In vanilla Emacs, yes. But not if you use `second-sel.el'. > > You can define (set) it in several ways using the keyboard (suggested keys shown): > > * Start secondary with `C-x C-M-SPC' (`set-secondary-start'). > * End secondary with `C-x C-M-<return>' (`secondary-save-then-kill'). Which ends the secondary at point position, something that was the main point of this discussion. Can you envision a way of setting a selection without the mouse, except when point is at one of the two ends of the selection? ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<83va75gvc8.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83va75gvc8.fsf@gnu.org> @ 2018-09-16 20:14 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-16 20:14 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > > > > The secondary selection doesn't have all these problems, > > > > so it's a good example. > > > > > > The secondary selection can only be defined by mouse gestures. > > > > In vanilla Emacs, yes. But not if you use `second-sel.el'. > > > > You can define (set) it in several ways using the keyboard (suggested keys > shown): > > > > * Start secondary with `C-x C-M-SPC' (`set-secondary-start'). > > * End secondary with `C-x C-M-<return>' (`secondary-save-then-kill'). > > Which ends the secondary at point position, something that was the > main point of this discussion. That's not the point you made, of the secondary only being defined by mouse gestures. My reply is to that point. > Can you envision a way of setting a selection without the mouse, > except when point is at one of the two ends of the selection? Of course I can. It can easily be set between any two positions. Neither end need have any relation to point. (And even in asking that you switched from "mouse gestures" to "selection".) (defun my-set-secondary (beg end) "Set the secondary selection to start at BEG and end at END." (setq mouse-secondary-start (make-marker)) (move-marker mouse-secondary-start beg) (move-overlay mouse-secondary-overlay beg end)) ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<CAP_d_8VcFjkQQxzgv+XUheE4Q33vNgbuGpGwtv2-dOEBuK7OeQ@mail.gmail.com>]
[parent not found: <<83tvmpgtwe.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83tvmpgtwe.fsf@gnu.org> @ 2018-09-16 20:29 ` Drew Adams 2018-09-17 5:28 ` Yuri Khan 0 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-16 20:29 UTC (permalink / raw) To: Eli Zaretskii, Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, drew.adams, phillip.lord > > The point of persistent blocks is that you can mark a region and leave > > it for a while before actually doing something to it. It is not a goal > > to be able to mark a block somewhere far away without ever leaving > > your position. > > > > So: you move point to one end, press a key (or hold down Shift), move > > to the other end, press another key (or release Shift), move to the > > target position, press an action key (C-k c for copy, C-k v for move). > > All without killing anything. Very pacifistic. > > And how, may I ask, you then indicate which of the "blocks" is to be > acted upon by some command? How do you choose anything in Emacs? There are many ways. To choose a kill (or to a secondary selection) using `browse-kill-ring', you cycle among those on the ring to get to the one you want. That's also an approach for choosing a previous search pattern for Isearch. But another common approach lets you use completion to choose. That's used even for selections (and buffer positions for navigation) by several libraries. Still another approach is to offer a menu of choices. (But I wonder why you even ask such a question.) > More to the point, what does this feature have to do with > delete-selection-mode and transient-mark-mode, and the issues we have > with their mix? Or did this discussion wandered away without hope? There are at least two threads (per their Subject lines) that have been discussing point, mark, region, selection, navigation, etc. in Emacs. Hw has put his preferences front and center in the discussions, and they have to do with the kind of thing discussed right here: defining and using stretches of text that do not necessarily have the cursor at one end. I too would like to see a narrower discussion that fits only the current Subject line. I would like to see that in addition the more far-ranging discussion, which I also welcome. But this Subject's actual thread, like the one it forked from, has been pretty wide-ranging throughout. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 20:29 ` Drew Adams @ 2018-09-17 5:28 ` Yuri Khan 0 siblings, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-17 5:28 UTC (permalink / raw) To: drew.adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, eliz, phillip.lord On Mon, Sep 17, 2018 at 3:29 AM Drew Adams <drew.adams@oracle.com> wrote: > > > The point of persistent blocks is that you can mark a region and leave > > > it for a while before actually doing something to it. It is not a goal > > > to be able to mark a block somewhere far away without ever leaving > > > your position. > > > > And how, may I ask, you then indicate which of the "blocks" is to be > > acted upon by some command? > > How do you choose anything in Emacs? There are many ways. […] > > (But I wonder why you even ask such a question.) No, it is a valid question, and possibly one of the reasons why persistent blocks went out of fashion. As I understand it, the pure persistent block model started out in single-buffer, single-window editors. In that setup, there is never more than one block. As soon as you have buffers and windows, the “which one?” question arises, and there are two major ways to answer it. * You can say the block is global; if you select a block in buffer B, then the block in buffer A is unselected. But this works against the general idea of block persistence. * Or you can say every buffer or window can have a block. Then you can have an easy gesture for copying/moving/deleting the block in the current buffer/window, but no natural way of direct inter-buffer or inter-window copying/moving. (Asking the user a question equivalent to “please type the first few characters of the selected region you’d like to copy and press TAB or, at your leisure, make your way through the 123 blocks currently active, one M-n at a time” is probably not the answer.) Several editors that had persistent blocks and multiple buffers arrived at the mixed model: persistent buffer-local blocks + clipboard. You can copy and move blocks within the current buffer directly, but if you want to copy or move across buffers, you go to the source buffer, copy or cut to clipboard, then go to the target buffer and paste. Of course you can also do that in a single buffer. So you now have two ways of doing the same things, and the less versatile one falls into disuse. You now use the clipboard for most copy and move operations. Now there is a subtle shift in your workflow. Before, you could mark a block, go to the target position, and press C-k v to move the block here. Now, when you cut, point is moved to where you cut from, because otherwise you could accidentally cut something and not notice it. So you cut right after selecting, and now persistent blocks lose most of the appeal. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 3:15 ` hw 2018-09-16 3:34 ` Drew Adams @ 2018-09-16 8:06 ` Yuri Khan 2018-09-16 13:36 ` hw 1 sibling, 1 reply; 245+ messages in thread From: Yuri Khan @ 2018-09-16 8:06 UTC (permalink / raw) To: hw Cc: spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord On Sun, Sep 16, 2018 at 10:15 AM hw <hw@adminart.net> wrote: > In joe, you make a selection by pressing C-k b to mark the beginning and > C-k k to mark the end of the selection. The selection is called a block > in joe. It is highlighted. You can change it any time by setting the > marks again. > > Now you can copy the block with C-k c, meaning the whole block is > inserted at point, and the copy is the new selection. The beginning and > the end of a block (selection) can both be off screen. I recognize this as the WordStar block/region/selection model. Yes, I, too, was quite used to it in my Turbo Pascal years (late ’90s). Later, I migrated to Windows and got used to its CUA-like model. (Emacs has a WordStar emulation in obsolete/ws-mode.el, but it is unusable because of several reasons: * It is unmaintained and obsolete. * It is a major mode, meaning no syntax highlight, no language-specific features, just text editing. * It does not highlight the block. * When deleting the block, it does not move point to where it was. This makes it possible to mark a block, scroll it off the screen, and delete it without realizing you did it.) I think it is instructive to compare a few selection/region/block models, all of which have been quite successful. * WordStar model: Block is delimited by two markers, and is highlighted. (Some implementations allow toggling the highlight; when highlight is off, markers are preserved but block commands are not available.) Moving the cursor or typing text does not affect block markers (except to adjust their positions to accommodate length changes). Basic block operations are: copy to point, move to point, delete, write to file, read from file. (The latter inserts the contents of the file at point and puts block markers around it.) * Brief model: Block is delimited by mark and point (like in Emacs). Pressing Alt+A starts selecting the corresponding type of block (which is highlighted); pressing the same key again removes the highlight. When selecting, newly typed text is inserted normally at point. Block operations are: cut, copy, paste, delete, write to file. When no block is highlighted, these act on the current line. * Windows model: Selection is defined by two positions, one of which is at point. Unshifted cursor movement cancels the selection, shifted cursor movement extends or shrinks it, text insertion replaces the selected text, and both Backspace and Delete delete the selected text. Selection operations are cut, copy, paste, and delete; when there is no selection, cut and copy are disabled, and Backspace and Delete act on one character backward and forward, respectively. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 8:06 ` Yuri Khan @ 2018-09-16 13:36 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-16 13:36 UTC (permalink / raw) To: Yuri Khan Cc: spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord Yuri Khan <yurivkhan@gmail.com> writes: > On Sun, Sep 16, 2018 at 10:15 AM hw <hw@adminart.net> wrote: > >> In joe, you make a selection by pressing C-k b to mark the beginning and >> C-k k to mark the end of the selection. The selection is called a block >> in joe. It is highlighted. You can change it any time by setting the >> marks again. >> >> Now you can copy the block with C-k c, meaning the whole block is >> inserted at point, and the copy is the new selection. The beginning and >> the end of a block (selection) can both be off screen. > > I recognize this as the WordStar block/region/selection model. Yes, I, > too, was quite used to it in my Turbo Pascal years (late ’90s). Later, > I migrated to Windows and got used to its CUA-like model. Yes, joe is "wordstarlike". You can start it with different names to get different key bindings, though, like jmacs is like Emacs. > [...] > I think it is instructive to compare a few selection/region/block > models, all of which have been quite successful. ,---- [ joe ] | New ways of selecting regions | The classic way is to hit ^K B at the beginning and ^K K at the | end. These set pointers called markb and markk. Once these are set | you can jump to markb with Esc B and jump to markk with Esc K. | | New way: hit Ctrl-Right Arrow to start selecting rightward. Each `---- The new ways refer to keys that don't work in a terminal unless you manage to somehow configure them. With mouse support, you use the mouse to select. There seems to be more to it because it seems that both pointers can be remembered, and operations on a block are not possible when there is no block highlighted. --- This also allows moving blocks, something that Emacs can't do. Also noteworthy: ,---- | How do I deselect a highlighted region? | After you are finished with some region operations, you can just | leave the highlighting on if you don´t mind it (but don´t acciden‐ | tally hit ^K Y). If it really bothers you, however, just hit ^K B | ^K K, to turn the highlighting off. | | Beginning with JOE 4.2, you can hit ^C to cancel the region selec‐ | tion. `---- > * WordStar model: Block is delimited by two markers, and is > highlighted. (Some implementations allow toggling the highlight; when > highlight is off, markers are preserved but block commands are not > available.) Moving the cursor or typing text does not affect block > markers (except to adjust their positions to accommodate length > changes). Basic block operations are: copy to point, move to point, > delete, write to file, read from file. (The latter inserts the > contents of the file at point and puts block markers around it.) + move block I like that. > * Brief model: Block is delimited by mark and point (like in Emacs). > Pressing Alt+A starts selecting the corresponding type of block (which > is highlighted); pressing the same key again removes the highlight. > When selecting, newly typed text is inserted normally at point. Block > operations are: cut, copy, paste, delete, write to file. When no block > is highlighted, these act on the current line. > > * Windows model: Selection is defined by two positions, one of which > is at point. Unshifted cursor movement cancels the selection, shifted > cursor movement extends or shrinks it, text insertion replaces the > selected text, and both Backspace and Delete delete the selected text. > Selection operations are cut, copy, paste, and delete; when there is > no selection, cut and copy are disabled, and Backspace and Delete act > on one character backward and forward, respectively. There are also multiple selections which you can usually make by holding control and clicking on something with the trackball to include it into a selection. I'm not sure if there is a version of that which works with text. The wordstar model could work with multiple selections. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 22:37 ` hw 2018-09-16 0:22 ` Drew Adams @ 2018-09-16 16:48 ` Eli Zaretskii 2018-09-17 22:11 ` hw 1 sibling, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-16 16:48 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: hw <hw@adminart.net> > Cc: Yuri Khan <yurivkhan@gmail.com>, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Sun, 16 Sep 2018 00:37:43 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > [...] > > The region is currently used for 3 purposes: navigation, invoking > > commands on a region of text, and delete-selection-mode. > > You don't need a region for commands to work on, a selection is enough. > > That would allow to decouple navigation from (making) selections, and > the concept of a region becomes obsolete, removing all the entanglement > and greatly simplifying things. You forget the kill-ring and the kill/yank commands. Those are almost exactly identical to what other apps give you with copy/paste, and the latter use selections. So the reasons Emacs implements selections using the region are more fundamental than just navigation. > > (If someone thinks that delete-selection-mode is a variant of > > "invoking commands on a region of text", they are mistaken, and this > > long discussion is one proof of that mistake.) > > That's why I said it's misguided in that it is an entirely different > idea. It's a very similar idea, see below. > > It should be clear from this discussion that there are fundamental > > tensions between these 3 purposes. The first two can be reconciled by > > using the "active" vs "inactive" region, something we already have. > > This distinction is needed because an Emacs buffer will almost always > > have a region, and therefore users need some knob to control whether a > > command should act on the region or on the entire buffer. (It is > > possible that we need some new command to "activate" the region, > > because the current method are IMO unsatisfactory: they require > > navigation, which is totally gratuitous.) > > Just use a selection for commands to work on? There's no need to > particularly activate a selected part of a buffer; it's kinda what a > selection is for. A region is not needed here, either. Once again: in Emacs, selection _is_ the region, and for some very good reasons. You can, of course, start inventing an Emacs that is based on selections. But if that Emacs will still support copy/paste inside Emacs and vis-a-vis other apps, if it will support commands that operate on the selected text and/or work different when some text is selected -- then what you will have at the end is the same Emacs, just one where the region is called "selection". OK, maybe you will lose the ability to do "C-x C-x" for navigation -- but to what purpose? It should be possible to introduce a separate feature of "selection", similar to what we already do with secondary-selection. But if you want commands and features to be sensitive to such a selection, you will have to write a lot of code and change a lot of commands. You are, of course, welcome to work on that, but my idea was to try a much simpler solution, one that doesn't need any significant changes in the infrastructure or the implementation of the relevant commands. If you do NOT entertain the possibility of introducing such a new kind of "selections", then it is IMO best to remember that in Emacs "selection" and 'region" are synonyms. By using these terms as if they were 2 different features you are just confusing this discussion. > > Instead of trying to reconcile them with some trick, we should > > consider introducing a new "state" of the region, > > You mean like a selection? :) Those do not require regions. Region and selection is the same thing in Emacs. > Since a region is obsolete, we could simply use C-spc to start making a > selection and another C-spc to finish it. How is that different from typing C-SPC to start a region? it isn't. > > or could be optionally activated by "C-x C-x" etc., given some > > optional setting. > > That is for navigation. No, it's also for "activating" the region (a.k.a. "selection"), which causes some commands to "sense" the selected text. > A region is not needed for navigation between two points. You only need > the two points, in this case, called mark and point. Just decouple them > from selections. You can't: selection in Emacs is the region. > Users preferring d-s-m could enable the deletion option of selections. > Then if they want to delete a selection, they can make one and overwrite > it. This doesn't need to be complicated. You are missing the point. The point is that sometimes the user doesn't want a selection to be replaced by a character she types, and other times she does. The issue at hand is how to design a UI that will allow both possibilities, without telling the users to turn on or off delete-selection-mode for that purpose. > >> With transient-mark-mode being the Emacs default, I’m inclined to > >> consider it a bug that certain commands act on the inactive region > >> when t-m-m is enabled, and possibly a flaw that (interactive "r") > >> makes it so easy to define such commands. > > > > It's not a bug, it's a feature: commands that make no sense without > > the region, like "upcase-region", should not need me to activate the > > region for them to do what I expect them. > > What when they implicitly and secretly activate something you wanted > deactivated and do something you didn't expect? "Parse error". Sorry, I don't understand what you meant here. > When a selection is required for a command that does something with a > selection, the command can not work when there is no selection, and it > is a bug when it does so nonetheless, like through Emacs assuming there > was a selection when there actually is none (because Emacs lacks the > ability to distinguish if something is selected or not because its > insistence on obsolete regions gets in the way). This flies in the face of a long tradition in Emacs to provide DWIMish operation, whereby if something makes a lot of sense in some specialized situation, Emacs should do that automatically, even if it deviates from the "normal" operation. A notable example is what C-t does when point is at end of line. So if some effect of a command would make sense when it is invoked without any "selection", we program Emacs to do that, and that is not a bug at all, it's why Emacs shines in many situations where other editors don't. > It's a clash between transient-mark-mode enabled and disabled. In one > case, the behaviour is a bug because the mode suggests that commands > doing something must not do it with regions but with selections (active > regions); in the other, it's fine because there is always something for > commands that do something with something to do what they do because > there's always a region, and the second case implies that it is > generally fine for software to make mistakes of the users worse rather > than protecting them from them. > > Actually, the second case is merely a slip-up, like driving your car > into the wall at full throttle and no seat belts on, either just because > you can, or unintentionally. For some reason, only with > transient-mark-mode enabled, this becomes obvious because it has been > overlooked at least for the unintentional variant. It probably was > never wanted even without transient-mark-mode, i. e. the intentional > variant. "Parse error". "One case"? "second case"? What is this about? > Or why would I want something like upcase-region to suddenly mess up > random parts of a buffer? Only they aren't random. > A region is not a selection, it's only a random part of the buffer > that has somehow gotten between mark and point, perhaps when mark > and point were used for navigation, or when I moved around, or when > the mark happened to be set somewhere last time I yanked something, > or when the cat stepped over the keyboard while I was pressing Ctrl > or when it hit the cursor keys ... The region _is_ selection in Emacs. If you want Emacs to do something with text in the region, you will redefine the region before invoking the command -- unless you know the region is already set up as you want it, e.g. because you have just yanked the text to which you want to apply the command. This is exactly why region and its integration with commands in Emacs is a very valuable feature. > > Other commands, which make sense both when there is and there isn't a > > region, need an indication of what the user wants them to do, and > > whether the region is active is that indication. > > The indication is whether there is a selection or not. Same thing. > The problem is the region. It's not needed for anything and keeps > getting in the way. Not in Emacs, it isn't. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 16:48 ` Eli Zaretskii @ 2018-09-17 22:11 ` hw 2018-09-17 22:44 ` Drew Adams 2018-09-18 12:31 ` Eli Zaretskii 0 siblings, 2 replies; 245+ messages in thread From: hw @ 2018-09-17 22:11 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Cc: Yuri Khan <yurivkhan@gmail.com>, spacibba@aol.com, >> joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, >> acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk >> Date: Sun, 16 Sep 2018 00:37:43 +0200 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > [...] >> > The region is currently used for 3 purposes: navigation, invoking >> > commands on a region of text, and delete-selection-mode. >> >> You don't need a region for commands to work on, a selection is enough. >> >> That would allow to decouple navigation from (making) selections, and >> the concept of a region becomes obsolete, removing all the entanglement >> and greatly simplifying things. > > You forget the kill-ring and the kill/yank commands. Those are almost > exactly identical to what other apps give you with copy/paste, and the > latter use selections. So the reasons Emacs implements selections > using the region are more fundamental than just navigation. What are these fundamental reasons? Other programs, like joe, allow you to use the selection for navigation without having a region. >> > (If someone thinks that delete-selection-mode is a variant of >> > "invoking commands on a region of text", they are mistaken, and this >> > long discussion is one proof of that mistake.) >> >> That's why I said it's misguided in that it is an entirely different >> idea. > > It's a very similar idea, see below. > >> > It should be clear from this discussion that there are fundamental >> > tensions between these 3 purposes. The first two can be reconciled by >> > using the "active" vs "inactive" region, something we already have. >> > This distinction is needed because an Emacs buffer will almost always >> > have a region, and therefore users need some knob to control whether a >> > command should act on the region or on the entire buffer. (It is >> > possible that we need some new command to "activate" the region, >> > because the current method are IMO unsatisfactory: they require >> > navigation, which is totally gratuitous.) >> >> Just use a selection for commands to work on? There's no need to >> particularly activate a selected part of a buffer; it's kinda what a >> selection is for. A region is not needed here, either. > > Once again: in Emacs, selection _is_ the region, and for some very > good reasons. Not to me. The selection is what becomes highlighted when I make one. > You can, of course, start inventing an Emacs that is based on > selections. But if that Emacs will still support copy/paste inside > Emacs and vis-a-vis other apps, if it will support commands that > operate on the selected text and/or work different when some text is > selected -- then what you will have at the end is the same Emacs, just > one where the region is called "selection". OK, maybe you will lose > the ability to do "C-x C-x" for navigation -- but to what purpose? I never use that, why would I? > It should be possible to introduce a separate feature of "selection", > similar to what we already do with secondary-selection. But if you > want commands and features to be sensitive to such a selection, you > will have to write a lot of code and change a lot of commands. You > are, of course, welcome to work on that, but my idea was to try a much > simpler solution, one that doesn't need any significant changes in the > infrastructure or the implementation of the relevant commands. Do you mean the one that solves some problems with delete-selection-mode by "arming" the region instead of activating it? I'd rather call it "disarming" because disarming before killing makes more sense than arming before killing :) IIUC, your idea is to *generally* either "activate" a region or to "disarm" it, depending on which behaviour a user wants. I'm not sure how this is different from delete-selection-mode, and I think it needs more variations: By setting mark-even-if-inactive to nil, I have "fortified" the region because nothing can be done with it unless it is "active". There are more variations, like disabling shift-selection and disabling making a selection with the trackball. That might make the region "protected". When it's also fortified, it would be "inert", unless it has been disarmed, in which case it would be "content". We'd have to find more funny names to designate all possible combinations of the fundamental variations. That would be the chance to throw out "active" and to replace it with "limiting". Then we could also have "highlightable", but that kinda throws out the concept of "the region" because we do not want the region to be highlighted all the time. Perhaps it could still be highlighted from starting to make the selection until something has been done with it when "highlightable" is desired. I would also want "marked", meaning that the mark is displayed. I like the idea because having a domain of fundamental region states that can be combined with each other can lead to more consistency, and the whole domain could be explained to users so they can get the behaviour they prefer by picking any combination of states. Currently, all the modes and options involved appear to be unrelated, and users may never find what suits them best because they don't know all the available options. Bringing them together in one domain would change that. > If you do NOT entertain the possibility of introducing such a new kind > of "selections", then it is IMO best to remember that in Emacs > "selection" and 'region" are synonyms. By using these terms as if > they were 2 different features you are just confusing this discussion. They actually *are* two different things for me. The selection is what I make to work with and what becomes highlighted. The region is something unwanted always lurking in the background waiting for me to make a mistake and making me feel uneasy. The problem is that Emacs is unable to make this important distinction. I could say that this confuses things. However, with mark-even-if-inactive set to nil, this lurking daemon has kinda been banished because it can only lurk and not do anything. >> > Instead of trying to reconcile them with some trick, we should >> > consider introducing a new "state" of the region, >> >> You mean like a selection? :) Those do not require regions. > > Region and selection is the same thing in Emacs. That's the problem ... >> Since a region is obsolete, we could simply use C-spc to start making a >> selection and another C-spc to finish it. > > How is that different from typing C-SPC to start a region? it isn't. It is different because the end of the region is also being marked and becomes independent from point. Using the same key binding is only intended to make it easy. >> > or could be optionally activated by "C-x C-x" etc., given some >> > optional setting. >> >> That is for navigation. > > No, it's also for "activating" the region (a.k.a. "selection"), which > causes some commands to "sense" the selected text. Navigating a buffer and making selections are two totally unrelated things. It doesn't make sense that the region be "navigating" (especially when it is not "active"). I might understand limiting navigation to the active region when transient-mark-mode is enabled --- but this doesn't come up because unfortunately, point can not be disentangled from the region. Besides, if a region was large enough that I would want to navigate it, I probably wouldn't want it highlighted. That would require "fortified" to be independent of "highlightable", which is currently not possible. >> A region is not needed for navigation between two points. You only need >> the two points, in this case, called mark and point. Just decouple them >> from selections. > > You can't: selection in Emacs is the region. That's the problem ... >> Users preferring d-s-m could enable the deletion option of selections. >> Then if they want to delete a selection, they can make one and overwrite >> it. This doesn't need to be complicated. > > You are missing the point. The point is that sometimes the user > doesn't want a selection to be replaced by a character she types, and > other times she does. The issue at hand is how to design a UI that > will allow both possibilities, without telling the users to turn on or > off delete-selection-mode for that purpose. Do you mean there is a big problem with delete-selection-mode when transient-mark-mode is disabled because then there is "maybe sometimes" a selection a user may want to replace by inserting characters? This problem wouldn't exist if the region could be disentangled from making selections. I'm not sure if it does exist because nobody would use d-s-m without t-m-m unless they wanted to do something that doesn't make sense. Other than that, Emacs would have to read the users` minds to figure out what they want with each character they insert. >> >> With transient-mark-mode being the Emacs default, I’m inclined to >> >> consider it a bug that certain commands act on the inactive region >> >> when t-m-m is enabled, and possibly a flaw that (interactive "r") >> >> makes it so easy to define such commands. >> > >> > It's not a bug, it's a feature: commands that make no sense without >> > the region, like "upcase-region", should not need me to activate the >> > region for them to do what I expect them. >> >> What when they implicitly and secretly activate something you wanted >> deactivated and do something you didn't expect? > > "Parse error". Sorry, I don't understand what you meant here. Upcase-region works without activating the region first though transient-mark-mode says that commands should be limited to the "active" region. So for upcase-region to work when no region is "active", it is as if the region is secretly activated so that upcase-region can work, and this may be unexpected. >> When a selection is required for a command that does something with a >> selection, the command can not work when there is no selection, and it >> is a bug when it does so nonetheless, like through Emacs assuming there >> was a selection when there actually is none (because Emacs lacks the >> ability to distinguish if something is selected or not because its >> insistence on obsolete regions gets in the way). > > This flies in the face of a long tradition in Emacs to provide DWIMish > operation, whereby if something makes a lot of sense in some > specialized situation, Emacs should do that automatically, even if it > deviates from the "normal" operation. A notable example is what C-t > does when point is at end of line. > > So if some effect of a command would make sense when it is invoked > without any "selection", we program Emacs to do that, and that is not > a bug at all, it's why Emacs shines in many situations where other > editors don't. That's a difficult thing because it creates inconsistencies. In this case, one problem is that the region is changing all the time through inserting characters (or files) and through navigation. That is actually always the problem, plus you can't even see the region and not even the mark. So MOTT, you have a region (which you call selection) that is entirely random, unlike a selection which has explicitly been made to contain what it is supposed to contain. You really can't call the region a selection. Nothing in particular has been selected, and things merely happen to have ended up the way they did and, because of technical limitations, a region is randomly formed. Now you have a mode the purpose of which is to limit commands to a region that has been made active. To make a region active, you have to select it, so you're actually making a selection. This mode is already inconsistent because it allows commands to do things with a region even when there is no active region, so these commands may do random things because the region is a random thing. You take that even further by having commands that imply doing something only with a region. Why would you expect a user who is working in a mode that limits commands doing things with a region to doing them with a selection to want to use commands implying they do something with a region? Why would you expect this user who wants to work with selections rather than with regions to want to work with regions instead? At least there needs to be a replacement for upcase-region and the like that work with the selection. In case of upcase-region, it could be called upcase. That would bring more consistency. BTW, upcase-dwim is flawed because it *extends* to the active region *if* the region contains more than one word. That contradicts transient-mark-mode and requires another state besides "limiting": "extending". However, upcase-dwim is also limited to the active region, so "limiting" together with "extending" can become a problem for region states because it becomes unclear again what exactly is desired. >> It's a clash between transient-mark-mode enabled and disabled. In one >> case, the behaviour is a bug because the mode suggests that commands >> doing something must not do it with regions but with selections (active >> regions); in the other, it's fine because there is always something for >> commands that do something with something to do what they do because >> there's always a region, and the second case implies that it is >> generally fine for software to make mistakes of the users worse rather >> than protecting them from them. >> >> Actually, the second case is merely a slip-up, like driving your car >> into the wall at full throttle and no seat belts on, either just because >> you can, or unintentionally. For some reason, only with >> transient-mark-mode enabled, this becomes obvious because it has been >> overlooked at least for the unintentional variant. It probably was >> never wanted even without transient-mark-mode, i. e. the intentional >> variant. > > "Parse error". "One case"? "second case"? What is this about? The two cases are the different results of the different behaviours caused by transient-mark-mode either enabled or disabled, as described. The same behaviour can be a bug or a design flaw, depending on t-m-m. That refers to operations that imply doing something with a region, like downcase-region. The design flaw was probably never intended. >> Or why would I want something like upcase-region to suddenly mess up >> random parts of a buffer? > > Only they aren't random. They are as random as the region, and the region is entirely random. >> A region is not a selection, it's only a random part of the buffer >> that has somehow gotten between mark and point, perhaps when mark >> and point were used for navigation, or when I moved around, or when >> the mark happened to be set somewhere last time I yanked something, >> or when the cat stepped over the keyboard while I was pressing Ctrl >> or when it hit the cursor keys ... > > The region _is_ selection in Emacs. That's the problem ... > If you want Emacs to do something with text in the region, you will > redefine the region before invoking the command I always do that. That's "making a selection", and it's the selection I work with, not the region. The only time the region is not random is when it is a(n active) selection. > -- unless you know the region is already set up as you want it, > e.g. because you have just yanked the text to which you want to apply > the command. I work with selections, not with regions. I can't even see the region. Before I yank text, the selection is gone because it goes away when copying. > This is exactly why region and its integration with commands in Emacs > is a very valuable feature. How is this inflexibility a valuable feature? >> > Other commands, which make sense both when there is and there isn't a >> > region, need an indication of what the user wants them to do, and >> > whether the region is active is that indication. >> >> The indication is whether there is a selection or not. > > Same thing. No, there is a big difference between a selection and a highlighted region. >> The problem is the region. It's not needed for anything and keeps >> getting in the way. > > Not in Emacs, it isn't. It is *the* problem. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-17 22:11 ` hw @ 2018-09-17 22:44 ` Drew Adams 2018-09-17 23:30 ` hw 2018-09-18 12:31 ` Eli Zaretskii 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-17 22:44 UTC (permalink / raw) To: hw, Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > nobody would use d-s-m without t-m-m unless they wanted to do > something that doesn't make sense. Actually, d-s-m requires t-m-m. It turns it on, and each time you try to use it it checks that t-m-m is on (if not, it does nothing). > transient-mark-mode says that commands should be limited to the "active" > region. No, it does not. It simply says that, when it is enabled: "the region is highlighted when the mark is active. ... Many commands change their behavior when Transient Mark mode is in effect and the mark is active, by acting on the region instead..." (That's from `C-h f transient-mark-mode'. Similarly for (emacs) `Disabled Transient Mark' and (elisp)`The Mark'.) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 22:44 ` Drew Adams @ 2018-09-17 23:30 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-17 23:30 UTC (permalink / raw) To: Drew Adams Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: >> nobody would use d-s-m without t-m-m unless they wanted to do >> something that doesn't make sense. > > Actually, d-s-m requires t-m-m. It turns it on, and each time you try > to use it it checks that t-m-m is on (if not, it does nothing). That makes sense. >> transient-mark-mode says that commands should be limited to the "active" >> region. > > No, it does not. It simply says that, when it is enabled: > > "the region is highlighted when the mark is active. > ... > Many commands change their behavior when Transient Mark mode is > in effect and the mark is active, by acting on the region instead..." > > (That's from `C-h f transient-mark-mode'. Similarly for (emacs) `Disabled > Transient Mark' and (elisp)`The Mark'.) Right, it does not very explicitly say that. Yet the distinction is "operating on the region" vs. "operating on the buffer". That is effectively a limitation unless you select the whole buffer. I suspect a limitation was the original idea and intention of transient-mark-mode while an extension was not. An extension wasn't even needed, so why would it have been intended? It probably never came to mind. Maybe someone knows for sure. In any case, isn't it useful for clarification to make a distinction between limiting and extending? Please explain why upcase-word is not extended to the active region but upcase-dwim is. The description of upcase-word doesn't say what effect transient-mark-mode and a(n active) region has on it. Shouldn't that be clarified? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 22:11 ` hw 2018-09-17 22:44 ` Drew Adams @ 2018-09-18 12:31 ` Eli Zaretskii 2018-09-18 13:14 ` Yuri Khan 2018-09-19 2:26 ` hw 1 sibling, 2 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 12:31 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: hw <hw@adminart.net> > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Tue, 18 Sep 2018 00:11:05 +0200 > > >> That would allow to decouple navigation from (making) selections, and > >> the concept of a region becomes obsolete, removing all the entanglement > >> and greatly simplifying things. > > > > You forget the kill-ring and the kill/yank commands. Those are almost > > exactly identical to what other apps give you with copy/paste, and the > > latter use selections. So the reasons Emacs implements selections > > using the region are more fundamental than just navigation. > > What are these fundamental reasons? They were just described above: the set of commands that copy/kill and paste text. > Other programs, like joe, allow you to use the selection for > navigation without having a region. Once again, in Emacs region _is_ the selection. > > Once again: in Emacs, selection _is_ the region, and for some very > > good reasons. > > Not to me. The selection is what becomes highlighted when I make one. That's a minor detail in Emacs. The underlying fundamental functionality is the region. > > You can, of course, start inventing an Emacs that is based on > > selections. But if that Emacs will still support copy/paste inside > > Emacs and vis-a-vis other apps, if it will support commands that > > operate on the selected text and/or work different when some text is > > selected -- then what you will have at the end is the same Emacs, just > > one where the region is called "selection". OK, maybe you will lose > > the ability to do "C-x C-x" for navigation -- but to what purpose? > > I never use that, why would I? Others do. Emacs caters to many different workflows, and it is fine not to have to use some of its features for which you don't have a need. But we cannot remove them just because you personally don't use them, can we? > Do you mean the one that solves some problems with delete-selection-mode > by "arming" the region instead of activating it? I'd rather call it > "disarming" because disarming before killing makes more sense than > arming before killing :) > > IIUC, your idea is to *generally* either "activate" a region or to > "disarm" it, depending on which behaviour a user wants. I'm not sure > how this is different from delete-selection-mode, and I think it needs > more variations: > > By setting mark-even-if-inactive to nil, I have "fortified" the region > because nothing can be done with it unless it is "active". > > There are more variations, like disabling shift-selection and disabling > making a selection with the trackball. That might make the region > "protected". When it's also fortified, it would be "inert", unless it > has been disarmed, in which case it would be "content". These word plays just muddy the waters. The basic point is to have more than just 2 states of the region, and allow various features behave differently by being sensitive to the current state of the region. > I like the idea because having a domain of fundamental region states > that can be combined with each other can lead to more consistency, and > the whole domain could be explained to users so they can get the > behaviour they prefer by picking any combination of states. Currently, > all the modes and options involved appear to be unrelated, and users may > never find what suits them best because they don't know all the > available options. Bringing them together in one domain would change > that. Good, so we agree. > They actually *are* two different things for me. The selection is what > I make to work with and what becomes highlighted. The region is > something unwanted always lurking in the background waiting for me to > make a mistake and making me feel uneasy. > > The problem is that Emacs is unable to make this important distinction. > I could say that this confuses things. Because in Emacs, selection _is_ the region. Adding a state property could allow us to make the distinction nonetheless. > Navigating a buffer and making selections are two totally unrelated > things. No, they are closely related, because in general you need to navigate to a place to mark it as beginning/ending a selection. > > You are missing the point. The point is that sometimes the user > > doesn't want a selection to be replaced by a character she types, and > > other times she does. The issue at hand is how to design a UI that > > will allow both possibilities, without telling the users to turn on or > > off delete-selection-mode for that purpose. > > Do you mean there is a big problem with delete-selection-mode when > transient-mark-mode is disabled because then there is "maybe sometimes" > a selection a user may want to replace by inserting characters? No, I mean delete-selection-mode changes the effects of some commands in ways that could be very inconvenient in some situations, and currently the only way for the user to deal with such conflicts is by turning on or off delete-selection-mode. There should be a better way of temporarily enabling/disabling delete-selection-mode, similar to what we have for transient-mark-mode. > Other than that, Emacs would have to read the users` minds to figure out > what they want with each character they insert. See above: I believe we can let the users speak their minds so that Emacs doesn't need to read them. > Upcase-region works without activating the region first though > transient-mark-mode says that commands should be limited to the "active" > region. So for upcase-region to work when no region is "active", it is > as if the region is secretly activated so that upcase-region can work, > and this may be unexpected. What do you want upcase-region to do when there's no active region, then? Doing nothing or signaling an error would go against Emacs's tradition of DWIM-ish operation. > > This flies in the face of a long tradition in Emacs to provide DWIMish > > operation, whereby if something makes a lot of sense in some > > specialized situation, Emacs should do that automatically, even if it > > deviates from the "normal" operation. A notable example is what C-t > > does when point is at end of line. > > > > So if some effect of a command would make sense when it is invoked > > without any "selection", we program Emacs to do that, and that is not > > a bug at all, it's why Emacs shines in many situations where other > > editors don't. > > That's a difficult thing because it creates inconsistencies. If what Emacs does is what the user would expect, what makes sense, then the inconsistencies don't matter. > >> Or why would I want something like upcase-region to suddenly mess up > >> random parts of a buffer? > > > > Only they aren't random. > > They are as random as the region, and the region is entirely random. I disagree. IME, it is never random when I want to act on it. > > If you want Emacs to do something with text in the region, you will > > redefine the region before invoking the command > > I always do that. That's "making a selection", and it's the selection I > work with, not the region. The only time the region is not random is > when it is a(n active) selection. Which always happens before you invoke a command that works on a region. And in some case, the region is already conveniently set to what you might want to act upon. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 12:31 ` Eli Zaretskii @ 2018-09-18 13:14 ` Yuri Khan 2018-09-18 14:14 ` Eli Zaretskii 2018-09-20 1:46 ` Richard Stallman 2018-09-19 2:26 ` hw 1 sibling, 2 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-18 13:14 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Drew Adams, Phillip Lord On Tue, Sep 18, 2018 at 7:32 PM Eli Zaretskii <eliz@gnu.org> wrote: > No, I mean delete-selection-mode changes the effects of some commands > in ways that could be very inconvenient in some situations, and > currently the only way for the user to deal with such conflicts is by > turning on or off delete-selection-mode. There should be a better way > of temporarily enabling/disabling delete-selection-mode, similar to > what we have for transient-mark-mode. What changes by delete-selection-mode cannot be worked around by (temporarily) deactivating the region? Initial state: some text before point is selected. We want to insert some text without replacing the selection. C-g <type some text> C-S-g Result: the same text + newly typed text is selected. Initial state: some text after point is selected. We want to yank something without replacing the selection. C-g C-y C-S-g Result: kill ring content inserted, same text is selected. (I am assuming C-S-g is bound to a command that activates the mark and does nothing else.) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 13:14 ` Yuri Khan @ 2018-09-18 14:14 ` Eli Zaretskii 2018-09-18 15:28 ` Yuri Khan 2018-09-20 1:46 ` Richard Stallman 1 sibling, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 14:14 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, drew.adams, phillip.lord > From: Yuri Khan <yurivkhan@gmail.com> > Date: Tue, 18 Sep 2018 20:14:41 +0700 > Cc: hw@adminart.net, spacibba@aol.com, > Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, > Emacs developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, Drew Adams <drew.adams@oracle.com>, > Phillip Lord <phillip.lord@russet.org.uk> > > On Tue, Sep 18, 2018 at 7:32 PM Eli Zaretskii <eliz@gnu.org> wrote: > > > No, I mean delete-selection-mode changes the effects of some commands > > in ways that could be very inconvenient in some situations, and > > currently the only way for the user to deal with such conflicts is by > > turning on or off delete-selection-mode. There should be a better way > > of temporarily enabling/disabling delete-selection-mode, similar to > > what we have for transient-mark-mode. > > What changes by delete-selection-mode cannot be worked around by > (temporarily) deactivating the region? Deactivating the region makes it disappear from view, which I think we should avoid. Users will not expect the region to disappear. Moreover, this is currently impossible, because your fictional C-S-g command doesn't exist. > Initial state: some text before point is selected. We want to insert > some text without replacing the selection. > > C-g <type some text> C-S-g > > Result: the same text + newly typed text is selected. If we are going to introduce a command for temporarily disabling or re-enabling the region, we had better do it without making it disappear from display, IMO. But in general, yes, that's the idea: introduce a state of the region whereby delete-selection-mode is temporarily suspended. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 14:14 ` Eli Zaretskii @ 2018-09-18 15:28 ` Yuri Khan 2018-09-18 15:37 ` Drew Adams 2018-09-18 16:46 ` Eli Zaretskii 0 siblings, 2 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-18 15:28 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Drew Adams, Phillip Lord On Tue, Sep 18, 2018 at 9:16 PM Eli Zaretskii <eliz@gnu.org> wrote: > > What changes by delete-selection-mode cannot be worked around by > > (temporarily) deactivating the region? > > Deactivating the region makes it disappear from view, which I think we > should avoid. Users will not expect the region to disappear. > Moreover, this is currently impossible, because your fictional C-S-g > command doesn't exist. Well, your hypothetical “disable-delete-selection-mode-temporarily” does not exist either. > If we are going to introduce a command for temporarily disabling or > re-enabling the region, we had better do it without making it > disappear from display, IMO. As a user of transient-mark-mode, shift-select-mode and delete-selection-mode, I’d expect to be among the target audience for this facility being discussed. But, strangely, I very rarely find myself in a situation where I have an active region that I want to preserve for later while wanting to type something. I am certainly okay with temporarily deactivating the mark and the region highlighting, if I know I’ll be easily able to re-activate it. How would a command to temporarily suspend delete-selection-mode work? I assume the user will have to press at least one key to invoke it. Then, I expect there will be an unpredictable sequence of self-insert and/or yank and/or other editing commands, so the user will also indicate the moment when he/she wants delete-selection-mode back. At this point, it is not going to be any more efficient than just binding delete-selection-mode to an easy key or binding C-S-g to (lambda () (interactive) (activate-mark)); each of these takes one keypress before and one keypress after typing-without-replacing-selection. Also, a user who enables and disables d-s-m often would need some kind of indication of its current status — either a modeline lighter or a special face for the region when it is active but will not be replaced by typing. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-18 15:28 ` Yuri Khan @ 2018-09-18 15:37 ` Drew Adams 2018-09-18 16:49 ` Eli Zaretskii 2018-09-18 16:46 ` Eli Zaretskii 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-18 15:37 UTC (permalink / raw) To: Yuri Khan, Eli Zaretskii Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Phillip Lord > > If we are going to introduce a command for temporarily disabling or > > re-enabling the region, we had better do it without making it > > disappear from display, IMO. > > As a user of transient-mark-mode, shift-select-mode and > delete-selection-mode, I’d expect to be among the target audience for > this facility being discussed. But, strangely, I very rarely find > myself in a situation where I have an active region that I want to > preserve for later while wanting to type something. I am certainly > okay with temporarily deactivating the mark and the region > highlighting, if I know I’ll be easily able to re-activate it. > > How would a command to temporarily suspend delete-selection-mode > work? > I assume the user will have to press at least one key to invoke it. > Then, I expect there will be an unpredictable sequence of self-insert > and/or yank and/or other editing commands, so the user will also > indicate the moment when he/she wants delete-selection-mode back. At > this point, it is not going to be any more efficient than just binding > delete-selection-mode to an easy key or binding C-S-g to (lambda () > (interactive) (activate-mark)); each of these takes one keypress > before and one keypress after typing-without-replacing-selection. > > Also, a user who enables and disables d-s-m often would need some kind > of indication of its current status — either a modeline lighter or a > special face for the region when it is active but will not be replaced > by typing. FWIW, Yuri said exactly what I would have said. What's the real use case for such temporary enabling/disabling of d-s-m? And how is it different from just, well, enabling/disabling d-s-m? You've said that you guess that at least some people will want to take advantage of d-s-m sometimes and sometimes not use it. OK, but maybe an example would help. In any case, how do you envision enabling/disabling d-s-m as something different from turning d-s-m on/off? If you want some key(s) to enable/disable it, how is that different from just binding a key (or keys) to `delete-selection-mode'? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 15:37 ` Drew Adams @ 2018-09-18 16:49 ` Eli Zaretskii 0 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 16:49 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > Date: Tue, 18 Sep 2018 08:37:12 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: hw@adminart.net, spacibba@aol.com, > Joost Kremers > <joostkremers@fastmail.fm>, > Noam Postavsky <npostavs@gmail.com>, > Emacs > developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, > Phillip Lord > <phillip.lord@russet.org.uk> > > What's the real use case for such temporary enabling/disabling of d-s-m? And how is it different from just, well, enabling/disabling d-s-m? People who are against turning on delete-selection-mode presented several such use cases. > In any case, how do you envision enabling/disabling d-s-m as something different from turning d-s-m on/off? If you want some key(s) to enable/disable it, how is that different from just binding a key (or keys) to `delete-selection-mode'? Why don't you ask the same question about transient-mark-mode? My idea was to extend the feature of region activation, which would avoid the need for turning on and off the mode. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 15:28 ` Yuri Khan 2018-09-18 15:37 ` Drew Adams @ 2018-09-18 16:46 ` Eli Zaretskii 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 16:46 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, drew.adams, phillip.lord > From: Yuri Khan <yurivkhan@gmail.com> > Date: Tue, 18 Sep 2018 22:28:23 +0700 > Cc: hw@adminart.net, spacibba@aol.com, > Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, > Emacs developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, Drew Adams <drew.adams@oracle.com>, > Phillip Lord <phillip.lord@russet.org.uk> > > On Tue, Sep 18, 2018 at 9:16 PM Eli Zaretskii <eliz@gnu.org> wrote: > > > > What changes by delete-selection-mode cannot be worked around by > > > (temporarily) deactivating the region? > > > > Deactivating the region makes it disappear from view, which I think we > > should avoid. Users will not expect the region to disappear. > > Moreover, this is currently impossible, because your fictional C-S-g > > command doesn't exist. > > Well, your hypothetical “disable-delete-selection-mode-temporarily” > does not exist either. Of course, it isn't. We are discussing what should we add to Emacs to make such actions possible. And my point is that as long as we are adding a feature, it would be better if it did not deactivate region, because doing so have certain disadvantages. > > If we are going to introduce a command for temporarily disabling or > > re-enabling the region, we had better do it without making it > > disappear from display, IMO. > > As a user of transient-mark-mode, shift-select-mode and > delete-selection-mode, I’d expect to be among the target audience for > this facility being discussed. But, strangely, I very rarely find > myself in a situation where I have an active region that I want to > preserve for later while wanting to type something. I am certainly > okay with temporarily deactivating the mark and the region > highlighting, if I know I’ll be easily able to re-activate it. Then perhaps we should have 2 variants of such a command, one that deactivates the region and another that doesn't. > How would a command to temporarily suspend delete-selection-mode work? > I assume the user will have to press at least one key to invoke it. > Then, I expect there will be an unpredictable sequence of self-insert > and/or yank and/or other editing commands, so the user will also > indicate the moment when he/she wants delete-selection-mode back. At > this point, it is not going to be any more efficient than just binding > delete-selection-mode to an easy key or binding C-S-g to (lambda () > (interactive) (activate-mark)); each of these takes one keypress > before and one keypress after typing-without-replacing-selection. It is not more efficient, but leaving the region highlighted might be preferable for use cases you don't care about. > Also, a user who enables and disables d-s-m often would need some kind > of indication of its current status — either a modeline lighter or a > special face for the region when it is active but will not be replaced > by typing. Agreed. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 13:14 ` Yuri Khan 2018-09-18 14:14 ` Eli Zaretskii @ 2018-09-20 1:46 ` Richard Stallman 2018-09-20 5:45 ` Yuri Khan 1 sibling, 1 reply; 245+ messages in thread From: Richard Stallman @ 2018-09-20 1:46 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, acm, eliz, drew.adams, phillip.lord [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > some text without replacing the selection. > C-g <type some text> C-S-g If C-S-g were given a suitable definition, that command sequence would do what you have in mind. However, it requires typing two extra characters, so it is an inconvenience in something that is currently easy and natural. It also requires remembering more. Sorry, I won't go along. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-20 1:46 ` Richard Stallman @ 2018-09-20 5:45 ` Yuri Khan 0 siblings, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-20 5:45 UTC (permalink / raw) To: rms Cc: hw, spacibba, Joost Kremers, Noam Postavsky, Emacs developers, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord On Thu, Sep 20, 2018 at 8:46 AM Richard Stallman <rms@gnu.org> wrote: > > some text without replacing the selection. > > > C-g <type some text> C-S-g > > If C-S-g were given a suitable definition, > that command sequence would do what you have in mind. > > However, it requires typing two extra characters, so it is an > inconvenience in something that is currently easy and natural. > It also requires remembering more. You are using the current default Emacs behavior (delete-selection-mode off) as the baseline for comparison. In that setup, yes, you can insert text right away. However, the context of discussion is when delete-selection-mode is on. In that setup, typing new text replaces the selection, and the assumption is that most new users expect that and want that behavior most of the time. So, in the rare case that one wants to insert text without replacing the active region, one has two options: a) Disable delete-selection-mode temporarily, insert new text, and then enable d-s-m again. This takes a minimum of two extra key presses, if d-s-m is bound to a key; more if it isn’t. b) Deactivate the region, insert new text, then reactivate the region. b0) As far as I can tell, currently, the most economical way to do that is C-g then C-x C-x (three extra key presses), and it has a side effect of exchanging mark and point. b1) A novice user will typically deactivate the region by doing a dummy point movement, either by clicking at the point, or by two mutually canceling motions: <left> <right>. After inserting new text, if they still need the region to be active, they will most probably re-select it, with whatever selection gesture they are used to (mouse or shift-selection). So my suggestion is no worse than the existing solutions. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 12:31 ` Eli Zaretskii 2018-09-18 13:14 ` Yuri Khan @ 2018-09-19 2:26 ` hw 2018-09-19 6:38 ` Eli Zaretskii 1 sibling, 1 reply; 245+ messages in thread From: hw @ 2018-09-19 2:26 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, >> drew.adams@oracle.com, phillip.lord@russet.org.uk >> Date: Tue, 18 Sep 2018 00:11:05 +0200 >> >> >> That would allow to decouple navigation from (making) selections, and >> >> the concept of a region becomes obsolete, removing all the entanglement >> >> and greatly simplifying things. >> > >> > You forget the kill-ring and the kill/yank commands. Those are almost >> > exactly identical to what other apps give you with copy/paste, and the >> > latter use selections. So the reasons Emacs implements selections >> > using the region are more fundamental than just navigation. >> >> What are these fundamental reasons? > > They were just described above: the set of commands that copy/kill and > paste text. I don't understand how being able to cut and paste selections becomes more fundamental than being able to navigate because all of those use the same fundamental concept. >> Other programs, like joe, allow you to use the selection for >> navigation without having a region. > > Once again, in Emacs region _is_ the selection. > >> > Once again: in Emacs, selection _is_ the region, and for some very >> > good reasons. >> >> Not to me. The selection is what becomes highlighted when I make one. > > That's a minor detail in Emacs. The underlying fundamental > functionality is the region. The distinction between a (the) selection and a (the) region is important and not a minor detail. For this distinction, it is pretty irrelevant how both are implemented. For practical usage, how both are implemented can be relevant. >> > You can, of course, start inventing an Emacs that is based on >> > selections. But if that Emacs will still support copy/paste inside >> > Emacs and vis-a-vis other apps, if it will support commands that >> > operate on the selected text and/or work different when some text is >> > selected -- then what you will have at the end is the same Emacs, just >> > one where the region is called "selection". OK, maybe you will lose >> > the ability to do "C-x C-x" for navigation -- but to what purpose? >> >> I never use that, why would I? > > Others do. Emacs caters to many different workflows, and it is fine > not to have to use some of its features for which you don't have a > need. But we cannot remove them just because you personally don't use > them, can we? I'm not suggesting to remove them. >> Do you mean the one that solves some problems with delete-selection-mode >> by "arming" the region instead of activating it? I'd rather call it >> "disarming" because disarming before killing makes more sense than >> arming before killing :) >> >> IIUC, your idea is to *generally* either "activate" a region or to >> "disarm" it, depending on which behaviour a user wants. I'm not sure >> how this is different from delete-selection-mode, and I think it needs >> more variations: >> >> By setting mark-even-if-inactive to nil, I have "fortified" the region >> because nothing can be done with it unless it is "active". >> >> There are more variations, like disabling shift-selection and disabling >> making a selection with the trackball. That might make the region >> "protected". When it's also fortified, it would be "inert", unless it >> has been disarmed, in which case it would be "content". > > These word plays just muddy the waters. It is sometimes an advantage when you can give something a name because the name can make it easier to understand and to remember. For example, "fortified" may be easier to remember than "state 00000101" or "state 5". > The basic point is to have more than just 2 states of the region, and > allow various features behave differently by being sensitive to the > current state of the region. > >> I like the idea because having a domain of fundamental region states >> that can be combined with each other can lead to more consistency, and >> the whole domain could be explained to users so they can get the >> behaviour they prefer by picking any combination of states. Currently, >> all the modes and options involved appear to be unrelated, and users may >> never find what suits them best because they don't know all the >> available options. Bringing them together in one domain would change >> that. > > Good, so we agree. I'm not sure, it seems to me that your idea is much different from how I thought it was. Do you mean the state to be general, like a default, or to be changed all the time depending on what a user wants and does? I suppose there would have to be some kind of default, and if users needed to change it or to somehow work around it all the time, it wouldn't look like a good default to me. >> They actually *are* two different things for me. The selection is what >> I make to work with and what becomes highlighted. The region is >> something unwanted always lurking in the background waiting for me to >> make a mistake and making me feel uneasy. >> >> The problem is that Emacs is unable to make this important distinction. >> I could say that this confuses things. > > Because in Emacs, selection _is_ the region. Adding a state property > could allow us to make the distinction nonetheless. You could consider transient-mark-mode as a state. How would you deal with its variations, are they states on their own? >> Navigating a buffer and making selections are two totally unrelated >> things. > > No, they are closely related, because in general you need to navigate > to a place to mark it as beginning/ending a selection. There are many other reasons to navigate than making selections. Having to go somewhere to make one is a special case and might not even fall under navigation because you can have navigated close to where you then make a selection. That means you're already there for other reasons and just need to move a little. There is a distinction between navigating and making a selection. >> > You are missing the point. The point is that sometimes the user >> > doesn't want a selection to be replaced by a character she types, and >> > other times she does. The issue at hand is how to design a UI that >> > will allow both possibilities, without telling the users to turn on or >> > off delete-selection-mode for that purpose. >> >> Do you mean there is a big problem with delete-selection-mode when >> transient-mark-mode is disabled because then there is "maybe sometimes" >> a selection a user may want to replace by inserting characters? > > No, I mean delete-selection-mode changes the effects of some commands > in ways that could be very inconvenient in some situations, and > currently the only way for the user to deal with such conflicts is by > turning on or off delete-selection-mode. There should be a better way > of temporarily enabling/disabling delete-selection-mode, similar to > what we have for transient-mark-mode. What if the commands were automatically prevented from having inconvenient effects? >> Other than that, Emacs would have to read the users` minds to figure out >> what they want with each character they insert. > > See above: I believe we can let the users speak their minds so that > Emacs doesn't need to read them. The amount of key bindings users are willing to learn and the number of defaults they are willing to change or to work around may be limited. >> Upcase-region works without activating the region first though >> transient-mark-mode says that commands should be limited to the "active" >> region. So for upcase-region to work when no region is "active", it is >> as if the region is secretly activated so that upcase-region can work, >> and this may be unexpected. > > What do you want upcase-region to do when there's no active region, > then? Doing nothing or signaling an error would go against Emacs's > tradition of DWIM-ish operation. The equivalent of not having a region when `transient-mark-mode' is disabled is not having an active region when `transient-mark-mode' is enabled. When `upcase-region' is called while the mark is nil, Emacs signals an error. Hence, when `transient-mark-mode' is enabled and the region is not active, `upcase-region' should signal an error. With transient-mark-mode enabled, the default should be mark-even-if-inactive set to nil. That would be more consistent: with this, Emacs signals an error when `upcase-region' is called while the region is not active. It's quite the enhancement `transient-mark-mode' can provide: it allows to actually fortify the region against accidental use. How can that be done when `transient-mark-mode' is disabled? Maybe you could consider this as an example for the "state idea" because it comes down to what the user wants. It's a default the user does not need to and will not want to work around, though. >> > This flies in the face of a long tradition in Emacs to provide DWIMish >> > operation, whereby if something makes a lot of sense in some >> > specialized situation, Emacs should do that automatically, even if it >> > deviates from the "normal" operation. A notable example is what C-t >> > does when point is at end of line. >> > >> > So if some effect of a command would make sense when it is invoked >> > without any "selection", we program Emacs to do that, and that is not >> > a bug at all, it's why Emacs shines in many situations where other >> > editors don't. >> >> That's a difficult thing because it creates inconsistencies. > > If what Emacs does is what the user would expect, what makes sense, > then the inconsistencies don't matter. When the user starts thinking about things, they can suddenly start to matter. Upcase-region and mark-even-if-inactive non-nil by default is a good example. >> >> Or why would I want something like upcase-region to suddenly mess up >> >> random parts of a buffer? >> > >> > Only they aren't random. >> >> They are as random as the region, and the region is entirely random. > > I disagree. IME, it is never random when I want to act on it. When you want to act on it, you have probably taken care so that it isn't random before you act. How is that different from making a selection to do something with before doing it? I'm assuming you don't want to do something with random parts of a buffer, and you seem to have confirmed that. >> > If you want Emacs to do something with text in the region, you will >> > redefine the region before invoking the command >> >> I always do that. That's "making a selection", and it's the selection I >> work with, not the region. The only time the region is not random is >> when it is a(n active) selection. > > Which always happens before you invoke a command that works on a > region. The selection I want to do something with doesn't form itself because it somehow just so happens. > And in some case, the region is already conveniently set to what you > might want to act upon. And I don't know when this happens because there is no indication of it. I might see it if the mark was visible and/or if point were to show the imaginary tail. I wouldn't mind writing something for it, but I have no idea where to start. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-19 2:26 ` hw @ 2018-09-19 6:38 ` Eli Zaretskii 2018-09-19 20:36 ` hw 0 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-19 6:38 UTC (permalink / raw) To: hw Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: hw <hw@adminart.net> > Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Wed, 19 Sep 2018 04:26:45 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: hw <hw@adminart.net> > >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, > >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, > >> drew.adams@oracle.com, phillip.lord@russet.org.uk > >> Date: Tue, 18 Sep 2018 00:11:05 +0200 > >> > >> >> That would allow to decouple navigation from (making) selections, and > >> >> the concept of a region becomes obsolete, removing all the entanglement > >> >> and greatly simplifying things. > >> > > >> > You forget the kill-ring and the kill/yank commands. Those are almost > >> > exactly identical to what other apps give you with copy/paste, and the > >> > latter use selections. So the reasons Emacs implements selections > >> > using the region are more fundamental than just navigation. > >> > >> What are these fundamental reasons? > > > > They were just described above: the set of commands that copy/kill and > > paste text. > > I don't understand how being able to cut and paste selections becomes > more fundamental than being able to navigate because all of those use > the same fundamental concept. It means if you lose the current meaning of the region, you also lose the cut/copy/paste commands, and their history on the kill-ring. > >> > Once again: in Emacs, selection _is_ the region, and for some very > >> > good reasons. > >> > >> Not to me. The selection is what becomes highlighted when I make one. > > > > That's a minor detail in Emacs. The underlying fundamental > > functionality is the region. > > The distinction between a (the) selection and a (the) region is > important and not a minor detail. For this distinction, it is pretty > irrelevant how both are implemented. This whole thread came to the existent because the underlying implementation is NOT irrelevant. > Do you mean the state to be general, like a default, or to be changed > all the time depending on what a user wants and does? I suppose there > would have to be some kind of default, and if users needed to change it > or to somehow work around it all the time, it wouldn't look like a good > default to me. That's the idea, but since the default should be OK most of the time, the need to override it should be rare. > You could consider transient-mark-mode as a state. How would you deal > with its variations, are they states on their own? For transient-mark-mode, the states are active and inactive. So a command that toggles the state would be something I have in mind. > > No, I mean delete-selection-mode changes the effects of some commands > > in ways that could be very inconvenient in some situations, and > > currently the only way for the user to deal with such conflicts is by > > turning on or off delete-selection-mode. There should be a better way > > of temporarily enabling/disabling delete-selection-mode, similar to > > what we have for transient-mark-mode. > > What if the commands were automatically prevented from having > inconvenient effects? That'd be nice, but I don't believe there's a way to do that without adversely affecting other important features. Hence I propose to place on the user the burden of preventing Emacs from having those inconvenient effects, assuming that each user chooses their defaults such that in most cases Emacs already does what the user expects. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-19 6:38 ` Eli Zaretskii @ 2018-09-19 20:36 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-19 20:36 UTC (permalink / raw) To: Eli Zaretskii Cc: spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, >> drew.adams@oracle.com, phillip.lord@russet.org.uk >> Date: Wed, 19 Sep 2018 04:26:45 +0200 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> >> From: hw <hw@adminart.net> >> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, >> >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de, >> >> drew.adams@oracle.com, phillip.lord@russet.org.uk >> >> Date: Tue, 18 Sep 2018 00:11:05 +0200 >> >> >> >> >> That would allow to decouple navigation from (making) selections, and >> >> >> the concept of a region becomes obsolete, removing all the entanglement >> >> >> and greatly simplifying things. >> >> > >> >> > You forget the kill-ring and the kill/yank commands. Those are almost >> >> > exactly identical to what other apps give you with copy/paste, and the >> >> > latter use selections. So the reasons Emacs implements selections >> >> > using the region are more fundamental than just navigation. >> >> >> >> What are these fundamental reasons? >> > >> > They were just described above: the set of commands that copy/kill and >> > paste text. >> >> I don't understand how being able to cut and paste selections becomes >> more fundamental than being able to navigate because all of those use >> the same fundamental concept. > > It means if you lose the current meaning of the region, you also lose > the cut/copy/paste commands, and their history on the kill-ring. They could just work with the selection instead. >> >> > Once again: in Emacs, selection _is_ the region, and for some very >> >> > good reasons. >> >> >> >> Not to me. The selection is what becomes highlighted when I make one. >> > >> > That's a minor detail in Emacs. The underlying fundamental >> > functionality is the region. >> >> The distinction between a (the) selection and a (the) region is >> important and not a minor detail. For this distinction, it is pretty >> irrelevant how both are implemented. > > This whole thread came to the existent because the underlying > implementation is NOT irrelevant. Is the implementation relevant for the distinction? The distinction between a region and a selection exists regardless of the implementation of each. >> Do you mean the state to be general, like a default, or to be changed >> all the time depending on what a user wants and does? I suppose there >> would have to be some kind of default, and if users needed to change it >> or to somehow work around it all the time, it wouldn't look like a good >> default to me. > > That's the idea, but since the default should be OK most of the time, > the need to override it should be rare. ok >> You could consider transient-mark-mode as a state. How would you deal >> with its variations, are they states on their own? > > For transient-mark-mode, the states are active and inactive. So a > command that toggles the state would be something I have in mind. The meaning of these states can vary through different behaviour resulting from changes to variables like delete-active-region and mark-even-if-inactive. These changes go so far as to make for different defaults on their own. A command that glides through all possible combinations of states and/or all possible defaults may have so many combinations to glide through that it would be troublesome to use. But if states/defaults could be stored in registers, users could quickly switch between those relevant for them. >> > No, I mean delete-selection-mode changes the effects of some commands >> > in ways that could be very inconvenient in some situations, and >> > currently the only way for the user to deal with such conflicts is by >> > turning on or off delete-selection-mode. There should be a better way >> > of temporarily enabling/disabling delete-selection-mode, similar to >> > what we have for transient-mark-mode. >> >> What if the commands were automatically prevented from having >> inconvenient effects? > > That'd be nice, but I don't believe there's a way to do that without > adversely affecting other important features. What would be an example for this? > Hence I propose to place on the user the burden of preventing Emacs > from having those inconvenient effects, assuming that each user > chooses their defaults such that in most cases Emacs already does what > the user expects. ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<874leq799e.fsf@toy.adminart.net>]
[parent not found: <<205df9be-2e5c-4cc4-a13a-7c80eb63bedc@default>]
[parent not found: <<87in363zgq.fsf@toy.adminart.net>]
[parent not found: <<aedad52c-aaf1-414d-bc8c-8e7d0284f4c8@default>]
[parent not found: <<835zz5ie17.fsf@gnu.org>]
[parent not found: <<87musg0wyf.fsf@toy.adminart.net>]
[parent not found: <<83va73f0mv.fsf@gnu.org>]
[parent not found: <<CAP_d_8WFoHecEv-krQmAP0fWVSYXDLWuwdKfXwpcLbkJYYfWJQ@mail.gmail.com>]
[parent not found: <<83musegaf2.fsf@gnu.org>]
[parent not found: <<CAP_d_8VH38kAdG3QZ4EiM_3-S+PVFg=7QyxZP6pZG_mc3Qct5w@mail.gmail.com>]
[parent not found: <<3f242636-6fa4-4e36-a37b-86f1d7088aae@default>]
[parent not found: <<83h8img39b.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83h8img39b.fsf@gnu.org> @ 2018-09-18 17:42 ` Drew Adams 2018-09-18 18:30 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-18 17:42 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > > What's the real use case for such temporary enabling/disabling of d-s-m? > > And how is it different from just, well, enabling/disabling d-s-m? > > People who are against turning on delete-selection-mode presented > several such use cases. I don't think so. I think you just postulated it, without any example. Did someone who is against using d-s-m actually say that s?he wanted to use it temporarily (and without turning d-s-m on, whatever that means)? But I could be wrong - it's a long thread. Feel free to point us to some mention by someone of such a use case. Or if that's not possible, please remind us of (describe) such a case. > > In any case, how do you envision enabling/disabling d-s-m as something > > different from turning d-s-m on/off? If you want some key(s) to > > enable/disable it, how is that different from just binding a key > > (or keys) to `delete-selection-mode'? > > Why don't you ask the same question about transient-mark-mode? Why do you think I should do that? What are you driving at? I don't have such a question about t-m-m. You seem to be proposing enabling/disabling d-s-m temporarily, and I'm asking what you envision about that. What's a use case for doing that, and how do you see someone doing it (other than by hitting a key bound to d-s-m, for example)? > My idea was to extend the feature of region activation, which > would avoid the need for turning on and off the mode. Why don't you please clarify that idea? What is it that you intend for users to do, to enable/disable d-s-m "temporarily"? And how is that different from (how does it "avoid") temporarily turning the mode on/off? Maybe I'm the only one who finds your proposal vague. I posted my questions about it only after it seemed that Yuri had the same, or similar questions. If you want me to understand - and I would like to, please try to elaborate. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 17:42 ` Drew Adams @ 2018-09-18 18:30 ` Eli Zaretskii 2018-09-18 19:15 ` Alan Mackenzie 0 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-18 18:30 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > Date: Tue, 18 Sep 2018 10:42:21 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: yurivkhan@gmail.com, hw@adminart.net, spacibba@aol.com, > joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, > acm@muc.de, phillip.lord@russet.org.uk > > > > What's the real use case for such temporary enabling/disabling of d-s-m? > > > And how is it different from just, well, enabling/disabling d-s-m? > > > > People who are against turning on delete-selection-mode presented > > several such use cases. > > I don't think so. I think you just postulated it, without any example. > Did someone who is against using d-s-m actually say that s?he > wanted to use it temporarily (and without turning d-s-m on, > whatever that means)? > > But I could be wrong - it's a long thread. Feel free to point us to > some mention by someone of such a use case. Or if that's not > possible, please remind us of (describe) such a case. Look for messages from Alan and Richard. I cannot afford searching for them, life is too short. > > > In any case, how do you envision enabling/disabling d-s-m as something > > > different from turning d-s-m on/off? If you want some key(s) to > > > enable/disable it, how is that different from just binding a key > > > (or keys) to `delete-selection-mode'? > > > > Why don't you ask the same question about transient-mark-mode? > > Why do you think I should do that? Because in that case we have a few commands that temporarily turn on transient-mark-mode. We don't tell users to turn it on and off explicitly. I thought it might be a good idea to have a similar feature for delete-selection-mode. > What's a use case for doing that, and how do you see someone > doing it (other than by hitting a key bound to d-s-m, for example)? See above: asked and answered. > > My idea was to extend the feature of region activation, which > > would avoid the need for turning on and off the mode. > > Why don't you please clarify that idea? What is it that you intend > for users to do, to enable/disable d-s-m "temporarily"? Something similar to what we do for turning on transient-mark-mode temporarily. > Maybe I'm the only one who finds your proposal vague. I posted > my questions about it only after it seemed that Yuri had the same, > or similar questions. If you want me to understand - and I would > like to, please try to elaborate. I explained the idea in so many words several times already. If it's still not clear, I guess I will have to give up. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-18 18:30 ` Eli Zaretskii @ 2018-09-18 19:15 ` Alan Mackenzie 0 siblings, 0 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-18 19:15 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, phillip.lord Hello, Eli and Drew. On Tue, Sep 18, 2018 at 21:30:28 +0300, Eli Zaretskii wrote: > > Date: Tue, 18 Sep 2018 10:42:21 -0700 (PDT) > > From: Drew Adams <drew.adams@oracle.com> > > Cc: yurivkhan@gmail.com, hw@adminart.net, spacibba@aol.com, > > joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, > > acm@muc.de, phillip.lord@russet.org.uk > > > > What's the real use case for such temporary enabling/disabling of d-s-m? > > > > And how is it different from just, well, enabling/disabling d-s-m? > > > People who are against turning on delete-selection-mode presented > > > several such use cases. > > I don't think so. I think you just postulated it, without any example. > > Did someone who is against using d-s-m actually say that s?he > > wanted to use it temporarily (and without turning d-s-m on, > > whatever that means)? > > But I could be wrong - it's a long thread. Feel free to point us to > > some mention by someone of such a use case. Or if that's not > > possible, please remind us of (describe) such a case. > Look for messages from Alan and Richard. I cannot afford searching > for them, life is too short. I think you mean the following reply to me, which I quote in full for Drew's benefit: ************************************************************************* Date: Sat, 15 Sep 2018 13:56:27 +0300 From: Eli Zaretskii <eliz@gnu.org> To: Alan Mackenzie <acm@muc.de> CC: drew.adams@oracle.com, yurivkhan@gmail.com, hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk Subject: Re: delete-selection-mode as default X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e > Date: Sat, 15 Sep 2018 10:20:16 +0000 > Cc: Drew Adams <drew.adams@oracle.com>, yurivkhan@gmail.com, > hw@adminart.net, > spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, > emacs-devel@gnu.org, phillip.lord@russet.org.uk > From: Alan Mackenzie <acm@muc.de> > > I can't help feeling that this isn't the right approach. I feel that > it > will increase complexity which the new features won't justify. I know > I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) > here, > but still: I think having to press a key sequence before d-s-m would > work > would take the purpose of d-s-m away - that key sequence might as well > be > C-w. People who want delete-selection-mode enabled by default won't need to type that additional key, because for them the region will already have the correct state. delete-selection-mode will take care of that. It is those who do NO want delete-selection-mode turned on by default, people like you and me, who will be ABLE to use delete-selection-mode by typing an extra key. Those users will also be capable of "activating" and "deactivating" the region like transient-mark-mode does with a single command, thus allowing them to invoke commands that act on an "active" region without turning on transient-mark-mode globally. > You seem to be proposing to associate a three-value state with the > region, which state users could change with key sequences. I can see > this being more confusing than the current two-value state (or is it > 2.5?) we currently have. It cannot be more confusing, because for those who already turn on transient-mark-mode and/or delete-selection-mode it leaves the matters exactly like they are. It actually should _improve_ on that by letting those users temporarily turn on/off those modes for the purposes of processing a given region by one or more commands. > It might well be that, having introduced transient-mark-mode as a > default, a certain degree of confusion in Emacs is unavoidable. If so, > does it make sense to spend a lot of effort which might merely switch > the > confusion to somewhere else? Assuming that we'd want to have options > to > retain all the "old" behaviour, I think it would be difficult to avoid > increasing the confusion. I hope you will now reconsider this remark. > I've interacted somewhat with hw, who's been driving this thread, and > come to the conclusion that he doesn't really want to use Emacs. That's irrelevant for the purposes of my proposal. I do want to use Emacs, and so I hope do you. ************************************************************************* And yes, Eli, I do want to use Emacs, very much so! I remain genuinely sceptical about the ideas for en/disabling delete-selection-mode. I'm convinced neither that they're a good idea, nor a bad idea. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 13:41 ` Yuri Khan ` (2 preceding siblings ...) 2018-09-14 14:33 ` Eli Zaretskii @ 2018-09-14 15:15 ` Elias Mårtenson 3 siblings, 0 replies; 245+ messages in thread From: Elias Mårtenson @ 2018-09-14 15:15 UTC (permalink / raw) To: Yuri Khan Cc: hw, spacibba, joostkremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, Drew Adams, Phillip Lord [-- Attachment #1: Type: text/plain, Size: 1619 bytes --] On Fri, 14 Sep 2018 at 21:43, Yuri Khan <yurivkhan@gmail.com> wrote: > One other thing that I want is that the region be highlighted if and > only if it is going to be the target of the next command I give, > because I like to look before I leap. It seems transient-mark-mode is > intended to give me this by adding the concept of active region and > highlighting the region when it is active. However, many commands act > on the region even if it is inactive. kill-region and > copy-region-as-kill are two such commands. I am sure there are many > more, because it is much easier to write: > > (defun my-command (BEGIN END) > (interactive "r") > ;; do something between BEGIN and END > ) > > than: > > (defun my-command (BEGIN END) > (interactive (if (use-region-p) > (list (min (point) (mark)) (max (point) (mark))) > ;; figure out what to do when no region is active > ;; * act on the whole buffer > ;; * act on the current narrowing > ;; * signal an error > ;; * do something else sensible > (list ?? ??))) > ;; do something between BEGIN and END > ) > I've seen functions implemented like that, and I would consider those buggy. It's going directly against the concept of the point and mark as being the region. I know some people want the same behaviour as gedit or whatever editor is default in desktop environments these days, but the Emacs way really is powerful and it would be useful if people who want to change things at least understood this concept first. Regards, Elias [-- Attachment #2: Type: text/html, Size: 2094 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-14 10:48 ` Alan Mackenzie 2018-09-14 13:41 ` Yuri Khan @ 2018-09-14 14:33 ` Drew Adams 2018-09-15 21:59 ` hw 2018-09-15 20:31 ` hw 2 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-14 14:33 UTC (permalink / raw) To: Alan Mackenzie, hw Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, phillip.lord > 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. 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. Actually, Emacs recognizes and has support for selections: the primary and secondary selections, if they exist. See (emacs) `Primary Selection'. But your main point is valid. The Emacs region can make use of or change the primary selection, but the two are not the same thing. And users can configure how much they want the region to interact with the primary selection. It is in part because of the existence of both the region (point and mark) and the primary selection that things can get complicated and users can choose quite different behaviors from each other. This is all Emacs - there is no one Emacs way when it comes to these things. But it is true that, however a user might choose to manifest it or have it behave, there is always the Emacs region (point and mark), as soon as a buffer has a mark. Keeping in mind the possible behaviors that other users might choose can be tricky, partly because we tend to know so well how "our" Emacs behaves and not so well how "their" Emacs behaves. When it comes to discussing what the default behavior should be, a prerequisite is that we try to learn about and keep in mind the "other" behaviors. Easier said than done, no doubt. Hw (and others): The behavior that Alan is describing - the one he chooses for Emacs, is the original Emacs region behavior. It is not some crazy, odd, or dangerous thing. It's a perfectly fine, efficient, and logical behavior. And yes, it is specific to Emacs - not known much, if at all, outside Emacs. It is no longer the default behavior, but it was for a long time. The current default behavior of Emacs wrt the region is what it is. In a way, I'd characterize it as being between two chairs, but it is not so bad or uncomfortable. I'd prefer that we turn on `delete-selection-mode' by default, but it's apparently already been decided (by RMS and Eli) that that won't happen just yet. Not a big deal. ---- We might want to consider making more obvious some of the main user choices regarding region, selection etc. I think it's not obvious to users, especially new users, what choices are available. I don't have a concrete suggestion of how we might do that, but I think there's probably room for improvement. The various variables, modes, etc. that control the behavior are here and there, and their presentation in the docs is also here and there. Depending on the choices you want, the notion and behavior of the region can have to do with cutting and pasting, navigation, acting on a stretch of text, narrowing, highlighting, mouse selection, and other things. You'll find some info in the docs under `Cut and Paste', some under other topics. And that's normal. The region affects almost everything, and it can behave differently for different uses and different people. But maybe there could also be some place where the modes and options that govern region-related behavior are discussed together. Dunno. I don't mean repeating what's said elsewhere in the doc, but somehow bringing these things together. A Customize group might be a start, though that wouldn't really provide an organized presentation of the main choices/approaches. Just wondering out loud, I guess. I don't have anything really to offer about this. I see a problem/opportunity more than a concrete solution in this regard. Whoever (Stefan?) suggested providing various high-level user "profiles" or whatever - behaviors to try on, had a good idea. For region-related behavior that could perhaps be as simple as defining some modes or options that combine existing modes and option values. If that were done then its presentation in the doc would maybe correspond to what I suggested (above) is missing. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 14:33 ` Drew Adams @ 2018-09-15 21:59 ` hw 0 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-15 21:59 UTC (permalink / raw) To: Drew Adams Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, phillip.lord Drew Adams <drew.adams@oracle.com> writes: > [...] > Hw (and others): The behavior that Alan is describing - the one > he chooses for Emacs, is the original Emacs region behavior. > It is not some crazy, odd, or dangerous thing. I know it's intended to be the way. Yet having a hidden region all the time always made me feel uneasy because it *is* dangerous to have a part of the buffer --- the extent of which is not really known and changes with every movement of point --- being always subject to commands that may delete it or do whatever with it when I happen to make a mistake. And I might not even realize having made the mistake because it all happens hidden. I remember when I learned about it, I immediately decided it's a very bad and dangerous thing to have and did my best to avoid it. So over the decades, I've become good at ignoring this stupid region thing and at not making mistakes that accidentally modify regions. That doesn't mean lurking hidden regions waiting for my mistakes are good, and it doesn't matter if that was the intended way. Not all of Emacs` ways are perfect, and this is a way I'd really like to see finally change. > It's a perfectly fine, efficient, and logical behavior. not to me And with evolutions like t-m-m and d-s-m it seems to have become more inconsistent, confusing and way too complicated. > [...] > I'd prefer that we turn > on `delete-selection-mode' by default, but it's apparently > already been decided (by RMS and Eli) that that won't > happen just yet. Not a big deal. Maybe it can happen once this mess has been cleaned up. > We might want to consider making more obvious some of > the main user choices regarding region, selection etc. I think > it's not obvious to users, especially new users, what choices > are available. I don't have a concrete suggestion of how we > might do that, but I think there's probably room for > improvement. > > The various variables, modes, etc. that control the behavior > are here and there, and their presentation in the docs is also > here and there. Depending on the choices you want, the > notion and behavior of the region can have to do with > cutting and pasting, navigation, acting on a stretch of text, > narrowing, highlighting, mouse selection, and other things. > [...] right an article and a tutorial ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 10:48 ` Alan Mackenzie 2018-09-14 13:41 ` Yuri Khan 2018-09-14 14:33 ` Drew Adams @ 2018-09-15 20:31 ` hw 2 siblings, 0 replies; 245+ messages in thread From: hw @ 2018-09-15 20:31 UTC (permalink / raw) To: Alan Mackenzie Cc: spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Eli Zaretskii, Drew Adams, phillip.lord Alan Mackenzie <acm@muc.de> 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 worse. > [...] > >> >> > 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? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 20:36 ` Drew Adams 2018-09-11 22:34 ` delete-selection-mode as default hw @ 2018-09-11 23:30 ` Juri Linkov 2018-09-12 0:13 ` Drew Adams 1 sibling, 1 reply; 245+ messages in thread From: Juri Linkov @ 2018-09-11 23:30 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, phillip.lord > But we should also offer a command that just activates the region, > nothing more. By default that would be unbound (or at most bound > to something other than `C-x C-x'). This is an interesting idea. Often there is need to type C-x four(!) times: first `C-x C-x' to activate the region, and another `C-x C-x' to put point back where it was before previous swapping point and mark with `C-x C-x' because some commands expect point to be at certain boundary of the region, like query-replace operating on the region with the initial position at the region beginning. So perhaps `activate-mark' should be a command, preferably bound to some easy to type key like `C-x C-SPC'. > `C-x C-x' bound to a command that just swaps point and mark > without activating the region `C-u C-x C-x' swaps point and mark without activating the region, so a new customizable option could invert the meaning of its prefix arg, and its default value could depend of whether d-s-m is active. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-11 23:30 ` Juri Linkov @ 2018-09-12 0:13 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-12 0:13 UTC (permalink / raw) To: Juri Linkov Cc: hw, spacibba, Joost Kremers, Noam Postavsky, emacs-devel, Alan Mackenzie, Eli Zaretskii, phillip.lord > > But we should also offer a command that just activates the region, > > nothing more. By default that would be unbound (or at most bound > > to something other than `C-x C-x'). > > This is an interesting idea. Often there is need to type C-x four(!) times: > first `C-x C-x' to activate the region, and another `C-x C-x' to put point > back where it was before previous swapping point and mark with `C-x C-x' > because some commands expect point to be at certain boundary of the region, > like query-replace operating on the region with the initial position > at the region beginning. > > So perhaps `activate-mark' should be a command, preferably > bound to some easy to type key like `C-x C-SPC'. That's taken by `pop-global-mark'. And users who have rebound it might well have rebound it to some similar action. Icicles binds it by default to ` icicle-goto-global-marker-or-pop-global-mark', which lets you navigate among local or global markers. Let's just have the command first, without binding it to a key. > > `C-x C-x' bound to a command that just swaps point and mark > > without activating the region > > `C-u C-x C-x' swaps point and mark without activating the region, > so a new customizable option could invert the meaning of its prefix arg, > and its default value could depend of whether d-s-m is active. Again, users who have rebound it might well have rebound it to some similar action. Icicles puts several alternative behaviors on `C-x C-x': 'exchange-point-and-mark' or save a region or select a saved region. With no prefix arg, invoke 'exchange-point-and-mark'. If you use library 'Bookmark+', then you can use a prefix arg. * Plain 'C-u': What vanilla Emacs does - temporary Transient Mark mode. * Plain 'C-u C-u': select (activate) one or more bookmarked regions. * Numeric prefix arg: bookmark (save) the active region using 'icicle-bookmark-cmd'. . Arg < 0: Prompt for the bookmark name. . Arg > 0: Do not prompt for the bookmark name. Use the buffer name plus a prefix of the region text as the bookmark name. . Arg = 0: Same as > 0, except do not overwrite any existing bookmark with the same name. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 20:39 ` delete-selection-mode as default (WAS: Some developement questions) Joost Kremers 2018-09-09 22:24 ` Drew Adams @ 2018-09-10 7:05 ` Eli Zaretskii 2018-09-10 13:41 ` delete-selection-mode as default Stefan Monnier 2018-09-11 4:22 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 1 sibling, 2 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-10 7:05 UTC (permalink / raw) To: Joost Kremers Cc: hw, spacibba, npostavs, emacs-devel, drew.adams, phillip.lord > From: Joost Kremers <joostkremers@fastmail.fm> > Cc: Noam Postavsky <npostavs@gmail.com>, hw@adminart.net, spacibba@aol.com, phillip.lord@russet.org.uk, drew.adams@oracle.com, emacs-devel@gnu.org > Date: Sun, 09 Sep 2018 22:39:54 +0200 > > what `delete-selection-mode` does is standard behaviour in most > software out there and most new users will take it for granted The _only_ problem I personally have with delete-selection-mode is that it also replaces the region created by the likes of "C-x C-x", something that "most software out there" does not and cannot do. If we were to change delete-selection-mode to replace only highlighted text created by mouse selections or by shift-selections, I think we could then enable it by default without much resistance, because typing a character or DEL after explicitly selecting text is many orders of magnitude less probable to be a mistake than when we make the region active by other means. I suspect that making the above happen would need to introduce a special kind of region, though. But if we want to present a UI and provide a UX similar to other editors, I don't see any other way. I think the conclusion from the transient-mark-mode experiment is that it is not up to the job we hoped it will do, due to conflicting requirements that cannot be reconciled by reasonably reliable heuristics. The traditional Emacs region cannot support delete-selection-mode and its traditional uses at the same time. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 7:05 ` delete-selection-mode as default (WAS: Some developement questions) Eli Zaretskii @ 2018-09-10 13:41 ` Stefan Monnier 2018-09-10 14:01 ` Eli Zaretskii ` (3 more replies) 2018-09-11 4:22 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 1 sibling, 4 replies; 245+ messages in thread From: Stefan Monnier @ 2018-09-10 13:41 UTC (permalink / raw) To: emacs-devel > The _only_ problem I personally have with delete-selection-mode is > that it also replaces the region created by the likes of "C-x C-x", > something that "most software out there" does not and cannot do. AFAIU the issue here is that you're using C-x C-x as navigation (a habit you might have gotten from the time when transient-mark-mode was disabled) rather than as a way to activate the region. So I think this is a not a problem with d-s-m but with C-x C-x. Also, I think it's a problem that comes from your habits, and if d-s-m had always been enabled you'd simply have different habits and wouldn't suffer from it. So I'm not sure it's an argument against d-s-m, really. Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 13:41 ` delete-selection-mode as default Stefan Monnier @ 2018-09-10 14:01 ` Eli Zaretskii 2018-09-10 14:19 ` Stefan Monnier 2018-09-10 14:24 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-10 14:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Mon, 10 Sep 2018 09:41:20 -0400 > > > The _only_ problem I personally have with delete-selection-mode is > > that it also replaces the region created by the likes of "C-x C-x", > > something that "most software out there" does not and cannot do. > > AFAIU the issue here is that you're using C-x C-x as navigation (a habit > you might have gotten from the time when transient-mark-mode was > disabled) rather than as a way to activate the region. > > So I think this is a not a problem with d-s-m but with C-x C-x. > > Also, I think it's a problem that comes from your habits, and if d-s-m > had always been enabled you'd simply have different habits and wouldn't > suffer from it. A lot of Emacs commands put a mark before moving "far away" (for some value of "far"), the reason being that the user might want to return there. What would you suggest as a "different habit" for returning to that previous place, instead of "C-x C-x"? And, btw, I find nothing wring with this habit of mine, the only problem here is that someone decided that "C-x C-x" should activate the region. > So I'm not sure it's an argument against d-s-m, really. Indeed, it could be an argument against "C-x C-x" and/or transient-mark-mode, except that "C-x C-x" was there first. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 14:01 ` Eli Zaretskii @ 2018-09-10 14:19 ` Stefan Monnier 0 siblings, 0 replies; 245+ messages in thread From: Stefan Monnier @ 2018-09-10 14:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > A lot of Emacs commands put a mark before moving "far away" (for some > value of "far"), the reason being that the user might want to return > there. What would you suggest as a "different habit" for returning to > that previous place, instead of "C-x C-x"? > And, btw, I find nothing wrong with this habit of mine, the only > problem here is that someone decided that "C-x C-x" should activate > the region. I don't find anything wrong with it either, but C-x C-x doesn't serve you well currently for this reason (this is a problem that affects more than d-s-m). It does two different (tho related) things, and for some users this isn't right. For use-cases like yours, you'd probably be better served by swapping the behavior of `C-x C-x` and `C-u C-x C-x` (i.e. make it so `C-x C-x` only activates the region if you specifically ask for it with C-u). Or split the two into two separate commands: - one to exchange mark and point. - another to (re)activate the region. >> So I'm not sure it's an argument against d-s-m, really. > Indeed, it could be an argument against "C-x C-x" and/or > transient-mark-mode, except that "C-x C-x" was there first. Exactly, Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-10 13:41 ` delete-selection-mode as default Stefan Monnier 2018-09-10 14:01 ` Eli Zaretskii @ 2018-09-10 14:24 ` Drew Adams [not found] ` <<83tvmxo3iy.fsf@gnu.org> [not found] ` <<<83tvmxo3iy.fsf@gnu.org> 3 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-10 14:24 UTC (permalink / raw) To: Stefan Monnier, emacs-devel > > The _only_ problem I personally have with delete-selection-mode is > > that it also replaces the region created by the likes of "C-x C-x", > > something that "most software out there" does not and cannot do. > > AFAIU the issue here is that you're using C-x C-x as navigation (a habit > you might have gotten from the time when transient-mark-mode was > disabled) rather than as a way to activate the region. > > So I think this is a not a problem with d-s-m but with C-x C-x. Exactly a point that I made too. From the moment that we introduced the notion of an "active" region (i.e. introduced `transient-mark-mode') the fact that a region is active means, in effect, that you expect to (because you are able to) do something with it. That's not necessarily the case for all uses of `C-x C-x'. When it's not the case, you can use `C-g' to deactivate it. And that's what you would (have to) do if `d-s-m' is enabled and you do not want to act on it (e.g. delete/replace it). If the annoyance for `d-s-m' for a particular user comes only from `C-x C-x' then a solution (for that user) is to have an equivalent of `C-x C-x' that does not activate (or that then deactivates) the region. > Also, I think it's a problem that comes from your habits, and if d-s-m > had always been enabled you'd simply have different habits and wouldn't > suffer from it. > > So I'm not sure it's an argument against d-s-m, really. ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<83tvmxo3iy.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83tvmxo3iy.fsf@gnu.org> @ 2018-09-10 14:30 ` Drew Adams 2018-09-10 14:54 ` Eli Zaretskii 2018-09-10 16:09 ` Yuri Khan 0 siblings, 2 replies; 245+ messages in thread From: Drew Adams @ 2018-09-10 14:30 UTC (permalink / raw) To: Eli Zaretskii, Stefan Monnier; +Cc: emacs-devel > And, btw, I find nothing wring with this habit of mine, the only > problem here is that someone decided that "C-x C-x" should activate > the region. Yes. `transient-mark-mode' does it. Consider a replacement for `C-x C-x' that does not activate the region. And a command to only activate it (without swapping point and mark), so you can still activate it on demand. Coupling swapping point and mark with activating the region - as the only way to do the former - was probably a mistake. It's OK to provide a command that couples the two, for convenience for those folks (most of us?) who want that. But perhaps we should now consider having two different commands (plus the convenience combo). > > So I'm not sure it's an argument against d-s-m, really. > > Indeed, it could be an argument against "C-x C-x" and/or > transient-mark-mode, except that "C-x C-x" was there first. Yes. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 14:30 ` Drew Adams @ 2018-09-10 14:54 ` Eli Zaretskii 2018-09-10 16:09 ` Yuri Khan 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-10 14:54 UTC (permalink / raw) To: Drew Adams; +Cc: monnier, emacs-devel > Date: Mon, 10 Sep 2018 07:30:08 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: emacs-devel@gnu.org > > > And, btw, I find nothing wring with this habit of mine, the only > > problem here is that someone decided that "C-x C-x" should activate > > the region. > > Yes. `transient-mark-mode' does it. > > Consider a replacement for `C-x C-x' that does not activate > the region. If you mean for everybody (i.e. by default), then I'd welcome patches to that effect, and maybe that would be a first step towards making delete-selection-mode on by default without annoying veteran Emacs users who are fast typist. If you mean for my own use, then it should be clear to you that my own problems with this were solved long ago by my customizations. All this thread is not about my usability problem, it's about everyone else. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-10 14:30 ` Drew Adams 2018-09-10 14:54 ` Eli Zaretskii @ 2018-09-10 16:09 ` Yuri Khan 1 sibling, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-10 16:09 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, Stefan Monnier, Emacs developers On Mon, Sep 10, 2018 at 9:34 PM Drew Adams <drew.adams@oracle.com> wrote: > Consider a replacement for `C-x C-x' that does not activate > the region. FWIW, with cua-mode active: === C-x C-x runs the command cua-exchange-point-and-mark (found in cua-global-keymap), which is an interactive compiled Lisp function in ‘cua-base.el’. It is bound to C-x C-x. (cua-exchange-point-and-mark ARG) Exchange point and mark. Don’t activate the mark if ‘cua-enable-cua-keys’ is non-nil. Otherwise, just activate the mark if a prefix ARG is given. See also ‘exchange-point-and-mark’. === ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<<83tvmxo3iy.fsf@gnu.org>]
[parent not found: <<c7872ab4-8a1b-43bc-aeb4-2d08bc899857@default>]
[parent not found: <<83muspo12f.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83muspo12f.fsf@gnu.org> @ 2018-09-10 15:25 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-10 15:25 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: monnier, emacs-devel > > > And, btw, I find nothing wring with this habit of mine, the only > > > problem here is that someone decided that "C-x C-x" should activate > > > the region. > > > > Yes. `transient-mark-mode' does it. > > > > Consider a replacement for `C-x C-x' that does not activate > > the region. > > If you mean for everybody (i.e. by default), then I'd welcome patches > to that effect, and maybe that would be a first step towards making > delete-selection-mode on by default without annoying veteran Emacs > users who are fast typist. I meant that it might help for Emacs to provide such things. I think that we should have decoupled point-mark swapping from region activation from the beginning, but we should also have provided a command that combines them (instead of only the latter, as `C-x C-x'). Personally, I'd like to see both d-s-m turned on by default and `C-x C-x' bound to a command that does what it does now (activates and swaps). But users should be able to choose: (1) not to use d-s-m, (2) to swap point and mark without activating the region. If d-s-m is not on by default, then the question is whether to change the default behavior of `C-x C-x'. I don't have an opinion about that, but maybe we shouldn't change it at this point. If we don't turn on d-s-m then it should be enough to provide the decoupling. But if long-time users who dislike d-s-m don't actually take advantage of the decoupling then that might not really ease the way toward a possible future enabling of d-s-m by default. > If you mean for my own use, then it should be clear to you that my own > problems with this were solved long ago by my customizations. All > this thread is not about my usability problem, it's about everyone > else. Right; this discussion not particularly about your use or my use. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-10 7:05 ` delete-selection-mode as default (WAS: Some developement questions) Eli Zaretskii 2018-09-10 13:41 ` delete-selection-mode as default Stefan Monnier @ 2018-09-11 4:22 ` Richard Stallman 2018-09-11 7:48 ` Eli Zaretskii ` (2 more replies) 1 sibling, 3 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-11 4:22 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, drew.adams, phillip.lord [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The _only_ problem I personally have with delete-selection-mode is > that it also replaces the region created by the likes of "C-x C-x", > something that "most software out there" does not and cannot do. I agree. What I want to happen after I make a region with ordinary Emacs commands, including C-SPC M-f and C-x C-x, is this: * It is active. * It is highlighted. * DEL does not delete it. * self-insert does not delete it. However, marking a region with the mouse is a different case. If DEL and self-insert were to delete such a region, I would not object. As for shift selection, that uses keyboard commands, so I think it is natural to treat them like other keyboard commands in this regard. But I don't use shift selection, so I would be inclined to follow the preferences of users that really do use shift selection. I'd create a separate setting to control this case, then set the default based on their preferences. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-11 4:22 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman @ 2018-09-11 7:48 ` Eli Zaretskii 2018-09-12 0:33 ` Richard Stallman 2018-09-11 8:08 ` Eli Zaretskii 2018-09-11 12:36 ` delete-selection-mode as default Stefan Monnier 2 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-11 7:48 UTC (permalink / raw) To: rms Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, drew.adams, phillip.lord > From: Richard Stallman <rms@gnu.org> > Cc: joostkremers@fastmail.fm, hw@adminart.net, spacibba@aol.com, > npostavs@gmail.com, emacs-devel@gnu.org, > drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Tue, 11 Sep 2018 00:22:18 -0400 > > As for shift selection, that uses keyboard commands, so I think it is > natural to treat them like other keyboard commands in this regard. > But I don't use shift selection, so I would be inclined to follow the > preferences of users that really do use shift selection. I'd create > a separate setting to control this case, then set the default based on > their preferences. Shift selection follows a feature of many applications out there, and AFAIK they all behave with such selections as with mouse selections. It is actually a more fine-grained selection mechanism, since mouse selection frequently doesn't let you select partial words, or exclude punctuation from the selection, at least not easily. So I think we don't need a separate option for shift selection, it already behaves like those who use it expect. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-11 7:48 ` Eli Zaretskii @ 2018-09-12 0:33 ` Richard Stallman 0 siblings, 0 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-12 0:33 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, drew.adams, phillip.lord [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > So I think we don't need a separate option for shift selection, If treating it like mouse selection makes people happy, fine with me. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-11 4:22 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2018-09-11 7:48 ` Eli Zaretskii @ 2018-09-11 8:08 ` Eli Zaretskii 2018-09-12 0:33 ` Richard Stallman 2018-09-11 12:36 ` delete-selection-mode as default Stefan Monnier 2 siblings, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-11 8:08 UTC (permalink / raw) To: rms Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, drew.adams, phillip.lord > From: Richard Stallman <rms@gnu.org> > Date: Tue, 11 Sep 2018 00:22:18 -0400 > Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, > npostavs@gmail.com, emacs-devel@gnu.org, drew.adams@oracle.com, > phillip.lord@russet.org.uk > > What I want to happen after I make a region with ordinary Emacs > commands, including C-SPC M-f and C-x C-x, is this: > > * It is active. > * It is highlighted. > * DEL does not delete it. > * self-insert does not delete it. Can you tell why you need it active and highlighted? Because otherwise, this is tantamount to turning off transient-mark-mode. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-11 8:08 ` Eli Zaretskii @ 2018-09-12 0:33 ` Richard Stallman 2018-09-12 14:07 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: Richard Stallman @ 2018-09-12 0:33 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, drew.adams, phillip.lord [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > * It is active. > > * It is highlighted. > > * DEL does not delete it. > > * self-insert does not delete it. > Can you tell why you need it active and highlighted? Because > otherwise, this is tantamount to turning off transient-mark-mode. It has to be active because C-x C-x is the way to activate the region without changing it. C-x C-x is also a way to make the region highlighted. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-12 0:33 ` Richard Stallman @ 2018-09-12 14:07 ` Eli Zaretskii 0 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-12 14:07 UTC (permalink / raw) To: rms Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, drew.adams, phillip.lord > From: Richard Stallman <rms@gnu.org> > Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm, > npostavs@gmail.com, emacs-devel@gnu.org, > drew.adams@oracle.com, phillip.lord@russet.org.uk > Date: Tue, 11 Sep 2018 20:33:05 -0400 > > > > * It is active. > > > * It is highlighted. > > > * DEL does not delete it. > > > * self-insert does not delete it. > > > Can you tell why you need it active and highlighted? Because > > otherwise, this is tantamount to turning off transient-mark-mode. > > It has to be active because C-x C-x is the way to activate the region > without changing it. > > C-x C-x is also a way to make the region highlighted. I guess I didn't explain myself clearly enough. What I was asking was why you need the region active? what features you want to use require that the region be active? what will you miss if "C-x C-x", "C-SPC M-f" etc. will not activate the region? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-11 4:22 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2018-09-11 7:48 ` Eli Zaretskii 2018-09-11 8:08 ` Eli Zaretskii @ 2018-09-11 12:36 ` Stefan Monnier 2018-09-11 23:09 ` hw 2018-09-12 0:33 ` Richard Stallman 2 siblings, 2 replies; 245+ messages in thread From: Stefan Monnier @ 2018-09-11 12:36 UTC (permalink / raw) To: emacs-devel > I agree. What I want to happen after I make a region with ordinary > Emacs commands, including C-SPC M-f and C-x C-x, is this: > > * It is active. > * It is highlighted. > * DEL does not delete it. > * self-insert does not delete it. DEL has been deleting the active region (in the default config) for a while now. And I'm pretty happy about that because it saves me a key-binding. I think it's just as useful as confining undo and search&replace to the active region: the active region is an extra argument to the command. It makes the active region into something comparable to the C-u prefix, a general way to structure the space of our commands. VI has even more structure, and I wish Emacs moved more in this direction. Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-11 12:36 ` delete-selection-mode as default Stefan Monnier @ 2018-09-11 23:09 ` hw 2018-09-12 0:33 ` Richard Stallman 1 sibling, 0 replies; 245+ messages in thread From: hw @ 2018-09-11 23:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I agree. What I want to happen after I make a region with ordinary >> Emacs commands, including C-SPC M-f and C-x C-x, is this: >> >> * It is active. >> * It is highlighted. >> * DEL does not delete it. >> * self-insert does not delete it. > > DEL has been deleting the active region (in the default config) for > a while now. And I'm pretty happy about that because it saves me > a key-binding. I think it's just as useful as confining undo and > search&replace to the active region: the active region is an extra > argument to the command. It makes the active region into something > comparable to the C-u prefix, a general way to structure the space of > our commands. VI has even more structure, and I wish Emacs moved more > in this direction. Aren't users going to need to set preferences as to what shall be limited or extended in which way to or by an highlighted region when more and more things fall under the paradigm of "doing something with a region just because it is highlighted and thus to be considered more active than when it is not"? Delete-selection-mode may count as an example of such a preference; a user not liking undo restricted to a region may be another. The next one might not like it that a non-highlighted region can be copied and deleted and abused for navigation and would rather have it entirely inert than only not so active. At least I would separate between "highlighted" and "active" first and go from there. Otherwise users who don't like this paradigm still won't be able to see what they have selected, and others can't see what they have selected unless they want to do something with it, or abort wanting to do something with it as soon as they've seen it. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-11 12:36 ` delete-selection-mode as default Stefan Monnier 2018-09-11 23:09 ` hw @ 2018-09-12 0:33 ` Richard Stallman 2018-09-12 13:23 ` Stefan Monnier 1 sibling, 1 reply; 245+ messages in thread From: Richard Stallman @ 2018-09-12 0:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > DEL has been deleting the active region (in the default config) for > a while now. It affects me only by screwing me. It means, for instance, that after a search I can't edit what I searched for in the natural way. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 0:33 ` Richard Stallman @ 2018-09-12 13:23 ` Stefan Monnier 2018-09-13 3:33 ` Richard Stallman 0 siblings, 1 reply; 245+ messages in thread From: Stefan Monnier @ 2018-09-12 13:23 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > DEL has been deleting the active region (in the default config) for > > a while now. > > It affects me only by screwing me. It means, for instance, that after > a search I can't edit what I searched for in the natural way. Not sure I understand how the active region relates to what you can do after a search. Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-12 13:23 ` Stefan Monnier @ 2018-09-13 3:33 ` Richard Stallman 0 siblings, 0 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-13 3:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Not sure I understand how the active region relates to what you can do > after a search. This is strange. I have a clear memory that search activated the region around the string that was found -- but it doesn't do that now. Was that behavior in effect before? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<87sh2ih0bp.fsf@fastmail.fm>]
[parent not found: <<770f48a8-664a-40ae-8e03-19f6aad248b6@default>]
[parent not found: <<20180910181615.GA4829@ACM>]
[parent not found: <<ab70ed3e-96a7-446f-be9b-e02130e71927@default>]
[parent not found: <<874lev3bq4.fsf@toy.adminart.net>]
[parent not found: <<20180912131602.GA5582@ACM>]
[parent not found: <<87d0tihxzw.fsf@toy.adminart.net>]
[parent not found: <<20180913174640.GB4019@ACM>]
[parent not found: <<8736udkuit.fsf@toy.adminart.net>]
[parent not found: <<20180914104833.GA4103@ACM>]
[parent not found: <<CAP_d_8WpO9+w-W1ZXMyoucUNtofNQ3Bc6Gchmxj6Rgy1nm3FOA@mail.gmail.com>]
[parent not found: <<83k1nojgia.fsf@gnu.org>]
[parent not found: <<7bed1f76-5bae-44cb-9b22-206b513043be@default>]
[parent not found: <<83d0tfkj77.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83d0tfkj77.fsf@gnu.org> @ 2018-09-14 20:57 ` Drew Adams 2018-09-15 7:50 ` Eli Zaretskii [not found] ` <<83zhwji4hx.fsf@gnu.org> 0 siblings, 2 replies; 245+ messages in thread From: Drew Adams @ 2018-09-14 20:57 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > > Users can trivially control which of the 5 behaviors to use for > > a given command, just by putting a property on the command > > symbol. > > Putting properties on symbols to change the behavior of a command is > not user-level customization. IOW, we are miscommunicating. There are users, and there are users. I didn't say that users will do that in general. Far from it. I don't know anyone who has ever bothered to set the d-s-m behavior for a particular command, unless it's a new command that they themselves created. That's the typical use case: causing your own command that's similar to standard `yank' or `backward-delete-char-untabify' or... to behave like the standard command wrt d-s-m. If you create a yank command then you want d-s-m to treat it as such (not to yank back the text that it just deleted). Typically this is done for a library, but it could be done in a user init file. The point is that you can, if you need/want to, _trivially_ define the specific behavior for a given command. Nothing complicated for any user to do that, even if very few will ever need to. > > There's no difficulty "reconciling" d-s-m with the "other > > uses" of the region that you cite. None whatsoever. > > You've shown none, AFAICT. No trick is needed. It just > > works. > > This whole thread makes it acutely clear that there is a problem. I disagree that there is a problem with d-s-m, or with turning it on by default. You tout irreconcilability but give no example. It's true that problems have been cited in the thread: Misunderstandings come from mistaken expectations and the fact that different users use Emacs differently. Confusion can come from the fact that there are multiple knobs to control region behavior (and not just two modes, t-m-m and d-s-m), and it's not obvious sometimes that a given knob exists or how the various knobs interact. That users can be confused about the region etc. does not stem from d-s-m - please don't scapegoat it. Confusion comes primarily from the introduction of t-m-m and, especially, the coupling, in C-x C-x, of region activation with swapping point and mark. There was no confusion before that. And no confusion was introduced by adding d-s-m. The fact that users who might want to really understand all of the various possibilities need to scour the manual to find info that is spread all over the place is too bad. I mentioned some possibilities for helping with that. But normally a given user just knows what s?he uses, and doesn't try to know about and understand every possibility regarding point, mark, region, selection, activation, highlighting, action, deletion, etc. This discussion, since it now deals with all possibilities (because people who take different approaches have widened the scope), has made apparent the complications. But a given user normally doesn't sense how complicated this stuff can be. Mr X knows his way of using the region; Ms Y knows her way, and so on. > And your message actually agrees with me towards the end. Again, I disagree. Do you mean the text cited just above? If not, where do you think I've agreed with you that there's inherent difficulty "reconciling" d-s-m with the "other uses" of the region that you cite? You make it sound like things are crystal clear and simple with the status quo, and that defaulting to d-s-m would muddy the waters. In fact, the waters are muddy now, if one bothers to look into them. And those umpteen knobs I mentioned do not come from d-s-m. You've correctly pointed out that the discussion, e.g., between Alan and Hw, ranging to `mark-even-if-inactive' and beyond, has pointed out complications. What's not correct is to suggest that the complications come from d-s-m. It's wrong to suggest that all is harmonious between your first two region "uses": navigation and invoking commands on a region, and that your third "use", delete-selection-mode, is the irreconcilable culprit that threatens to spit in the soup and turn harmony into discord. Defaulting to d-s-m would just make life simpler for most users (IMHO). And those who don't want d-s-m on can turn it off. And whether it is on or off, or whether d-s-m even exists or not, the complications we've pointed out are present - they don't come from d-s-m mode. You've decided that d-s-m won't be on by default anytime soon. OK. But it's wrong to paint a picture of d-s-m as a bogey man that threatens to sow contradiction. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-14 20:57 ` Drew Adams @ 2018-09-15 7:50 ` Eli Zaretskii 2018-09-15 10:20 ` Alan Mackenzie 2018-09-15 15:02 ` Stefan Monnier [not found] ` <<83zhwji4hx.fsf@gnu.org> 1 sibling, 2 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-15 7:50 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > Date: Fri, 14 Sep 2018 13:57:59 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: yurivkhan@gmail.com, acm@muc.de, hw@adminart.net, spacibba@aol.com, > joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, > phillip.lord@russet.org.uk > > > > Users can trivially control which of the 5 behaviors to use for > > > a given command, just by putting a property on the command > > > symbol. > > > > Putting properties on symbols to change the behavior of a command is > > not user-level customization. IOW, we are miscommunicating. > > There are users, and there are users. I didn't say that users > will do that in general. Far from it. > > I don't know anyone who has ever bothered to set the d-s-m > behavior for a particular command, unless it's a new command > that they themselves created. Fine, then we agree. The above issue is not relevant to what I perceive as the main problem here: how to give us a way to allow turning on delete-selection-mode without alienating users who have no use for it and very much dislike its effects, in particular when those effects are unintended. > I disagree that there is a problem with d-s-m, or with > turning it on by default. You tout irreconcilability but give > no example. There are plenty of examples in this thread, I see no need to repeat them. > That users can be confused about the region etc. does not > stem from d-s-m - please don't scapegoat it. > > Confusion comes primarily from the introduction of > t-m-m and, especially, the coupling, in C-x C-x, of region > activation with swapping point and mark. There was no > confusion before that. And no confusion was introduced > by adding d-s-m. I didn't "scapegoat" anything. It is immaterial which of the 3 uses of the region is "to blame", because this is not about assigning blame. My description was following the time line: the other 2 uses of the region are already turned on by default, whereas delete-selection-mode is not. It doesn't mean delete-selection-mode is somehow "guilty". > But normally a given user just knows what s?he uses, > and doesn't try to know about and understand every > possibility regarding point, mark, region, selection, > activation, highlighting, action, deletion, etc. My point is that even users who know what they are doing currently have no good means to tell that to Emacs on a case by case basis. If they turn on transient-mark-mode, they get a whole slew of non-trivial behaviors as a single package deal; if they turn on delete-selection-mode, they have another package deal which contradicts some of the one they get with transient-mark-mode. My proposal is to give users a more fine-grained control of that, so that users could control the "meaning" of the current region with easily typed commands, and by that tell the next command(s) how to interpret the region. The implementation of this proposal could be based on a new "state" of the region, which will be the 3rd state in addition to the currently-available "active" and "inactive" states. The 3rd state will have the semantics of supporting the behavior provided by the commands that have the delete-selection property on their symbols. Or it could be based on something else. The important facet of the proposal is that we need to introduce easily typed commands that will assign one of the 3 possible meanings to the current region. With that, users will have the capability of using delete-selection features when they need them, without deciding up front that they prefer those features to other commands that pay attention to active regions. We could also teach the commands which could support either behavior to DTRT by default using some heuristics. All of this and more is currently impossible because the same state of the region is interpreted differently by some commands given a global mode. > This discussion, since it now deals with all possibilities > (because people who take different approaches have > widened the scope), has made apparent the complications. > > But a given user normally doesn't sense how complicated > this stuff can be. Mr X knows his way of using the region; > Ms Y knows her way, and so on. You assume that there's only one "way" for Mr X and Ms Y. But that assumption is not necessarily true, for experienced users. They will want each of those "ways" in some specific circumstances. For example, "C-x C-x" used as navigation tools doesn't need to activate the region; only the user knows whether that is the case in each specific use case. Similarly, typing a character or DEL when the region is active should replace/delete the region _sometimes_, but not always, and only the user knows which is which. As an experienced user who sometimes needs each one of those features, I would like to be able to control what happens in each case, and turning on and off global modes is too blunt an instrument for that; in particular, the relevant commands are too long and tedious to type. So I'm currently forced to choose just one of these 3 features, the one that gets in my way the least. I would like to be freed from this "one fits all use cases" prison. > You make it sound like things are crystal clear and simple > with the status quo, and that defaulting to d-s-m would > muddy the waters. I said nothing of the kind. See above. > In fact, the waters are muddy now, if one bothers to look > into them. That's exactly what I'm saying. I also suggested one way out of this conundrum. > What's not correct is to suggest that the complications come from > d-s-m. Nothing like that was suggested. And even if it could be somehow understood it was, discussing this particular aspect is a tangent that gets us away from the real issues. Let's not go there just because we can. > It's wrong to suggest that all is harmonious between > your first two region "uses": navigation and invoking > commands on a region, and that your third "use", > delete-selection-mode, is the irreconcilable culprit that > threatens to spit in the soup and turn harmony into discord. There's no such suggestion. Don't feel "offended" on behalf of delete-selection-mode. (And there's no need to say the same thing time and again in so many different ways.) > Defaulting to d-s-m would just make life simpler for > most users (IMHO). And those who don't want d-s-m > on can turn it off. I believe this is a false dichotomy; there's a better solution that would leave more users happy. > You've decided that d-s-m won't be on by default > anytime soon. No such decision was made. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 7:50 ` Eli Zaretskii @ 2018-09-15 10:20 ` Alan Mackenzie 2018-09-15 10:56 ` Eli Zaretskii 2018-09-15 19:44 ` Ergus 2018-09-15 15:02 ` Stefan Monnier 1 sibling, 2 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-15 10:20 UTC (permalink / raw) To: Eli Zaretskii Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, Drew Adams, phillip.lord Hello, Eli. On Sat, Sep 15, 2018 at 10:50:18 +0300, Eli Zaretskii wrote: > > Date: Fri, 14 Sep 2018 13:57:59 -0700 (PDT) > > From: Drew Adams <drew.adams@oracle.com> > > Cc: yurivkhan@gmail.com, acm@muc.de, hw@adminart.net, spacibba@aol.com, > > joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, > > phillip.lord@russet.org.uk [ .... ] > My point is that even users who know what they are doing currently > have no good means to tell that to Emacs on a case by case basis. If > they turn on transient-mark-mode, they get a whole slew of non-trivial > behaviors as a single package deal; if they turn on > delete-selection-mode, they have another package deal which > contradicts some of the one they get with transient-mark-mode. > My proposal is to give users a more fine-grained control of that, so > that users could control the "meaning" of the current region with > easily typed commands, and by that tell the next command(s) how to > interpret the region. The implementation of this proposal could be > based on a new "state" of the region, which will be the 3rd state in > addition to the currently-available "active" and "inactive" states. > The 3rd state will have the semantics of supporting the behavior > provided by the commands that have the delete-selection property on > their symbols. Or it could be based on something else. The important > facet of the proposal is that we need to introduce easily typed > commands that will assign one of the 3 possible meanings to the > current region. > With that, users will have the capability of using delete-selection > features when they need them, without deciding up front that they > prefer those features to other commands that pay attention to active > regions. We could also teach the commands which could support either > behavior to DTRT by default using some heuristics. All of this and > more is currently impossible because the same state of the region is > interpreted differently by some commands given a global mode. I can't help feeling that this isn't the right approach. I feel that it will increase complexity which the new features won't justify. I know I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here, but still: I think having to press a key sequence before d-s-m would work would take the purpose of d-s-m away - that key sequence might as well be C-w. You seem to be proposing to associate a three-value state with the region, which state users could change with key sequences. I can see this being more confusing than the current two-value state (or is it 2.5?) we currently have. It might well be that, having introduced transient-mark-mode as a default, a certain degree of confusion in Emacs is unavoidable. If so, does it make sense to spend a lot of effort which might merely switch the confusion to somewhere else? Assuming that we'd want to have options to retain all the "old" behaviour, I think it would be difficult to avoid increasing the confusion. I've interacted somewhat with hw, who's been driving this thread, and come to the conclusion that he doesn't really want to use Emacs. The mechanisms of point, mark, and the regions are fundamental to Emacs and can't be readily customised away. I don't think we should try to provide this customisability. Sorry if I've been a bit negative in this post. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 10:20 ` Alan Mackenzie @ 2018-09-15 10:56 ` Eli Zaretskii 2018-09-15 19:44 ` Ergus 1 sibling, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-15 10:56 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, drew.adams, phillip.lord > Date: Sat, 15 Sep 2018 10:20:16 +0000 > Cc: Drew Adams <drew.adams@oracle.com>, yurivkhan@gmail.com, hw@adminart.net, > spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com, > emacs-devel@gnu.org, phillip.lord@russet.org.uk > From: Alan Mackenzie <acm@muc.de> > > I can't help feeling that this isn't the right approach. I feel that it > will increase complexity which the new features won't justify. I know > I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here, > but still: I think having to press a key sequence before d-s-m would work > would take the purpose of d-s-m away - that key sequence might as well be > C-w. People who want delete-selection-mode enabled by default won't need to type that additional key, because for them the region will already have the correct state. delete-selection-mode will take care of that. It is those who do NO want delete-selection-mode turned on by default, people like you and me, who will be ABLE to use delete-selection-mode by typing an extra key. Those users will also be capable of "activating" and "deactivating" the region like transient-mark-mode does with a single command, thus allowing them to invoke commands that act on an "active" region without turning on transient-mark-mode globally. > You seem to be proposing to associate a three-value state with the > region, which state users could change with key sequences. I can see > this being more confusing than the current two-value state (or is it > 2.5?) we currently have. It cannot be more confusing, because for those who already turn on transient-mark-mode and/or delete-selection-mode it leaves the matters exactly like they are. It actually should _improve_ on that by letting those users temporarily turn on/off those modes for the purposes of processing a given region by one or more commands. > It might well be that, having introduced transient-mark-mode as a > default, a certain degree of confusion in Emacs is unavoidable. If so, > does it make sense to spend a lot of effort which might merely switch the > confusion to somewhere else? Assuming that we'd want to have options to > retain all the "old" behaviour, I think it would be difficult to avoid > increasing the confusion. I hope you will now reconsider this remark. > I've interacted somewhat with hw, who's been driving this thread, and > come to the conclusion that he doesn't really want to use Emacs. That's irrelevant for the purposes of my proposal. I do want to use Emacs, and so I hope do you. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 10:20 ` Alan Mackenzie 2018-09-15 10:56 ` Eli Zaretskii @ 2018-09-15 19:44 ` Ergus 2018-09-15 20:01 ` Eli Zaretskii 2018-09-16 10:52 ` Alan Mackenzie 1 sibling, 2 replies; 245+ messages in thread From: Ergus @ 2018-09-15 19:44 UTC (permalink / raw) To: Alan Mackenzie Cc: hw, joostkremers, npostavs, emacs-devel, yurivkhan, Eli Zaretskii, Drew Adams, phillip.lord Hi Alan: On Sat, Sep 15, 2018 at 10:20:16AM +0000, Alan Mackenzie wrote: >Hello, Eli. > >On Sat, Sep 15, 2018 at 10:50:18 +0300, Eli Zaretskii wrote: > >I can't help feeling that this isn't the right approach. I feel that it >will increase complexity which the new features won't justify. I know >I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here, >but still: I think having to press a key sequence before d-s-m would work >would take the purpose of d-s-m away - that key sequence might as well be >C-w. > >You seem to be proposing to associate a three-value state with the >region, which state users could change with key sequences. I can see >this being more confusing than the current two-value state (or is it >2.5?) we currently have. > >It might well be that, having introduced transient-mark-mode as a >default, a certain degree of confusion in Emacs is unavoidable. If so, >does it make sense to spend a lot of effort which might merely switch the >confusion to somewhere else? Assuming that we'd want to have options to >retain all the "old" behaviour, I think it would be difficult to avoid >increasing the confusion. > >I've interacted somewhat with hw, who's been driving this thread, and >come to the conclusion that he doesn't really want to use Emacs. The >mechanisms of point, mark, and the regions are fundamental to Emacs and >can't be readily customised away. I don't think we should try to provide >this customisability. > I have also interacted with hw and I totally disagree that he doesn't want to use emacs. Maybe it is because I am a "younger" emacs users too, or that I have tried many other editors & IDEs, but I understand what he says and the fear the first time a user opens emacs comparing to other similar tools. He just perceives the same than I: Emacs needs changes to simplify the user experience, but any key change faces too much resistance. My approach is 1) To keep the default things AS SIMPLE AS POSSIBLE for the user in any case, specially in a basic software like a text editor. (SIMPLE and INTUITIVE if possible) 2) I agree with the Eli's approach to find a mean point that makes less unhappy most of the people (if possible). 3) But interface changes are needed to survive, they require care to avoid conflicts and reduce the collapse with backward compatibility, but are needed. NEVERTHELESS The mark-point approach is not a fundamental emacs thing, it is just a design choice enforced for technical limitations 40 years ago (like the vi modes, the meta-hyper-syntax and so on) This means that (citing Bill Joy about vi) it was created for a world that doesn't exist anymore. So it can (and should) be updated/upgraded as many other things in emacs and any long living project. Many emacs default behaviors are confusing for ALL new users even after reading the tutorial or the manual. Others are just considered as limitations/bugs because they require too many binds or are very difficult to find/remember comparing with other editors. But some of them are design choices made 40, 30 or 20 years ago. New ideas have born after 1980, different approaches that make the user live easier or were impossible to try in 1980. But any intent to change the old, becomes in a thread like this, where many opinions (and very strong ones specially the ones to keep the status quo) come out and conduce to nothing. This difficult to change anything in the user interaction makes emacs to feel still like in 1990 in spite of all the changes and modern stuff if has. It has open doors to the actual vim use increase, the born and HUGE grow of editors like atom and sublime and communities like spacemacs or evil-mode; while the pure emacs use is becoming marginal. There are new functionalities that appeared more recently and Emacs can (and should) incorporate asap out of the box (switching lines, selection highlight, better rectangular selection and interaction). And the real problem to implement all this is not the emacs potential, but the most orthodox/purist users that resist too much to any change. Same thing happens with the suggestions about the tutorial changes, the proposal of a centralized documentation in a web site and so on. I think the only way to properly solve this kind of endless discussions is to ask the users and not only the developers or advanced users. Something like feathub in the emacs page will work (this should be extended to many other GNU projects too). Advantages: 1) Users (new and old) will have a voice in the emacs future. 2) The Developers will know if a proposed functionality will be usefully for many users and check if it worth to invest time in it (and emacs code size). 3) Better interaction user-user and user-developer. 4) Developers will know what are the most demanded functionalities with priorities (easy and fast). 5) Users will have an idea if some functionality will be delivered soon or not and why, and how many other users claimed them. 6) The featured comments opinions arguments and everything will be grouped and ordered and if they reborn after some years will be easier to check if the conditions changed to add it or if I know that the mailing list can offer all this somehow... but again, it is something that can be improved. Thinking as a 2018 under 30 yo user. >Sorry if I've been a bit negative in this post. > >[ .... ] > >-- >Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 19:44 ` Ergus @ 2018-09-15 20:01 ` Eli Zaretskii 2018-09-16 0:29 ` Ergus 2018-09-16 10:52 ` Alan Mackenzie 1 sibling, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-15 20:01 UTC (permalink / raw) To: Ergus Cc: hw, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > Date: Sat, 15 Sep 2018 21:44:19 +0200 > From: Ergus <spacibba@aol.com> > Cc: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>, > yurivkhan@gmail.com, hw@adminart.net, joostkremers@fastmail.fm, > npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk > > The mark-point approach is not a fundamental emacs thing, it is just a > design choice enforced for technical limitations 40 years ago (like the > vi modes, the meta-hyper-syntax and so on) This means that (citing Bill > Joy about vi) it was created for a world that doesn't exist anymore. So > it can (and should) be updated/upgraded as many other things in emacs > and any long living project. I don't agree with you, and in any case it's pointless to try to argue that using mark and point for navigation in Emacs should go away. You will never get this past long-time Emacs users. We must look for other ways. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 20:01 ` Eli Zaretskii @ 2018-09-16 0:29 ` Ergus 2018-09-16 16:55 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: Ergus @ 2018-09-16 0:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On 15 September 2018 22:01:32 CEST, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Sat, 15 Sep 2018 21:44:19 +0200 >> From: Ergus <spacibba@aol.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>, >> yurivkhan@gmail.com, hw@adminart.net, joostkremers@fastmail.fm, >> npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk >> >> The mark-point approach is not a fundamental emacs thing, it is just >a >> design choice enforced for technical limitations 40 years ago (like >the >> vi modes, the meta-hyper-syntax and so on) This means that (citing >Bill >> Joy about vi) it was created for a world that doesn't exist anymore. >So >> it can (and should) be updated/upgraded as many other things in emacs >> and any long living project. > >I don't agree with you, and in any case it's pointless to try to argue >that using mark and point for navigation in Emacs should go away. You >will never get this past long-time Emacs users. We must look for >other ways. Hi. I never told that it should go away now, or ever. But as many other design choices they could be a solution in a time. But if it needs changes or a reimplementation (or go away in the future) in favor of something better or new needs, then we shouldn't keep it as is only because a reduced number of people don't want to adapt to the new behaviours. It should be clear about what is fundamental in emacs behaviour and whats just something that has survived. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-16 0:29 ` Ergus @ 2018-09-16 16:55 ` Eli Zaretskii 0 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-16 16:55 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel > Date: Sun, 16 Sep 2018 02:29:57 +0200 > CC: emacs-devel@gnu.org > From: Ergus <spacibba@aol.com> > > >I don't agree with you, and in any case it's pointless to try to argue > >that using mark and point for navigation in Emacs should go away. You > >will never get this past long-time Emacs users. We must look for > >other ways. > > Hi. I never told that it should go away now, or ever. But as many other design choices they could be a solution in a time. But if it needs changes or a reimplementation (or go away in the future) in favor of something better or new needs, then we shouldn't keep it as is only because a reduced number of people don't want to adapt to the new behaviours. See my other message: the fact that region in Emacs serves as basis for "selections" has deeper roots than just "a reduced number of people" who use it. I also question your assessment of the number of people who use the region in Emacs for features that are beyond what selections can support. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 19:44 ` Ergus 2018-09-15 20:01 ` Eli Zaretskii @ 2018-09-16 10:52 ` Alan Mackenzie [not found] ` <3D72B095-01EC-4E7D-90F9-5691AEFE16DC@aol.com> 1 sibling, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-16 10:52 UTC (permalink / raw) To: Ergus Cc: hw, joostkremers, npostavs, emacs-devel, yurivkhan, Eli Zaretskii, Drew Adams, phillip.lord Hello, Ergus. On Sat, Sep 15, 2018 at 21:44:19 +0200, Ergus wrote: > I have also interacted with hw and I totally disagree that he doesn't > want to use emacs. Maybe it is because I am a "younger" emacs users > too, or that I have tried many other editors & IDEs, but I understand > what he says and the fear the first time a user opens emacs comparing > to other similar tools. He just perceives the same than I: Emacs needs > changes to simplify the user experience, but any key change faces too > much resistance. > My approach is > 1) To keep the default things AS SIMPLE AS POSSIBLE for the user in > any case, specially in a basic software like a text editor. (SIMPLE > and INTUITIVE if possible) By "simple and intuitive" I think you just mean "like other editors the user may have already used". What could be simpler than Emacs's point, mark and region scheme, and still get the job done? > 2) I agree with the Eli's approach to find a mean point that makes > less unhappy most of the people (if possible). That means, I think, being able to customise Emacs to suit ones' own preferences. > 3) But interface changes are needed to survive, they require care to > avoid conflicts and reduce the collapse with backward compatibility, > but are needed. > NEVERTHELESS > The mark-point approach is not a fundamental emacs thing, it is just a > design choice enforced for technical limitations 40 years ago (like the > vi modes, the meta-hyper-syntax and so on) This means that (citing Bill > Joy about vi) it was created for a world that doesn't exist anymore. So > it can (and should) be updated/upgraded as many other things in emacs > and any long living project. I can't let this pass without comment. The point, mark, region approach (I'm considering it here without the complications introduced by transient-mark-mode) is a stroke of genius, combining austere simplicity with great flexibility and ease of use. How well do you understand this approach? Just what were these technical limitations which you assert gave rise to point/mark/region? The world which gave rise to it may no longer exist, but the idea is so good that it remains powerful and relevant. Analogously, the worlds which gave rise to the pottery which archaeologists dig up are no more, but we still make and use pottery today. I fear that by "updated/upgraded" you really mean "made more complicated, less flexible, and (possibly) dumbed down". You say "it should be updated/upgraded". Somebody has to do this work. Are you prepared to contribute, yourself? Proposals for changes, particularly drastic changes, tend to be much better received here when they come in the form of patches rather than just vague ideas. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <3D72B095-01EC-4E7D-90F9-5691AEFE16DC@aol.com>]
* Re: delete-selection-mode as default [not found] ` <3D72B095-01EC-4E7D-90F9-5691AEFE16DC@aol.com> @ 2018-09-17 2:17 ` Alan Mackenzie 2018-09-17 5:46 ` Elias Mårtenson 0 siblings, 1 reply; 245+ messages in thread From: Alan Mackenzie @ 2018-09-17 2:17 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel On Sun, Sep 16, 2018 at 17:18:53 +0200, Ergus wrote: > On 16 September 2018 12:52:25 CEST, Alan Mackenzie <acm@muc.de> wrote: > >Hello, Ergus. > >On Sat, Sep 15, 2018 at 21:44:19 +0200, Ergus wrote: > >> My approach is > >> 1) To keep the default things AS SIMPLE AS POSSIBLE for the user in > >> any case, specially in a basic software like a text editor. (SIMPLE > >> and INTUITIVE if possible) > >By "simple and intuitive" I think you just mean "like other editors the > >user may have already used". > There is a reason why all the other editors use similar aproach > different to this. So it shouldnt be that bad. I suggest that reason is to be easily learnable with the minimum of mental effort. Emacs's priority is to be as easily usable with the minimum of effort. Hence the different approaches. > >What could be simpler than Emacs's point, mark and region scheme, and > >still get the job done? > There are many options but depends of the users and the use case. Modes > like vim, cua-mode and similar aproaches for rectangular work, multiple > cursors. A real selection as anything else... highlighted. Don't have a > region when you dont want a region... > It depends on the workflow... Simple for me may not be simpler for you. You've completely misconstrued my meaning. By simple, I meant something like the aesthetic of minimality. Point and mark define a region. There is nothing left in that set of concepts that you could take away and still have a usable editor. At the same time, point and mark are fully adequate for efficient working. That's not to say that some people prefer less elegance and more elaborate facilities (such as transient-mark-mode). That's fine. > >> 2) I agree with the Eli's approach to find a mean point that makes > >> less unhappy most of the people (if possible). > >That means, I think, being able to customise Emacs to suit ones' own > >preferences. > Also agree. For example: If i dont like to have always a region do I > have an alternative? <sigh> The region is simply a portion of your buffer. What you're suggesting is epistemologically incoherent. It's "if I don't like always to have a portion of my buffer do I have an alternative?". No, Emacs can't support such nonsense. Sorry. I wonder just how widespread this misconception is in Emacs users. > >> 3) But interface changes are needed to survive, they require care to > >> avoid conflicts and reduce the collapse with backward compatibility, > >> but are needed. > >> NEVERTHELESS > >> The mark-point approach is not a fundamental emacs thing, it is just > >> a design choice enforced for technical limitations 40 years ago > >> (like the vi modes, the meta-hyper-syntax and so on) This means that > >> (citing Bill Joy about vi) it was created for a world that doesn't > >> exist anymore. So it can (and should) be updated/upgraded as many > >> other things in emacs and any long living project. > >I can't let this pass without comment. The point, mark, region > >approach (I'm considering it here without the complications introduced > >by transient-mark-mode) is a stroke of genius, combining austere > >simplicity with great flexibility and ease of use. How well do you > >understand this approach? > This is your very personal opinion. It is a good approach, but there > are others equally good and in my opinion some better and more logical > for some use cases. (Or just faster) It's not just my personal opinion, it's objective, too. Your assertion that "the mark-point approach is not a fundamental emacs thing" is, I think, a personal wish, but unfounded. This approach is baked into so many Emacs primitives and higher level commands that to try to remove it would be essentially impossible. It would likely be less work to write a new editor from scratch. > Some people likes to use vim with its insert and copy modes. Some > people likes to use the mouse... They are much much more than the ones > that likes emacs in tty... Some people uses windows... Emacs aims to cater for all these user preferences, and, I think, does a reasonable job at this. How many other modern editors support a tty? > There are standards in all the interfaces and programs. A user dont > need to read anything to know how to do basic stuf anywhere. Even gnu > programs have created many of these standards. (Screen tmux bash xterm) Emacs is about more than just doing basic stuff. It's a powerful tool with extreme user friendliness. This necessarily means it's not going to be beginner friendly, or easy to learn. > In my telegram emacs group 80 % of the users use evil mode or > spacemacs... Does it means something to you as a developer? If that usage pattern is widespread, then it suggests that these facilities are worth maintaining, or possibly incorporating into the Emacs core, as the case may be. > >Just what were these technical limitations which you assert gave rise > >to point/mark/region? The world which gave rise to it may no longer > >exist, but the idea is so good that it remains powerful and relevant. > In this thread I only see you with so strong feelings that it is a kind > of divine perfect iluminated idea and should be as is for the universal > equilibrium. Again, what were these supposed technical limitations which you say gave rise to point/mark/region? I suggest to you that there were and are no such technical limitations. [ .... ] > >I fear that by "updated/upgraded" you really mean "made more > >complicated, less flexible, and (possibly) dumbed down". > You dont know... Maybe after all eli or anyone comes with a most genius > and iluminated idea. Or if we ask the users they can propose > alternatives that we havent even imagined. Emacs is an open project. Anybody is welcome to contribute and implement new ideas, and if they are coherent and worthwhile will likely be incorporated into Emacs. transient-mark-mode was such an idea, which was quickly incorporated, eventually becoming the default setting (something I think was unwise). > >You say "it should be updated/upgraded". Somebody has to do this > >work. > I didnt say that. In fact i dont have actually any urgent problem with > this. But i dont like the orthodox idea of consider it as perfect and > better than anything else, because it isnt. Perfect, no, but better than anything else, for some values of "better", then yes. But, as just said, anybody who considers the point/mark mechanism inadequate is welcome to enhance it, or to add some other mechanism. > I am not ready to contribute... But this kind of aptitude and strong > strict opinions about a simple detail dont help to attract new > developers. Doesn't it? There has been a steady stream of new people actively contributing in the last few years. > The same if you suggest to use a different editor when anyone proposes > to change something because you consider it is a fundamental axiom. Point/mark _is_ fundamental to Emacs, and hardly possible to remove. And good as Emacs is, I would not maintain it is suitable for everybody. > >Are you prepared to contribute, yourself? > WIP. > >Proposals for changes, particularly drastic changes, tend to be much > >better received here when they come in the form of patches rather than > >just vague ideas. > Totaly right. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 2:17 ` Alan Mackenzie @ 2018-09-17 5:46 ` Elias Mårtenson 2018-09-17 18:37 ` Alan Mackenzie 2018-09-17 19:57 ` hw 0 siblings, 2 replies; 245+ messages in thread From: Elias Mårtenson @ 2018-09-17 5:46 UTC (permalink / raw) To: Alan Mackenzie; +Cc: spacibba, emacs-devel [-- Attachment #1: Type: text/plain, Size: 552 bytes --] On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <acm@muc.de> wrote: > > <sigh> The region is simply a portion of your buffer. What you're > suggesting is epistemologically incoherent. It's "if I don't like always > to have a portion of my buffer do I have an alternative?". No, Emacs > can't support such nonsense. Sorry. It seems to me that the desires of hw could be fulfilled by simply disabling the mark whenever the region becomes inactive. It does sound like something I would never want to use, but it does seem like what is being suggested. [-- Attachment #2: Type: text/html, Size: 990 bytes --] ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 5:46 ` Elias Mårtenson @ 2018-09-17 18:37 ` Alan Mackenzie 2018-09-17 19:57 ` hw 1 sibling, 0 replies; 245+ messages in thread From: Alan Mackenzie @ 2018-09-17 18:37 UTC (permalink / raw) To: Elias Mårtenson; +Cc: spacibba, emacs-devel Hello, Elias. On Mon, Sep 17, 2018 at 13:46:54 +0800, Elias Mårtenson wrote: > On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <acm@muc.de> wrote: > > <sigh> The region is simply a portion of your buffer. What you're > > suggesting is epistemologically incoherent. It's "if I don't like always > > to have a portion of my buffer do I have an alternative?". No, Emacs > > can't support such nonsense. Sorry. > It seems to me that the desires of hw could be fulfilled by simply > disabling the mark whenever the region becomes inactive. This can be done by setting mark-even-if-inactive to nil. This has been going around this list for several days, now. It's been getting on my nerves that (unwittingly) false accusations about the region, that its "existence" (whatever that might mean) somehow represents an inconvenience or danger, are doing the rounds on this list. It only takes a little clear thought to see how ridiculous this is. > It does sound like something I would never want to use, but it does seem > like what is being suggested. Yes, I think so too. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 5:46 ` Elias Mårtenson 2018-09-17 18:37 ` Alan Mackenzie @ 2018-09-17 19:57 ` hw 2018-09-17 22:56 ` Drew Adams 1 sibling, 1 reply; 245+ messages in thread From: hw @ 2018-09-17 19:57 UTC (permalink / raw) To: Elias Mårtenson; +Cc: Alan Mackenzie, spacibba, emacs-devel Elias Mårtenson <lokedhs@gmail.com> writes: > On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <acm@muc.de> wrote: > >> >> <sigh> The region is simply a portion of your buffer. What you're >> suggesting is epistemologically incoherent. It's "if I don't like always >> to have a portion of my buffer do I have an alternative?". No, Emacs >> can't support such nonsense. Sorry. > > > It seems to me that the desires of hw could be fulfilled by simply > disabling the mark whenever the region becomes inactive. > > It does sound like something I would never want to use, but it does seem > like what is being suggested. Yes and no: With mark-even-if-inactive set to nil, it is not so relevant for me that the mark be disabled. That leaves the option of not disabling it, in which case it might be useful to use the mark for navigation. To do that, I only need to put a command that changes point and mark on C-x C-x, as Eli suggested. I never used that, but that doesn't mean it can't be useful when it is not involved with making selections because it's easier to press C-spc than to set a register or a bookmark. It also leaves the issue of persistent selections. Yuri and Drew said that it would be a huge amount of work, and Yuri explained how the appeal of persistent selections may be limited when multiple buffers and windows get involved. I'd still like having that, but it doesn't really provide additional functionality other than the possibility of multiple persistent selections per buffer which I never missed --- and apparently can already have with zones, as Drew suggested. The region still won't make any sense to me, and it doesn't need to. What new users might want or expect and what might make sense to them is another question. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-17 19:57 ` hw @ 2018-09-17 22:56 ` Drew Adams 0 siblings, 0 replies; 245+ messages in thread From: Drew Adams @ 2018-09-17 22:56 UTC (permalink / raw) To: hw, Elias Mårtenson; +Cc: Alan Mackenzie, spacibba, emacs-devel > It also leaves the issue of persistent selections. Yuri and Drew said > that it would be a huge amount of work, I don't think I said that (but I'm not going to search all that I've said in this thread). I pointed out various things that could be done to implement multiple persistent selections, in particular pointing to what is already available in `second-sel.el' and `zones.el'. > and Yuri explained how the > appeal of persistent selections may be limited when multiple buffers and > windows get involved. I'd still like having that, but it doesn't really > provide additional functionality other than the possibility of multiple > persistent selections per buffer which I never missed --- and apparently > can already have with zones, as Drew suggested. To be clear, the zones in a set (list) of zones can be in the same buffer, which might or might not be the current buffer, or they can be in different buffers. You can have multiple sets (lists) of zones, and any zone in any of them can have its limit positions in any buffer. The limits defining a given zone can be unspecified as to their buffer, in which case that zone can be used in any buffer. The only requirement on the two limits of a given zone is that if they each specify a buffer then they must specify the same buffer (otherwise the behavior is undefined). Any zone limit can be an Emacs marker, a "readable marker" (which can be saved to disk), or a positive integer. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 7:50 ` Eli Zaretskii 2018-09-15 10:20 ` Alan Mackenzie @ 2018-09-15 15:02 ` Stefan Monnier 2018-09-15 15:27 ` Eli Zaretskii 2018-09-16 3:14 ` Richard Stallman 1 sibling, 2 replies; 245+ messages in thread From: Stefan Monnier @ 2018-09-15 15:02 UTC (permalink / raw) To: emacs-devel > Fine, then we agree. The above issue is not relevant to what I > perceive as the main problem here: how to give us a way to allow > turning on delete-selection-mode without alienating users who have no > use for it and very much dislike its effects, in particular when those > effects are unintended. AFAIK d-s-m has currently only 2 effects: - delete the selection before self-insert-command - same before yank In both cases, if that's not what the user intended, an important question is: why was the region active before those commands? Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 15:02 ` Stefan Monnier @ 2018-09-15 15:27 ` Eli Zaretskii 2018-09-15 18:30 ` Stefan Monnier 2018-09-16 3:14 ` Richard Stallman 1 sibling, 1 reply; 245+ messages in thread From: Eli Zaretskii @ 2018-09-15 15:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sat, 15 Sep 2018 11:02:54 -0400 > > > Fine, then we agree. The above issue is not relevant to what I > > perceive as the main problem here: how to give us a way to allow > > turning on delete-selection-mode without alienating users who have no > > use for it and very much dislike its effects, in particular when those > > effects are unintended. > > AFAIK d-s-m has currently only 2 effects: > - delete the selection before self-insert-command > - same before yank > > In both cases, if that's not what the user intended, an important > question is: why was the region active before those commands? Because the user did "C-x C-x"? ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 15:27 ` Eli Zaretskii @ 2018-09-15 18:30 ` Stefan Monnier 2018-09-15 20:04 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: Stefan Monnier @ 2018-09-15 18:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> > Fine, then we agree. The above issue is not relevant to what I >> > perceive as the main problem here: how to give us a way to allow >> > turning on delete-selection-mode without alienating users who have no >> > use for it and very much dislike its effects, in particular when those >> > effects are unintended. >> AFAIK d-s-m has currently only 2 effects: >> - delete the selection before self-insert-command >> - same before yank >> In both cases, if that's not what the user intended, an important >> question is: why was the region active before those commands? > Because the user did "C-x C-x"? So again the problem is not with d-s-m but with C-x C-x, then. I think many users who are heavy users of the marks for navigation would benefit from a "halfway" setting for transient-mark-mode, where commands like C-M-SPC, M-h etc... still activate the region, but where C-SPC, and C-x C-x don't. Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 18:30 ` Stefan Monnier @ 2018-09-15 20:04 ` Eli Zaretskii 0 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-09-15 20:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: emacs-devel@gnu.org > Date: Sat, 15 Sep 2018 14:30:35 -0400 > > >> > Fine, then we agree. The above issue is not relevant to what I > >> > perceive as the main problem here: how to give us a way to allow > >> > turning on delete-selection-mode without alienating users who have no > >> > use for it and very much dislike its effects, in particular when those > >> > effects are unintended. > >> AFAIK d-s-m has currently only 2 effects: > >> - delete the selection before self-insert-command > >> - same before yank > >> In both cases, if that's not what the user intended, an important > >> question is: why was the region active before those commands? > > Because the user did "C-x C-x"? > > So again the problem is not with d-s-m but with C-x C-x, then. I never said there was some "problem" with delete-selection-mode. It's not delete-selection-mode that is the problem, it's the fact that we use the region for 3 different purposes. > I think many users who are heavy users of the marks for navigation would > benefit from a "halfway" setting for transient-mark-mode, where commands > like C-M-SPC, M-h etc... still activate the region, but where C-SPC, and > C-x C-x don't. Did you read any of my messages? I think we can have that cake and eat it, too. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-15 15:02 ` Stefan Monnier 2018-09-15 15:27 ` Eli Zaretskii @ 2018-09-16 3:14 ` Richard Stallman 1 sibling, 0 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-16 3:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > In both cases, if that's not what the user intended, an important > question is: why was the region active before those commands? It could be because the user typed C-SPC to mark one end of the region. Or because of C-x C-x. There are commends for which an active region changes the behavior. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
[parent not found: <<83zhwji4hx.fsf@gnu.org>]
* RE: delete-selection-mode as default [not found] ` <<83zhwji4hx.fsf@gnu.org> @ 2018-09-17 0:55 ` Drew Adams 2018-10-03 0:22 ` Richard Stallman 0 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-17 0:55 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, phillip.lord > > You've decided that d-s-m won't be on by default > > anytime soon. > > No such decision was made. Good to hear. I (mis)understood that, based on this from RMS on 09/10: ELi and I, the Emacs maintainers, are both opposed to making delete-selection-mode the default. I misread that as a decision by the maintainers. I should also have noticed that he immediately followed that with "Please don't do that." It was essentially a vote, I guess, but a vote given extra weight by the maintainer attribution. (I was in fact surprised to hear that Richard is again participating as a maintainer. Does that mean we have three now? Anyway, I, for one, would welcome it.) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-17 0:55 ` Drew Adams @ 2018-10-03 0:22 ` Richard Stallman 2018-10-03 17:38 ` Eli Zaretskii 0 siblings, 1 reply; 245+ messages in thread From: Richard Stallman @ 2018-10-03 0:22 UTC (permalink / raw) To: Drew Adams Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, eliz, drew.adams, phillip.lord [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Good to hear. I (mis)understood that, based on > this from RMS on 09/10: > ELi and I, the Emacs maintainers, are both > opposed to making delete-selection-mode > the default. > I misread that as a decision by the maintainers. That's what I meant it as. Eli had said he was against this change. I hope he is against it once again. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-10-03 0:22 ` Richard Stallman @ 2018-10-03 17:38 ` Eli Zaretskii 0 siblings, 0 replies; 245+ messages in thread From: Eli Zaretskii @ 2018-10-03 17:38 UTC (permalink / raw) To: rms Cc: hw, spacibba, joostkremers, npostavs, emacs-devel, yurivkhan, acm, drew.adams, phillip.lord > From: Richard Stallman <rms@gnu.org> > Cc: eliz@gnu.org, drew.adams@oracle.com, hw@adminart.net, > spacibba@aol.com, joostkremers@fastmail.fm, > npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, > acm@muc.de, phillip.lord@russet.org.uk > Date: Tue, 02 Oct 2018 20:22:44 -0400 > > > Good to hear. I (mis)understood that, based on > > this from RMS on 09/10: > > > ELi and I, the Emacs maintainers, are both > > opposed to making delete-selection-mode > > the default. > > > I misread that as a decision by the maintainers. > > That's what I meant it as. Eli had said he was against this change. > I hope he is against it once again. My opinion was and remains that delete-selection-mode cannot be turned on by default without also taking some additional measures. My suggestions for one possible set of such measures drowned in the irrelevant noise. If someone wants to implement some variant of my suggestions, or come up with a different idea to the same effect, we can then resume the discussion whether delete-selection-mode could be enabled by default together with implementing these additional measures. The "no such decision was made" part wanted to tell that this "discussion" was hardly conducive to any decision-making, and consequently no decisions were made. Each one remains of their previous opinions, for now. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 0:32 delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 2018-09-07 0:35 ` Drew Adams 2018-09-07 6:47 ` Eli Zaretskii @ 2018-09-08 5:13 ` Richard Stallman 2018-09-08 14:54 ` Drew Adams ` (2 more replies) 2 siblings, 3 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-08 5:13 UTC (permalink / raw) To: Noam Postavsky; +Cc: hw, spacibba, emacs-devel, eliz, drew.adams, phillip.lord [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] It seems to me that the people who like delete-selection-mode are those who are used to some similar behavior in some other editor and have not truly got used to Emacs. They have two possible paths to follow: get used to Emacs, or stay in the middle. We can provide various features to make Emacs serve each group. But here we have a proposal to make the defaults serve cater primarily to those who don't want to get used to Emacs, rather than those who want to get used to Emacs, and also at the expense of experienced Emacs users. I am against making delete-selection-mode the default. However, there might be some way of helping new users choose this and other settings based on whether they want to truly get used to Emacs or just use it occasionally. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman @ 2018-09-08 14:54 ` Drew Adams 2018-09-09 1:23 ` Ergus 2018-09-08 17:25 ` Clément Pit-Claudel 2018-09-08 18:08 ` delete-selection-mode as default Stefan Monnier 2 siblings, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-08 14:54 UTC (permalink / raw) To: rms, Noam Postavsky; +Cc: hw, eliz, emacs-devel, spacibba, phillip.lord > It seems to me that the people who like delete-selection-mode > are those who are used to some similar behavior in some other > editor and have not truly got used to Emacs. FWIW, that's not my case. My case is the opposite: I was used to "old" Emacs, e.g., pre transient-mark-mode. When `delete-selection-mode' came along I tried it and appreciated it immediately. I had no problem getting used to it. Dunno why. Perhaps simultaneously, or soon thereafter, I started to use other apps that had similar behavior. But I did not use them before using `d-s-m' in Emacs. I used `d-s-m' long before I ever used Emacs on MS Windows, for example. Anyway, I think you're right about most other people who use `d-s-m'. It's likely that they got used to the behavior first outside Emacs. That's probable, simply because many users came to Emacs later and the behavior was already ubiquitous outside Emacs. > They have two possible paths to follow: get used to Emacs, "Get used to Emacs" has nothing to do with it. That's almost insulting, I think. > or stay in the middle. We can provide various features to > make Emacs serve each group. > But here we have a proposal to make the defaults serve cater > primarily to those who don't want to get used to Emacs, I think that's an awful way to express it. What is "Emacs", that these people supposedly don't want to get used to? Emacs to me includes `d-s-mode'. To me, it's just as (un)reasonable to say that those who don't want `d-s-m' to be the default "don't want to get used to Emacs." Neither makes sense. This is not about assimilating immigrants to some dominant culture, and bothering over the question about what to do with those who just "don't want to get used to it" - whether to give them tourist visas, make their short stays comfortable, and not make them adapt. That's the wrong way to look at this, IMO, but that's kind of what I hear you suggesting. (But I hope I'm wrong, and this does really surprise me coming from you, who have typically taken a very positive and fair moral stance.) > rather than those who want to get used to Emacs, > and also at the expense of experienced Emacs users. I don't think either default behavior would be at the expense of experienced Emacs users. It's trivial to set one's preference about this in an init file. I've been doing it for decades. Not a big deal. This is only about what the default behavior should be. That should have no effect on experienced Emacs users. It's not helpful, I think, to cast this as being about people who do or don't "want to get used to Emacs." Putting it that way betrays, at best, a misunderstanding, I think. I vote for making `d-s-m' the default because I think it makes Emacs better - like `transient-mark-mode'. Can't people just opt into it? Sure, and that's been the case for years. It will likely remain the case for many more years, I expect. Why make it the default? No great reason, I think. More people are likely to "get used to Emacs with it". More existing Emacs users are likely to make use of it (maybe). But there's no _compelling_ reason to turn it on - or off - by default, IMO. > I am against making delete-selection-mode the default. Got it. And I am for it. (I wonder where we each stood initially when the question was raised about turning on `transient-mark-mode'?) It's fine and normal for different people to feel differently about such things, and even to feel strongly. I feel (fairly) strongly that `cua-mode' should not be turned on by default, for instance. But most of the same arguments that some are making here for `d-s-m' have been made also for `cua-mode'. To me, those two are very different, especially wrt how they affect the rest of Emacs. `d-s-m' has little to no effect on the use of other keys etc. `cua-mode' conflicts deeply with much of the rest of Emacs (IMO). That's why my arguments for turning on `d-s-m' by default don't focus on most people being already used to that behavior, from outside Emacs. That's the most common argument here in favor of `d-s-m', but it's not mine. I think it is good behavior, and good especially for Emacs. I picked it up after using Emacs for years without it - because I found it helpful. That it facilitates going back and forth between Emacs and other apps is a nice thing, but it's no compelling argument. `cua-mode' would also make it easier to go back and forth, and I'm against that. Does it sometimes trip me up inside Emacs or outside it, when I try to use `C-s' or `C-f' mistakenly? Yup. But I still don't want to use `cua-mode' in Emacs, and I still don't think it should be turned on by default. Just one opinion. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-08 14:54 ` Drew Adams @ 2018-09-09 1:23 ` Ergus 0 siblings, 0 replies; 245+ messages in thread From: Ergus @ 2018-09-09 1:23 UTC (permalink / raw) To: Drew Adams; +Cc: hw, rms, Noam Postavsky, emacs-devel, eliz, phillip.lord On Sat, Sep 08, 2018 at 07:54:18AM -0700, Drew Adams wrote: >> It seems to me that the people who like delete-selection-mode >> are those who are used to some similar behavior in some other >> editor and have not truly got used to Emacs. > >FWIW, that's not my case. My case is the opposite: I was used >to "old" Emacs, e.g., pre transient-mark-mode. When >`delete-selection-mode' came along I tried it and appreciated >it immediately. I had no problem getting used to it. Dunno why. > >Perhaps simultaneously, or soon thereafter, I started to use >other apps that had similar behavior. But I did not use them >before using `d-s-m' in Emacs. I used `d-s-m' long before I ever >used Emacs on MS Windows, for example. > >Anyway, I think you're right about most other people who >use `d-s-m'. It's likely that they got used to the behavior first >outside Emacs. That's probable, simply because many users >came to Emacs later and the behavior was already ubiquitous >outside Emacs. > >> They have two possible paths to follow: get used to Emacs, > >"Get used to Emacs" has nothing to do with it. That's almost >insulting, I think. > >> or stay in the middle. We can provide various features to >> make Emacs serve each group. > >> But here we have a proposal to make the defaults serve cater >> primarily to those who don't want to get used to Emacs, > >I think that's an awful way to express it. What is "Emacs", >that these people supposedly don't want to get used to? > >Emacs to me includes `d-s-mode'. To me, it's just as >(un)reasonable to say that those who don't want `d-s-m' to >be the default "don't want to get used to Emacs." Neither >makes sense. > >This is not about assimilating immigrants to some >dominant culture, and bothering over the question >about what to do with those who just "don't want to get >used to it" - whether to give them tourist visas, make their >short stays comfortable, and not make them adapt. > >That's the wrong way to look at this, IMO, but that's kind >of what I hear you suggesting. (But I hope I'm wrong, and >this does really surprise me coming from you, who have >typically taken a very positive and fair moral stance.) > >> rather than those who want to get used to Emacs, >> and also at the expense of experienced Emacs users. > >I don't think either default behavior would be at the >expense of experienced Emacs users. It's trivial to set >one's preference about this in an init file. I've been >doing it for decades. Not a big deal. > >This is only about what the default behavior should be. >That should have no effect on experienced Emacs users. > >It's not helpful, I think, to cast this as being about people >who do or don't "want to get used to Emacs." Putting it >that way betrays, at best, a misunderstanding, I think. > >I vote for making `d-s-m' the default because I think it >makes Emacs better - like `transient-mark-mode'. > >Can't people just opt into it? Sure, and that's been the >case for years. It will likely remain the case for many >more years, I expect. > >Why make it the default? No great reason, I think. More >people are likely to "get used to Emacs with it". More >existing Emacs users are likely to make use of it (maybe). >But there's no _compelling_ reason to turn it on - or off - >by default, IMO. > >> I am against making delete-selection-mode the default. > >Got it. And I am for it. > >(I wonder where we each stood initially when the question >was raised about turning on `transient-mark-mode'?) > >It's fine and normal for different people to feel differently >about such things, and even to feel strongly. > >I feel (fairly) strongly that `cua-mode' should not be turned >on by default, for instance. But most of the same arguments >that some are making here for `d-s-m' have been made also >for `cua-mode'. > >To me, those two are very different, especially wrt how >they affect the rest of Emacs. `d-s-m' has little to no effect >on the use of other keys etc. `cua-mode' conflicts deeply >with much of the rest of Emacs (IMO). > >That's why my arguments for turning on `d-s-m' by default >don't focus on most people being already used to that >behavior, from outside Emacs. > >That's the most common argument here in favor of `d-s-m', >but it's not mine. I think it is good behavior, and good >especially for Emacs. I picked it up after using Emacs for >years without it - because I found it helpful. > >That it facilitates going back and forth between Emacs and >other apps is a nice thing, but it's no compelling argument. > >`cua-mode' would also make it easier to go back and forth, >and I'm against that. Does it sometimes trip me up inside >Emacs or outside it, when I try to use `C-s' or `C-f' mistakenly? >Yup. But I still don't want to use `cua-mode' in Emacs, and >I still don't think it should be turned on by default. > >Just one opinion. > I agree because cua-mode is very intrusive with the normal emacs workflow, but on the other had cua-rectangle-mode is not and it is not by default in emacs (I can't really understand why) and the default rectangle selection is very primitive. The actual C-x SPC rectangle selection is not as good as cua-rectangle selection in any sense and duplicated functionalities that where already there, it is not possible to move the rectangle or change the rectangle selection to global selection, and for copy/paste/edit it requires extra commands with C-x r prefix. Cua-rectangle-mode offers exactly the same functionalities without the C-x r prefix, plus commands like rectangle selection, edition and move out of the box with no extra commands and not changing the emacs behavior. I think this is one example where the default behavior it much more primitive than the default one for not real reason. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2018-09-08 14:54 ` Drew Adams @ 2018-09-08 17:25 ` Clément Pit-Claudel 2018-09-08 18:08 ` delete-selection-mode as default Stefan Monnier 2 siblings, 0 replies; 245+ messages in thread From: Clément Pit-Claudel @ 2018-09-08 17:25 UTC (permalink / raw) To: emacs-devel On 2018-09-08 01:13, Richard Stallman wrote: > It seems to me that the people who like delete-selection-mode > are those who are used to some similar behavior in some other > editor and have not truly got used to Emacs. I think that might be begging the question, actually. Or, at least, this argument can be applied to any Emacs default, if that default doesn't align with what other editors do. In other words, sufficiently proficient users of Emacs will get used to all of its defaults, or change them. That doesn't mean that they are all good defaults. delete-selection-mode might be a good default; I don't know. I tend to think that we should only diverge from the behavior of other programs if it yields significant benefits. I see lossless undo, kill ring, undo-in-region, and many other features as yielding significant benefits, worth the divergence from other more typical behavior. I don't see delete-selection-mode being off in the same way. That could be because I don't see all that it offers. Clément. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2018-09-08 14:54 ` Drew Adams 2018-09-08 17:25 ` Clément Pit-Claudel @ 2018-09-08 18:08 ` Stefan Monnier 2018-09-09 6:08 ` Richard Stallman 2 siblings, 1 reply; 245+ messages in thread From: Stefan Monnier @ 2018-09-08 18:08 UTC (permalink / raw) To: emacs-devel > It seems to me that the people who like delete-selection-mode > are those who are used to some similar behavior in some other > editor and have not truly got used to Emacs. I think you take it for granted that the non-delete-selection-mode behavior of Emacs is fundamentally superior. I disagree. Both behaviors have their advantages and disadvantages, but I don't see either of them clearly superior to the other. Stefan ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 18:08 ` delete-selection-mode as default Stefan Monnier @ 2018-09-09 6:08 ` Richard Stallman 2018-09-09 7:56 ` Yuri Khan 2018-09-09 14:33 ` Drew Adams 0 siblings, 2 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-09 6:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I think you take it for granted that the non-delete-selection-mode > behavior of Emacs is fundamentally superior. "Fundamentally" is not what I'm talking about. delete-selection-mode is designed for the interface scheme where you select a region with the mouse. That's where we copied it from. In that interface scheme, delete-selection-mode fits. The traditional Emacs interface is that you edit with the keyboard. What fits that interface is that Backspace deletes one character. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 6:08 ` Richard Stallman @ 2018-09-09 7:56 ` Yuri Khan 2018-09-09 14:33 ` Drew Adams 1 sibling, 0 replies; 245+ messages in thread From: Yuri Khan @ 2018-09-09 7:56 UTC (permalink / raw) To: rms; +Cc: Stefan Monnier, Emacs developers On Sun, Sep 9, 2018 at 1:24 PM Richard Stallman <rms@gnu.org> wrote: > delete-selection-mode is designed for the interface scheme where you > select a region with the mouse. That's where we copied it from. > In that interface scheme, delete-selection-mode fits. This is inaccurate. delete-selection-mode works very well with Shift+arrows region selection. ^ permalink raw reply [flat|nested] 245+ messages in thread
* RE: delete-selection-mode as default 2018-09-09 6:08 ` Richard Stallman 2018-09-09 7:56 ` Yuri Khan @ 2018-09-09 14:33 ` Drew Adams 2018-09-10 5:47 ` Richard Stallman 1 sibling, 1 reply; 245+ messages in thread From: Drew Adams @ 2018-09-09 14:33 UTC (permalink / raw) To: rms, Stefan Monnier; +Cc: emacs-devel > > I think you take it for granted that the non-delete-selection-mode > > behavior of Emacs is fundamentally superior. > > "Fundamentally" is not what I'm talking about. > > delete-selection-mode is designed for the interface scheme where you > select a region with the mouse. That's where we copied it from. > In that interface scheme, delete-selection-mode fits. I can't speak to its history - that may be where you copied it from. But its design and its behavior fit just as well with selecting the region in any way, not just with a mouse. The region can be selected programmatically, by setting the mark and moving point interactively, using shift-selection, or any other method that might exist to select the region. > The traditional Emacs interface is that you edit with the > keyboard. What fits that interface is that Backspace deletes > one character. The traditional Emacs interface is defined how? Do you mean Emacs in a terminal? No faces? No mouse support? No text properties? How far back do you go, to find it? Or by traditional do you just mean the default behavior, which means of course that `d-s-m' is off? In any case, `d-s-m' works fine when editing with only the keyboard, with both keyboard and mouse, and with only the mouse (or foot pedals or...). Please don't suggest that `d-s-m' behavior is in some way limited to use with a mouse or that it in some way promotes or is connected with any particular OS (e.g. MS Windows) - it's not. ^ permalink raw reply [flat|nested] 245+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 14:33 ` Drew Adams @ 2018-09-10 5:47 ` Richard Stallman 0 siblings, 0 replies; 245+ messages in thread From: Richard Stallman @ 2018-09-10 5:47 UTC (permalink / raw) To: Drew Adams; +Cc: monnier, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I can't speak to its history - that may be where you copied it from. Your ignorance does not trump my memory. > But its design and its behavior fit just as well with selecting the > region in any way, not just with a mouse. It will operate regardless of how the region was selected, but the case it makes sense for is when the kind of input used for selection is something quite different from the kind of input used for the subsequent deletion. > The traditional Emacs interface is defined how? Do you mean > Emacs in a terminal? No faces? No mouse support? No text > properties? How far back do you go, to find it? These questions don't need to be answered. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 245+ messages in thread
end of thread, other threads:[~2018-10-04 20:20 UTC | newest] Thread overview: 245+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-09-07 0:32 delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 2018-09-07 0:35 ` Drew Adams 2018-09-07 6:47 ` Eli Zaretskii 2018-09-07 9:18 ` delete-selection-mode as default hw 2018-09-07 13:16 ` Clément Pit-Claudel 2018-09-07 13:28 ` Robert Pluim 2018-09-07 13:47 ` Dmitry Gutov 2018-09-07 13:50 ` Eli Zaretskii 2018-09-07 14:16 ` Robert Pluim 2018-09-07 16:02 ` Drew Adams 2018-09-07 17:08 ` Robert Pluim 2018-09-07 20:28 ` Jostein Kjønigsen 2018-09-07 14:22 ` Stefan Monnier 2018-09-08 23:11 ` Juri Linkov 2018-09-09 5:49 ` Eli Zaretskii 2018-09-09 16:16 ` Juri Linkov 2018-09-09 14:22 ` Drew Adams 2018-09-16 23:34 ` Juri Linkov 2018-09-17 0:36 ` Drew Adams 2018-09-17 22:37 ` Juri Linkov 2018-09-17 23:12 ` Drew Adams 2018-09-17 23:21 ` Juri Linkov 2018-09-17 23:36 ` Drew Adams 2018-09-19 6:53 ` Jostein Kjønigsen 2018-09-19 22:44 ` Juri Linkov 2018-09-07 14:39 ` hw 2018-09-07 16:27 ` Drew Adams 2018-09-08 17:37 ` Clément Pit-Claudel 2018-09-09 5:15 ` hw 2018-09-08 5:14 ` Richard Stallman 2018-09-08 11:32 ` Elias Mårtenson 2018-09-08 14:01 ` Eli Zaretskii 2018-09-08 15:52 ` hw 2018-09-08 19:31 ` Charles A. Roelli 2018-09-09 3:19 ` Drew Adams 2018-09-09 6:08 ` Richard Stallman 2018-09-09 14:48 ` Drew Adams 2018-09-10 11:50 ` hw 2018-09-11 4:25 ` Richard Stallman 2018-09-10 7:52 ` hw 2018-09-10 11:52 ` visual-region-mode? (was: delete-selection-mode as default) hw 2018-09-10 20:02 ` Charles A. Roelli 2018-09-11 5:43 ` Yuri Khan 2018-09-11 18:25 ` Charles A. Roelli 2018-09-12 5:12 ` Yuri Khan 2018-09-12 6:59 ` visual-region-mode? Andreas Schwab 2018-09-12 7:12 ` visual-region-mode? Yuri Khan 2018-09-12 7:44 ` visual-region-mode? Andreas Schwab 2018-09-12 18:31 ` visual-region-mode? (was: delete-selection-mode as default) Charles A. Roelli 2018-09-16 22:55 ` visual-region-mode? Juri Linkov 2018-09-11 21:56 ` visual-region-mode? hw 2018-09-12 19:47 ` visual-region-mode? Charles A. Roelli 2018-09-12 20:40 ` visual-region-mode? Drew Adams 2018-09-12 20:50 ` visual-region-mode? Juri Linkov 2018-09-13 4:01 ` visual-region-mode? hw 2018-09-13 4:00 ` visual-region-mode? hw 2018-09-13 17:22 ` visual-region-mode? Alan Mackenzie 2018-09-13 20:08 ` visual-region-mode? hw 2018-09-13 20:42 ` visual-region-mode? Charles A. Roelli 2018-09-15 19:21 ` visual-region-mode? hw 2018-09-16 19:31 ` visual-region-mode? Charles A. Roelli 2018-09-17 20:36 ` visual-region-mode? hw 2018-09-17 22:24 ` visual-region-mode? Drew Adams 2018-09-17 23:11 ` visual-region-mode? hw 2018-09-18 0:11 ` visual-region-mode? Juri Linkov 2018-09-18 12:32 ` visual-region-mode? Eli Zaretskii 2018-09-18 19:22 ` visual-region-mode? Charles A. Roelli 2018-09-19 1:45 ` visual-region-mode? hw 2018-09-19 19:22 ` visual-region-mode? Charles A. Roelli 2018-09-19 20:04 ` visual-region-mode? hw 2018-09-20 18:14 ` visual-region-mode? Charles A. Roelli 2018-09-21 20:28 ` visual-region-mode? hw 2018-09-24 17:42 ` visual-region-mode? Charles A. Roelli 2018-09-24 18:07 ` visual-region-mode? Yuri Khan 2018-09-29 11:18 ` visual-region-mode? Charles A. Roelli 2018-10-03 13:13 ` visual-region-mode? hw 2018-10-04 20:20 ` visual-region-mode? Charles A. Roelli 2018-09-26 22:00 ` visual-region-mode? hw 2018-09-27 21:01 ` visual-region-mode? Charles A. Roelli 2018-10-03 13:59 ` visual-region-mode? hw 2018-09-24 20:24 ` visual-region-mode? Alan Mackenzie 2018-09-26 18:12 ` visual-region-mode? Charles A. Roelli 2018-09-26 22:45 ` visual-region-mode? hw 2018-09-27 17:26 ` visual-region-mode? Alan Mackenzie 2018-10-03 15:43 ` visual-region-mode? hw 2018-10-03 17:03 ` visual-region-mode? Alan Mackenzie [not found] ` <<m2ftxy3i79.fsf@aurox.ch> 2018-09-24 20:39 ` visual-region-mode? Drew Adams 2018-09-12 20:27 ` visual-region-mode? Juri Linkov 2018-09-08 18:16 ` delete-selection-mode as default Dmitry Gutov 2018-09-09 7:42 ` Elias Mårtenson 2018-09-09 14:25 ` Clément Pit-Claudel 2018-09-07 9:40 ` delete-selection-mode as default (WAS: Some developement questions) Phil Sainty 2018-09-07 13:41 ` Eli Zaretskii 2018-09-08 11:37 ` Phil Sainty 2018-09-08 14:04 ` Eli Zaretskii 2018-09-07 15:35 ` Drew Adams 2018-09-07 16:16 ` Yuri Khan 2018-09-07 19:01 ` tomas 2018-09-07 19:23 ` Drew Adams 2018-09-07 20:28 ` tomas 2018-09-08 23:19 ` delete-selection-mode as default Juri Linkov 2018-09-09 8:02 ` tomas 2018-09-07 20:33 ` delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 2018-09-07 21:31 ` tomas 2018-09-10 8:01 ` delete-selection-mode as default Robert Pluim 2018-09-10 8:09 ` tomas 2018-09-09 13:45 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 2018-09-09 14:22 ` Clément Pit-Claudel 2018-09-09 15:12 ` Drew Adams 2018-09-10 11:42 ` delete-selection-mode as default Filipp Gunbin 2018-09-09 20:39 ` delete-selection-mode as default (WAS: Some developement questions) Joost Kremers 2018-09-09 22:24 ` Drew Adams 2018-09-10 3:08 ` Phil Sainty 2018-09-10 3:17 ` Drew Adams 2018-09-10 5:15 ` Bingo 2018-09-10 13:34 ` delete-selection-mode as default Stefan Monnier 2018-09-10 8:46 ` hw 2018-09-10 18:16 ` delete-selection-mode as default (WAS: Some developement questions) Alan Mackenzie 2018-09-10 18:35 ` Clément Pit-Claudel 2018-09-10 19:19 ` Alan Mackenzie 2018-09-10 20:36 ` Drew Adams 2018-09-11 22:34 ` delete-selection-mode as default hw 2018-09-12 0:04 ` Drew Adams 2018-09-13 2:58 ` hw 2018-09-12 13:16 ` Alan Mackenzie 2018-09-12 13:41 ` Drew Adams 2018-09-12 14:53 ` Alan Mackenzie 2018-09-12 15:51 ` Yuri Khan 2018-09-12 15:59 ` Alan Mackenzie 2018-09-12 16:36 ` Yuri Khan 2018-09-13 3:59 ` Elias Mårtenson 2018-09-13 4:16 ` hw 2018-09-13 17:46 ` Alan Mackenzie 2018-09-13 20:32 ` hw 2018-09-14 10:48 ` Alan Mackenzie 2018-09-14 13:41 ` Yuri Khan 2018-09-14 14:03 ` Alan Mackenzie 2018-09-14 15:37 ` Yuri Khan 2018-09-14 14:29 ` Phil Sainty 2018-09-14 14:32 ` Phil Sainty 2018-09-14 14:33 ` Eli Zaretskii 2018-09-14 15:23 ` Drew Adams 2018-09-14 18:49 ` Eli Zaretskii 2018-09-15 21:20 ` hw 2018-09-15 22:37 ` hw 2018-09-16 0:22 ` Drew Adams 2018-09-16 3:15 ` hw 2018-09-16 3:34 ` Drew Adams 2018-09-16 13:48 ` hw 2018-09-16 14:14 ` Alan Mackenzie 2018-09-17 21:00 ` hw 2018-09-16 15:28 ` Yuri Khan 2018-09-16 16:30 ` Drew Adams 2018-09-16 16:59 ` Eli Zaretskii 2018-09-16 18:20 ` Yuri Khan 2018-09-16 18:49 ` Eli Zaretskii 2018-09-16 20:17 ` Drew Adams 2018-09-17 21:22 ` hw 2018-09-18 12:14 ` Eli Zaretskii 2018-09-18 23:45 ` hw 2018-09-19 5:41 ` Eli Zaretskii 2018-09-19 20:09 ` hw [not found] ` <<831s9tidjc.fsf@gnu.org> 2018-09-16 18:04 ` Drew Adams 2018-09-16 18:17 ` Eli Zaretskii [not found] ` <<83va75gvc8.fsf@gnu.org> 2018-09-16 20:14 ` Drew Adams [not found] ` <<CAP_d_8VcFjkQQxzgv+XUheE4Q33vNgbuGpGwtv2-dOEBuK7OeQ@mail.gmail.com> [not found] ` <<83tvmpgtwe.fsf@gnu.org> 2018-09-16 20:29 ` Drew Adams 2018-09-17 5:28 ` Yuri Khan 2018-09-16 8:06 ` Yuri Khan 2018-09-16 13:36 ` hw 2018-09-16 16:48 ` Eli Zaretskii 2018-09-17 22:11 ` hw 2018-09-17 22:44 ` Drew Adams 2018-09-17 23:30 ` hw 2018-09-18 12:31 ` Eli Zaretskii 2018-09-18 13:14 ` Yuri Khan 2018-09-18 14:14 ` Eli Zaretskii 2018-09-18 15:28 ` Yuri Khan 2018-09-18 15:37 ` Drew Adams 2018-09-18 16:49 ` Eli Zaretskii 2018-09-18 16:46 ` Eli Zaretskii 2018-09-20 1:46 ` Richard Stallman 2018-09-20 5:45 ` Yuri Khan 2018-09-19 2:26 ` hw 2018-09-19 6:38 ` Eli Zaretskii 2018-09-19 20:36 ` hw [not found] ` <<874leq799e.fsf@toy.adminart.net> [not found] ` <<205df9be-2e5c-4cc4-a13a-7c80eb63bedc@default> [not found] ` <<87in363zgq.fsf@toy.adminart.net> [not found] ` <<aedad52c-aaf1-414d-bc8c-8e7d0284f4c8@default> [not found] ` <<835zz5ie17.fsf@gnu.org> [not found] ` <<87musg0wyf.fsf@toy.adminart.net> [not found] ` <<83va73f0mv.fsf@gnu.org> [not found] ` <<CAP_d_8WFoHecEv-krQmAP0fWVSYXDLWuwdKfXwpcLbkJYYfWJQ@mail.gmail.com> [not found] ` <<83musegaf2.fsf@gnu.org> [not found] ` <<CAP_d_8VH38kAdG3QZ4EiM_3-S+PVFg=7QyxZP6pZG_mc3Qct5w@mail.gmail.com> [not found] ` <<3f242636-6fa4-4e36-a37b-86f1d7088aae@default> [not found] ` <<83h8img39b.fsf@gnu.org> 2018-09-18 17:42 ` Drew Adams 2018-09-18 18:30 ` Eli Zaretskii 2018-09-18 19:15 ` Alan Mackenzie 2018-09-14 15:15 ` Elias Mårtenson 2018-09-14 14:33 ` Drew Adams 2018-09-15 21:59 ` hw 2018-09-15 20:31 ` hw 2018-09-11 23:30 ` Juri Linkov 2018-09-12 0:13 ` Drew Adams 2018-09-10 7:05 ` delete-selection-mode as default (WAS: Some developement questions) Eli Zaretskii 2018-09-10 13:41 ` delete-selection-mode as default Stefan Monnier 2018-09-10 14:01 ` Eli Zaretskii 2018-09-10 14:19 ` Stefan Monnier 2018-09-10 14:24 ` Drew Adams [not found] ` <<83tvmxo3iy.fsf@gnu.org> 2018-09-10 14:30 ` Drew Adams 2018-09-10 14:54 ` Eli Zaretskii 2018-09-10 16:09 ` Yuri Khan [not found] ` <<<83tvmxo3iy.fsf@gnu.org> [not found] ` <<c7872ab4-8a1b-43bc-aeb4-2d08bc899857@default> [not found] ` <<83muspo12f.fsf@gnu.org> 2018-09-10 15:25 ` Drew Adams 2018-09-11 4:22 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2018-09-11 7:48 ` Eli Zaretskii 2018-09-12 0:33 ` Richard Stallman 2018-09-11 8:08 ` Eli Zaretskii 2018-09-12 0:33 ` Richard Stallman 2018-09-12 14:07 ` Eli Zaretskii 2018-09-11 12:36 ` delete-selection-mode as default Stefan Monnier 2018-09-11 23:09 ` hw 2018-09-12 0:33 ` Richard Stallman 2018-09-12 13:23 ` Stefan Monnier 2018-09-13 3:33 ` Richard Stallman [not found] ` <<87sh2ih0bp.fsf@fastmail.fm> [not found] ` <<770f48a8-664a-40ae-8e03-19f6aad248b6@default> [not found] ` <<20180910181615.GA4829@ACM> [not found] ` <<ab70ed3e-96a7-446f-be9b-e02130e71927@default> [not found] ` <<874lev3bq4.fsf@toy.adminart.net> [not found] ` <<20180912131602.GA5582@ACM> [not found] ` <<87d0tihxzw.fsf@toy.adminart.net> [not found] ` <<20180913174640.GB4019@ACM> [not found] ` <<8736udkuit.fsf@toy.adminart.net> [not found] ` <<20180914104833.GA4103@ACM> [not found] ` <<CAP_d_8WpO9+w-W1ZXMyoucUNtofNQ3Bc6Gchmxj6Rgy1nm3FOA@mail.gmail.com> [not found] ` <<83k1nojgia.fsf@gnu.org> [not found] ` <<7bed1f76-5bae-44cb-9b22-206b513043be@default> [not found] ` <<83d0tfkj77.fsf@gnu.org> 2018-09-14 20:57 ` Drew Adams 2018-09-15 7:50 ` Eli Zaretskii 2018-09-15 10:20 ` Alan Mackenzie 2018-09-15 10:56 ` Eli Zaretskii 2018-09-15 19:44 ` Ergus 2018-09-15 20:01 ` Eli Zaretskii 2018-09-16 0:29 ` Ergus 2018-09-16 16:55 ` Eli Zaretskii 2018-09-16 10:52 ` Alan Mackenzie [not found] ` <3D72B095-01EC-4E7D-90F9-5691AEFE16DC@aol.com> 2018-09-17 2:17 ` Alan Mackenzie 2018-09-17 5:46 ` Elias Mårtenson 2018-09-17 18:37 ` Alan Mackenzie 2018-09-17 19:57 ` hw 2018-09-17 22:56 ` Drew Adams 2018-09-15 15:02 ` Stefan Monnier 2018-09-15 15:27 ` Eli Zaretskii 2018-09-15 18:30 ` Stefan Monnier 2018-09-15 20:04 ` Eli Zaretskii 2018-09-16 3:14 ` Richard Stallman [not found] ` <<83zhwji4hx.fsf@gnu.org> 2018-09-17 0:55 ` Drew Adams 2018-10-03 0:22 ` Richard Stallman 2018-10-03 17:38 ` Eli Zaretskii 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 2018-09-08 14:54 ` Drew Adams 2018-09-09 1:23 ` Ergus 2018-09-08 17:25 ` Clément Pit-Claudel 2018-09-08 18:08 ` delete-selection-mode as default Stefan Monnier 2018-09-09 6:08 ` Richard Stallman 2018-09-09 7:56 ` Yuri Khan 2018-09-09 14:33 ` Drew Adams 2018-09-10 5:47 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.