* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark @ 2011-11-15 20:06 Dani Moncayo 2011-11-15 20:15 ` Dani Moncayo ` (4 more replies) 0 siblings, 5 replies; 30+ messages in thread From: Dani Moncayo @ 2011-11-15 20:06 UTC (permalink / raw) To: 10056 Hello. According to (info "(emacs)Text Registers"), the mark should be deactivated at the end of the command `copy-to-register' (which is TRT; `C-w' behaves that way, for example). But I see that: * The mark (region) remains active after doing "C-x h C-x r s s" (from emacs -Q). * The command's docstring does not mention anything about this. It should, no? In GNU Emacs 24.0.91.1 (i386-mingw-nt6.1.7601) of 2011-11-11 on DANI-PC Windowing system distributor `Microsoft Corp.', version 6.1.7601 configured using `configure --with-gcc (4.5)' -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo @ 2011-11-15 20:15 ` Dani Moncayo 2011-11-15 20:36 ` Dani Moncayo 2011-11-15 20:18 ` Dani Moncayo ` (3 subsequent siblings) 4 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2011-11-15 20:15 UTC (permalink / raw) To: 10056 > But I see that: > * The mark (region) remains active after doing "C-x h C-x r s s" (from > emacs -Q). > * The command's docstring does not mention anything about this. It should, no? I see the same problem with `C-x r k' from a read-only buffer: it should deactivate the mark, as C-w does. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-15 20:15 ` Dani Moncayo @ 2011-11-15 20:36 ` Dani Moncayo 0 siblings, 0 replies; 30+ messages in thread From: Dani Moncayo @ 2011-11-15 20:36 UTC (permalink / raw) To: 10056 >> But I see that: >> * The mark (region) remains active after doing "C-x h C-x r s s" (from >> emacs -Q). >> * The command's docstring does not mention anything about this. It should, no? > > I see the same problem with `C-x r k' from a read-only buffer: it > should deactivate the mark, as C-w does. Same problem for `C-x r r'. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo 2011-11-15 20:15 ` Dani Moncayo @ 2011-11-15 20:18 ` Dani Moncayo 2011-11-21 6:30 ` Chong Yidong ` (2 subsequent siblings) 4 siblings, 0 replies; 30+ messages in thread From: Dani Moncayo @ 2011-11-15 20:18 UTC (permalink / raw) To: 10056 > According to (info "(emacs)Text Registers"), the mark should be > deactivated at the end of the command `copy-to-register' (which is > TRT; `C-w' behaves that way, for example). ^^^^ I meant `M-w', of course. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo 2011-11-15 20:15 ` Dani Moncayo 2011-11-15 20:18 ` Dani Moncayo @ 2011-11-21 6:30 ` Chong Yidong 2012-06-05 7:44 ` Dani Moncayo 2012-07-28 19:01 ` Dani Moncayo 2012-12-05 8:04 ` bug#10056: 24.0.91; Mark deactivation Dani Moncayo 2022-04-26 13:50 ` bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Lars Ingebrigtsen 4 siblings, 2 replies; 30+ messages in thread From: Chong Yidong @ 2011-11-21 6:30 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056 Dani Moncayo <dmoncayo@gmail.com> writes: > Hello. > > According to (info "(emacs)Text Registers"), the mark should be > deactivated at the end of the command `copy-to-register' (which is > TRT; `C-w' behaves that way, for example). > > But I see that: > * The mark (region) remains active after doing "C-x h C-x r s s" (from > emacs -Q). > * The command's docstring does not mention anything about this. It should, no? I agree that the mark should be deactivated. But the current behavior has been in place for a long time, so this change can probably wait till after the release. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-21 6:30 ` Chong Yidong @ 2012-06-05 7:44 ` Dani Moncayo 2012-07-28 19:01 ` Dani Moncayo 1 sibling, 0 replies; 30+ messages in thread From: Dani Moncayo @ 2012-06-05 7:44 UTC (permalink / raw) To: Chong Yidong; +Cc: 10056 On Mon, Nov 21, 2011 at 7:30 AM, Chong Yidong <cyd@gnu.org> wrote: > I agree that the mark should be deactivated. But the current behavior > has been in place for a long time, so this change can probably wait till > after the release. Ping. Could this change[*] be made in the trunk, please? [*] Deactivate the mark after some commands which save the region: `copy-to-register', `copy-rectangle-to-register', `kill-rectangle' (from a read-only buffer). TIA. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-21 6:30 ` Chong Yidong 2012-06-05 7:44 ` Dani Moncayo @ 2012-07-28 19:01 ` Dani Moncayo 2012-07-29 4:45 ` Chong Yidong 2012-07-29 4:50 ` Chong Yidong 1 sibling, 2 replies; 30+ messages in thread From: Dani Moncayo @ 2012-07-28 19:01 UTC (permalink / raw) To: Chong Yidong; +Cc: 10056 > I agree that the mark should be deactivated. But the current behavior > has been in place for a long time, so this change can probably wait till > after the release. Ping (again). Summing up, I find annoying that the following commands currently don't deactivate the mark at the end (when invoked in transient mark mode, when the mark is active): copy-to-register copy-rectangle-to-register kill-rectangle (from a read-only buffer) and I've found a couple more: narrow-to-region c-indent-line-or-region (when the region is already well indented) TIA. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-07-28 19:01 ` Dani Moncayo @ 2012-07-29 4:45 ` Chong Yidong 2012-07-29 9:46 ` Dani Moncayo 2012-07-29 4:50 ` Chong Yidong 1 sibling, 1 reply; 30+ messages in thread From: Chong Yidong @ 2012-07-29 4:45 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056 Dani Moncayo <dmoncayo@gmail.com> writes: > Ping (again). > > Summing up, I find annoying that the following commands currently > don't deactivate the mark at the end (when invoked in transient mark > mode, when the mark is active): > copy-to-register > copy-rectangle-to-register > kill-rectangle (from a read-only buffer) > > and I've found a couple more: > narrow-to-region > c-indent-line-or-region (when the region is already well indented) Thanks for the remider. I've changed copy-to-register and copy-rectangle-to-register to deactivate the mark. I left prepend-to-register and append-to-register alone for now; there may be cases where users want to keep the mark active for those commands, but I'm not certain. As for C-x r k on read-only buffers, the mark is now deactivated, but only if kill-read-only-ok is non-nil (similar to C-w). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-07-29 4:45 ` Chong Yidong @ 2012-07-29 9:46 ` Dani Moncayo 0 siblings, 0 replies; 30+ messages in thread From: Dani Moncayo @ 2012-07-29 9:46 UTC (permalink / raw) To: Chong Yidong; +Cc: 10056 > I left prepend-to-register and append-to-register alone for now; there > may be cases where users want to keep the mark active for those > commands, but I'm not certain. I can't imagine such cases right now, but my imagination is limited :) > As for C-x r k on read-only buffers, the mark is now deactivated, but > only if kill-read-only-ok is non-nil (similar to C-w). ?? I don't see such behavior in a recent build of the trunk. I've just tested C-x r k (from Emacs -Q, in an Info buffer), and the mark is not deactivated, even if kill-read-only-ok is non-nil. IMO, the mark should definitely be deactivated in this case. And what is more, when kill-read-only-ok is nil, "C-x r k" still does its job (despite the error message shown in the echo area), i.e., it saves the rectangle contents. Therefore, this is confusing from my POV. IMO, either the command should do nothing in this case (no rectangle text gets saved), or, if the intention is to save the rectangle also in this case, the mark should be deactivated, because not doing so gives (me) the wrong impression, i.e, that the command has been cancelled and nothing more happened. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-07-28 19:01 ` Dani Moncayo 2012-07-29 4:45 ` Chong Yidong @ 2012-07-29 4:50 ` Chong Yidong 2012-07-29 10:01 ` Dani Moncayo 1 sibling, 1 reply; 30+ messages in thread From: Chong Yidong @ 2012-07-29 4:50 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056 Dani Moncayo <dmoncayo@gmail.com> writes: > and I've found a couple more: > narrow-to-region > c-indent-line-or-region (when the region is already well indented) I'm not sure about narrow-to-region. It's probably wrong for it to unconditionally deactivate the mark, because it is commonly called as a Lisp function. Maybe it should only deactivate the mark when called interactively. As for c-indent-line-or-region, I have no opinion on that at all. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-07-29 4:50 ` Chong Yidong @ 2012-07-29 10:01 ` Dani Moncayo 2012-08-01 21:17 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2012-07-29 10:01 UTC (permalink / raw) To: Chong Yidong; +Cc: Alan Mackenzie, 10056 >> and I've found a couple more: >> narrow-to-region >> c-indent-line-or-region (when the region is already well indented) > > I'm not sure about narrow-to-region. It's probably wrong for it to > unconditionally deactivate the mark, because it is commonly called as a > Lisp function. Maybe it should only deactivate the mark when called > interactively. I will be happy if the deactivation is limited to the interactive call. But at least in this case should be deactivated, because it is annoying to have to do the deactivation manually with C-g. > As for c-indent-line-or-region, I have no opinion on that at all. (I'm CC-ing Alan. Hopefully he has an opinion) This is the current behavior I observe: * If the command has to adjust the indentation of some line(s) in the region, the mark is deactivated at the end of the command. * Else, the mark is not deactivated. This behavior is definitely annoying for me: when I mark some fragment of code and type TAB, what I want is that Emacs revise the indentation of code, and correct it if necessary, but in any case, I don't want the mark to remain active. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-07-29 10:01 ` Dani Moncayo @ 2012-08-01 21:17 ` Alan Mackenzie 2012-08-01 22:07 ` Dani Moncayo 2012-09-08 20:21 ` Stefan Monnier 0 siblings, 2 replies; 30+ messages in thread From: Alan Mackenzie @ 2012-08-01 21:17 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056, Chong Yidong Hi, Dani. On Sun, Jul 29, 2012 at 12:01:51PM +0200, Dani Moncayo wrote: > >> and I've found a couple more: > >> narrow-to-region > >> c-indent-line-or-region (when the region is already well indented) > > I'm not sure about narrow-to-region. It's probably wrong for it to > > unconditionally deactivate the mark, because it is commonly called as a > > Lisp function. Maybe it should only deactivate the mark when called > > interactively. > I will be happy if the deactivation is limited to the interactive > call. But at least in this case should be deactivated, because it is > annoying to have to do the deactivation manually with C-g. > > As for c-indent-line-or-region, I have no opinion on that at all. > (I'm CC-ing Alan. Hopefully he has an opinion) This is the current > behavior I observe: > * If the command has to adjust the indentation of some line(s) in the > region, the mark is deactivated at the end of the command. > * Else, the mark is not deactivated. > This behavior is definitely annoying for me: when I mark some fragment > of code and type TAB, what I want is that Emacs revise the indentation > of code, and correct it if necessary, but in any case, I don't want > the mark to remain active. Have you looked at the code for c-i-l-o-region? At a quick glance, I can't see where the distinction is made between indentation adjusted and not adjusted. I don't actually use transient-mark-mode myself, so this hasn't annoyed me one way or the other. Is the distinction there for a reason, or did it just get there by accident? The defun is only several (as opposed to many) years old, so the evidence should still be available in the bzr repo. > -- > Dani Moncayo -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-08-01 21:17 ` Alan Mackenzie @ 2012-08-01 22:07 ` Dani Moncayo 2012-08-03 21:47 ` Alan Mackenzie 2012-09-08 20:21 ` Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2012-08-01 22:07 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 10056, Chong Yidong >> > As for c-indent-line-or-region, I have no opinion on that at all. > >> (I'm CC-ing Alan. Hopefully he has an opinion) This is the current >> behavior I observe: >> * If the command has to adjust the indentation of some line(s) in the >> region, the mark is deactivated at the end of the command. >> * Else, the mark is not deactivated. > >> This behavior is definitely annoying for me: when I mark some fragment >> of code and type TAB, what I want is that Emacs revise the indentation >> of code, and correct it if necessary, but in any case, I don't want >> the mark to remain active. > > Have you looked at the code for c-i-l-o-region? At a quick glance, I > can't see where the distinction is made between indentation adjusted and > not adjusted. I don't actually use transient-mark-mode myself, so this > hasn't annoyed me one way or the other. > > Is the distinction there for a reason, or did it just get there by > accident? The defun is only several (as opposed to many) years old, so > the evidence should still be available in the bzr repo. I'm sorry, I (still) don't have enough knowledge of Emacs to delve into such questions. I reported this bug as a mere user, hoping that you (the maintainers), if agree with my reasoning, make the suitable changes to the program. In the case at hand, what I reported is quite simple, I think: from "emacs -Q" (transient mark mode on) visit some C file, select some fragment of code and type TAB. Hopefully you'll see the same behavior as me: * If the code in the region was already well indented, nothing happens and the mark remains active. * Else, the code is indented and the mark is deactivated. What I say is that the mark should be deactivated _always_ at the end of the command, because the "transient" operation (revise the indentation of those lines) is done. This is so obvious to me that I'm surprised of seeing you so hesitant... but well, you decide :) -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-08-01 22:07 ` Dani Moncayo @ 2012-08-03 21:47 ` Alan Mackenzie 0 siblings, 0 replies; 30+ messages in thread From: Alan Mackenzie @ 2012-08-03 21:47 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056, Chong Yidong Hi, Dani. On Thu, Aug 02, 2012 at 12:07:06AM +0200, Dani Moncayo wrote: > >> > As for c-indent-line-or-region, I have no opinion on that at all. > >> (I'm CC-ing Alan. Hopefully he has an opinion) This is the current > >> behavior I observe: > >> * If the command has to adjust the indentation of some line(s) in the > >> region, the mark is deactivated at the end of the command. > >> * Else, the mark is not deactivated. > >> This behavior is definitely annoying for me: when I mark some fragment > >> of code and type TAB, what I want is that Emacs revise the indentation > >> of code, and correct it if necessary, but in any case, I don't want > >> the mark to remain active. > > Have you looked at the code for c-i-l-o-region? At a quick glance, I > > can't see where the distinction is made between indentation adjusted and > > not adjusted. I don't actually use transient-mark-mode myself, so this > > hasn't annoyed me one way or the other. > > Is the distinction there for a reason, or did it just get there by > > accident? The defun is only several (as opposed to many) years old, so > > the evidence should still be available in the bzr repo. > I'm sorry, I (still) don't have enough knowledge of Emacs to delve > into such questions. > I reported this bug as a mere user, hoping that you (the maintainers), > if agree with my reasoning, make the suitable changes to the program. Sorry, misunderstanding on my part there. > In the case at hand, what I reported is quite simple, I think: from > "emacs -Q" (transient mark mode on) visit some C file, select some > fragment of code and type TAB. > Hopefully you'll see the same behavior as me: > * If the code in the region was already well indented, nothing happens > and the mark remains active. > * Else, the code is indented and the mark is deactivated. Yes, I see this. > What I say is that the mark should be deactivated _always_ at the end > of the command, because the "transient" operation (revise the > indentation of those lines) is done. > This is so obvious to me that I'm surprised of seeing you so > hesitant... but well, you decide :) The hesitancy comes from long experience of Emacs; things which are so obviously wrong to some are obviously the RT to others. I was wondering if this behaviour, strange though it seems to both of us, might have been programmed deliberately. In this case, there seems to be some bug at the lower levels of Emacs. There is nothing in CC Mode I can find to explain this strange behaviour. According to the elisp manual, the normal way of deactivating a region when transient mark mode is enabled is to set the variable `deactivate-mark', which instructs the command loop to do the business. CC Mode doesn't set `deactivate-mark' at all. Maybe some primitive does. I don't really know transient-mark-mode. Yidong, have you any suggestions here? > -- > Dani Moncayo -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-08-01 21:17 ` Alan Mackenzie 2012-08-01 22:07 ` Dani Moncayo @ 2012-09-08 20:21 ` Stefan Monnier 2012-09-09 20:20 ` Dani Moncayo 1 sibling, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2012-09-08 20:21 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 10056, Chong Yidong >> This behavior is definitely annoying for me: when I mark some fragment >> of code and type TAB, what I want is that Emacs revise the indentation >> of code, and correct it if necessary, but in any case, I don't want >> the mark to remain active. > Have you looked at the code for c-i-l-o-region? At a quick glance, I > can't see where the distinction is made between indentation adjusted and > not adjusted. The way mark deactivation works is that the mark gets deactivated after any command that modified the buffer (that's the basic heuristic used to avoid having to change umpteen commands to explicitly deactivate-mark). In the case of commands like indent-region which sometimes modify the buffer and sometimes not, it's often necessary to explicitly call deactivate-mark to avoid the kind of inconsistencies described above. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-09-08 20:21 ` Stefan Monnier @ 2012-09-09 20:20 ` Dani Moncayo 2012-09-11 14:42 ` Bastien 0 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2012-09-09 20:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alan Mackenzie, 10056, Chong Yidong > The way mark deactivation works is that the mark gets deactivated after > any command that modified the buffer (that's the basic heuristic used > to avoid having to change umpteen commands to explicitly deactivate-mark). I think that the general principle for deactivating the mark is not (and should not be) "after any command that modified the buffer", but "after any command that _used_ the active region (for any purpose)". For example, to copy some text on the kill ring, you select the text and do C-w. After that, the mark is deactivated. The C-w command doesn't modified the buffer, but _used_ the active region. Thus, after the operation on the active region is done, the mark must be deactivated. IMO, that is what the user wants/expects/needs, and Emacs not always follows this principle. Hence this bug report. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2012-09-09 20:20 ` Dani Moncayo @ 2012-09-11 14:42 ` Bastien 0 siblings, 0 replies; 30+ messages in thread From: Bastien @ 2012-09-11 14:42 UTC (permalink / raw) To: Dani Moncayo; +Cc: Alan Mackenzie, 10056, Chong Yidong Dani Moncayo <dmoncayo@gmail.com> writes: >> The way mark deactivation works is that the mark gets deactivated after >> any command that modified the buffer (that's the basic heuristic used >> to avoid having to change umpteen commands to explicitly deactivate-mark). > > I think that the general principle for deactivating the mark is not > (and should not be) "after any command that modified the buffer", but > "after any command that _used_ the active region (for any purpose)". ... unless it's immediately useful to reuse the active region? But FWIW I agree in general. -- Bastien ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo ` (2 preceding siblings ...) 2011-11-21 6:30 ` Chong Yidong @ 2012-12-05 8:04 ` Dani Moncayo 2012-12-08 10:09 ` Dani Moncayo 2022-04-26 13:50 ` bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Lars Ingebrigtsen 4 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2012-12-05 8:04 UTC (permalink / raw) To: 10056 Hello, As I pointed out previously in this thread, the mark should be deactivated (in general - there can be some exceptions) after any command that operates on the active region. Not doing so is annoying, because the mark must be deactivated in that cases manually by typing `C-g'. There are still cases where I observe this misbehavior. Namely: kill-region [1] kill-rectangle [1] prepend-to-register append-to-register narrow-to-region [2] c-indent-line-or-region [3] delete-duplicate-lines [3] delete-matching-lines [3] delete-non-matching-lines [3] delete-blank-lines [3] I hope this is fixed at some time. Thanks. --- Footnotes --- [1] From a read-only buffer, having `kill-read-only-ok' set to nil. Note that the command does its job in this case, but the mark still remains active. Not TRT IMO. [2] According to Chong, in this case perhaps the mark deactivation should be made only when the call is interactive. [3] When the command doesn't alter the buffer text. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-05 8:04 ` bug#10056: 24.0.91; Mark deactivation Dani Moncayo @ 2012-12-08 10:09 ` Dani Moncayo 2012-12-08 23:03 ` Juri Linkov 0 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2012-12-08 10:09 UTC (permalink / raw) To: 10056 > As I pointed out previously in this thread, the mark should be > deactivated (in general - there can be some exceptions) after any > command that operates on the active region. Not doing so is annoying, > because the mark must be deactivated in that cases manually by typing > `C-g'. > > There are still cases where I observe this misbehavior. Namely: > > kill-region [1] > kill-rectangle [1] > prepend-to-register > append-to-register I forgot to mention, for the two above commands, that the use case is "when invoked with a prefix argument, from a read-only buffer." (regardless of the value of `kill-read-only-ok', which doesn't seem to have any effect on them). > narrow-to-region [2] > c-indent-line-or-region [3] > delete-duplicate-lines [3] > delete-matching-lines [3] > delete-non-matching-lines [3] > delete-blank-lines [3] Add "fill-paragraph [3]" to the above list. Important use-case. > --- Footnotes --- > > [1] From a read-only buffer, having `kill-read-only-ok' set to nil. > Note that the command does its job in this case, but the mark still > remains active. Not TRT IMO. > [2] According to Chong, in this case perhaps the mark deactivation > should be made only when the call is interactive. > [3] When the command doesn't alter the buffer text. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-08 10:09 ` Dani Moncayo @ 2012-12-08 23:03 ` Juri Linkov 2012-12-09 0:00 ` Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Juri Linkov @ 2012-12-08 23:03 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056 >> As I pointed out previously in this thread, the mark should be >> deactivated (in general - there can be some exceptions) after any >> command that operates on the active region. Not doing so is annoying, The problem is how to implement a general rule "the mark should be deactivated after any command that operates on the active region". One way to define "operates on the active region" is when a command uses `region-beginning' and `region-end'. You can try this definition by evaluating: (defun deactivate-mark--advice () (setq deactivate-mark t)) (advice-add 'region-beginning :after #'deactivate-mark--advice) (advice-add 'region-end :after #'deactivate-mark--advice) Does this do what you want with the following functions? >> There are still cases where I observe this misbehavior. Namely: >> >> kill-region [1] >> kill-rectangle [1] >> prepend-to-register >> append-to-register >> narrow-to-region [2] >> c-indent-line-or-region [3] >> delete-duplicate-lines [3] >> delete-matching-lines [3] >> delete-non-matching-lines [3] >> delete-blank-lines [3] > > Add "fill-paragraph [3]" to the above list. Important use-case. Does this have a side effect undesirable for other functions? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-08 23:03 ` Juri Linkov @ 2012-12-09 0:00 ` Drew Adams 2012-12-09 0:29 ` Juri Linkov 0 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2012-12-09 0:00 UTC (permalink / raw) To: 'Juri Linkov', 'Dani Moncayo'; +Cc: 10056 > >> As I pointed out previously in this thread, the mark should be > >> deactivated (in general - there can be some exceptions) after any > >> command that operates on the active region. Not doing so > >> is annoying, > > The problem is how to implement a general rule "the mark should be > deactivated after any command that operates on the active region". To me, the question is why we would do that, and even what the latter part means. > One way to define "operates on the active region" is when a command > uses `region-beginning' and `region-end'. You can try this definition > by evaluating: > (defun deactivate-mark--advice () (setq deactivate-mark t)) > (advice-add 'region-beginning :after #'deactivate-mark--advice) > (advice-add 'region-end :after #'deactivate-mark--advice) > Does this do what you want with the following functions? > ... > Does this have a side effect undesirable for other functions? Please think again before doing this. "Operates on the active region" can mean just about anything, and I fear that such a blanket manipulation will have adverse affects here and there. And I expect in particular that any use of either `region-beginning' or `region-end' casts the net far too wide. Those functions are often used without making any changes to the text in the region (or even in the buffer). For one thing, any such blanket change would still need to respect (not override) a commands's explicit setting or let-binding of `deactivate-mark'. This has been the of policy ever since there was a notion of mark "activeness" (i.e., since `transient-mark-mode'): -- Variable: deactivate-mark If an editor command sets this variable non-`nil', then the editor command loop deactivates the mark after the command returns (if Transient Mark mode is enabled). All the primitives that change the buffer set `deactivate-mark', to deactivate the mark when the command is finished. To write Lisp code that modifies the buffer without causing deactivation of the mark at the end of the command, bind `deactivate-mark' to `nil' around the code that does the modification. For example: (let (deactivate-mark) (insert " ")) I, and I'm sure others too, have a certain amount of code that binds or sets `deactivate-mark'. Just grep the Emacs Lisp sources for examples. There are commands that use the region and are used as functions within other commands. There are commands that can be used repetitively and might expect to leave the region active between successive calls. There are commands whose purpose is to set the active region. Emacs is complex, and one size does not fit all for this kind of thing. If for some reason a particular Emacs command does not deactivate the mark when it is finished, but you think it should, then just deactivate it explicitly in that command. Just because you find some commands that should but do not yet do so is not a sufficient reason to try forcing this everywhere. Someone took the time to ensure that "All the primitives that change the buffer" DTRT in this regard, and that the command loop respects `deactivate-mark'. You have only to continue that policy carefully: if deactivating (or activating) needs doing here or there, then do it here or there, case by case. Otherwise, I think you're asking for trouble. I could be wrong, of course. But it seems a bit heavy-handed to set out on such a crusade just because this or that command might need fixing. Let's try first to fix (only) the commands that Dani or others report such have a problem. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-09 0:00 ` Drew Adams @ 2012-12-09 0:29 ` Juri Linkov 2012-12-09 3:21 ` Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Juri Linkov @ 2012-12-09 0:29 UTC (permalink / raw) To: Drew Adams; +Cc: 10056 > Let's try first to fix (only) the commands that Dani > or others report such have a problem. That means adding `(setq deactivate-mark t)' to some functions, but this is not user-configurable. Maybe like delsel.el puts the property `delete-selection' on some functions, we should use the property `deactivate-mark', e.g.: (put 'fill-paragraph 'deactivate-mark t) ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-09 0:29 ` Juri Linkov @ 2012-12-09 3:21 ` Drew Adams 2012-12-09 9:07 ` Dani Moncayo 0 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2012-12-09 3:21 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 10056 > > Let's try first to fix (only) the commands that Dani > > or others report such have a problem. > > That means adding `(setq deactivate-mark t)' to some functions, > but this is not user-configurable. What is not user-configurable? Why should it be user-configurable whether a command activates or deactivates the mark? Where is that user-configurable today? And if Emacs Dev decides that standard command foo should deactivate the mark when done, but some user wants it to activate the mark (but why?), then s?he can define a command foo' that calls foo and then deactivates the mark. My impression is that you are inventing a problem where there is none. But perhaps I am missing something. Just what is the problem you are trying to solve? > Maybe like delsel.el puts > the property `delete-selection' on some functions, we should use > the property `deactivate-mark', e.g.: > > (put 'fill-paragraph 'deactivate-mark t) YAGNI. What problem are you looking to solve? (And BTW, when you grep for `deactivate-mark' you will notice that delsel.el is one of the libraries with a function that explicitly sets that variable.) ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-09 3:21 ` Drew Adams @ 2012-12-09 9:07 ` Dani Moncayo 2013-01-25 12:34 ` Dani Moncayo 0 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2012-12-09 9:07 UTC (permalink / raw) To: Drew Adams; +Cc: 10056 Thanks to both of you for taking time to think and debate about this. I don't feel qualified enough to have an opinion on which approach is better for fixing this. Drew's proposal (deactivate the mark in a case-by-case basis) seems less general but safer/easier than Juri's in the short-term. Maybe we could take the easy route for now, and perhaps do a refactoring later. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2012-12-09 9:07 ` Dani Moncayo @ 2013-01-25 12:34 ` Dani Moncayo 2013-01-25 17:41 ` Drew Adams 2013-01-25 19:01 ` Stefan Monnier 0 siblings, 2 replies; 30+ messages in thread From: Dani Moncayo @ 2013-01-25 12:34 UTC (permalink / raw) To: Drew Adams; +Cc: 10056 I've just noticed a new case where the mark is not deactivated, when it clearly should (IMO): after `eval-region'. So this is the updated list: eval-region kill-region [1] kill-rectangle [1] prepend-to-register [4] append-to-register [4] narrow-to-region [2] fill-paragraph [3] c-indent-line-or-region [3] delete-duplicate-lines [3] delete-matching-lines [3] delete-non-matching-lines [3] delete-blank-lines [3] --- Footnotes --- [1] From a read-only buffer, having `kill-read-only-ok' set to nil. Note that the command does its job in this case, but the mark still remains active. Not TRT IMO. [2] According to Chong, in this case perhaps the mark deactivation should be made only when the call is interactive. [3] When the command doesn't alter the buffer text. [4] When invoked with a prefix argument, from a read-only buffer (regardless of the value of `kill-read-only-ok', which doesn't seem to have any effect on them). -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2013-01-25 12:34 ` Dani Moncayo @ 2013-01-25 17:41 ` Drew Adams 2013-01-25 19:07 ` Dani Moncayo 2013-01-25 19:01 ` Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: Drew Adams @ 2013-01-25 17:41 UTC (permalink / raw) To: 'Dani Moncayo'; +Cc: 10056 > I've just noticed a new case where the mark is not deactivated, when > it clearly should (IMO): after `eval-region'. Why should it? Even when used interactively (and certainly when not!), a user can want to do something else with the active region after evaluating it. Yes, s?he can always hit `C-x C-x C-x C-x' to reactivate it (there is probably a shorter way to do it nowadays, but I still have that habit). But the question is why? What's the reason to deactivate the region after `eval-region'? To be clear, I have no particular objection that I can think of offhand. But I don't see why the behavior should be changed. "If it ain't broke don't fix it." IOW, please argue a bit in favor of the change for this specific command - some reasons, please. Wrt your footnote [2]: Why should we deactivate the region for _any_ command when it is called non-interactively? That doesn't make sense to me (yet - but I'm willing to learn why). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2013-01-25 17:41 ` Drew Adams @ 2013-01-25 19:07 ` Dani Moncayo 2013-01-25 19:34 ` Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2013-01-25 19:07 UTC (permalink / raw) To: Drew Adams; +Cc: 10056 On Fri, Jan 25, 2013 at 6:41 PM, Drew Adams <drew.adams@oracle.com> wrote: >> I've just noticed a new case where the mark is not deactivated, when >> it clearly should (IMO): after `eval-region'. > > Why should it? > > Even when used interactively (and certainly when not!), I'm concerned about _interactive_ usability. Sorry if I didn't make that clear before. > a user can want to do > something else with the active region after evaluating it. > > Yes, s?he can always hit `C-x C-x C-x C-x' to reactivate it (there is probably a > shorter way to do it nowadays, but I still have that habit). But the question > is why? What's the reason to deactivate the region after `eval-region'? > > To be clear, I have no particular objection that I can think of offhand. But I > don't see why the behavior should be changed. "If it ain't broke don't fix it." > IOW, please argue a bit in favor of the change for this specific command - some > reasons, please. Well, the reason is the same for all commands I've mentioned: In my experience (or my usage pattern), after defining an active region and invoking a command to operate on it, it's much more likely that the next commands have nothing to do with that active region. IOW, I almost always set up an active region to do a single operation on it, not several ones. So keeping the region active is, at best, counter intuitive and visually annoying to me. > Wrt your footnote [2]: Why should we deactivate the region for _any_ command > when it is called non-interactively? That doesn't make sense to me (yet - but > I'm willing to learn why). That footnote is about `narrow-to-region', not about "any command". But, well, I'm thinking that perhaps the mark deactivation I'm requesting should be specific to interactive calls. After all, what I want to avoid is just the annoyance of having to type `C-g' to deactivate the mark after realizing that Emacs didn't do it for me. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2013-01-25 19:07 ` Dani Moncayo @ 2013-01-25 19:34 ` Drew Adams 0 siblings, 0 replies; 30+ messages in thread From: Drew Adams @ 2013-01-25 19:34 UTC (permalink / raw) To: 'Dani Moncayo'; +Cc: 10056 > Well, the reason is the same for all commands I've mentioned: In my > experience (or my usage pattern), after defining an active region and > invoking a command to operate on it, it's much more likely that the > next commands have nothing to do with that active region. IOW, I > almost always set up an active region to do a single operation on it, > not several ones. So keeping the region active is, at best, counter > intuitive and visually annoying to me. I agree, and I think that's the general rule, i.e., the behavior by default. I think the command loop automatically does that, unless a given command explicitly inhibits it. And I have no objection to that general default behavior. I would object, though, if we were to somehow stop an individual command from inhibiting deactivation. Wrt `eval-region', I have no objection to deactivation. But I wonder why that does not happen automatically. I don't have the C code available, but presumably it explicitly inhibits deactivation (?). If so, I wonder what the designers had in mind, IOW, why that inhibition in this case? Maybe you can do some archaeology to find out the history? > > Wrt your footnote [2]: Why should we deactivate the region > > for _any_ command when it is called non-interactively? > > That doesn't make sense to me (yet - but I'm willing to learn why). > > That footnote is about `narrow-to-region', not about "any command". Yes, I understood that it is about `narrow-to-region'. I wondered why Yidong would bother to say that specifically about `narrow-to-region', since it should be true of _all_ commands, AFAIK. Unless a particular command is somehow a special case (are there any such?), we should not automatically deactivate the region for _any_ command when it is called non-interactively. If Lisp code that calls a command wants to deactivate the mark it can do that. _Automatic_ deactivation should be only for interactive invocation, IMO. > But, well, I'm thinking that perhaps the mark deactivation I'm > requesting should be specific to interactive calls. Yes. And I think that is the case wrt automatic deactivation. > After all, what I want to avoid is just the annoyance of having > to type `C-g' to deactivate the mark after realizing that Emacs > didn't do it for me. Yes, and that too should already be the case in general: automatic deactivation for any command that does not, itself, explicitly inhibit deactivation. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; Mark deactivation 2013-01-25 12:34 ` Dani Moncayo 2013-01-25 17:41 ` Drew Adams @ 2013-01-25 19:01 ` Stefan Monnier 1 sibling, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2013-01-25 19:01 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056 I agree with the idea that those commands should be thought of as "consuming" the region, so they should deactivate the mark even if the buffer is not modified. > [2] According to Chong, in this case perhaps the mark deactivation > should be made only when the call is interactive. Right, obviously when called non-interactively, they should take BEG..END arguments, and these are not necessarily related to the region, so they should deactivate the mark if they indeed used it to figure out the BEG..END, i.e. when called interactively. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark 2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo ` (3 preceding siblings ...) 2012-12-05 8:04 ` bug#10056: 24.0.91; Mark deactivation Dani Moncayo @ 2022-04-26 13:50 ` Lars Ingebrigtsen 4 siblings, 0 replies; 30+ messages in thread From: Lars Ingebrigtsen @ 2022-04-26 13:50 UTC (permalink / raw) To: Dani Moncayo; +Cc: 10056 Dani Moncayo <dmoncayo@gmail.com> writes: > According to (info "(emacs)Text Registers"), the mark should be > deactivated at the end of the command `copy-to-register' (which is > TRT; `C-w' behaves that way, for example). > > But I see that: > * The mark (region) remains active after doing "C-x h C-x r s s" (from > emacs -Q). > * The command's docstring does not mention anything about this. It should, no? (I'm going through old bug reports that unfortunately weren't resolved at the time.) Chong fixed this at the time, but the discussion then went on to whether other commands, like `eval-region' should do the same. The rough consensus seemed to be "nope", and I think that's the right decision, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-04-26 13:50 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-15 20:06 bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Dani Moncayo 2011-11-15 20:15 ` Dani Moncayo 2011-11-15 20:36 ` Dani Moncayo 2011-11-15 20:18 ` Dani Moncayo 2011-11-21 6:30 ` Chong Yidong 2012-06-05 7:44 ` Dani Moncayo 2012-07-28 19:01 ` Dani Moncayo 2012-07-29 4:45 ` Chong Yidong 2012-07-29 9:46 ` Dani Moncayo 2012-07-29 4:50 ` Chong Yidong 2012-07-29 10:01 ` Dani Moncayo 2012-08-01 21:17 ` Alan Mackenzie 2012-08-01 22:07 ` Dani Moncayo 2012-08-03 21:47 ` Alan Mackenzie 2012-09-08 20:21 ` Stefan Monnier 2012-09-09 20:20 ` Dani Moncayo 2012-09-11 14:42 ` Bastien 2012-12-05 8:04 ` bug#10056: 24.0.91; Mark deactivation Dani Moncayo 2012-12-08 10:09 ` Dani Moncayo 2012-12-08 23:03 ` Juri Linkov 2012-12-09 0:00 ` Drew Adams 2012-12-09 0:29 ` Juri Linkov 2012-12-09 3:21 ` Drew Adams 2012-12-09 9:07 ` Dani Moncayo 2013-01-25 12:34 ` Dani Moncayo 2013-01-25 17:41 ` Drew Adams 2013-01-25 19:07 ` Dani Moncayo 2013-01-25 19:34 ` Drew Adams 2013-01-25 19:01 ` Stefan Monnier 2022-04-26 13:50 ` bug#10056: 24.0.91; `copy-to-register' does not deactivate the mark Lars Ingebrigtsen
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.