Emacs's handling of line numbers [from bug#5042]

Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

[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

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

[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

Re: Emacs's handling of line numbers [from bug#5042]

[Stefan Monnier]

> 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

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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

Re: Emacs's handling of line numbers [from bug#5042]

[Stefan Monnier]

> 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

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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?

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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?

Re: Emacs's handling of line numbers [from bug#5042]

[Juanma Barranquero]

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

RE: Emacs's handling of line numbers [from bug#5042]

[Drew Adams]

> 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.

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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?

Re: Emacs's handling of line numbers [from bug#5042]

[Juanma Barranquero]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Juri Linkov]

> 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/

RE: Emacs's handling of line numbers [from bug#5042]

[Drew Adams]

> > 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).

RE: Emacs's handling of line numbers [from bug#5042]

[Drew Adams]

> 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.)

Re: Emacs's handling of line numbers [from bug#5042]

[Lennart Borgman]

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?

Re: Emacs's handling of line numbers [from bug#5042]

[Juanma Barranquero]

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

Re: Emacs's handling of line numbers [from bug#5042]

[David Kastrup]

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

RE: Emacs's handling of line numbers [from bug#5042]

[Drew Adams]

> >> > 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.)

RE: Emacs's handling of line numbers [from bug#5042]

[Drew Adams]

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.

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Juanma Barranquero]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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.)

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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.

Re: Emacs's handling of line numbers [from bug#5042]

[Juanma Barranquero]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Eli Zaretskii]

> 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.

Re: Emacs's handling of line numbers [from bug#5042]

[Lennart Borgman]

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.

widen-one-level [was: Emacs's handling of line numbers]

[Drew Adams]

> 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...

Re: Emacs's handling of line numbers [from bug#5042]

[Juri Linkov]

>> 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/

Re: widen-one-level [was: Emacs's handling of line numbers]

[Juri Linkov]

> 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/

Re: widen-one-level [was: Emacs's handling of line numbers]

[Davis Herring]

>   (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.

RE: widen-one-level [was: Emacs's handling of line numbers]

[Drew Adams]

> > 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)

Re: widen-one-level [was: Emacs's handling of line numbers]

[Leo]

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

RE: widen-one-level [was: Emacs's handling of line numbers]

[Drew Adams]

 

> > (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.

Re: widen-one-level [was: Emacs's handling of line numbers]

[Leo]

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

RE: widen-one-level [was: Emacs's handling of line numbers]

[Drew Adams]

> > > (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.

Re: widen-one-level [was: Emacs's handling of line numbers]

[Leo]

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

Re: widen-one-level [was: Emacs's handling of line numbers]

[Richard Stallman]

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.

RE: widen-one-level [was: Emacs's handling of line numbers]

[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.

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'.

Re: widen-one-level [was: Emacs's handling of line numbers]

[Juri Linkov]

> 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/

RE: widen-one-level [was: Emacs's handling of line numbers]

[Drew Adams]

> 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.

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

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

Re: Emacs's handling of line numbers [from bug#5042]

[David Kastrup]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Juri Linkov]

> 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/

Re: Emacs's handling of line numbers [from bug#5042]

[Juanma Barranquero]

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

Re: widen-one-level [was: Emacs's handling of line numbers]

[Leo]

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

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

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.

Re: Emacs's handling of line numbers [from bug#5042]

[Stefan Monnier]

> * {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

Re: Emacs's handling of line numbers [from bug#5042]

[Lennart Borgman]

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"?

Re: Emacs's handling of line numbers [from bug#5042]

[Stefan Monnier]

>> 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

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

>  > * {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

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

>  >> 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.

Re: Emacs's handling of line numbers [from bug#5042]

[Miles Bader]

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.

Re: Emacs's handling of line numbers [from bug#5042]

[Glenn Morris]

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.

Re: Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

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