* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer [not found] ` <<83tuvt1qwq.fsf@gnu.org> @ 2020-09-19 20:22 ` Drew Adams 2020-09-19 20:27 ` bug#9917: " Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Drew Adams @ 2020-09-19 20:22 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, dmoncayo, 9917, monnier, 5042 > > In any buffer, including Info, a user can > > want to go to a line counted from bob or from > > point-min (current narrowing/restriction). > > If that is the main use case for this issue, we could > have a different binding for "M-g g" in Info mode. It's not about Info mode, or any particular mode. It's not about whether the buffer happens to be narrowed. It's about what the users wants in the current context. My point is that a user can want _either_ behavior, and there's no way to know which behavior is wanted at any given moment, in any given buffer, whether narrowed or not. IMO, we need either two different commands (& keys) or a command with different prefix-arg behaviors. We need _some_ way for a user to be able to get either behavior, regardless of what a "default" behavior might be. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-19 20:22 ` bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer Drew Adams @ 2020-09-19 20:27 ` Eli Zaretskii 0 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2020-09-19 20:27 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, dmoncayo, 9917, monnier, 5042 > Date: Sat, 19 Sep 2020 13:22:41 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: monnier@iro.umontreal.ca, larsi@gnus.org, dmoncayo@gmail.com, > 9917@debbugs.gnu.org, 5042@debbugs.gnu.org > > My point is that a user can want _either_ behavior, > and there's no way to know which behavior is wanted > at any given moment, in any given buffer, whether > narrowed or not. > > IMO, we need either two different commands (& keys) > or a command with different prefix-arg behaviors. I suggested the former up-thread (and thought that your response meant you are unhappy about that for some reason). Different prefix-arg behaviors would be tricky in this case, I think, because goto-line accepts a numeric argument already. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <<83zh5l1uqw.fsf@gnu.org>]
[parent not found: <<87wo0osspd.fsf@gnus.org>]
[parent not found: <<87lfh3dtoj.fsf@mail.linkov.net>]
[parent not found: <<878sd1j2rv.fsf@gnus.org>]
[parent not found: <<871ritbs6t.fsf@mail.linkov.net>]
[parent not found: <<cd8f2969-6705-46c8-b090-03e284b0ba0c@default>]
[parent not found: <<83zh5gvauy.fsf@gnu.org>]
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer [not found] ` <<83zh5gvauy.fsf@gnu.org> @ 2020-09-23 18:09 ` Drew Adams 2020-09-23 19:40 ` Juri Linkov 0 siblings, 1 reply; 39+ messages in thread From: Drew Adams @ 2020-09-23 18:09 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: 5042, juri, 9917, monnier, dmoncayo, larsi > > > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'. > > > > I gave my opinion about this. And it was a reason given > > for having two different commands: Do not base which > > command gets the standard key binding on anything to do > > with the current context - in particular, on whether the > > buffer is narrowed. > > > > Please do _not_ bind `M-g M-g' to anything different in Info. > > Why not? We do this kind of thing -- have mode-specific bindings -- > all the time in Emacs. Because we will now have two commands, with two bindings, to let users get the behavior they want - in any mode, any context. Changing the binding of one of those 2 commands to invoke the other command, makes no sense. It takes away a possibility (one command gets two bindings; the other gets zero bindings). And it confuses users. > > Emacs should not be second-guessing users about this. > > It's not second-guessing. Info shows narrowed line numbers in its > buffers, so from the user POV the key sequence keeps invoking the same > command. Info uses narrowing to show a node. Users can further use narrowing within a node. Users can widen, to see all of a file. That Info uses narrowing for this special purpose might be seen as a kludge. In any case, it's a different use of narrowing from a user's. From a user POV the key sequence `M-g M-g' does NOT keep invoking the same command. If it invoked the same command then it would still move to an absolute position. From a user POV, the user has _lost_ a key binding for one of the commands, and the other command now has two bindings. > I see no problem and don't see why you object so much. So much? I just presented my objection; that's all. I see no reason for this. I see reasons against it, both wrt the particular case (Info) and in terms of setting a bad precedent. I don't object "so much". I do think it would be a mistake. And it's not necessary. At the very least, if you insist on this "so much", then please consider swapping the two command bindings in Info mode, and advertising this (anomalous swap). ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-23 18:09 ` bug#5042: " Drew Adams @ 2020-09-23 19:40 ` Juri Linkov 0 siblings, 0 replies; 39+ messages in thread From: Juri Linkov @ 2020-09-23 19:40 UTC (permalink / raw) To: Drew Adams; +Cc: 5042, 9917, monnier, dmoncayo, larsi > That Info uses narrowing for this special purpose might be seen as > a kludge. Indeed, Info narrowing is an implementation detail irrelevant for most users. And BTW Info-mode is the only mode that sets widen-automatically to nil. Now I pushed this change to the trunk because two maintainers confirmed that this is the right thing to do. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer @ 2011-10-31 14:31 Dani Moncayo 2011-11-01 9:35 ` Juri Linkov 2020-09-19 17:42 ` bug#5042: " Lars Ingebrigtsen 0 siblings, 2 replies; 39+ messages in thread From: Dani Moncayo @ 2011-10-31 14:31 UTC (permalink / raw) To: 9917 Hi, When you are in a narrowed buffer (e.g. an Info buffer), the line number that you see in the mode-line is relative to the narrowed portion, whereas the `goto-line' (M-g g) command requires you to supply an absolute line number. This discrepancy is quite confusing for users, so my proposal is obvious: adjust the behaviour of `goto-line' to make it consistent with the line number showed in the minibuffer, i.e, to consider its LINE argument relative to the narrowed part if there's one, or else to the whole buffer. In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601) of 2011-10-27 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] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-10-31 14:31 Dani Moncayo @ 2011-11-01 9:35 ` Juri Linkov 2011-11-01 17:56 ` Stefan Monnier 2020-09-19 17:42 ` bug#5042: " Lars Ingebrigtsen 1 sibling, 1 reply; 39+ messages in thread From: Juri Linkov @ 2011-11-01 9:35 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9917 > When you are in a narrowed buffer (e.g. an Info buffer), the line > number that you see in the mode-line is relative to the narrowed > portion, whereas the `goto-line' (M-g g) command requires you to > supply an absolute line number. > > This discrepancy is quite confusing for users, so my proposal is > obvious: adjust the behaviour of `goto-line' to make it consistent > with the line number showed in the minibuffer, i.e, to consider its > LINE argument relative to the narrowed part if there's one, or else to > the whole buffer. Just removing `(widen)' from `goto-line' will fix this. But the question is why it's here. What was the intention of adding `(widen)' here. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-11-01 9:35 ` Juri Linkov @ 2011-11-01 17:56 ` Stefan Monnier 2011-11-01 22:35 ` Juri Linkov 2011-11-02 9:46 ` Juri Linkov 0 siblings, 2 replies; 39+ messages in thread From: Stefan Monnier @ 2011-11-01 17:56 UTC (permalink / raw) To: Juri Linkov; +Cc: 9917 > Just removing `(widen)' from `goto-line' will fix this. But the question is > why it's here. What was the intention of adding `(widen)' here. Because depending on the use of narrow-to-region, you'll want widen or not. Some code was written with some particular uses in mind, while other code was written with other uses in mind, hence the inconsistencies. The difference is whether narrow-to-region really wants to pretend the text outside the region doesn't exist at all (e.g. in Rmail or Info), or whether it is just meant to temporarily only display a subpart (e.g. most other cases). Then things get interesting when the user uses narrow-to-region in Info or Rmail. Currently the only data we have to distinguish the two cases is font-lock-dont-widen, but clearly it's not sufficient to handle the "user narrowing in Info" case. Stefan ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-11-01 17:56 ` Stefan Monnier @ 2011-11-01 22:35 ` Juri Linkov 2011-11-01 23:22 ` Drew Adams 2011-11-02 9:46 ` Juri Linkov 1 sibling, 1 reply; 39+ messages in thread From: Juri Linkov @ 2011-11-01 22:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9917 > Because depending on the use of narrow-to-region, you'll want widen > or not. Some code was written with some particular uses in mind, while > other code was written with other uses in mind, hence > the inconsistencies. Yes, I can confirm this: when someone says "see the line 42 in window.c" then `goto-line' should visit by the absolute line number, ignoring any narrowing in effect. But when someone says "see the line 42 in the Info node" then it should be relative to the node's beginning. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-11-01 22:35 ` Juri Linkov @ 2011-11-01 23:22 ` Drew Adams 2011-11-02 9:48 ` Juri Linkov 0 siblings, 1 reply; 39+ messages in thread From: Drew Adams @ 2011-11-01 23:22 UTC (permalink / raw) To: 'Juri Linkov', 'Stefan Monnier'; +Cc: 9917 > when someone says "see the line 42 in window.c" > then `goto-line' should visit by the absolute line number, > ignoring any narrowing in effect. But when someone says > "see the line 42 in the Info node" then it should be relative > to the node's beginning. For `goto-line': Let a negative prefix arg use line numbering wrt the restriction (region), and let a positive prefix arg use line numbering wrt the buffer (widened). Likewise for a number read at the prompt: negative for restriction numbering, positive for full-buffer numbering. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-11-01 23:22 ` Drew Adams @ 2011-11-02 9:48 ` Juri Linkov 2011-11-02 12:59 ` Drew Adams 0 siblings, 1 reply; 39+ messages in thread From: Juri Linkov @ 2011-11-02 9:48 UTC (permalink / raw) To: Drew Adams; +Cc: 9917 > For `goto-line': > > Let a negative prefix arg use line numbering wrt the restriction (region), and > let a positive prefix arg use line numbering wrt the buffer (widened). > > Likewise for a number read at the prompt: negative for restriction numbering, > positive for full-buffer numbering. A negative line number usually means counting from the end of the buffer. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-11-02 9:48 ` Juri Linkov @ 2011-11-02 12:59 ` Drew Adams 0 siblings, 0 replies; 39+ messages in thread From: Drew Adams @ 2011-11-02 12:59 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 9917 > > For `goto-line': > > > > Let a negative prefix arg use line numbering wrt the > > restriction (region), and let a positive prefix arg use > > line numbering wrt the buffer (widened). > > > > Likewise for a number read at the prompt: negative for > > restriction numbering, positive for full-buffer numbering. > > A negative line number usually means counting from the end of > the buffer. Dunno what "usually" means here. It certainly does not mean that for `goto-line'. Currently, using a negative prefix arg seems to just move to line 1. We can define what a negative arg means for `goto-line' to be anything we want. Consistency is all well and good, especially when there are other, supporting, good reasons to keep it up. But it sometimes happens that "usually" gets "established" more or less by accident/default, no better alternative having occurred to the designer at the time. Other suggestions welcome. I think it would be good to be able to quickly say whether you want numbering relative to the restriction or the whole buffer. Of course another possibility is to simply have a separate command for that. The only reason to use the same command and, say, a prefix arg, would be to save keys (and user memory). A separate `goto-line-in-restriction' is a reasonable solution, IMO. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-11-01 17:56 ` Stefan Monnier 2011-11-01 22:35 ` Juri Linkov @ 2011-11-02 9:46 ` Juri Linkov 1 sibling, 0 replies; 39+ messages in thread From: Juri Linkov @ 2011-11-02 9:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9917 > The difference is whether narrow-to-region really wants to pretend the > text outside the region doesn't exist at all (e.g. in Rmail or Info), or > whether it is just meant to temporarily only display a subpart > (e.g. most other cases). While fixing `Info-revert-find-node' for bug#9915, I noticed the following comment in `Info-revert-find-node': ;; note goto-line is no good, we want to measure from point-min (goto-char (point-min)) (forward-line wline) This means that `goto-line' should be fixed even for non-interactive use in Info. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2011-10-31 14:31 Dani Moncayo 2011-11-01 9:35 ` Juri Linkov @ 2020-09-19 17:42 ` Lars Ingebrigtsen 2020-09-19 18:01 ` Stefan Monnier 2020-09-19 18:33 ` Eli Zaretskii 1 sibling, 2 replies; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-09-19 17:42 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9917, Stefan Monnier, 5042 Dani Moncayo <dmoncayo@gmail.com> writes: > This discrepancy is quite confusing for users, so my proposal is > obvious: adjust the behaviour of `goto-line' to make it consistent > with the line number showed in the minibuffer, i.e, to consider its > LINE argument relative to the narrowed part if there's one, or else to > the whole buffer. The suggestion here is to make the interactive `goto-line' go to the narrowed-to line instead of the absolute line. I can see the reasoning here -- especially after `display-line-numbers-mode' was added, displaying line numbers seems to be getting more popular, and having `M-x goto-char' not going to the number you're seeing (if the buffer is narrowed) sounds confusing. But it is a breaking change -- somewhat. `goto-line' isn't supposed to be used in code, and isn't used in-tree, but who knows what people have done out there... We could bind `M-g g' (and friends) to a new command that acts this new way? Anybody got any opinions here? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-19 17:42 ` bug#5042: " Lars Ingebrigtsen @ 2020-09-19 18:01 ` Stefan Monnier 2020-09-19 19:27 ` bug#9917: bug#5042: " Drew Adams 2020-09-19 18:33 ` Eli Zaretskii 1 sibling, 1 reply; 39+ messages in thread From: Stefan Monnier @ 2020-09-19 18:01 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Dani Moncayo, 9917, 5042 > The suggestion here is to make the interactive `goto-line' go to the > narrowed-to line instead of the absolute line. I can see the reasoning > here -- especially after `display-line-numbers-mode' was added, > displaying line numbers seems to be getting more popular, and having > `M-x goto-char' not going to the number you're seeing (if the buffer is > narrowed) sounds confusing. I agree that the same should be used for `M-g g` and for the numbers displayed in `display-line-numbers-mode' or in the mode-line. I think all those need some common way to decide if the first line is at `point-min` or somewhere else. > But it is a breaking change -- somewhat. `goto-line' isn't supposed to > be used in code, and isn't used in-tree, but who knows what people have > done out there... Agree. We used to have calls to `goto-line` in our code, so there's probably more in the wild. > We could bind `M-g g' (and friends) to a new command that acts this > new way? Fine by me, Stefan ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-19 18:01 ` Stefan Monnier @ 2020-09-19 19:27 ` Drew Adams 2020-09-19 19:56 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Drew Adams @ 2020-09-19 19:27 UTC (permalink / raw) To: Stefan Monnier, Lars Ingebrigtsen; +Cc: Dani Moncayo, 9917, 5042 In any buffer, including Info, a user can want to go to a line counted from bob or from point-min (current narrowing/restriction). (Stefan mentioned the use case of an Info node that's further narrowed. There's also the case of an Info buffer that a user has widened intentionally.) There's no good way to read a user's mind about this. We can have a reasonable _default_ behavior, and provide the other behavior as an alternative. We can do that using a prefix arg (I suggested a negative one). Or we can do it by providing two separate commands. Or in some other way. And we could decide to have the default behavior depend on something (type of buffer or whatever). But this might not be the best approach. (I think it's probably not.) In any case, we should give users a way to choose what they want, whatever the buffer. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-19 19:27 ` bug#9917: bug#5042: " Drew Adams @ 2020-09-19 19:56 ` Eli Zaretskii 0 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2020-09-19 19:56 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, dmoncayo, 9917, monnier, 5042 > Date: Sat, 19 Sep 2020 12:27:13 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: Dani Moncayo <dmoncayo@gmail.com>, 9917@debbugs.gnu.org, > 5042@debbugs.gnu.org > > In any buffer, including Info, a user can > want to go to a line counted from bob or from > point-min (current narrowing/restriction). If that is the main use case for this issue, we could have a different binding for "M-g g" in Info mode. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-19 17:42 ` bug#5042: " Lars Ingebrigtsen 2020-09-19 18:01 ` Stefan Monnier @ 2020-09-19 18:33 ` Eli Zaretskii 2020-09-20 9:28 ` Lars Ingebrigtsen 1 sibling, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2020-09-19 18:33 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: dmoncayo, 9917, monnier, 5042 > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Sat, 19 Sep 2020 19:42:04 +0200 > Cc: 9917@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, > 5042@debbugs.gnu.org > > Dani Moncayo <dmoncayo@gmail.com> writes: > > > This discrepancy is quite confusing for users, so my proposal is > > obvious: adjust the behaviour of `goto-line' to make it consistent > > with the line number showed in the minibuffer, i.e, to consider its > > LINE argument relative to the narrowed part if there's one, or else to > > the whole buffer. > > The suggestion here is to make the interactive `goto-line' go to the > narrowed-to line instead of the absolute line. I can see the reasoning > here -- especially after `display-line-numbers-mode' was added, > displaying line numbers seems to be getting more popular, and having > `M-x goto-char' not going to the number you're seeing (if the buffer is > narrowed) sounds confusing. > > But it is a breaking change -- somewhat. `goto-line' isn't supposed to > be used in code, and isn't used in-tree, but who knows what people have > done out there... The alternative POV, whereby line numbers are absolute disregarding the narrowing, is also valid. What's more important, it was there first. So I think it has to be a different command. If someone wants to rebind "M-g g" to that new command, they can always do that. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-19 18:33 ` Eli Zaretskii @ 2020-09-20 9:28 ` Lars Ingebrigtsen 2020-09-21 19:03 ` Juri Linkov 0 siblings, 1 reply; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-09-20 9:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dmoncayo, 9917, monnier, 5042 Eli Zaretskii <eliz@gnu.org> writes: > So I think it has to be a different command. If someone wants to > rebind "M-g g" to that new command, they can always do that. I'm sympathetic to the idea of not disrupting anybody's workflow. However if the keystroke isn't useful as it is today, then changing how it works (so that it's useful) is an option. So: Is `M-g g' (in a narrowed buffer) useful today? `M-g g 2' will almost inevitably take you to the start of the buffer, so that's not useful, and I think is what people are complaining about, because it just seems to... unhelpful. However, if people have a narrowed buffer, and are looking at (say) the compilation output that says "error on like 45" in a shell, then `M-g g 45' will definitely do the wrong thing is we change the command to start counting from the start of the narrowed region. So a new command and keystroke seems warranted. How about... `M-g M-v'? (The mnemonic is "goto visual line".) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-20 9:28 ` Lars Ingebrigtsen @ 2020-09-21 19:03 ` Juri Linkov 2020-09-22 14:37 ` Lars Ingebrigtsen 2020-10-27 20:52 ` Juri Linkov 0 siblings, 2 replies; 39+ messages in thread From: Juri Linkov @ 2020-09-21 19:03 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: dmoncayo, 9917, monnier, 5042 > However, if people have a narrowed buffer, and are looking at (say) the > compilation output that says "error on like 45" in a shell, then `M-g g > 45' will definitely do the wrong thing is we change the command to start > counting from the start of the narrowed region. In this case another option is to widen the buffer before going to that line. This is what for example help-function-def--button-function does: ;; Widen the buffer if necessary to go to this position. (when (or (< position (point-min)) (> position (point-max))) (widen)) (goto-char position) Unfortunately, xref doesn't provide such nice feature, so 'M-.' fails to navigate in a narrowed buffer. For 'M-g M-g' this means removing 'save-restriction' from 'goto-line'. > So a new command and keystroke seems warranted. How about... > `M-g M-v'? (The mnemonic is "goto visual line".) Or to add a new key to narrow-map 'C-x n' that currently contains only 4 keys: C-x n d narrow-to-defun C-x n n narrow-to-region C-x n p narrow-to-page C-x n w widen where a new key could be: C-x n g go to narrowed line ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-21 19:03 ` Juri Linkov @ 2020-09-22 14:37 ` Lars Ingebrigtsen 2020-09-22 18:08 ` Juri Linkov 2020-10-29 9:19 ` Juri Linkov 2020-10-27 20:52 ` Juri Linkov 1 sibling, 2 replies; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-09-22 14:37 UTC (permalink / raw) To: Juri Linkov; +Cc: dmoncayo, 9917, monnier, 5042 Juri Linkov <juri@linkov.net> writes: >> So a new command and keystroke seems warranted. How about... >> `M-g M-v'? (The mnemonic is "goto visual line".) > > Or to add a new key to narrow-map 'C-x n' that currently > contains only 4 keys: > > C-x n d narrow-to-defun > C-x n n narrow-to-region > C-x n p narrow-to-page > C-x n w widen > > where a new key could be: > > C-x n g go to narrowed line Perhaps both? The keystroke makes sense in both contexts -- as a variation on `M-g M-g', and in the group of narrowing keystroke. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-22 14:37 ` Lars Ingebrigtsen @ 2020-09-22 18:08 ` Juri Linkov 2020-09-22 20:10 ` Drew Adams 2020-09-23 13:18 ` Lars Ingebrigtsen 2020-10-29 9:19 ` Juri Linkov 1 sibling, 2 replies; 39+ messages in thread From: Juri Linkov @ 2020-09-22 18:08 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: dmoncayo, 9917, monnier, 5042 [-- Attachment #1: Type: text/plain, Size: 933 bytes --] >>> So a new command and keystroke seems warranted. How about... >>> `M-g M-v'? (The mnemonic is "goto visual line".) >> >> C-x n g go to narrowed line > > Perhaps both? The keystroke makes sense in both contexts -- as a > variation on `M-g M-g', and in the group of narrowing keystroke. Yep, having both is a win-win situation. Here is the patch that: 1. leaves the existing 'goto-line' completely backward-compatible (actually a small difference is that in a narrowed buffer it displays now the prompt "Goto absolute line:" instead of just "Goto line:") 2. adds two optional args RELATIVE and WIDEN to 'goto-line'; 3. adds two new commands 'goto-line-absolute' and 'goto-line-relative': 3.1. 'goto-line-absolute' widens the buffer and doesn't narrow it back; 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'. If this is ok, then 'goto-line-relative' could be bound to `M-g M-v' and `C-x n g'. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: goto-line-relative.patch --] [-- Type: text/x-diff, Size: 5295 bytes --] diff --git a/lisp/info.el b/lisp/info.el index e4f75b481f..20633fd059 100644 --- a/lisp/info.el +++ b/lisp/info.el @@ -4053,6 +4053,7 @@ Info-mode-map (define-key map "^" 'Info-up) (define-key map "," 'Info-index-next) (define-key map "\177" 'Info-scroll-down) + (define-key map [remap goto-line] 'goto-line-relative) (define-key map [mouse-2] 'Info-mouse-follow-nearest-node) (define-key map [follow-link] 'mouse-face) (define-key map [XF86Back] 'Info-history-back) diff --git a/lisp/simple.el b/lisp/simple.el index 050c81a410..724d2d96aa 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -1231,7 +1231,38 @@ goto-line-history "History of values entered with `goto-line'.") (make-variable-buffer-local 'goto-line-history) -(defun goto-line (line &optional buffer) +(defun goto-line-read-args (&optional relative) + "Read arguments for `goto-line' related commands." + (if (and current-prefix-arg (not (consp current-prefix-arg))) + (list (prefix-numeric-value current-prefix-arg)) + ;; Look for a default, a number in the buffer at point. + (let* ((default + (save-excursion + (skip-chars-backward "0-9") + (if (looking-at "[0-9]") + (string-to-number + (buffer-substring-no-properties + (point) + (progn (skip-chars-forward "0-9") + (point))))))) + ;; Decide if we're switching buffers. + (buffer + (if (consp current-prefix-arg) + (other-buffer (current-buffer) t))) + (buffer-prompt + (if buffer + (concat " in " (buffer-name buffer)) + ""))) + ;; Read the argument, offering that number (if any) as default. + (list (read-number (format "Goto%s line%s: " + (if (= (point-min) 1) "" + (if relative " relative" " absolute")) + buffer-prompt) + (list default (line-number-at-pos)) + 'goto-line-history) + buffer)))) + +(defun goto-line (line &optional buffer relative widen) "Go to LINE, counting from line 1 at beginning of buffer. If called interactively, a numeric prefix argument specifies LINE; without a numeric prefix argument, read LINE from the @@ -1241,6 +1272,12 @@ goto-line move to line LINE there. If called interactively with \\[universal-argument] as argument, BUFFER is the most recently selected other buffer. +If optional argument RELATIVE is non-nil, counting is relative +from the beginning of the narrowed buffer. + +If optional argument WIDEN is non-nil, cancel narrowing +and leave all lines accessible. + Prior to moving point, this function sets the mark (without activating it), unless Transient Mark mode is enabled and the mark is already active. @@ -1252,32 +1289,7 @@ goto-line If at all possible, an even better solution is to use char counts rather than line counts." (declare (interactive-only forward-line)) - (interactive - (if (and current-prefix-arg (not (consp current-prefix-arg))) - (list (prefix-numeric-value current-prefix-arg)) - ;; Look for a default, a number in the buffer at point. - (let* ((default - (save-excursion - (skip-chars-backward "0-9") - (if (looking-at "[0-9]") - (string-to-number - (buffer-substring-no-properties - (point) - (progn (skip-chars-forward "0-9") - (point))))))) - ;; Decide if we're switching buffers. - (buffer - (if (consp current-prefix-arg) - (other-buffer (current-buffer) t))) - (buffer-prompt - (if buffer - (concat " in " (buffer-name buffer)) - ""))) - ;; Read the argument, offering that number (if any) as default. - (list (read-number (format "Goto line%s: " buffer-prompt) - (list default (line-number-at-pos)) - 'goto-line-history) - buffer)))) + (interactive (goto-line-read-args)) ;; Switch to the desired buffer, one way or another. (if buffer (let ((window (get-buffer-window buffer))) @@ -1286,12 +1298,28 @@ goto-line ;; Leave mark at previous position (or (region-active-p) (push-mark)) ;; Move to the specified line number in that buffer. - (save-restriction - (widen) - (goto-char (point-min)) - (if (eq selective-display t) - (re-search-forward "[\n\C-m]" nil 'end (1- line)) - (forward-line (1- line))))) + (if (and (not relative) (not widen)) + ;; Useless case because it just moves point to the edge of visible portion. + (save-restriction + (widen) + (goto-char (point-min)) + (if (eq selective-display t) + (re-search-forward "[\n\C-m]" nil 'end (1- line)) + (forward-line (1- line)))) + (progn + (unless relative (widen)) + (goto-char (point-min)) + (if (eq selective-display t) + (re-search-forward "[\n\C-m]" nil 'end (1- line)) + (forward-line (1- line)))))) + +(defun goto-line-absolute (line &optional buffer) + (interactive (goto-line-read-args)) + (goto-line line buffer nil t)) + +(defun goto-line-relative (line &optional buffer) + (interactive (goto-line-read-args t)) + (goto-line line buffer t t)) (defun count-words-region (start end &optional arg) "Count the number of words in the region. ^ permalink raw reply related [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-22 18:08 ` Juri Linkov @ 2020-09-22 20:10 ` Drew Adams 2020-09-23 14:14 ` bug#5042: bug#9917: " Eli Zaretskii 2020-09-23 13:18 ` Lars Ingebrigtsen 1 sibling, 1 reply; 39+ messages in thread From: Drew Adams @ 2020-09-22 20:10 UTC (permalink / raw) To: Juri Linkov, Lars Ingebrigtsen; +Cc: dmoncayo, 9917, monnier, 5042 > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'. I gave my opinion about this. And it was a reason given for having two different commands: Do not base which command gets the standard key binding on anything to do with the current context - in particular, on whether the buffer is narrowed. Please do _not_ bind `M-g M-g' to anything different in Info. Emacs should not be second-guessing users about this. The point of having two commands (and two key bindings) is to let users get the behavior they want, in any context. Please do not have the same key bound to different behaviors for going to a line. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-22 20:10 ` Drew Adams @ 2020-09-23 14:14 ` Eli Zaretskii 0 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2020-09-23 14:14 UTC (permalink / raw) To: Drew Adams; +Cc: 5042, juri, 9917, monnier, dmoncayo, larsi > Date: Tue, 22 Sep 2020 13:10:09 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: dmoncayo@gmail.com, 9917@debbugs.gnu.org, monnier@iro.umontreal.ca, > 5042@debbugs.gnu.org > > > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'. > > I gave my opinion about this. And it was a reason given > for having two different commands: Do not base which > command gets the standard key binding on anything to do > with the current context - in particular, on whether the > buffer is narrowed. > > Please do _not_ bind `M-g M-g' to anything different in Info. Why not? We do this kind of thing -- have mode-specific bindings -- all the time in Emacs. > Emacs should not be second-guessing users about this. It's not second-guessing. Info shows narrowed line numbers in its buffers, so from the user POV the key sequence keeps invoking the same command. I see no problem and don't see why you object so much. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-22 18:08 ` Juri Linkov 2020-09-22 20:10 ` Drew Adams @ 2020-09-23 13:18 ` Lars Ingebrigtsen 2020-09-23 17:58 ` Drew Adams 1 sibling, 1 reply; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-09-23 13:18 UTC (permalink / raw) To: Juri Linkov; +Cc: dmoncayo, 9917, monnier, 5042 Juri Linkov <juri@linkov.net> writes: > 1. leaves the existing 'goto-line' completely backward-compatible > (actually a small difference is that in a narrowed buffer it displays > now the prompt "Goto absolute line:" instead of just "Goto line:") > 2. adds two optional args RELATIVE and WIDEN to 'goto-line'; > 3. adds two new commands 'goto-line-absolute' and 'goto-line-relative': > 3.1. 'goto-line-absolute' widens the buffer and doesn't narrow it back; > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'. > > If this is ok, then 'goto-line-relative' could be bound to > `M-g M-v' and `C-x n g'. Sounds good to me. Drew objected to rebinding the keystroke in Info mode, but I think that's probably fine -- nobody is ever going to refer to an absolute line in Info. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-23 13:18 ` Lars Ingebrigtsen @ 2020-09-23 17:58 ` Drew Adams 2020-09-24 7:39 ` Robert Pluim 0 siblings, 1 reply; 39+ messages in thread From: Drew Adams @ 2020-09-23 17:58 UTC (permalink / raw) To: Lars Ingebrigtsen, Juri Linkov; +Cc: dmoncayo, 9917, monnier, 5042 > Drew objected to rebinding the keystroke in Info > mode, but I think that's probably fine -- nobody is ever going to refer > to an absolute line in Info. Why do you think so? The principle is general. Logically, this has nothing to do with the mode or context, except if the user thinks it does. No such coupling should be done automatically (hard-coded). Just give users two commands/keys and let them use whichever they feel is appropriate in any given mode/context. You're setting a bad precedent by overruling users here. `M-g M-g' should do the same thing, wherever. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-23 17:58 ` Drew Adams @ 2020-09-24 7:39 ` Robert Pluim 2020-09-24 17:31 ` bug#9917: " Drew Adams 0 siblings, 1 reply; 39+ messages in thread From: Robert Pluim @ 2020-09-24 7:39 UTC (permalink / raw) To: Drew Adams; +Cc: 5042, Juri Linkov, 9917, monnier, dmoncayo, Lars Ingebrigtsen >>>>> On Wed, 23 Sep 2020 10:58:11 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said: >> Drew objected to rebinding the keystroke in Info >> mode, but I think that's probably fine -- nobody is ever going to refer >> to an absolute line in Info. Drew> Why do you think so? Drew> The principle is general. Logically, this has Drew> nothing to do with the mode or context, except if Drew> the user thinks it does. No such coupling should Drew> be done automatically (hard-coded). Just give users Drew> two commands/keys and let them use whichever they Drew> feel is appropriate in any given mode/context. Drew> You're setting a bad precedent by overruling users Drew> here. `M-g M-g' should do the same thing, wherever. If I turn on display-line-numbers-mode in an *info* buffer, or have the line number displayed in the mode line, those numbers are the narrowed line numbers. Having M-g M-g go to the absolute line number there would be very confusing as they donʼt match the visual information provided (how many people even know that *info* buffers are narrowed? They behave like a linked set of buffers). Robert ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-24 7:39 ` Robert Pluim @ 2020-09-24 17:31 ` Drew Adams 0 siblings, 0 replies; 39+ messages in thread From: Drew Adams @ 2020-09-24 17:31 UTC (permalink / raw) To: Robert Pluim Cc: 5042, Juri Linkov, 9917, monnier, dmoncayo, Lars Ingebrigtsen > >> Drew objected to rebinding the keystroke in Info > >> mode, but I think that's probably fine -- nobody is > >> ever going to refer to an absolute line in Info. > > Drew> Why do you think so? > > Drew> The principle is general. Logically, this has > Drew> nothing to do with the mode or context, except if > Drew> the user thinks it does. No such coupling should > Drew> be done automatically (hard-coded). Just give users > Drew> two commands/keys and let them use whichever they > Drew> feel is appropriate in any given mode/context. > > Drew> You're setting a bad precedent by overruling users > Drew> here. `M-g M-g' should do the same thing, wherever. > > If I turn on display-line-numbers-mode in an *info* buffer, or have the > line number displayed in the mode line, those numbers are the narrowed > line numbers. Having M-g M-g go to the absolute line number there > would be very confusing as they donʼt match the visual information > provided (how many people even know that *info* buffers are narrowed? > They behave like a linked set of buffers). Either Info should be made to NOT use narrowing to simulate what you describe as "a linked set of buffers", or ordinary considerations of narrowing apply. How do you know that an Info buffer is narrowed? Same way as any other buffer: the mode line says "(Info Narrow)". Nothing new here. Someone decided that relative line numbering was appropriate as the default behavior for Info. That's not bad. And yes, if a user is _not aware_ that line numbering is relative, and that the buffer is narrowed, then s?he may mistakenly use `M-g M-g' to go to what s?he thinks is a normal, i.e., absolute line number. Info is between two chairs. It should instead be handled consistently (pick a chair) - either: 1. As an explicitly narrowed buffer, with relative line numbers - and a user would then use the (new) command and key for going to a relative line number. A user would get that the buffer is narrowed, and relative line numbers are appropriate. or 2. As an widened buffer (or with narrowing completely imperceptible by users), with absolute line numbers - and a user would then use good old `goto-line' and its key, `M-g M-g'. Currently, half the indications for users are that Info IS narrowed (by default), which it is, and half of them are that Info is NOT narrowed (which is incorrect). We now have two ways to show line numbers and two keys for going to a line number: relative and absolute. A user is free to show relative but goto absolute, or the opposite, or either of the two same-type combinations - 4 combinations altogether. A user who is used to `M-g M-g' being goto absolute will not expect it to sometimes instead become goto relative behind her back (invisibly). That a user might not know that Info is narrowed is a separate problem, which should maybe be addressed. The fact is that Info IS narrowed (by default). And Emacs tells you so, pretty clearly. If you're aware of that then you're not surprised that Emacs has chosen to show you relative line numbers (by default). But you _will_ be surprised to discover that `M-g M-g' has changed silently. And that there is no longer any key for `goto-line'. What's needed is some better alignment of things. Plus better informing of users of what the state is. As for the goto keys and their commands: they should be kept separate, and both available at all times. I mentioned the possibility of swapping the bindings in the Info setting. I'm not in favor of any such key changes, but certainly it's better to swap (if someone insists that `M-g M-g' needs to become relative), rather than to just give both keys to relative goto. Again, I don't feel strongly about any of this. I do, however, think we're making a mistake by doing what's being done. In particular because it sets a bad precedent. Someone may say that Info is a very special case, and there won't ever be another like it, and we have no plan to change how Info represents nodes (that is, we'll continue to just narrow - it's not a bad approach, even if it's a bit rudimentary), and so therefore it's OK to make this special exception. Will it continue to be regarded as a special case? Or will other modes where someone thinks that the default expectation will be going to relative line numbers also get `M-g M-g' hijacked for relative goto? I unfortunately have to bet on the latter. If we continue to narrow to Info nodes, and if we think that the mode-line indication isn't strong enough, here's a suggestion: My library zones.el has a Boolean option, `zz-narrowing-use-fringe-flag', to highlight the fringe when the buffer is narrowed. It's then pretty obvious when you narrow a buffer. But until a user has done that, and noticed the effect, s?he might not get it when just going to a buffer, like Info, that's already narrowed. Another possibility is to highlight `Narrow' in the mode line, at least for Info. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-22 14:37 ` Lars Ingebrigtsen 2020-09-22 18:08 ` Juri Linkov @ 2020-10-29 9:19 ` Juri Linkov 2020-10-29 14:31 ` Eli Zaretskii ` (2 more replies) 1 sibling, 3 replies; 39+ messages in thread From: Juri Linkov @ 2020-10-29 9:19 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 5042, 9917, monnier, dmoncayo >>> So a new command and keystroke seems warranted. How about... >>> `M-g M-v'? (The mnemonic is "goto visual line".) >> >> Or to add a new key to narrow-map 'C-x n' where a new key could be: >> >> C-x n g go to narrowed line > > Perhaps both? The keystroke makes sense in both contexts -- as a > variation on `M-g M-g', and in the group of narrowing keystroke. I've added a more localized key binding 'C-x n g', but still not sure about the global 'M-g' key bindings. Here are some possible variants: 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g' bound to goto-line that currently uses absolute line numbers (btw, this fact should be mentioned in its docstring); 2. Re-bind 'M-g g' to goto-line-relative as many asked to do with the reasoning that 'M-g g' should use by default the same numbering scheme as is displayed by display-line-numbers-mode; 3. Leave the existing 'M-g g' bound to goto-line, but allow changing the numbering scheme using a prefix arg and a user option. Or another idea: maybe it should depend on whether display-line-numbers-mode is enabled or not? When display-line-numbers-mode is enabled, then use relative line numbers that are displayed on the left side (WYSIWYG). ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-29 9:19 ` Juri Linkov @ 2020-10-29 14:31 ` Eli Zaretskii 2020-10-30 7:27 ` Juri Linkov 2020-10-29 16:44 ` bug#5042: " Drew Adams 2020-10-30 9:49 ` Lars Ingebrigtsen 2 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2020-10-29 14:31 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, 5042, 9917, monnier, dmoncayo > From: Juri Linkov <juri@linkov.net> > Cc: Eli Zaretskii <eliz@gnu.org>, 5042@debbugs.gnu.org, > 9917@debbugs.gnu.org, monnier@iro.umontreal.ca, dmoncayo@gmail.com > Date: Thu, 29 Oct 2020 11:19:11 +0200 > > 2. Re-bind 'M-g g' to goto-line-relative as many asked to do > with the reasoning that 'M-g g' should use by default the > same numbering scheme as is displayed by display-line-numbers-mode; Two comments: 1) display-line-numbers-mode by default behaves the same as line-number-mode 2) display-line-numbers-mode has the display-line-numbers-widen option which disregards narrowing, so if you want to follow display-line-numbers-mode, you will need to heed that option as well > 3. Leave the existing 'M-g g' bound to goto-line, but allow changing > the numbering scheme using a prefix arg and a user option. I like this the best. > Or another idea: maybe it should depend on whether > display-line-numbers-mode is enabled or not? That sounds wrong to me: there's no real relation between these two, and having the same command behave differently in two buffers doesn't sound right to me. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-29 14:31 ` Eli Zaretskii @ 2020-10-30 7:27 ` Juri Linkov 2020-10-30 8:19 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Juri Linkov @ 2020-10-30 7:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, 5042, 9917, monnier, dmoncayo >> 2. Re-bind 'M-g g' to goto-line-relative as many asked to do >> with the reasoning that 'M-g g' should use by default the >> same numbering scheme as is displayed by display-line-numbers-mode; > > Two comments: > > 1) display-line-numbers-mode by default behaves the same as > line-number-mode > 2) display-line-numbers-mode has the display-line-numbers-widen > option which disregards narrowing, so if you want to follow > display-line-numbers-mode, you will need to heed that option as > well > >> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing >> the numbering scheme using a prefix arg and a user option. > > I like this the best. If making the current goto-line 'M-g g' more DWIM is not easy to do, maybe really a user option could help with such choices: - always use absolute line numbers; - always use relative line numbers; - follow the value of display-line-numbers-widen; ... Also more explicit keys are needed, e.g.: M-g l a - with mnemonics: goto line absolute M-g l r - with mnemonics: goto line relative ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-30 7:27 ` Juri Linkov @ 2020-10-30 8:19 ` Eli Zaretskii 0 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2020-10-30 8:19 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, 5042, 9917, monnier, dmoncayo > From: Juri Linkov <juri@linkov.net> > Cc: larsi@gnus.org, 5042@debbugs.gnu.org, 9917@debbugs.gnu.org, > monnier@iro.umontreal.ca, dmoncayo@gmail.com > Date: Fri, 30 Oct 2020 09:27:43 +0200 > > >> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing > >> the numbering scheme using a prefix arg and a user option. > > > > I like this the best. > > If making the current goto-line 'M-g g' more DWIM is not easy to do, > maybe really a user option could help with such choices: > > - always use absolute line numbers; > - always use relative line numbers; > - follow the value of display-line-numbers-widen; > ... That's also a possibility, but I think "M-1 M-g g" would still be useful, even with these options, because sometimes the need in narrow-relative line numbers is a one-time thing. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-29 9:19 ` Juri Linkov 2020-10-29 14:31 ` Eli Zaretskii @ 2020-10-29 16:44 ` Drew Adams 2020-10-30 9:49 ` Lars Ingebrigtsen 2 siblings, 0 replies; 39+ messages in thread From: Drew Adams @ 2020-10-29 16:44 UTC (permalink / raw) To: Juri Linkov, Lars Ingebrigtsen; +Cc: 5042, 9917, monnier, dmoncayo > >>> So a new command and keystroke seems warranted. How about... > >>> `M-g M-v'? (The mnemonic is "goto visual line".) > >> > >> Or to add a new key to narrow-map 'C-x n' where a new key could be: > >> > >> C-x n g go to narrowed line > > > > Perhaps both? The keystroke makes sense in both contexts -- as a > > variation on `M-g M-g', and in the group of narrowing keystroke. > > I've added a more localized key binding 'C-x n g', > but still not sure about the global 'M-g' key bindings. > Here are some possible variants: > > 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g' > bound to goto-line that currently uses absolute line numbers > (btw, this fact should be mentioned in its docstring); > > 2. Re-bind 'M-g g' to goto-line-relative as many asked to do > with the reasoning that 'M-g g' should use by default the > same numbering scheme as is displayed by display-line-numbers-mode; > > 3. Leave the existing 'M-g g' bound to goto-line, but allow changing > the numbering scheme using a prefix arg and a user option. > Or another idea: maybe it should depend on whether > display-line-numbers-mode is enabled or not? > When display-line-numbers-mode is enabled, then use > relative line numbers that are displayed on the left side (WYSIWYG). FWIW, I think this belongs on `M-g', and not on `C-x n' (and not on both). The aim of the command is to go to a line. IIUC, it's not a command that is essentially an action on the buffer restriction (narrowing). Users will think of this as a goto-line action, and they will look for it on a key related to going to a line number. As others have pointed out, some users won't even recognize that Info shows a node by narrowing the overall buffer (the manual). They won't look for the key on `C-x n' (and they shouldn't). Functions that act on relative, instead of absolute, file names are still basically about file names or files, and their names and keys generally reflect that. Similarly here - this about going to a relative line number. Why a user would most likely want to do that in Info (answer: because it's narrowed) is secondary, and can almost remain unremarked. ___ Which brings us back perhaps to _swapping_ relative and absolute whenever the buffer is narrowed - the Info case is just a special case of that. What about doing that (advertising it prominently)? By default (add an option, to let users choose), when the buffer is narrowed the regular absolute goto-line key goes to a relative line number, and the regular goto-relative line key goes to an absolute line number. That would mentally cement the natural relation between relative line numbering and narrowed buffer. But by _swapping_ (and certainly not letting one of the behaviors grab both keys, as was suggested here), users always have both behaviors available on keys (including in Info). Yes, such swapping would be perhaps a first for Emacs. But I think it would end up being pretty natural, even expected. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-29 9:19 ` Juri Linkov 2020-10-29 14:31 ` Eli Zaretskii 2020-10-29 16:44 ` bug#5042: " Drew Adams @ 2020-10-30 9:49 ` Lars Ingebrigtsen 2020-10-31 19:28 ` Juri Linkov 2 siblings, 1 reply; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-10-30 9:49 UTC (permalink / raw) To: Juri Linkov; +Cc: 5042, 9917, monnier, dmoncayo Juri Linkov <juri@linkov.net> writes: > I've added a more localized key binding 'C-x n g', > but still not sure about the global 'M-g' key bindings. > Here are some possible variants: > > 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g' > bound to goto-line that currently uses absolute line numbers > (btw, this fact should be mentioned in its docstring); This makes most sense to me -- sometimes you want to go relative (when you're working on stuff wrt. the buffer) and sometimes you want to go absolute (when you're looking at external data, like error reports and the like). So two commands (and keystrokes), and document the difference properly. > 3. Leave the existing 'M-g g' bound to goto-line, but allow changing > the numbering scheme using a prefix arg and a user option. > Or another idea: maybe it should depend on whether > display-line-numbers-mode is enabled or not? > When display-line-numbers-mode is enabled, then use > relative line numbers that are displayed on the left side (WYSIWYG). I'm not opposed to this, but I wonder whether it'd be used much (if we have two keystrokes, which I think we should have anyway). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-30 9:49 ` Lars Ingebrigtsen @ 2020-10-31 19:28 ` Juri Linkov 2020-10-31 20:00 ` bug#5042: " Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Juri Linkov @ 2020-10-31 19:28 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 5042, 9917, monnier, dmoncayo >> 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g' >> bound to goto-line that currently uses absolute line numbers >> (btw, this fact should be mentioned in its docstring); > > This makes most sense to me -- sometimes you want to go relative (when > you're working on stuff wrt. the buffer) and sometimes you want to go > absolute (when you're looking at external data, like error reports and > the like). > > So two commands (and keystrokes), and document the difference properly. What do you think about binding upper-case 'M-G G' to goto-line, where the big G has mnemonics of more global absolute line numbers, and binding lower-case 'M-g g' to goto-line-relative where the little g means more local relative addressing. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-31 19:28 ` Juri Linkov @ 2020-10-31 20:00 ` Eli Zaretskii 0 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2020-10-31 20:00 UTC (permalink / raw) To: Juri Linkov; +Cc: larsi, 5042, 9917, monnier, dmoncayo > From: Juri Linkov <juri@linkov.net> > Cc: Eli Zaretskii <eliz@gnu.org>, 5042@debbugs.gnu.org, > 9917@debbugs.gnu.org, monnier@iro.umontreal.ca, dmoncayo@gmail.com > Date: Sat, 31 Oct 2020 21:28:41 +0200 > > What do you think about binding upper-case 'M-G G' to goto-line, It's harder to type. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-09-21 19:03 ` Juri Linkov 2020-09-22 14:37 ` Lars Ingebrigtsen @ 2020-10-27 20:52 ` Juri Linkov 2020-10-28 9:48 ` bug#5042: " Lars Ingebrigtsen 1 sibling, 1 reply; 39+ messages in thread From: Juri Linkov @ 2020-10-27 20:52 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 5042, 9917, monnier, dmoncayo > This is what for example help-function-def--button-function does: > > ;; Widen the buffer if necessary to go to this position. > (when (or (< position (point-min)) > (> position (point-max))) > (widen)) > (goto-char position) > > Unfortunately, xref doesn't provide such nice feature, > so 'M-.' fails to navigate in a narrowed buffer. Here is the fix for xref: diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index eed73f5791..c7ff351845 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -897,8 +897,10 @@ xref-location-marker (let ((buffer-point (find-function-search-for-symbol symbol type file))) (with-current-buffer (car buffer-point) (save-excursion - (goto-char (or (cdr buffer-point) (point-min))) - (point-marker)))))) + (save-restriction + (widen) + (goto-char (or (cdr buffer-point) (point-min))) + (point-marker))))))) (cl-defmethod xref-location-group ((l xref-elisp-location)) (xref-elisp-location-file l)) ^ permalink raw reply related [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-27 20:52 ` Juri Linkov @ 2020-10-28 9:48 ` Lars Ingebrigtsen 2020-10-28 11:58 ` Dmitry Gutov 0 siblings, 1 reply; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-10-28 9:48 UTC (permalink / raw) To: Juri Linkov; +Cc: 5042, dmoncayo, 9917, monnier, Dmitry Gutov Juri Linkov <juri@linkov.net> writes: > Here is the fix for xref: [...] > - (goto-char (or (cdr buffer-point) (point-min))) > - (point-marker)))))) > + (save-restriction > + (widen) > + (goto-char (or (cdr buffer-point) (point-min))) > + (point-marker))))))) Hm... Does Dmitry have any comments here? (Added to Cc.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-28 9:48 ` bug#5042: " Lars Ingebrigtsen @ 2020-10-28 11:58 ` Dmitry Gutov 2020-10-30 9:44 ` Lars Ingebrigtsen 0 siblings, 1 reply; 39+ messages in thread From: Dmitry Gutov @ 2020-10-28 11:58 UTC (permalink / raw) To: Lars Ingebrigtsen, Juri Linkov; +Cc: 5042, 9917, monnier, dmoncayo On 28.10.2020 11:48, Lars Ingebrigtsen wrote: > Juri Linkov <juri@linkov.net> writes: > >> Here is the fix for xref: > > [...] > >> - (goto-char (or (cdr buffer-point) (point-min))) >> - (point-marker)))))) >> + (save-restriction >> + (widen) >> + (goto-char (or (cdr buffer-point) (point-min))) >> + (point-marker))))))) If this works, sure, please install. This piece by itself makes sense. > Hm... Does Dmitry have any comments here? (Added to Cc.) I'm subscribed to the bug tracker, but I skip over a number of discussions automatically (and an extra email in a thread is relatively easy to miss, too). In case I don't respond in similar circumstances in the future, may I ask for a personal email? One without 'debbugs.gnu.org' in the From/To/Cc. ^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 2020-10-28 11:58 ` Dmitry Gutov @ 2020-10-30 9:44 ` Lars Ingebrigtsen 0 siblings, 0 replies; 39+ messages in thread From: Lars Ingebrigtsen @ 2020-10-30 9:44 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Juri Linkov, dmoncayo, 9917, monnier, 5042 Dmitry Gutov <dgutov@yandex.ru> writes: > In case I don't respond in similar circumstances in the future, may I > ask for a personal email? One without 'debbugs.gnu.org' in the > From/To/Cc. OK, will try to remember. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2020-10-31 20:00 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <<CAH8Pv0jBbJoyJfW+Xh-m3kqGQnVc0eO2+kM40SJ23JOKiBrx-A@mail.gmail.com>
[not found] ` <<877dspmzo3.fsf@gnus.org>
[not found] ` <<jwv4kntbqep.fsf-monnier+emacs@gnu.org>
[not found] ` <<28534d1c-6652-4cfe-acb4-f0a30624f878@default>
[not found] ` <<83tuvt1qwq.fsf@gnu.org>
2020-09-19 20:22 ` bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer Drew Adams
2020-09-19 20:27 ` bug#9917: " Eli Zaretskii
[not found] ` <<83zh5l1uqw.fsf@gnu.org>
[not found] ` <<87wo0osspd.fsf@gnus.org>
[not found] ` <<87lfh3dtoj.fsf@mail.linkov.net>
[not found] ` <<878sd1j2rv.fsf@gnus.org>
[not found] ` <<871ritbs6t.fsf@mail.linkov.net>
[not found] ` <<cd8f2969-6705-46c8-b090-03e284b0ba0c@default>
[not found] ` <<83zh5gvauy.fsf@gnu.org>
2020-09-23 18:09 ` bug#5042: " Drew Adams
2020-09-23 19:40 ` Juri Linkov
2011-10-31 14:31 Dani Moncayo
2011-11-01 9:35 ` Juri Linkov
2011-11-01 17:56 ` Stefan Monnier
2011-11-01 22:35 ` Juri Linkov
2011-11-01 23:22 ` Drew Adams
2011-11-02 9:48 ` Juri Linkov
2011-11-02 12:59 ` Drew Adams
2011-11-02 9:46 ` Juri Linkov
2020-09-19 17:42 ` bug#5042: " Lars Ingebrigtsen
2020-09-19 18:01 ` Stefan Monnier
2020-09-19 19:27 ` bug#9917: bug#5042: " Drew Adams
2020-09-19 19:56 ` Eli Zaretskii
2020-09-19 18:33 ` Eli Zaretskii
2020-09-20 9:28 ` Lars Ingebrigtsen
2020-09-21 19:03 ` Juri Linkov
2020-09-22 14:37 ` Lars Ingebrigtsen
2020-09-22 18:08 ` Juri Linkov
2020-09-22 20:10 ` Drew Adams
2020-09-23 14:14 ` bug#5042: bug#9917: " Eli Zaretskii
2020-09-23 13:18 ` Lars Ingebrigtsen
2020-09-23 17:58 ` Drew Adams
2020-09-24 7:39 ` Robert Pluim
2020-09-24 17:31 ` bug#9917: " Drew Adams
2020-10-29 9:19 ` Juri Linkov
2020-10-29 14:31 ` Eli Zaretskii
2020-10-30 7:27 ` Juri Linkov
2020-10-30 8:19 ` Eli Zaretskii
2020-10-29 16:44 ` bug#5042: " Drew Adams
2020-10-30 9:49 ` Lars Ingebrigtsen
2020-10-31 19:28 ` Juri Linkov
2020-10-31 20:00 ` bug#5042: " Eli Zaretskii
2020-10-27 20:52 ` Juri Linkov
2020-10-28 9:48 ` bug#5042: " Lars Ingebrigtsen
2020-10-28 11:58 ` Dmitry Gutov
2020-10-30 9:44 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).