* Re: delete-selection-mode as default (WAS: Some developement questions) @ 2018-09-08 3:46 Bingo 2018-09-08 15:03 ` delete-selection-mode as default hw 0 siblings, 1 reply; 169+ messages in thread From: Bingo @ 2018-09-08 3:46 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 612 bytes --] Hi, Can we consider changing defaults only for users who don't have any init file at all ? This change may not solve many problems, due to two other features of emacs : 1. Emacs undo is frustrating for most new users. Correcting mistakes with delete-selection-mode i.e. restore a selection that was deleted due to a mistaken delete by typing/pasting , will need them to use undo. 2. In their attempt to play with undo/redo, they might do C-y. Which pastes in Emacs : but it is the key for redo in many "modern" editors. This can cause more unintended deletions in delete-selection-mode. Thanks [-- Attachment #2: Type: text/html, Size: 662 bytes --] ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 3:46 delete-selection-mode as default (WAS: Some developement questions) Bingo @ 2018-09-08 15:03 ` hw 2018-09-08 16:15 ` Eli Zaretskii 2018-09-08 16:31 ` Bingo 0 siblings, 2 replies; 169+ messages in thread From: hw @ 2018-09-08 15:03 UTC (permalink / raw) To: Bingo; +Cc: emacs-devel Bingo <right.ho@gmail.com> writes: > Can we consider changing defaults only for users who don't have any init file at all ? Unexpectable behaviour of Emacs only because there is no ~/.emacs would be confusing. Which defaults is Emacs supposed to assume for settings that have not been made in ~/.emacs because the user didn't need to change them before the developers did? > This change may not solve many problems, due to two other features of emacs : These are problems of other editors. > 1. Emacs undo is frustrating for most new users. Correcting mistakes > with delete-selection-mode i.e. restore a selection that was deleted > due to a mistaken delete by typing/pasting , will need them to use > undo. Every editor that doesn't understand Emacs` key bindings and doesn't have its functions is frustrating (to use an euphemism). Emacs` undo sucks when you need it more than once because you have to press two keys for it. Using a prefix doesn't work to make this easier because I have no way of knowing how many times I have to use undo before I get back to where I want to. It is a really bad choice. C-z can not easily be used for undo. Other editors should never have used it for that anyway. I don't see why they would because it suspends the process. > 2. In their attempt to play with undo/redo, they might do C-y. Which > pastes in Emacs : but it is the key for redo in many "modern" > editors. This can cause more unintended deletions in > delete-selection-mode. This is another example of how delete-selection-mode supports making mistakes. Without it, C-y seems fine. Shift+Insert works only in X frames. Now imagine you change the key binding for undo and for yank when there is no ~/.emacs to make things easier for beginners. The beginner uses customize to change colours and to set a font and saves this settings. Suddenly undo and yank --- and perhaps lots of other things --- "don't work" anymore because the key bindings have changed. Does that make things easier for beginners --- or more difficult? ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 15:03 ` delete-selection-mode as default hw @ 2018-09-08 16:15 ` Eli Zaretskii 2018-09-08 23:27 ` hw 2018-09-08 16:31 ` Bingo 1 sibling, 1 reply; 169+ messages in thread From: Eli Zaretskii @ 2018-09-08 16:15 UTC (permalink / raw) To: hw; +Cc: right.ho, emacs-devel > From: hw <hw@adminart.net> > Date: Sat, 08 Sep 2018 17:03:16 +0200 > Cc: emacs-devel@gnu.org > > Emacs` undo sucks when you need it more than once because you have to > press two keys for it. Is C-/ and C-_ one key or two? If two, then so it C-z; thus, Emacs is not worse than other editors in this regard. ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 16:15 ` Eli Zaretskii @ 2018-09-08 23:27 ` hw 2018-09-09 1:15 ` Phil Sainty 0 siblings, 1 reply; 169+ messages in thread From: hw @ 2018-09-08 23:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: right.ho, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: hw <hw@adminart.net> >> Date: Sat, 08 Sep 2018 17:03:16 +0200 >> Cc: emacs-devel@gnu.org >> >> Emacs` undo sucks when you need it more than once because you have to >> press two keys for it. > > Is C-/ and C-_ one key or two? If two, then so it C-z; thus, Emacs is > not worse than other editors in this regard. On a German keyboard with default bindings, those are both 3 keys each, which are rather awkward to press: Shift+Control+7 and Shift+Control+-. By that counting, C-x u is three keys, too, sorry. It is less awkward than the others. I'm inconsistent with the counting because in most cases, I don't make much difference between pressing a key together with or without a modifier. But when it becomes awkward, it does make a difference, and the awkward part of C-x u is not the C-x but the u. With the others, all of it is awkward and they are definitely 3 keys :) I guess this is how we learn to count to 3 eventually ;) ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 23:27 ` hw @ 2018-09-09 1:15 ` Phil Sainty 2018-09-09 3:33 ` Drew Adams 2018-09-09 17:41 ` hw 0 siblings, 2 replies; 169+ messages in thread From: Phil Sainty @ 2018-09-09 1:15 UTC (permalink / raw) To: hw; +Cc: Eli Zaretskii, right.ho, emacs-devel On 09/09/18 11:27, hw wrote: >> Is C-/ and C-_ one key or two? If two, then so it C-z; thus, Emacs is >> not worse than other editors in this regard. > > On a German keyboard with default bindings, those are both 3 keys each, > which are rather awkward to press: Shift+Control+7 and Shift+Control+-. That's unfortunate. It's notable that of the CUA-style bindings, one can rebind C-z to `undo' in Emacs without the same degree of conflict that the other CUA keys introduce; so you might consider: (global-set-key (kbd "C-z") #'undo) C-z is `suspend-frame' by default (which makes complete sense when Emacs is running in a terminal, so changing this default isn't an option IMO), but it's a convenient key to *intentionally* re-purpose if you know how to `suspend-frame' without it (n.b. C-x C-z is also provided by default). Because it's such a fundamental behaviour, AFAIK no other default keymaps touch this key sequence. Or you could pick any other convenient `undo' binding, of course (but even then you might still change C-z. I use C-z as a prefix key, with C-z C-z as `suspend-frame', which I find provides me with a very useful additional prefix for custom bindings.) -Phil ^ permalink raw reply [flat|nested] 169+ messages in thread
* RE: delete-selection-mode as default 2018-09-09 1:15 ` Phil Sainty @ 2018-09-09 3:33 ` Drew Adams 2018-09-09 17:41 ` hw 1 sibling, 0 replies; 169+ messages in thread From: Drew Adams @ 2018-09-09 3:33 UTC (permalink / raw) To: Phil Sainty, hw; +Cc: Eli Zaretskii, right.ho, emacs-devel > It's notable that of the CUA-style bindings, one can rebind C-z to > `undo' in Emacs without the same degree of conflict that the other CUA > keys introduce; so you might consider: > > (global-set-key (kbd "C-z") #'undo) > > C-z is `suspend-frame' by default (which makes complete sense when > Emacs is running in a terminal, so changing this default isn't an > option IMO), but it's a convenient key to *intentionally* re-purpose > if you know how to `suspend-frame' without it (n.b. C-x C-z is also > provided by default). Because it's such a fundamental behaviour, > AFAIK no other default keymaps touch this key sequence. > > Or you could pick any other convenient `undo' binding, of course > (but even then you might still change C-z. I use C-z as a prefix > key, with C-z C-z as `suspend-frame', which I find provides me with > a very useful additional prefix for custom bindings.) One of the reasons I'm not a fan of `cua-mode' for Emacs is that it wastes good prefix keys (C-x, C-c ). (Yes, I know that `cua-mode' can accommodate to some extent this by way of timing, but that's not good UI, IMO.) I think C-z is wasted on a single action not only in `cua-mode' but also in vanilla Emacs. It makes sense to use it as either a prefix key or at least as a key that can be used for actions that are repeatable (by holding down the key). That said, for my own use I haven't bothered to use C-z as a prefix key or for a repeatable command. I use it to thumbify and dethumbify a frame (like iconify deiconify). But for Emacs I think it should be used as stated above, not wasted on `suspend-frame'. ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 1:15 ` Phil Sainty 2018-09-09 3:33 ` Drew Adams @ 2018-09-09 17:41 ` hw 1 sibling, 0 replies; 169+ messages in thread From: hw @ 2018-09-09 17:41 UTC (permalink / raw) To: Phil Sainty; +Cc: Eli Zaretskii, right.ho, emacs-devel Phil Sainty <psainty@orcon.net.nz> writes: > On 09/09/18 11:27, hw wrote: >>> Is C-/ and C-_ one key or two? If two, then so it C-z; thus, Emacs is >>> not worse than other editors in this regard. >> >> On a German keyboard with default bindings, those are both 3 keys each, >> which are rather awkward to press: Shift+Control+7 and Shift+Control+-. > > That's unfortunate. Fortunately, MOTT a single undo or a few are sufficient. A few are still ok, quite a few sucks, one reason being that it's easy to hit the wrong key and screw up the undoing when you have to press C-x u so many times. > It's notable that of the CUA-style bindings, one can rebind C-z to > `undo' in Emacs without the same degree of conflict that the other CUA > keys introduce; so you might consider: > > (global-set-key (kbd "C-z") #'undo) > > C-z is `suspend-frame' by default (which makes complete sense when > Emacs is running in a terminal, so changing this default isn't an > option IMO), but it's a convenient key to *intentionally* re-purpose > if you know how to `suspend-frame' without it (n.b. C-x C-z is also > provided by default). Because it's such a fundamental behaviour, > AFAIK no other default keymaps touch this key sequence. > > Or you could pick any other convenient `undo' binding, of course > (but even then you might still change C-z. I use C-z as a prefix > key, with C-z C-z as `suspend-frame', which I find provides me with > a very useful additional prefix for custom bindings.) I could use C-v for undo. Too much customizing has the disadvantage of getting in trouble with not or differently customized Emacs`. Maybe I should look into a way to have all customization files Emacs needs on a web browser or the like so they can easily be accessed and used everywhere without having to have multiple copies in all places which then need to be kept in sync. I'm probably not the first one to have this idea ... Using git for this comes to mind, but it is horribly difficult to set up access to a git repo when users do not have ssh access to the machine. Emacs would have to clone the repo during startup to put all its files into place. But then, it could be done using a wrapper script that updates the repo and then starts Emacs. I'll give that some thought. ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 15:03 ` delete-selection-mode as default hw 2018-09-08 16:15 ` Eli Zaretskii @ 2018-09-08 16:31 ` Bingo 2018-09-10 2:33 ` hw 1 sibling, 1 reply; 169+ messages in thread From: Bingo @ 2018-09-08 16:31 UTC (permalink / raw) To: hw; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2432 bytes --] Le 8 septembre 2018 20:33:16 GMT+05:30, hw <hw@adminart.net> a écrit : >Bingo <right.ho@gmail.com> writes: > >> Can we consider changing defaults only for users who don't have any >init file at all ? > >Unexpectable behaviour of Emacs only because there is no ~/.emacs would >be confusing. > >Which defaults is Emacs supposed to assume for settings that have not >been made in ~/.emacs because the user didn't need to change them >before >the developers did? > >> This change may not solve many problems, due to two other features >of emacs : > >These are problems of other editors. > >> 1. Emacs undo is frustrating for most new users. Correcting mistakes >> with delete-selection-mode i.e. restore a selection that was deleted >> due to a mistaken delete by typing/pasting , will need them to use >> undo. > >Every editor that doesn't understand Emacs` key bindings and doesn't >have its functions is frustrating (to use an euphemism). > >Emacs` undo sucks when you need it more than once because you have to >press two keys for it. Using a prefix doesn't work to make this easier >because I have no way of knowing how many times I have to use undo >before I get back to where I want to. It is a really bad choice. > >C-z can not easily be used for undo. Other editors should never have >used it for that anyway. I don't see why they would because it >suspends >the process. > >> 2. In their attempt to play with undo/redo, they might do C-y. Which >> pastes in Emacs : but it is the key for redo in many "modern" >> editors. This can cause more unintended deletions in >> delete-selection-mode. > >This is another example of how delete-selection-mode supports making >mistakes. Without it, C-y seems fine. Shift+Insert works only in X >frames. > >Now imagine you change the key binding for undo and for yank when there >is no ~/.emacs to make things easier for beginners. The beginner uses >customize to change colours and to set a font and saves this settings. > >Suddenly undo and yank --- and perhaps lots of other things --- "don't >work" anymore because the key bindings have changed. Does that make >things easier for beginners --- or more difficult? I have clarified here : https://lists.gnu.org/archive/html/emacs-devel/2018-09/msg00330.html. Absence of init file is to be noticed only once. At other places in your email, is it sarcasm ? Thanks [-- Attachment #2: Type: text/html, Size: 3350 bytes --] ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 16:31 ` Bingo @ 2018-09-10 2:33 ` hw 0 siblings, 0 replies; 169+ messages in thread From: hw @ 2018-09-10 2:33 UTC (permalink / raw) To: Bingo; +Cc: emacs-devel Bingo <right.ho@gmail.com> writes: > Le 8 septembre 2018 20:33:16 GMT+05:30, hw <hw@adminart.net> a écrit : >>Bingo <right.ho@gmail.com> writes: > [...] > I have clarified here : > https://lists.gnu.org/archive/html/emacs-devel/2018-09/msg00330.html. Absence > of init file is to be noticed only once. I think it might be better to let the users pick from selections of skins and of groups of settings when there is no ~/.emacs: It leaves the decisions to the users rather than secretly foisting settings and their non-defaults upon them, which is something they might not be willing to wolf down as easily as good defaults. Skins might make Emacs appear more handsomely or prettier, and otherwise more appealing, too. > At other places in your email, is it sarcasm ? How could I possibly answer that? When I say "It depends on how seriously you take it.", I would be very inappropriately sarcastic. I could say "no", and you would think I'm sarcastic. If I say "It's only the way I write that can make it seem so.", you don't know what to think. Just asking which places you're referring to could also make you think I'm sarcastic. ^ permalink raw reply [flat|nested] 169+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) @ 2018-09-07 0:32 Noam Postavsky 2018-09-07 6:47 ` Eli Zaretskii 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 0 siblings, 2 replies; 169+ 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] 169+ 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 6:47 ` Eli Zaretskii 2018-09-07 9:18 ` delete-selection-mode as default hw ` (4 more replies) 2018-09-08 5:13 ` delete-selection-mode as default (WAS: Some developement questions) Richard Stallman 1 sibling, 5 replies; 169+ 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] 169+ 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 19:01 ` delete-selection-mode as default (WAS: Some developement questions) tomas ` (3 subsequent siblings) 4 siblings, 1 reply; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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 2 siblings, 0 replies; 169+ 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] 169+ 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 ` Dmitry Gutov 2 siblings, 1 reply; 169+ 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] 169+ 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 2018-09-09 6:08 ` Richard Stallman 0 siblings, 2 replies; 169+ 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] 169+ 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 1 sibling, 0 replies; 169+ 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] 169+ 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 1 sibling, 2 replies; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-08 18:16 ` Dmitry Gutov @ 2018-09-09 7:42 ` Elias Mårtenson 2018-09-09 14:25 ` Clément Pit-Claudel 0 siblings, 1 reply; 169+ 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] 169+ 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; 169+ 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] 169+ 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 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) 4 siblings, 2 replies; 169+ 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] 169+ messages in thread
* RE: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 19:01 ` delete-selection-mode as default (WAS: Some developement questions) 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-07 19:01 ` delete-selection-mode as default (WAS: Some developement questions) 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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 19:01 ` delete-selection-mode as default (WAS: Some developement questions) tomas @ 2018-09-09 13:45 ` Alan Mackenzie 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 [not found] ` <<87sh2ih0bp.fsf@fastmail.fm> 4 siblings, 1 reply; 169+ 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] 169+ 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-10 11:42 ` Filipp Gunbin 0 siblings, 0 replies; 169+ 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] 169+ 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-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> 4 siblings, 2 replies; 169+ 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] 169+ 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 5:15 ` Bingo ` (2 more replies) 2018-09-10 7:05 ` delete-selection-mode as default (WAS: Some developement questions) Eli Zaretskii 1 sibling, 3 replies; 169+ 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] 169+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 22:24 ` 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 2 siblings, 1 reply; 169+ 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] 169+ 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; 169+ 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] 169+ messages in thread
* Re: delete-selection-mode as default 2018-09-09 22:24 ` Drew Adams 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 2 siblings, 0 replies; 169+ 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] 169+ messages in thread
* Re: delete-selection-mode as default (WAS: Some developement questions) 2018-09-09 22:24 ` Drew Adams 2018-09-10 5:15 ` Bingo 2018-09-10 8:46 ` hw @ 2018-09-10 18:16 ` Alan Mackenzie 2018-09-10 20:36 ` Drew Adams 2 siblings, 1 reply; 169+ 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] 169+ 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 20:36 ` Drew Adams 2018-09-11 22:34 ` delete-selection-mode as default hw 2018-09-11 23:30 ` Juri Linkov 0 siblings, 2 replies; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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 12:36 ` delete-selection-mode as default Stefan Monnier 1 sibling, 1 reply; 169+ 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] 169+ 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 12:36 ` Stefan Monnier 2018-09-11 23:09 ` hw 2018-09-12 0:33 ` Richard Stallman 0 siblings, 2 replies; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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 6:47 ` Eli Zaretskii @ 2018-09-08 5:13 ` Richard Stallman 2018-09-08 18:08 ` delete-selection-mode as default Stefan Monnier 1 sibling, 1 reply; 169+ 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] 169+ 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 18:08 ` Stefan Monnier 2018-09-09 6:08 ` Richard Stallman 0 siblings, 1 reply; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ 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; 169+ 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] 169+ messages in thread
end of thread, other threads:[~2018-10-03 17:38 UTC | newest] Thread overview: 169+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-09-08 3:46 delete-selection-mode as default (WAS: Some developement questions) Bingo 2018-09-08 15:03 ` delete-selection-mode as default hw 2018-09-08 16:15 ` Eli Zaretskii 2018-09-08 23:27 ` hw 2018-09-09 1:15 ` Phil Sainty 2018-09-09 3:33 ` Drew Adams 2018-09-09 17:41 ` hw 2018-09-08 16:31 ` Bingo 2018-09-10 2:33 ` hw -- strict thread matches above, loose matches on Subject: below -- 2018-09-07 0:32 delete-selection-mode as default (WAS: Some developement questions) Noam Postavsky 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-08 18:16 ` Dmitry Gutov 2018-09-09 7:42 ` Elias Mårtenson 2018-09-09 14:25 ` Clément Pit-Claudel 2018-09-07 19:01 ` delete-selection-mode as default (WAS: Some developement questions) 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-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 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 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 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 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.