* Emacs's handling of line numbers [from bug#5042] @ 2010-02-15 18:47 Mark Lillibridge [not found] ` <jwvd4068dsr.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-02-15 18:47 UTC (permalink / raw) To: emacs-devel; +Cc: lekktu, markus.triska, drew.adams [Moved here from bug tracker bug #5042; subject line was "RE: bug#5042: 23.1;linum-mode gives incorrect line numbers with narrowed buffers"] Gnu emacs's assignment of line numbers to lines is inconsistent when a buffer is narrowed: * goto-line and (not part of standard emacs) wb-line-number.el always starts numbering lines from the start of the buffer but, * line-number-at-pos and linum mode start numbering lines from (point-min) so a given line's line number depends on what restriction (if any) is in effect at the moment. This has a number of bad consequences; perhaps most importantly, it is not possible to reliably jump to a on-screen line using goto-line and its displayed line number. (This is a crucial primitive for controlling emacs via voice.) After some discussion on the bug tracker list, it was agreed that all of these functions should be made consistent. Because both methods of numbering lines have defenders and uses: * always numbering from the start of the buffer makes it easy to see that you're in a restriction and to compare to external line numbers (e.g., as produced by gcc) * numbering from the start of a restriction makes it easy to see how big the restriction is; it also makes modes like Rmail or info have "normal" line numbers. (Otherwise, you get counterintuitive effects like Rmail messages starting with line number 242634.) the consensus was that the method of line numbering should be customizable/settable on a per buffer basis. To be concrete, the current proposal is to add something like: (defcustom restart-numbering-restriction nil "If true, lines inside a restriction are numbered starting from 1. If false, line numbers correspond to position inside the buffer." :group 'editing-basics :type 'boolean) goto-line, line-number-at-pos, and linum mode would then use the current value of this variable to decide how to number lines. Modes like Rmail and info would make this variable buffer local and set it to t. There was no strong consensus on the default value for this variable other than that no one felt strongly about its value. A weak preference was expressed for nil. Opinions? If this proposal is acceptable, I volunteer to produce a draft patch implementing it. - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
[parent not found: <jwvd4068dsr.fsf-monnier+emacs@gnu.org>]
* Re: Emacs's handling of line numbers [from bug#5042] [not found] ` <jwvd4068dsr.fsf-monnier+emacs@gnu.org> @ 2010-04-11 22:22 ` Mark Lillibridge 2010-04-12 2:27 ` Stefan Monnier 0 siblings, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-04-11 22:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, drew.adams, markus.triska, emacs-devel [sorry for the delay replying] Stefan wrote: > Mark wrote: > > (defcustom restart-numbering-restriction nil > > "If true, lines inside a restriction are numbered starting from 1. > > If false, line numbers correspond to position inside the buffer." > > :group 'editing-basics > > :type 'boolean) > > The problem is not one of line-numbers but of narrowing/restriction only > (which in turn has impacts on line-numbering among other things). > So I don't think "number" deserves to be part of the name. > > While implementing it, please try and merge it with (AKA have it replace) > font-lock-dont-widen. > > Of course, a better approach would distinguish the two kinds of > narrowing not on a buffer-basis but on a narrowing-basis, so that if you > interactively narrow to a portion of a page in an Info buffer, you > can still get line-numbers starting at the beginning of the page > (even if it's outside the narrowed portion). Hmmm. I think some more design may be in order before implementing. Let me try and sketch an idea based on the above: * There are two (optional) levels of restriction: "semantic" and "temporary". (better names anyone?) * The temporary restriction is always contained in or the same as the semantic one. * font-lock always uses the semantic restriction (font-lock-dont-widen goes away) * By default, line numbering is also based on the semantic restriction * a global option allows switching this behavior to use the temporary restriction for line numbering. * Rmail, Info, and the like, use the semantic restriction because the restricted-to-unit is effectively an independent buffer (semantic unit) * The default narrowing commands available to users use the temporary restriction. Does this sort of approach make sense? Do people like it? It is a more global change than I was originally envisioning. - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-11 22:22 ` Mark Lillibridge @ 2010-04-12 2:27 ` Stefan Monnier 2010-04-17 1:57 ` Mark Lillibridge 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2010-04-12 2:27 UTC (permalink / raw) To: mark.lillibridge; +Cc: lekktu, drew.adams, markus.triska, emacs-devel > Hmmm. I think some more design may be in order before implementing. > Let me try and sketch an idea based on the above: > * There are two (optional) levels of restriction: "semantic" and > "temporary". (better names anyone?) > * The temporary restriction is always contained in or the same as the > semantic one. > * font-lock always uses the semantic restriction (font-lock-dont-widen > goes away) > * By default, line numbering is also based on the semantic restriction > * a global option allows switching this behavior to use the temporary > restriction for line numbering. > * Rmail, Info, and the like, use the semantic restriction because the > restricted-to-unit is effectively an independent buffer (semantic > unit) > * The default narrowing commands available to users use the temporary > restriction. > Does this sort of approach make sense? Do people like it? It is a more > global change than I was originally envisioning. This does sound right. And yes, it might introduce some "far" changes, but hopefully it will still be fairly limited. One visible change that's missing in the above is that we need to have two forms of widening: whether we want to widen the current temporary narrowing (if any), or we want to widen it all (i.e. not only the temporary narrowing but the semantic one as well). An important part of the design is to try and minimize the amount of changes to the C code (which currently keeps track of BEG and Z which are the widened limits of the buffer and BEGV and ZV which are the current narrowed buffer limits). So ideally, the distinction between the two kinds of narrowing would only be visible to Elisp code. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-12 2:27 ` Stefan Monnier @ 2010-04-17 1:57 ` Mark Lillibridge 2010-04-17 7:29 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-04-17 1:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, drew.adams, markus.triska, emacs-devel Stefan wrote: > Mark wrote: > > Hmmm. I think some more design may be in order before implementing. > > Let me try and sketch an idea based on the above: > > * There are two (optional) levels of restriction: "semantic" and > > "temporary". (better names anyone?) > > * The temporary restriction is always contained in or the same as the > > semantic one. > > * font-lock always uses the semantic restriction (font-lock-dont-widen > > goes away) > > * By default, line numbering is also based on the semantic restriction > > * a global option allows switching this behavior to use the temporary > > restriction for line numbering. > > * Rmail, Info, and the like, use the semantic restriction because the > > restricted-to-unit is effectively an independent buffer (semantic > > unit) > > * The default narrowing commands available to users use the temporary > > restriction. > > Does this sort of approach make sense? Do people like it? It is a more > > global change than I was originally envisioning. > > This does sound right. And yes, it might introduce some "far" changes, > but hopefully it will still be fairly limited. > > One visible change that's missing in the above is that we need to have > two forms of widening: whether we want to widen the current temporary > narrowing (if any), or we want to widen it all (i.e. not only the > temporary narrowing but the semantic one as well). > > An important part of the design is to try and minimize the amount of > changes to the C code (which currently keeps track of BEG and Z which > are the widened limits of the buffer and BEGV and ZV which are the > current narrowed buffer limits). So ideally, the distinction between > the two kinds of narrowing would only be visible to Elisp code. What do other people think? I'm reluctant to try and make such a major change as thus without more input. - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 1:57 ` Mark Lillibridge @ 2010-04-17 7:29 ` Eli Zaretskii 2010-04-17 14:45 ` Stefan Monnier 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2010-04-17 7:29 UTC (permalink / raw) To: mark.lillibridge; +Cc: emacs-devel > Date: Fri, 16 Apr 2010 18:57:26 -0700 > From: Mark Lillibridge <mark.lillibridge@hp.com> > Cc: lekktu@gmail.com, drew.adams@oracle.com, markus.triska@gmx.at, > emacs-devel@gnu.org > > What do other people think? I'm reluctant to try and make such a > major change as thus without more input. I wanted to provide some input, but found I'm unable to do that, because the proposed change is not described in enough detail, and in particular the description uses terminology it never explains. What are these two ``kinds'' of restriction you are talking about, and how are they relevant to the issue at hand, which is how to number lines when a buffer is narrowed? IOW, the initial message you posted here 2 months ago was clear, but then you switched into a domain where I cannot follow you. TIA ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 7:29 ` Eli Zaretskii @ 2010-04-17 14:45 ` Stefan Monnier 2010-04-17 15:57 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2010-04-17 14:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: mark.lillibridge, emacs-devel > What are these two ``kinds'' of restriction you are talking about, and > how are they relevant to the issue at hand, which is how to number > lines when a buffer is narrowed? He's proposing to distinguish between two different kinds of narrowing (aka "restrictions"). How they'd be implemented/distinguished is still up in the air, AFAIK. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 14:45 ` Stefan Monnier @ 2010-04-17 15:57 ` Eli Zaretskii 2010-04-17 19:51 ` Mark Lillibridge 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2010-04-17 15:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: mark.lillibridge, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: mark.lillibridge@hp.com, emacs-devel@gnu.org > Date: Sat, 17 Apr 2010 10:45:19 -0400 > > > What are these two ``kinds'' of restriction you are talking about, and > > how are they relevant to the issue at hand, which is how to number > > lines when a buffer is narrowed? > > He's proposing to distinguish between two different kinds of narrowing > (aka "restrictions"). Yes, but what _are_ these two kinds? How are they different from one another? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 15:57 ` Eli Zaretskii @ 2010-04-17 19:51 ` Mark Lillibridge 2010-04-17 21:04 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-04-17 19:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli wrote: > > From: Stefan Monnier <monnier@iro.umontreal.ca> > > Cc: mark.lillibridge@hp.com, emacs-devel@gnu.org > > Date: Sat, 17 Apr 2010 10:45:19 -0400 > > > > > What are these two ``kinds'' of restriction you are talking about, and > > > how are they relevant to the issue at hand, which is how to number > > > lines when a buffer is narrowed? > > > > He's proposing to distinguish between two different kinds of narrowing > > (aka "restrictions"). > > Yes, but what _are_ these two kinds? How are they different from one > another? Sorry, I should've explained better. Originally, the issue was just how to do line numbering, but Stefan suggested widening the issue. Broadly speaking, the issue arises with "applications" like Rmail and Info that use a single Emacs buffer as what amounts to a collection of logical buffers; they switch among these logical buffers by restricting the Emacs buffer to the logical buffer in question. Thus, for example Rmail restricts my inbox file to just the current message. When I advance to a different message, it changes the restriction to the new message. Info is similar, but instead of messages, it is nodes(?). Unfortunately, many Emacs features don't expect this and so behave suboptimally. For example, font lock attempts to process the entire buffer instead of just the current logical buffer; font-lock-dont-widen was invented to allow these applications to prevent this. The example which started this discussion is line numbering: goto-line numbers lines based on the physical buffer while linum mode numbers lines based on the logical buffer (actually, the current restriction). Things get even messier when the user narrows the (logical) buffer temporarily, say to limit macro application. If the application used font-lock-dont-widen, then font locking will attempt to run only on the temporary restriction, probably with confusing results. The intuition is that these two kinds of restrictions, the first for creating logical buffers, and the second for temporary limitation of commands, are fundamentally different and should be distinguished. Does that make more sense? - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 19:51 ` Mark Lillibridge @ 2010-04-17 21:04 ` Eli Zaretskii 2010-04-17 21:17 ` Juanma Barranquero 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2010-04-17 21:04 UTC (permalink / raw) To: mark.lillibridge; +Cc: monnier, emacs-devel > Date: Sat, 17 Apr 2010 12:51:17 -0700 > From: Mark Lillibridge <mark.lillibridge@hp.com> > CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > The intuition is that these two kinds of restrictions, the first for > creating logical buffers, and the second for temporary limitation of > commands, are fundamentally different and should be distinguished. Why do you think they should be distinguished? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 21:04 ` Eli Zaretskii @ 2010-04-17 21:17 ` Juanma Barranquero 2010-04-17 21:31 ` Drew Adams 2010-04-18 3:12 ` Emacs's handling of line numbers [from bug#5042] Eli Zaretskii 0 siblings, 2 replies; 56+ messages in thread From: Juanma Barranquero @ 2010-04-17 21:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, mark.lillibridge, emacs-devel On Sat, Apr 17, 2010 at 23:04, Eli Zaretskii <eliz@gnu.org> wrote: > Why do you think they should be distinguished? It would perhaps be useful to distinguish between user narrowing and program narrowing (the one used by Info, rmail, etc., I mean). Or, put it other way, perhaps we need a narrowing facility for elisp code, separate and independent from the user widen/narrowing interactive command set. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Emacs's handling of line numbers [from bug#5042] 2010-04-17 21:17 ` Juanma Barranquero @ 2010-04-17 21:31 ` Drew Adams 2010-04-18 18:15 ` widen-one-level [was: Emacs's handling of line numbers] Drew Adams 2010-04-18 3:12 ` Emacs's handling of line numbers [from bug#5042] Eli Zaretskii 1 sibling, 1 reply; 56+ messages in thread From: Drew Adams @ 2010-04-17 21:31 UTC (permalink / raw) To: 'Juanma Barranquero', 'Eli Zaretskii' Cc: monnier, mark.lillibridge, emacs-devel > It would perhaps be useful to distinguish between user narrowing and > program narrowing (the one used by Info, rmail, etc., I mean). Or, put > it other way, perhaps we need a narrowing facility for elisp code, > separate and independent from the user widen/narrowing interactive > command set. [I suspect that the following is not what Mark has in mind, and if so then I don't want to divert attention from his questions - I'll drop it (or start a different thread if there is any interest).] One thing I've sometimes thought would be handy is an additional widening command, `widen-one-level', which would widen only as far as the next-to-last narrowing. You can narrow and then narrow further, any number of times. But `widen' always widens completely. Sometimes I would like to just undo the last level of narrowing, returning to the previous level (or to the top level, if there is only one narrowing). This would require managing a list or stack of narrowing limits etc. I have no idea whether anyone else would find such a command useful. And I can't really characterize useful use cases. But I know I've sometimes wanted such a feature. ^ permalink raw reply [flat|nested] 56+ messages in thread
* widen-one-level [was: Emacs's handling of line numbers] 2010-04-17 21:31 ` Drew Adams @ 2010-04-18 18:15 ` Drew Adams 2010-04-18 21:31 ` Juri Linkov ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Drew Adams @ 2010-04-18 18:15 UTC (permalink / raw) To: 'Juanma Barranquero', 'Eli Zaretskii' Cc: monnier, mark.lillibridge, emacs-devel > One thing I've sometimes thought would be handy is an > additional widening command, `widen-one-level', which > would widen only as far as the next-to-last narrowing. > > You can narrow and then narrow further, any number of times. > But `widen' always widens completely. Sometimes I would like > to just undo the last level of narrowing, returning to the > previous level (or to the top level, if there is > only one narrowing). > > This would require managing a list or stack of narrowing > limits etc. > > I have no idea whether anyone else would find such a command > useful. And I can't really characterize useful use cases. > But I know I've sometimes wanted such a feature. If you want to get a quick idea what this would be like, eval this code and bind `widen-one-level' (e.g. to `C-x n w' ;-)). --- (defvar restriction-stack () "Stack of buffer restrictions.") (make-variable-buffer-local 'restriction-stack) (defun widen-one-level (top) "Widen to the previous buffer restriction. With a prefix argument, widen completely." (interactive "P") (unless restriction-stack (error "Cannot widen; buffer is not narrowed")) (if top (widen) (pop restriction-stack) (if (null restriction-stack) (widen) (narrow-to-region (caar restriction-stack) (cdar restriction-stack)) (pop restriction-stack)))) (defadvice narrow-to-region (before push-restriction-stack activate) (setq restriction-stack (cons (cons start end) restriction-stack)) (when (and (= start 1) (= end (1+ (buffer-size)))) (setq restriction-stack ()))) (defadvice widen (before empty-restriction-stack activate) (setq restriction-stack ())) ; (define-key ctl-x-map "nw" 'widen-one-level) --- Another possibility would be to make a restriction ring, instead of a stack, and let you browse among the restrictions... ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-18 18:15 ` widen-one-level [was: Emacs's handling of line numbers] Drew Adams @ 2010-04-18 21:31 ` Juri Linkov 2010-04-19 0:25 ` Drew Adams 2010-04-18 23:30 ` Davis Herring 2010-04-19 1:56 ` Leo 2 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2010-04-18 21:31 UTC (permalink / raw) To: Drew Adams Cc: 'Juanma Barranquero', 'Eli Zaretskii', monnier, mark.lillibridge, emacs-devel > If you want to get a quick idea what this would be like, eval this > code and bind `widen-one-level' (e.g. to `C-x n w' ;-)). I propose a better UI compatible with current commands: bind `C-x n w' to a new user command `widen-command' that by default works exactly like `widen' currently works, i.e. without a prefix argument, widen completely. But with a numeric prefix it will widen that many levels, e.g. `C-u 1 C-x n w' for one level. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: widen-one-level [was: Emacs's handling of line numbers] 2010-04-18 21:31 ` Juri Linkov @ 2010-04-19 0:25 ` Drew Adams 0 siblings, 0 replies; 56+ messages in thread From: Drew Adams @ 2010-04-19 0:25 UTC (permalink / raw) To: 'Juri Linkov' Cc: 'Juanma Barranquero', 'Eli Zaretskii', monnier, mark.lillibridge, emacs-devel > > If you want to get a quick idea what this would be like, eval this > > code and bind `widen-one-level' (e.g. to `C-x n w' ;-)). > > I propose a better UI compatible with current commands: > bind `C-x n w' to a new user command `widen-command' that > by default works exactly like `widen' currently works, > i.e. without a prefix argument, widen completely. > > But with a numeric prefix it will widen that many levels, > e.g. `C-u 1 C-x n w' for one level. I prefer something like this: http://www.emacswiki.org/emacs/wide-n.el It follows this suggestion I made: >> Another possibility would be to make a restriction ring, >> instead of a stack, and let you browse among the restrictions... * The binding is `C-x n x', not `C-x n w'. You can still use `C-x n w' normally. * You can repeat the `x' to cycle: `C-x n x x x'... * Use a plain prefix arg (`C-u') to widen completely. * Use a prefix arg N < 0 to widen completely and empty the ring. * Use a prefix arg N >= 0 to go to the Nth previous restriction. You can have any number of regions that you can return to as restrictions. They can be, but need not be, nested. --- One question I have, at least for this library if something like this is not added to Emacs: In which of the two categories of primitive functions is `narrow-to-region' (quoting from Stefan's mail to bug #5863 thread): > there are several categories of functions: > - functions that have their own byte-code (things like widen, > car, cdr, ...). > - functions that are implemented in C but don't have their own > byte-code. > - other functions. > > Pieces of advice on the first kind of functions only work for > calls from interpreted Lisp code. Pieces of advice on the > second kind of functions only work for calls from Lisp code > (both interpreted and byte-compiled). If `narrow-to-region' has its own byte-code, then I'll add a note to the library telling users not to byte-compile it. And for future reference, how to tell whether a primitive has its own byte-code? And shouldn't this info about advising primitives be documented? (see bug #5863) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-18 18:15 ` widen-one-level [was: Emacs's handling of line numbers] Drew Adams 2010-04-18 21:31 ` Juri Linkov @ 2010-04-18 23:30 ` Davis Herring 2010-04-19 19:57 ` Richard Stallman 2010-04-19 1:56 ` Leo 2 siblings, 1 reply; 56+ messages in thread From: Davis Herring @ 2010-04-18 23:30 UTC (permalink / raw) To: Drew Adams Cc: 'Juanma Barranquero', 'Eli Zaretskii', monnier, mark.lillibridge, emacs-devel > (if top > (widen) You probably want to clear the stack here > (setq restriction-stack (cons (cons start end) restriction-stack)) ...and use markers here. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-18 23:30 ` Davis Herring @ 2010-04-19 19:57 ` Richard Stallman 2010-04-19 20:22 ` Drew Adams 2010-04-19 22:52 ` Juri Linkov 0 siblings, 2 replies; 56+ messages in thread From: Richard Stallman @ 2010-04-19 19:57 UTC (permalink / raw) To: herring; +Cc: lekktu, mark.lillibridge, emacs-devel, monnier, eliz, drew.adams If we add a stack of buffer boundaries, we need an easy way to pop out of all levels. The natural thing is that ESC ESC ESC should do it. ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 19:57 ` Richard Stallman @ 2010-04-19 20:22 ` Drew Adams 2010-04-19 22:52 ` Juri Linkov 1 sibling, 0 replies; 56+ messages in thread From: Drew Adams @ 2010-04-19 20:22 UTC (permalink / raw) To: rms, herring; +Cc: lekktu, eliz, monnier, mark.lillibridge, emacs-devel > If we add a stack of buffer boundaries, we need an easy way to pop > out of all levels. The natural thing is that ESC ESC ESC > should do it. Try the code I pointed to: http://www.emacswiki.org/emacs/wide-n.el You have these ways to widen completely: 1. C-x n w (ordinary `widen') 2. C-u C-x n x (equivalent to `widen') 3. C-0 C-x n x (widen and empty the ring) #1 and #2 leave the ring as it was. #3 empties the ring. You can cycle among restrictions by repeating `x': `C-x n x x x x...'. You can use a numeric prefix arg (e.g. `C-3 C-x n x') to restore a particular restriction from the ring. A negative prefix arg does that too, but it also pops off all entries up to the target one. IOW, if you use a negative prefix arg, you get stack behavior: `C-x n n' pushes, and `C-- C-x n x' pops'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 19:57 ` Richard Stallman 2010-04-19 20:22 ` Drew Adams @ 2010-04-19 22:52 ` Juri Linkov 1 sibling, 0 replies; 56+ messages in thread From: Juri Linkov @ 2010-04-19 22:52 UTC (permalink / raw) To: rms; +Cc: mark.lillibridge, emacs-devel > If we add a stack of buffer boundaries, we need an easy way to pop > out of all levels. To keep compatibility with the current user interface, I think that `C-x n w' should pop out of all levels. The effect will be the same as it currently does without a stack. > The natural thing is that ESC ESC ESC should do it. ESC ESC ESC could do this as well, and the question is where to put it in a list of its "modes". I think a good place is between `(funcall buffer-quit-function)' and `(delete-other-windows)'. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-18 18:15 ` widen-one-level [was: Emacs's handling of line numbers] Drew Adams 2010-04-18 21:31 ` Juri Linkov 2010-04-18 23:30 ` Davis Herring @ 2010-04-19 1:56 ` Leo 2010-04-19 2:04 ` Drew Adams 2 siblings, 1 reply; 56+ messages in thread From: Leo @ 2010-04-19 1:56 UTC (permalink / raw) To: emacs-devel On 2010-04-18 19:15 +0100, Drew Adams wrote: > (defadvice narrow-to-region (before push-restriction-stack activate) > (setq restriction-stack (cons (cons start end) restriction-stack)) > (when (and (= start 1) (= end (1+ (buffer-size)))) > (setq restriction-stack ()))) I also have something similar in my .emacs. I wonder if you noticed this problem. After advising narrow-to-region, preloaded functions such as narrow-to-page narrow-to-defun still use the original narrow-to-region ignoring the advice. Leo ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 1:56 ` Leo @ 2010-04-19 2:04 ` Drew Adams 2010-04-19 11:34 ` Leo 2010-04-19 16:31 ` Drew Adams 0 siblings, 2 replies; 56+ messages in thread From: Drew Adams @ 2010-04-19 2:04 UTC (permalink / raw) To: 'Leo', emacs-devel > > (defadvice narrow-to-region (before push-restriction-stack activate) > > (setq restriction-stack (cons (cons start end) > > restriction-stack)) > > (when (and (= start 1) (= end (1+ (buffer-size)))) > > (setq restriction-stack ()))) > > I also have something similar in my .emacs. I wonder if you > noticed this > problem. After advising narrow-to-region, preloaded functions such as > narrow-to-page narrow-to-defun still use the original narrow-to-region > ignoring the advice. Yes, I noticed that too. Presumably it's because `narrow-to-region' has its own byte code. At least that's my guess. `narrow-to-defun' is a lisp function, and it is byte-compiled, which presumably means the byte-code for `narrow-to-region' is inlined. Or something like that. Someone more knowledgable will no doubt enlighten us. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 2:04 ` Drew Adams @ 2010-04-19 11:34 ` Leo 2010-04-19 16:31 ` Drew Adams 1 sibling, 0 replies; 56+ messages in thread From: Leo @ 2010-04-19 11:34 UTC (permalink / raw) To: emacs-devel On 2010-04-19 03:04 +0100, Drew Adams wrote: > Yes, I noticed that too. Presumably it's because `narrow-to-region' has its own > byte code. At least that's my guess. `narrow-to-defun' is a lisp function, and > it is byte-compiled, which presumably means the byte-code for `narrow-to-region' > is inlined. > > Or something like that. Someone more knowledgable will no doubt enlighten us. Thanks. Leo ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 2:04 ` Drew Adams 2010-04-19 11:34 ` Leo @ 2010-04-19 16:31 ` Drew Adams 2010-04-19 17:57 ` Leo 1 sibling, 1 reply; 56+ messages in thread From: Drew Adams @ 2010-04-19 16:31 UTC (permalink / raw) To: 'Leo', emacs-devel > > > (defadvice narrow-to-region > > > (before push-restriction-stack activate) > > > (setq restriction-stack (cons (cons start end) > > > restriction-stack)) > > > (when (and (= start 1) (= end (1+ (buffer-size)))) > > > (setq restriction-stack ()))) > > > > I also have something similar in my .emacs. I wonder if you > > noticed this problem. After advising narrow-to-region, > > preloaded functions such as narrow-to-page narrow-to-defun > > still use the original narrow-to-region ignoring the advice. > > Yes, I noticed that too. Presumably it's because > `narrow-to-region' has its own byte code. At least that's my > guess. `narrow-to-defun' is a lisp function, and it is > byte-compiled, which presumably means the byte-code for > `narrow-to-region' is inlined. > > Or something like that. Someone more knowledgable will no > doubt enlighten us. One (ugly) solution is to copy the Lisp source code for `narrow-to-defun' and `narrow-to-page' to the same library that advises `narrow-to-region'. That way, the advised definition is used also for the other two. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 16:31 ` Drew Adams @ 2010-04-19 17:57 ` Leo 2010-04-19 22:56 ` Drew Adams 0 siblings, 1 reply; 56+ messages in thread From: Leo @ 2010-04-19 17:57 UTC (permalink / raw) To: emacs-devel On 2010-04-19 17:31 +0100, Drew Adams wrote: >> Or something like that. Someone more knowledgable will no >> doubt enlighten us. > > One (ugly) solution is to copy the Lisp source code for `narrow-to-defun' and > `narrow-to-page' to the same library that advises `narrow-to-region'. That way, > the advised definition is used also for the other two. Yes. I suspect defadvice will do too. My original idea was to implement some sort of undo for narrowing using a ring structure and have narrow-to-region record that info for me. Because of this (which I think is ugly) I abandoned the plan. In the end I implemented something that needs a user to explicitly record the state (bound to C-x n r). The use case for me is this: suppose I am writing an around 50 page article in LaTeX and I don't feel like splitting it into multiple files. But during writing I only want to focus on a portion of the article (a section for example), I can narrow to that section and record that state so that C-x n w will not expose me to the entire file. I posted my code here http://paste.lisp.org/display/97993. Leo ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 17:57 ` Leo @ 2010-04-19 22:56 ` Drew Adams 2010-04-22 9:59 ` Leo 0 siblings, 1 reply; 56+ messages in thread From: Drew Adams @ 2010-04-19 22:56 UTC (permalink / raw) To: 'Leo', emacs-devel > My original idea was to implement some sort of undo for > narrowing using a ring structure and have narrow-to-region > record that info for me. Because of this (which I think is ugly) > I abandoned the plan. > > In the end I implemented something that needs a user to explicitly > record the state (bound to C-x n r). > > The use case for me is this: suppose I am writing an around 50 page > article in LaTeX and I don't feel like splitting it into > multiple files. > But during writing I only want to focus on a portion of the article (a > section for example), I can narrow to that section and record that > state so that C-x n w will not expose me to the entire file. > > I posted my code here http://paste.lisp.org/display/97993. I think the code I posted does what you describe above for your use case, and you can use it with regular narrowing and widening. Each buffer has its own ring of restrictions. Also, if you use bookmark+.el then you can also bookmark regions, IOW, have persistence. Dunno, but it sounds like that too could be helpful for your use case. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: widen-one-level [was: Emacs's handling of line numbers] 2010-04-19 22:56 ` Drew Adams @ 2010-04-22 9:59 ` Leo 0 siblings, 0 replies; 56+ messages in thread From: Leo @ 2010-04-22 9:59 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel On 2010-04-19 23:56 +0100, Drew Adams wrote: > I think the code I posted does what you describe above for your use case, and > you can use it with regular narrowing and widening. Each buffer has its own ring > of restrictions. > > Also, if you use bookmark+.el then you can also bookmark regions, IOW, have > persistence. Dunno, but it sounds like that too could be helpful for your use > case. I will take a look. Thanks. Leo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-17 21:17 ` Juanma Barranquero 2010-04-17 21:31 ` Drew Adams @ 2010-04-18 3:12 ` Eli Zaretskii 2010-04-18 3:49 ` Juanma Barranquero 2010-04-18 17:00 ` Mark Lillibridge 1 sibling, 2 replies; 56+ messages in thread From: Eli Zaretskii @ 2010-04-18 3:12 UTC (permalink / raw) To: Juanma Barranquero; +Cc: monnier, mark.lillibridge, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Sat, 17 Apr 2010 23:17:26 +0200 > Cc: mark.lillibridge@hp.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > On Sat, Apr 17, 2010 at 23:04, Eli Zaretskii <eliz@gnu.org> wrote: > > > Why do you think they should be distinguished? > > It would perhaps be useful to distinguish between user narrowing and > program narrowing (the one used by Info, rmail, etc., I mean). I don't see why. Both use-cases limit commands to a portion of a buffer. What's the difference between these two classes of narrowing, and how would distinguishing between them be useful? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 3:12 ` Emacs's handling of line numbers [from bug#5042] Eli Zaretskii @ 2010-04-18 3:49 ` Juanma Barranquero 2010-04-18 8:05 ` Juri Linkov 2010-04-18 17:29 ` Eli Zaretskii 2010-04-18 17:00 ` Mark Lillibridge 1 sibling, 2 replies; 56+ messages in thread From: Juanma Barranquero @ 2010-04-18 3:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, mark.lillibridge, emacs-devel On Sun, Apr 18, 2010 at 05:12, Eli Zaretskii <eliz@gnu.org> wrote: > I don't see why. Both use-cases limit commands to a portion of a > buffer. What's the difference between these two classes of narrowing, > and how would distinguishing between them be useful? For the same reason that the narrowing stack that Drew proposes could be useful: if I'm reading an Info node, my narrowing/widening shouldn't interfere with the use of narrowing by Info-mode, because that's just an artifact of its implementation. Being able to do M-x widen in an Info node and seeing the whole buffer is IMO a "bug" because it destroys the abstraction. On the same vein, if I were implementing a package that needed to show/hide portions of the buffer, I would likely prefer the user not to be able to break the abstraction just by accidentally doing M-x widen. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 3:49 ` Juanma Barranquero @ 2010-04-18 8:05 ` Juri Linkov 2010-04-18 13:44 ` Drew Adams 2010-04-18 13:45 ` Drew Adams 2010-04-18 17:29 ` Eli Zaretskii 1 sibling, 2 replies; 56+ messages in thread From: Juri Linkov @ 2010-04-18 8:05 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Eli Zaretskii, monnier, mark.lillibridge, emacs-devel > For the same reason that the narrowing stack that Drew proposes could > be useful: if I'm reading an Info node, my narrowing/widening > shouldn't interfere with the use of narrowing by Info-mode, because > that's just an artifact of its implementation. Being able to do M-x > widen in an Info node and seeing the whole buffer is IMO a "bug" > because it destroys the abstraction. I agree that user commands (with the prefix map `C-x n') should not widen or narrow the Info buffer outside of the current Info node. Only some low-level functions should be allowed to do this. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Emacs's handling of line numbers [from bug#5042] 2010-04-18 8:05 ` Juri Linkov @ 2010-04-18 13:44 ` Drew Adams 2010-04-18 13:50 ` Lennart Borgman 2010-04-18 14:03 ` Juanma Barranquero 2010-04-18 13:45 ` Drew Adams 1 sibling, 2 replies; 56+ messages in thread From: Drew Adams @ 2010-04-18 13:44 UTC (permalink / raw) To: 'Juri Linkov', 'Juanma Barranquero' Cc: 'Eli Zaretskii', monnier, mark.lillibridge, emacs-devel > > For the same reason that the narrowing stack that Drew > > proposes could be useful: if I'm reading an Info node, my > > narrowing/widening shouldn't interfere with the use of narrowing > > by Info-mode, because that's just an artifact of its > > implementation. Being able to do M-x widen in an Info node > > and seeing the whole buffer is IMO a "bug" > > because it destroys the abstraction. > > I agree that user commands (with the prefix map `C-x n') should not > widen or narrow the Info buffer outside of the current Info node. > Only some low-level functions should be allowed to do this. That's going too far, IMO. As Eli will perhaps point out (see bug #5839), there are reasons that some users will want to widen Info buffers. More generally, we should not remove `widen' as a command, even if in only some contexts. Likewise, `narrow'. What we should do is provide more user control (not less), possibly by creating a `widen-one-level' command as I suggested earlier. As I suggested in the thread for bug #5839, one way to at least not encourage user narrowing when that might get users (especially newbies) into trouble, would be to inhibit the activation of the `Narrow' lighter in the mode line (the lighter would still be shown but would not act as a widening button). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 13:44 ` Drew Adams @ 2010-04-18 13:50 ` Lennart Borgman 2010-04-18 16:40 ` Drew Adams 2010-04-18 14:03 ` Juanma Barranquero 1 sibling, 1 reply; 56+ messages in thread From: Lennart Borgman @ 2010-04-18 13:50 UTC (permalink / raw) To: Drew Adams Cc: Juanma Barranquero, mark.lillibridge, emacs-devel, Juri Linkov, monnier, Eli Zaretskii On Sun, Apr 18, 2010 at 3:44 PM, Drew Adams <drew.adams@oracle.com> wrote: >> > For the same reason that the narrowing stack that Drew >> > proposes could be useful: if I'm reading an Info node, my >> > narrowing/widening shouldn't interfere with the use of narrowing >> > by Info-mode, because that's just an artifact of its >> > implementation. Being able to do M-x widen in an Info node >> > and seeing the whole buffer is IMO a "bug" >> > because it destroys the abstraction. >> >> I agree that user commands (with the prefix map `C-x n') should not >> widen or narrow the Info buffer outside of the current Info node. >> Only some low-level functions should be allowed to do this. > > That's going too far, IMO. As Eli will perhaps point out (see bug #5839), there > are reasons that some users will want to widen Info buffers. I think Juri sugggested that there should not be an interactive command for doing that. Would not low level elisp functions be enough for the purpose of widening Info buffers? ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Emacs's handling of line numbers [from bug#5042] 2010-04-18 13:50 ` Lennart Borgman @ 2010-04-18 16:40 ` Drew Adams 0 siblings, 0 replies; 56+ messages in thread From: Drew Adams @ 2010-04-18 16:40 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 'Juanma Barranquero', mark.lillibridge, emacs-devel, 'Juri Linkov', monnier, 'Eli Zaretskii' > >> > For the same reason that the narrowing stack that Drew > >> > proposes could be useful: if I'm reading an Info node, my > >> > narrowing/widening shouldn't interfere with the use of narrowing > >> > by Info-mode, because that's just an artifact of its > >> > implementation. Being able to do M-x widen in an Info node > >> > and seeing the whole buffer is IMO a "bug" > >> > because it destroys the abstraction. > >> > >> I agree that user commands (with the prefix map `C-x n') should not > >> widen or narrow the Info buffer outside of the current Info node. > >> Only some low-level functions should be allowed to do this. > > > > That's going too far, IMO. As Eli will perhaps point out > > (see bug #5839), there are reasons that some users will > > want to widen Info buffers. > > I think Juri sugggested that there should not be an interactive > command for doing that. Would not low level elisp functions be enough > for the purpose of widening Info buffers? (All commands are interactive.) Yes, I understood that that was Juri's suggestion. I disagree - `widen' should be a user command. And it should be available (but not especially encouraged) in Info - see the reasons that Eli gave in the bug #5839 thread as one example. The proper way to tame widening is not to eliminate `widen' as a user command or to restrict its use in a coarse, black-and-white way. The proper way is to: 1. Remove the button on the `Narrow' lighter in modes such as Info where we don't want newbies to narrow without knowing what they're doing. (And perhaps (_perhaps_), in such contexts, also ask for confirmation if the user invokes `widen' in such a context. We already disable the command by default.) 2. Provide another command, `widen-one-level', which gives users more control over the scope of widening. It would give them the same degree of control they have now for narrowing. (No, this wouldn't prevent a user from widening to the top level in Info, but it would give users more control generally.) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 13:44 ` Drew Adams 2010-04-18 13:50 ` Lennart Borgman @ 2010-04-18 14:03 ` Juanma Barranquero 2010-04-18 14:14 ` David Kastrup 2010-04-18 16:41 ` Drew Adams 1 sibling, 2 replies; 56+ messages in thread From: Juanma Barranquero @ 2010-04-18 14:03 UTC (permalink / raw) To: Drew Adams Cc: Juri Linkov, Eli Zaretskii, monnier, mark.lillibridge, emacs-devel On Sun, Apr 18, 2010 at 15:44, Drew Adams <drew.adams@oracle.com> wrote: > That's going too far, IMO. As Eli will perhaps point out (see bug #5839), there > are reasons that some users will want to widen Info buffers. What I proposed is not removing that possibility, just making user n/w and program n/w two different facilities; one is a user commodity, and the other is (low or medium)-level infrastructure for elisp libraries. That the two are conflated is the result of library auhors not having other equally easy way to show selected parts of a buffer, I guess. > More generally, we should not remove `widen' as a command, even if in only some > contexts. Likewise, `narrow'. What we should do is provide more user control > (not less), possibly by creating a `widen-one-level' command as I suggested > earlier. No one has been proposing less user control. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 14:03 ` Juanma Barranquero @ 2010-04-18 14:14 ` David Kastrup 2010-04-18 16:41 ` Drew Adams 1 sibling, 0 replies; 56+ messages in thread From: David Kastrup @ 2010-04-18 14:14 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > On Sun, Apr 18, 2010 at 15:44, Drew Adams <drew.adams@oracle.com> wrote: > >> That's going too far, IMO. As Eli will perhaps point out (see bug >> #5839), there are reasons that some users will want to widen Info >> buffers. > > What I proposed is not removing that possibility, just making user n/w > and program n/w two different facilities; one is a user commodity, and > the other is (low or medium)-level infrastructure for elisp libraries. > That the two are conflated is the result of library auhors not having > other equally easy way to show selected parts of a buffer, I guess. > >> More generally, we should not remove `widen' as a command, even if in >> only some contexts. Likewise, `narrow'. What we should do is provide >> more user control (not less), possibly by creating a >> `widen-one-level' command as I suggested earlier. > > No one has been proposing less user control. Maybe clone-indirect-buffer should have a way to clone just a partial buffer. In that manner, info nodes and tar subfiles could get a proper "unnarrowed" buffer of their own. -- David Kastrup ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Emacs's handling of line numbers [from bug#5042] 2010-04-18 14:03 ` Juanma Barranquero 2010-04-18 14:14 ` David Kastrup @ 2010-04-18 16:41 ` Drew Adams 2010-04-18 17:03 ` Juanma Barranquero 1 sibling, 1 reply; 56+ messages in thread From: Drew Adams @ 2010-04-18 16:41 UTC (permalink / raw) To: 'Juanma Barranquero' Cc: 'Juri Linkov', 'Eli Zaretskii', monnier, mark.lillibridge, emacs-devel Juri> user commands (with the prefix map `C-x n') should not Juri> widen or narrow the Info buffer outside of the current Juri> Info node. Only some low-level functions should be Juri> allowed to do this. > > > > That's going too far, IMO. As Eli will perhaps point out > > (see bug #5839), there are reasons that some users will want > > to widen Info buffers. > > What I proposed is not removing that possibility, My post replied not to your proposal but to Juri's statement (which you clipped, but I've put back, for context). And Juri did propose removing that possibility. He said that users should not be able to use a command to widen or narrow the buffer outside of the current node. In the bug #5839 thread, Eli argues that users should be able to do that, and I agree. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5839 > > More generally, we should not remove `widen' as a command, > > even if in only some contexts. Likewise, `narrow'. What we > > should do is provide more user control (not less), possibly > > by creating a `widen-one-level' command as I suggested > > earlier. > > No one has been proposing less user control. IMO Juri did, by saying that user narrowing and widening commands should not go beyond the current Info node. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 16:41 ` Drew Adams @ 2010-04-18 17:03 ` Juanma Barranquero 2010-04-18 21:29 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Juanma Barranquero @ 2010-04-18 17:03 UTC (permalink / raw) To: Drew Adams Cc: Juri Linkov, Eli Zaretskii, monnier, mark.lillibridge, emacs-devel On Sun, Apr 18, 2010 at 18:41, Drew Adams <drew.adams@oracle.com> wrote: > My post replied not to your proposal but to Juri's statement I know. And Juri was commenting on mine. > He said that users should not be able to use a command to widen or narrow the > buffer outside of the current node. Not exactly. He said "user commands (with the prefix map `C-x n')". I don't know whether he was against defining other user commands, menu options or other ways to do that. I would be *for* defining them. Just not as general user commands. > IMO Juri did, by saying that user narrowing and widening commands should not go > beyond the current Info node. Again, user commands in the C-x n prefix map. And I would agree with that. Even if it is sometimes (how often?) useful to be able to widen the restriction in an Info buffer, that restriction is a programming convenience for Info-mode (that it uses narrowing is an implementation detail), so Info-mode should offer the way to deactivate it. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 17:03 ` Juanma Barranquero @ 2010-04-18 21:29 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2010-04-18 21:29 UTC (permalink / raw) To: Juanma Barranquero Cc: Eli Zaretskii, mark.lillibridge, monnier, Drew Adams, emacs-devel >> IMO Juri did, by saying that user narrowing and widening commands >> should not go beyond the current Info node. > > Again, user commands in the C-x n prefix map. And I would agree with > that. Even if it is sometimes (how often?) useful to be able to widen > the restriction in an Info buffer, that restriction is a programming > convenience for Info-mode (that it uses narrowing is an implementation > detail), so Info-mode should offer the way to deactivate it. Yes, this is what I meant. The primitive function `widen' should remove narrowing from the whole buffer completely as it currently does. But a new user command `widen-command' bound to `C-x n w' should not remove narrowing that was created programmatically, not by a user command like `C-x n n'. When authors of some mode decide that users should be able to remove narrowing from the whole buffer completely then this mode should provide a special command to do that. And indeed, Info mode already has such a command. It is `g * RET' that is documented in (info "(info) Go to node") as: The node name `*' specifies the whole file. So you can look at all of the current file by typing `g*<RET>' or all of any other file with `g(FILENAME)*<RET>'. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Emacs's handling of line numbers [from bug#5042] 2010-04-18 8:05 ` Juri Linkov 2010-04-18 13:44 ` Drew Adams @ 2010-04-18 13:45 ` Drew Adams 1 sibling, 0 replies; 56+ messages in thread From: Drew Adams @ 2010-04-18 13:45 UTC (permalink / raw) To: 'Juri Linkov', 'Juanma Barranquero' Cc: 'Eli Zaretskii', monnier, mark.lillibridge, emacs-devel > inhibit the activation of the `Narrow' lighter in the mode line (the > lighter would still be shown but would not act as a widening button). (I meant only in contexts where we do not want to encourage user narrowing.) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 3:49 ` Juanma Barranquero 2010-04-18 8:05 ` Juri Linkov @ 2010-04-18 17:29 ` Eli Zaretskii 2010-04-18 17:52 ` Juanma Barranquero 1 sibling, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2010-04-18 17:29 UTC (permalink / raw) To: Juanma Barranquero; +Cc: monnier, mark.lillibridge, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Sun, 18 Apr 2010 05:49:54 +0200 > Cc: mark.lillibridge@hp.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > if I'm reading an Info node, my narrowing/widening > shouldn't interfere with the use of narrowing by Info-mode, because > that's just an artifact of its implementation. If that's the problem, we could disable narrowing/widening in Info mode. (I'm not saying we should, but if we decided to do so, it would be IMO a better solution than a whole new infrastructure with two kinds of restrictions.) > Being able to do M-x > widen in an Info node and seeing the whole buffer is IMO a "bug" > because it destroys the abstraction. Actually, it happens to be a feature (more accurately, a basis for a feature), both in Info and in Rmail. > On the same vein, if I were implementing a package that needed to > show/hide portions of the buffer, I would likely prefer the user not > to be able to break the abstraction just by accidentally doing M-x > widen. But you will never be able to disallow widening completely, because the primitives are not going to go away, and there's nothing to prevent a motivated individual from invoking them, even if they are non-interactive. IOW, I don't see how the suggested duplicity will solve enough of the problem to justify the added complexity. (For that matter, I don't see the problem, either -- see my other mail in this thread.) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 17:29 ` Eli Zaretskii @ 2010-04-18 17:52 ` Juanma Barranquero 2010-04-18 17:56 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Juanma Barranquero @ 2010-04-18 17:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, mark.lillibridge, emacs-devel On Sun, Apr 18, 2010 at 19:29, Eli Zaretskii <eliz@gnu.org> wrote: > If that's the problem, we could disable narrowing/widening in Info > mode. Surely there are legitimate reasons why a user would want to use narrowing to show just part of an Info node. > (I'm not saying we should, but if we decided to do so, it would > be IMO a better solution than a whole new infrastructure with two > kinds of restrictions.) OK, don't think of it as two kinds of restrictions, but the current restriction user interface, and an additional elisp API to treat parts of a buffer as a "virtual buffer" or some such. > Actually, it happens to be a feature (more accurately, a basis for a > feature), both in Info and in Rmail. It is that feature inequivocally linked to being implemented via narrowing? > But you will never be able to disallow widening completely, because > the primitives are not going to go away, and there's nothing to > prevent a motivated individual from invoking them, even if they are > non-interactive. Of course. You can always shoot your own foot. That's no reason not to provide adequate abstractions. > IOW, I don't see how the suggested duplicity will solve enough of the > problem to justify the added complexity. I'm not sure, either. It's hard to say beforehand whether adding that would be a waste of resources (sort of like frame-local variables), or an enabling technology for some kind of problems... A priori, it seems like Info and rmail and some other packages could benefit from it. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 17:52 ` Juanma Barranquero @ 2010-04-18 17:56 ` Eli Zaretskii 0 siblings, 0 replies; 56+ messages in thread From: Eli Zaretskii @ 2010-04-18 17:56 UTC (permalink / raw) To: Juanma Barranquero; +Cc: monnier, mark.lillibridge, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Sun, 18 Apr 2010 19:52:11 +0200 > Cc: mark.lillibridge@hp.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > Actually, it happens to be a feature (more accurately, a basis for a > > feature), both in Info and in Rmail. > > It is that feature inequivocally linked to being implemented via narrowing? Well, Rmail no longer uses narrowing, it uses buffer-swap-text instead. Maybe Info should do the same, and then we will have no conflicts. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 3:12 ` Emacs's handling of line numbers [from bug#5042] Eli Zaretskii 2010-04-18 3:49 ` Juanma Barranquero @ 2010-04-18 17:00 ` Mark Lillibridge 2010-04-18 17:38 ` Eli Zaretskii 1 sibling, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-04-18 17:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> wrote: > > From: Juanma Barranquero <lekktu@gmail.com> > > Date: Sat, 17 Apr 2010 23:17:26 +0200 > > Cc: mark.lillibridge@hp.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > > On Sat, Apr 17, 2010 at 23:04, Eli Zaretskii <eliz@gnu.org> wrote: > > > > > Why do you think they should be distinguished? > > > > It would perhaps be useful to distinguish between user narrowing and > > program narrowing (the one used by Info, rmail, etc., I mean). > > I don't see why. Both use-cases limit commands to a portion of a > buffer. What's the difference between these two classes of narrowing, > and how would distinguishing between them be useful? The issue is that font-lock mode, goto-line, linum mode, and perhaps other features need to treat them differently. These features want to widen to the "application" restriction when processing the current buffer, ignoring any temporary restriction. - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 17:00 ` Mark Lillibridge @ 2010-04-18 17:38 ` Eli Zaretskii 2010-04-18 18:11 ` Lennart Borgman 2010-04-22 2:17 ` Mark Lillibridge 0 siblings, 2 replies; 56+ messages in thread From: Eli Zaretskii @ 2010-04-18 17:38 UTC (permalink / raw) To: mark.lillibridge; +Cc: lekktu, monnier, emacs-devel > Date: Sun, 18 Apr 2010 10:00:45 -0700 > From: Mark Lillibridge <mark.lillibridge@hp.com> > CC: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > The issue is that font-lock mode, goto-line, linum mode, and perhaps > other features need to treat them differently. These features want to > widen to the "application" restriction when processing the current > buffer, ignoring any temporary restriction. But if this is the problem you want to solve, you cannot solve it by introducing yet another kind of restriction: there's always a chance that a command will want to use the "application" restriction, when one is already in place, because, e.g., you have font-lock or whatever active. And then you are back at the same problem. IOW, by introducing 2 kinds of restriction, you don't solve the problem, you just push it a bit farther. Moreover, I'm not sure I see the problem that is grave enough to justify this. The 3 examples you mentioned can be solved by programming the features to do what you want (I believe font-lock already solved it, albeit not too elegantly). I understand now the difference between two classes of use of restriction (thanks to all who labored to explain that to this old fart), but are there _practical_ use-cases where the current situation gets in our way so badly that such a new feature would be justified? I wonder. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 17:38 ` Eli Zaretskii @ 2010-04-18 18:11 ` Lennart Borgman 2010-04-22 2:17 ` Mark Lillibridge 1 sibling, 0 replies; 56+ messages in thread From: Lennart Borgman @ 2010-04-18 18:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, monnier, mark.lillibridge, emacs-devel On Sun, Apr 18, 2010 at 7:38 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Sun, 18 Apr 2010 10:00:45 -0700 >> From: Mark Lillibridge <mark.lillibridge@hp.com> >> CC: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org >> >> The issue is that font-lock mode, goto-line, linum mode, and perhaps >> other features need to treat them differently. These features want to >> widen to the "application" restriction when processing the current >> buffer, ignoring any temporary restriction. > ... > IOW, by introducing 2 kinds of restriction, you don't solve the > problem, you just push it a bit farther. When it comes to things that needs to do some parsing (font-lock, indentation, completion etc) I am not sure widening is always the right mechanism. At least for multiple major modes in a buffer I think something like "show me all characters that belongs to this major mode" would fit better. And that of course requires very low level changes to Emacs. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-18 17:38 ` Eli Zaretskii 2010-04-18 18:11 ` Lennart Borgman @ 2010-04-22 2:17 ` Mark Lillibridge 2010-04-22 8:06 ` David Kastrup 2010-06-06 18:18 ` Mark Lillibridge 1 sibling, 2 replies; 56+ messages in thread From: Mark Lillibridge @ 2010-04-22 2:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> wrote: > Mark Lillibridge <mark.lillibridge@hp.com> wrote: > > The issue is that font-lock mode, goto-line, linum mode, and perhaps > > other features need to treat them differently. These features want to > > widen to the "application" restriction when processing the current > > buffer, ignoring any temporary restriction. > > But if this is the problem you want to solve, you cannot solve it by > introducing yet another kind of restriction: there's always a chance > that a command will want to use the "application" restriction, when > one is already in place, because, e.g., you have font-lock or whatever > active. And then you are back at the same problem. > > IOW, by introducing 2 kinds of restriction, you don't solve the > problem, you just push it a bit farther. > > Moreover, I'm not sure I see the problem that is grave enough to > justify this. The 3 examples you mentioned can be solved by > programming the features to do what you want (I believe font-lock > already solved it, albeit not too elegantly). I understand now the > difference between two classes of use of restriction (thanks to all > who labored to explain that to this old fart), but are there > _practical_ use-cases where the current situation gets in our way so > badly that such a new feature would be justified? I wonder. Personally, the problem I need fixed is that goto-line and linum mode number lines inconsistently. Given that linum mode already numbers the first line of a restriction starting with one and Info mode looks weird if we start numbering at the beginning of the physical buffer, I think the minimal change would be to change goto-line to number lines so that the first line of the current restriction is 1. Some wanted an option to control whether line numbers were numbered from the beginning of the restriction or the beginning of the physical buffer and some (others?) to solve this problem (which characters really belong to the (logical) buffer) once and for all. - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-22 2:17 ` Mark Lillibridge @ 2010-04-22 8:06 ` David Kastrup 2010-04-22 8:38 ` Juri Linkov 2010-04-22 8:45 ` Juanma Barranquero 2010-06-06 18:18 ` Mark Lillibridge 1 sibling, 2 replies; 56+ messages in thread From: David Kastrup @ 2010-04-22 8:06 UTC (permalink / raw) To: emacs-devel Mark Lillibridge <mark.lillibridge@hp.com> writes: >> Moreover, I'm not sure I see the problem that is grave enough to >> justify this. The 3 examples you mentioned can be solved by >> programming the features to do what you want (I believe font-lock >> already solved it, albeit not too elegantly). I understand now the >> difference between two classes of use of restriction (thanks to all >> who labored to explain that to this old fart), but are there >> _practical_ use-cases where the current situation gets in our way so >> badly that such a new feature would be justified? I wonder. > > Personally, the problem I need fixed is that goto-line and linum > mode number lines inconsistently. Given that linum mode already > numbers the first line of a restriction starting with one and Info > mode looks weird if we start numbering at the beginning of the > physical buffer, I think the minimal change would be to change > goto-line to number lines so that the first line of the current > restriction is 1. I repeat my suggestion to let clone-indirect-buffer be able to clone just part of a buffer. Using this for info nodes and tar subfiles would yield perfectly consistent behavior for the user without narrowing. -- David Kastrup ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-22 8:06 ` David Kastrup @ 2010-04-22 8:38 ` Juri Linkov 2010-04-22 8:45 ` Juanma Barranquero 1 sibling, 0 replies; 56+ messages in thread From: Juri Linkov @ 2010-04-22 8:38 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > I repeat my suggestion to let clone-indirect-buffer be able to clone > just part of a buffer. Using this for info nodes and tar subfiles would > yield perfectly consistent behavior for the user without narrowing. Oh, yes, then we could finally avoid all these permanent problems with Info breadcrumbs. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-22 8:06 ` David Kastrup 2010-04-22 8:38 ` Juri Linkov @ 2010-04-22 8:45 ` Juanma Barranquero 1 sibling, 0 replies; 56+ messages in thread From: Juanma Barranquero @ 2010-04-22 8:45 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel On Thu, Apr 22, 2010 at 10:06, David Kastrup <dak@gnu.org> wrote: > I repeat my suggestion to let clone-indirect-buffer be able to clone > just part of a buffer. Using this for info nodes and tar subfiles would > yield perfectly consistent behavior for the user without narrowing. I think this is a good idea, but orthogonal to the issue. I'd still like linum to number a region using the whole-buffer line numbers, for example. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-04-22 2:17 ` Mark Lillibridge 2010-04-22 8:06 ` David Kastrup @ 2010-06-06 18:18 ` Mark Lillibridge 2010-06-07 1:30 ` Stefan Monnier 1 sibling, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-06-06 18:18 UTC (permalink / raw) To: mark.lillibridge; +Cc: lekktu, eliz, monnier, emacs-devel In an attempt to make progress on this bug, I propose the following: * all the relevant proposals require {esc}g to move by the line number shown by linum mode if it were on. (they disagree about which numbering scheme(s) linum should use.) * this means we need to redefine the behavior of {esc}g * {esc}g currently calls goto-line, but a grep through the elisp sources of Emacs shows a lots of calls to goto-line, any of which might be broken by changing the behavior of goto-line * Accordingly, I suggest introducing a new function, goto-numbered-line, which will replace the binding of {esc}g and the edit menu option. * the current documentation for goto-line is: (goto-line line &optional buffer) Goto line, counting from line 1 at beginning of buffer. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. When called from Lisp code, the optional argument buffer specifies a buffer to switch to. If there's a number in the buffer at point, it is the default for line. * I propose documentation for goto-numbered-line as: (goto-numbered-line line &optional buffer) Goto line with line number line; use linum mode to see what line numbers each line is assigned. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. When called from Lisp code, the optional argument buffer specifies a buffer to switch to. If there's a number in the buffer at point, it is the default for line. * for the initial implementation, goto-numbered-line would effectively be a copy of goto-line without the widening function. (This is what linum mode currently does.) Later, if we change how linum assigns line numbers, we can change goto-number-line in parallel. What do people think? This resolves the bug ({esc}g and linum numbering lines differently) without forcing us to make a hard decision on exactly how linum should number lines first. - Mark I (Mark Lillibridge) wrote: > Eli Zaretskii <eliz@gnu.org> wrote: > > Mark Lillibridge <mark.lillibridge@hp.com> wrote: > > > The issue is that font-lock mode, goto-line, linum mode, and perhaps > > > other features need to treat them differently. These features want to > > > widen to the "application" restriction when processing the current > > > buffer, ignoring any temporary restriction. > > > > But if this is the problem you want to solve, you cannot solve it by > > introducing yet another kind of restriction: there's always a chance > > that a command will want to use the "application" restriction, when > > one is already in place, because, e.g., you have font-lock or whatever > > active. And then you are back at the same problem. > > > > IOW, by introducing 2 kinds of restriction, you don't solve the > > problem, you just push it a bit farther. > > > > Moreover, I'm not sure I see the problem that is grave enough to > > justify this. The 3 examples you mentioned can be solved by > > programming the features to do what you want (I believe font-lock > > already solved it, albeit not too elegantly). I understand now the > > difference between two classes of use of restriction (thanks to all > > who labored to explain that to this old fart), but are there > > _practical_ use-cases where the current situation gets in our way so > > badly that such a new feature would be justified? I wonder. > > Personally, the problem I need fixed is that goto-line and linum > mode number lines inconsistently. Given that linum mode already numbers > the first line of a restriction starting with one and Info mode looks weird > if we start numbering at the beginning of the physical buffer, I think > the minimal change would be to change goto-line to number lines so that > the first line of the current restriction is 1. > > Some wanted an option to control whether line numbers were numbered > from the beginning of the restriction or the beginning of the physical > buffer and some (others?) to solve this problem (which characters really > belong to the (logical) buffer) once and for all. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-06 18:18 ` Mark Lillibridge @ 2010-06-07 1:30 ` Stefan Monnier 2010-06-07 1:41 ` Lennart Borgman 2010-06-09 2:19 ` Mark Lillibridge 0 siblings, 2 replies; 56+ messages in thread From: Stefan Monnier @ 2010-06-07 1:30 UTC (permalink / raw) To: mark.lillibridge; +Cc: lekktu, eliz, emacs-devel > * {esc}g currently calls goto-line, but a grep through the elisp sources > of Emacs shows a lots of calls to goto-line, any of which might be > broken by changing the behavior of goto-line Grep counts 8 such calls only. Doesn't seem unmanageable at all. > * Accordingly, I suggest introducing a new function, goto-numbered-line, > which will replace the binding of {esc}g and the edit menu option. goto-line is already marked as "should only be called from Elisp", so introducing goto-numbered-line doesn't sound right. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-07 1:30 ` Stefan Monnier @ 2010-06-07 1:41 ` Lennart Borgman 2010-06-07 13:45 ` Stefan Monnier 2010-06-09 2:19 ` Mark Lillibridge 1 sibling, 1 reply; 56+ messages in thread From: Lennart Borgman @ 2010-06-07 1:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, eliz, mark.lillibridge, emacs-devel On Mon, Jun 7, 2010 at 3:30 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> * {esc}g currently calls goto-line, but a grep through the elisp sources >> of Emacs shows a lots of calls to goto-line, any of which might be >> broken by changing the behavior of goto-line > > Grep counts 8 such calls only. Doesn't seem unmanageable at all. > >> * Accordingly, I suggest introducing a new function, goto-numbered-line, >> which will replace the binding of {esc}g and the edit menu option. > > goto-line is already marked as "should only be called from Elisp", so > introducing goto-numbered-line doesn't sound right. => "should not be called from Elisp"? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-07 1:41 ` Lennart Borgman @ 2010-06-07 13:45 ` Stefan Monnier 2010-06-09 2:20 ` Mark Lillibridge 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2010-06-07 13:45 UTC (permalink / raw) To: Lennart Borgman; +Cc: lekktu, eliz, mark.lillibridge, emacs-devel >> goto-line is already marked as "should only be called from Elisp", so >> introducing goto-numbered-line doesn't sound right. > => "should not be called from Elisp"? Oops, thanks, Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-07 13:45 ` Stefan Monnier @ 2010-06-09 2:20 ` Mark Lillibridge 2010-06-09 3:44 ` Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-06-09 2:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, eliz, lennart.borgman, emacs-devel > >> goto-line is already marked as "should only be called from Elisp", so > >> introducing goto-numbered-line doesn't sound right. > > => "should not be called from Elisp"? > > Oops, thanks, > > Stefan That's funny; the documentation for goto-line specifically talks about its behavior when called from elisp! M-g (translated from <escape> g) runs the command goto-line, which is an interactive compiled Lisp function in `simple.el'. It is bound to M-g, <menu-bar> <edit> <goto> <go-to-line>. (goto-line line &optional buffer) Goto line, counting from line 1 at beginning of buffer. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. When called from Lisp code, the optional argument buffer specifies a buffer to switch to. If there's a number in the buffer at point, it is the default for line. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-09 2:20 ` Mark Lillibridge @ 2010-06-09 3:44 ` Miles Bader 0 siblings, 0 replies; 56+ messages in thread From: Miles Bader @ 2010-06-09 3:44 UTC (permalink / raw) To: mark.lillibridge Cc: lekktu, eliz, lennart.borgman, Stefan Monnier, emacs-devel Mark Lillibridge <mark.lillibridge@hp.com> writes: >> > => "should not be called from Elisp"? >> >> Oops, thanks, > > That's funny; the documentation for goto-line specifically talks about > its behavior when called from elisp! Well of course you _can_ call it from elisp, but still, many commands can be thought of as being "user-oriented". These are discouraged from being used in elisp because they have things like side-effects and more complicated DWIMy behavior that can be undesirable for programming. However, occasionally, you want to call such commands anyway (e.g., when you're writing a wrapper for them). -Miles -- Politics, n. A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-07 1:30 ` Stefan Monnier 2010-06-07 1:41 ` Lennart Borgman @ 2010-06-09 2:19 ` Mark Lillibridge 2010-06-09 6:37 ` Glenn Morris 1 sibling, 1 reply; 56+ messages in thread From: Mark Lillibridge @ 2010-06-09 2:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, eliz, emacs-devel > > * {esc}g currently calls goto-line, but a grep through the elisp sources > > of Emacs shows a lots of calls to goto-line, any of which might be > > broken by changing the behavior of goto-line > > Grep counts 8 such calls only. Doesn't seem unmanageable at all. I think you missed some: ts-rhel4 [58]% pwd /nfs/pm-data1/mnt/d4/home/mdl/bin/emacs-23.1/lisp ts-rhel4 [59]% find . -name \*.el -exec grep '(goto-line' {} \; -print (goto-line line)) ./bs.el (goto-line line) (goto-line (1+ line))) ./cus-edit.el (goto-line (string-to-number line)) ./diff-mode.el (goto-line line) (goto-line 1) (goto-line line) ./org/org-agenda.el (goto-line (car x)) (goto-line line) (goto-line (car x)) ./org/org-colview.el (goto-line (1+ skip1)) ./org/org-exp.el (goto-line line) (goto-line line) ./org/org-list.el (goto-line _line) ./org/org-macs.el (goto-line winstartline) (goto-line linepos) (goto-line linepos) (goto-line linepos) (goto-line linepos) (goto-line thisline) (goto-line l1) (goto-line line) (goto-line cline) (goto-line last-dline) (if l1 (goto-line l1)) (goto-line l1) (goto-line l1))) (goto-line l) (goto-line r1) (goto-line r1) (goto-line r2) (goto-line (nth 1 a)) (goto-line org-last-recalc-line) (goto-line (nth 1 eq)) (goto-line thisline) (goto-line thisline) (goto-line startline) (goto-line line))) (goto-line (nth 1 e)) (goto-line (aref org-table-dlines l)) (goto-line (nth 1 e)) (goto-line l1) ./org/org-table.el (goto-line line) (goto-line line) (goto-line line)) (goto-line line) (if line (goto-line line) (goto-line l) (goto-line 3) ./org/org.el (goto-line line))) ./ibuffer.el (goto-line (cvs-find-modif fi))) ./pcvs.el (goto-line (car line-col)) ./server.el (goto-line line)) (goto-line line)) ./startup.el (goto-line (+ 16 i y)) (goto-line (+ 17 y)) ./strokes.el (goto-line line) ./term.el (goto-line ,current-line) ./vc-annotate.el (goto-line (pop insn)) (goto-line (pop insn)) ./vc-rcs.el ;; (if line (goto-line (prefix-numeric-value line)) (goto-line line) ./view.el (goto-line 3)) ; first error message (goto-line 3)) ; first error message ./textmodes/bibtex.el (goto-line top) (goto-line sl) ./textmodes/picture.el (goto-line 3) ./textmodes/reftex-index.el (goto-line loc) (goto-line reftex-last-line)) ./textmodes/reftex-sel.el (goto-line 3) (progn (goto-line mark-line) (if point-line (goto-line point-line)) ./textmodes/reftex-toc.el (goto-line line) (goto-line (car deco)) (goto-line (car deco)) (goto-line (car deco)) (goto-line line) (goto-line (car cur)) ./textmodes/rst.el (progn (goto-line linenum) (setq last-position nil)) ./textmodes/tex-mode.el (newline (goto-line line)) ./textmodes/two-column.el (goto-line (if (consp ns-input-line) (goto-line (if (consp ns-input-line) (goto-line (+ 1 (if (consp ns-input-line) ./term/ns-win.el (goto-line (string-to-number line))) ./progmodes/ada-mode.el (goto-line (caar declist))) (goto-line (car (nth (1- choice) declist))) (goto-line line) ./progmodes/ada-xref.el `(goto-line (string-to-int (elt ,elt 1)))) (goto-line l) ./progmodes/cperl-mode.el (goto-line old-line))) (goto-line n) ./progmodes/ebrowse.el (cond (line (goto-line line)) (setq startpos (progn (goto-line line) ./progmodes/etags.el (goto-line line-no) (goto-line line))) (goto-line line-no) ./progmodes/flymake.el (goto-line (line-number-at-pos (posn-point end))) (goto-line (line-number-at-pos (posn-point end))) (goto-line (string-to-number line)) (goto-line (string-to-number line)) (goto-line (string-to-number line)) ./progmodes/gdb-ui.el (goto-line line) ./progmodes/gud.el (goto-line (nth 1 frame))))) (goto-line (nth 1 frame)) (goto-line bp-line))) ./progmodes/idlw-shell.el (goto-line this-line) (goto-line 1) ./progmodes/make-mode.el (goto-line line)))) (goto-line target_lineno) ./progmodes/python.el (goto-line (string-to-number line)) ./progmodes/verilog-mode.el (goto-line (cdr token)) (progn (goto-line (cdr token)) (progn (goto-line (nth 3 (car ent-alist))) ./progmodes/vhdl-mode.el (goto-line (+ (* 5x5-y-pos 5x5-y-scale) 2)) ./play/5x5.el (goto-line 4) ./play/decipher.el (goto-line (1+ gamegrid-score-file-length)) ./play/gamegrid.el (goto-line (+ 1 gomoku-y-offset (* gomoku-square-height (1- y))))) ./play/gomoku.el (goto-line (+ 1 lm-y-offset (* lm-square-height (1- y))))) ./play/landmark.el (goto-line 3) (goto-line 7) (goto-line (car square)) ; line before column! ./play/mpuz.el (narrow-to-region (point-min) (progn (goto-line (point-min)) ./obsolete/rnewspost.el (goto-line (vi-prefix-numeric-value arg)))) ./emulation/vi.el (goto-line calendar-first-date-row) (goto-line (+ calendar-first-date-row ./calendar/cal-move.el (goto-line (string-to-number line)))) ./gnus/gnus-art.el (goto-line min-line) ./gnus/gnus-salt.el (goto-line calc-final-point-line) (goto-line calc-final-point-line) (goto-line 2) ./calc/calc.el - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-09 2:19 ` Mark Lillibridge @ 2010-06-09 6:37 ` Glenn Morris 2010-06-24 2:24 ` Mark Lillibridge 0 siblings, 1 reply; 56+ messages in thread From: Glenn Morris @ 2010-06-09 6:37 UTC (permalink / raw) To: mark.lillibridge; +Cc: lekktu, eliz, Stefan Monnier, emacs-devel Mark Lillibridge wrote: >> Grep counts 8 such calls only. Doesn't seem unmanageable at all. > > I think you missed some: > > ts-rhel4 [58]% pwd > /nfs/pm-data1/mnt/d4/home/mdl/bin/emacs-23.1/lisp You should check the trunk (or even Emacs 23.2), where the documentation and usage of goto-line is different to that in 23.1. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Emacs's handling of line numbers [from bug#5042] 2010-06-09 6:37 ` Glenn Morris @ 2010-06-24 2:24 ` Mark Lillibridge 0 siblings, 0 replies; 56+ messages in thread From: Mark Lillibridge @ 2010-06-24 2:24 UTC (permalink / raw) To: Glenn Morris; +Cc: lekktu, eliz, monnier, emacs-devel Glenn wrote: > Mark Lillibridge wrote: > > >> Grep counts 8 such calls only. Doesn't seem unmanageable at all. > > > > I think you missed some: > > > > ts-rhel4 [58]% pwd > > /nfs/pm-data1/mnt/d4/home/mdl/bin/emacs-23.1/lisp > > You should check the trunk (or even Emacs 23.2), where the > documentation and usage of goto-line is different to that in 23.1. Finally got a chance to do that; you are correct: GNU Emacs 24.0.50.1 (i386-mingw-nt6.0.6002) of 2010-06-23 on LENNART-69DE564 goto-line is an interactive compiled Lisp function in `simple.el'. It is bound to M-g, <menu-bar> <edit> <goto> <go-to-line>. (goto-line LINE &optional BUFFER) Goto LINE, counting from line 1 at beginning of buffer. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. If there's a number in the buffer at point, it is the default for LINE. This function is usually the wrong thing to use in a Lisp program. What you probably want instead is something like: (goto-char (point-min)) (forward-line (1- N)) If at all possible, an even better solution is to use char counts rather than line counts. Mark@MDL2 /cygdrive/c/Program Files (x86)/Emacs_24/emacs/lisp $ find . -name \*.el -exec grep '(goto-line' {} \; -print (with-no-warnings (goto-line line)) ./cedet/semantic/symref/list.el ;; (goto-line line) ./cedet/semantic/symref.el (with-no-warnings (goto-line (vi-prefix-numeric-value arg))))) ./emulation/vi.el `(goto-line (string-to-int (elt ,elt 1)))) ./progmodes/cperl-mode.el (goto-line ,current-line) ./vc/vc-annotate.el ;; (if line (goto-line (prefix-numeric-value line)) ./view.el So, am I hearing that we should change goto-line to the following functionality: goto-line is an interactive compiled Lisp function in `simple.el'. It is bound to M-g, <menu-bar> <edit> <goto> <go-to-line>. (goto-line LINE &optional BUFFER) | Goto line with line number LINE; use linum mode to see what line | numbers each line is assigned. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. If there's a number in the buffer at point, it is the default for LINE. This function is usually the wrong thing to use in a Lisp program. What you probably want instead is something like: (goto-char (point-min)) (forward-line (1- N)) If at all possible, an even better solution is to use char counts rather than line counts. Amusingly, the core of the first implementation would be the elisp above: (goto-char (point-min)) (forward-line (1- N)) which is *not* what goto-line actually does! (It does a widen, which this change would remove.) - Mark ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2010-06-24 2:24 UTC | newest] Thread overview: 56+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-02-15 18:47 Emacs's handling of line numbers [from bug#5042] Mark Lillibridge [not found] ` <jwvd4068dsr.fsf-monnier+emacs@gnu.org> 2010-04-11 22:22 ` Mark Lillibridge 2010-04-12 2:27 ` Stefan Monnier 2010-04-17 1:57 ` Mark Lillibridge 2010-04-17 7:29 ` Eli Zaretskii 2010-04-17 14:45 ` Stefan Monnier 2010-04-17 15:57 ` Eli Zaretskii 2010-04-17 19:51 ` Mark Lillibridge 2010-04-17 21:04 ` Eli Zaretskii 2010-04-17 21:17 ` Juanma Barranquero 2010-04-17 21:31 ` Drew Adams 2010-04-18 18:15 ` widen-one-level [was: Emacs's handling of line numbers] Drew Adams 2010-04-18 21:31 ` Juri Linkov 2010-04-19 0:25 ` Drew Adams 2010-04-18 23:30 ` Davis Herring 2010-04-19 19:57 ` Richard Stallman 2010-04-19 20:22 ` Drew Adams 2010-04-19 22:52 ` Juri Linkov 2010-04-19 1:56 ` Leo 2010-04-19 2:04 ` Drew Adams 2010-04-19 11:34 ` Leo 2010-04-19 16:31 ` Drew Adams 2010-04-19 17:57 ` Leo 2010-04-19 22:56 ` Drew Adams 2010-04-22 9:59 ` Leo 2010-04-18 3:12 ` Emacs's handling of line numbers [from bug#5042] Eli Zaretskii 2010-04-18 3:49 ` Juanma Barranquero 2010-04-18 8:05 ` Juri Linkov 2010-04-18 13:44 ` Drew Adams 2010-04-18 13:50 ` Lennart Borgman 2010-04-18 16:40 ` Drew Adams 2010-04-18 14:03 ` Juanma Barranquero 2010-04-18 14:14 ` David Kastrup 2010-04-18 16:41 ` Drew Adams 2010-04-18 17:03 ` Juanma Barranquero 2010-04-18 21:29 ` Juri Linkov 2010-04-18 13:45 ` Drew Adams 2010-04-18 17:29 ` Eli Zaretskii 2010-04-18 17:52 ` Juanma Barranquero 2010-04-18 17:56 ` Eli Zaretskii 2010-04-18 17:00 ` Mark Lillibridge 2010-04-18 17:38 ` Eli Zaretskii 2010-04-18 18:11 ` Lennart Borgman 2010-04-22 2:17 ` Mark Lillibridge 2010-04-22 8:06 ` David Kastrup 2010-04-22 8:38 ` Juri Linkov 2010-04-22 8:45 ` Juanma Barranquero 2010-06-06 18:18 ` Mark Lillibridge 2010-06-07 1:30 ` Stefan Monnier 2010-06-07 1:41 ` Lennart Borgman 2010-06-07 13:45 ` Stefan Monnier 2010-06-09 2:20 ` Mark Lillibridge 2010-06-09 3:44 ` Miles Bader 2010-06-09 2:19 ` Mark Lillibridge 2010-06-09 6:37 ` Glenn Morris 2010-06-24 2:24 ` Mark Lillibridge
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.