goto-line trouble with narrowing

goto-line trouble with narrowing

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Thu, 2006 Jan 26  16:05 UTC
GNU Emacs 22.0.50.15 (i686-pc-linux-gnu, GTK+ Version 2.8.10) 
started with

     /usr/local/src/emacs/src/emacs -Q -D

In a narrowed region, `goto-line' goes to the widened buffer line (but
not outside the narrowed region) even though the Mode Line tells you
the narrowed line number.

For example, when the Mode Line shows L228,  and `what-line' says

    line 431 (narrowed line 228)

then `M-g M-g 228' (goto-line 228 nil) takes you to what is shown in
the Mode Line as L25.

However, in the same buffer widened, `M-g M-g 228' takes you to what
is shown in the Mode Line as L228

The defun for `goto-line' in emacs/lisp/simple.el specifically calls

    (widen)

on the buffer before moving to the specified line number.  I don't
know whether this is intended.

If it is intended, the documentation should be modified in
(emacs)Optional Mode Line

If not, the `widen' should be removed from the defun for `goto-line'.
As far as I can determine, this action is safe.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: goto-line trouble with narrowing

[Richard M. Stallman]

    The defun for `goto-line' in emacs/lisp/simple.el specifically calls

	(widen)

    on the buffer before moving to the specified line number.  I don't
    know whether this is intended.

That line wasn't written by accident!

The most common use of goto-line is to go to a line number
that you got from some other program.  That program normally
operates on the whole file.  For goto-line to use a narrowed
line number would hardly ever be useful.

    If it is intended, the documentation should be modified in
    (emacs)Optional Mode Line

I don't see anything about goto-line in that node.
The text looks correct to me.

Re: goto-line trouble with narrowing

[Robert J. Chassell]

        The defun for `goto-line' in emacs/lisp/simple.el specifically calls
            (widen) ...

    That line wasn't written by accident!

    The most common use of goto-line is to go to a line number that
    you got from some other program.  That program normally operates
    on the whole file.

That is a good argument.

In  @node Optional Mode Line   in   emacs/man/display.texi
after the sentence that says,

      If you have narrowed the buffer (@pxref{Narrowing}), the size of the
    accessible part of the buffer is shown.

I recommend adding two sentences such as the following:

    Since the current line number function counts only in the
    accessible part of the buffer, it may not provide useful
    information for a command that moves dot to a line counted from
    the non-narrowed beginning, such as @code{goto-line}.  (The
    @code{what-line} command provides both counts.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: goto-line trouble with narrowing

[Richard M. Stallman]

	Since the current line number function counts only in the
	accessible part of the buffer, it may not provide useful
	information for a command that moves dot to a line counted from
	the non-narrowed beginning, such as @code{goto-line}.  (The
	@code{what-line} command provides both counts.)

Thanks.

Re: goto-line trouble with narrowing

[Kevin Rodgers]

Richard M. Stallman wrote:
>     The defun for `goto-line' in emacs/lisp/simple.el specifically calls
> 
> 	(widen)
> 
>     on the buffer before moving to the specified line number.  I don't
>     know whether this is intended.
> 
> That line wasn't written by accident!

Perhaps the doc string should be changed from:
"Goto line ARG, counting from line 1 at beginning of buffer."

to:
"Goto line ARG, counting from line 1 at beginning of widened buffer."

> The most common use of goto-line is to go to a line number
> that you got from some other program.  That program normally
> operates on the whole file.  For goto-line to use a narrowed
> line number would hardly ever be useful.

I sometimes would like to be able to do that, as when working
in a narrowed buffer visiting a very large file that I pipe into
a shell command that reports line numbers (e.g. C-x h M-| grep -n foo).

goto-line already takes a prefix arg to mean a different buffer,
which is useful in the resulting *Shell Command Output* buffer, so I
guess I need to roll my own goto-line-in-narrowed-buffer command that
just omits the call to (widen).  :-(

-- 
Kevin Rodgers

Re: goto-line trouble with narrowing

[Kevin Rodgers]

 > goto-line already takes a prefix arg to mean a different buffer,
 > which is useful in the resulting *Shell Command Output* buffer, so I
 > guess I need to roll my own goto-line-in-narrowed-buffer command that
 > just omits the call to (widen).  :-(

OK, can anyone explain why this doesn't work:

(eval-when-compile
   (require 'cl-macs))                   ; flet

(defun goto-line-in-narrowed-buffer (&rest args)
   "Like `goto-line', but count from line 1 of the accessible part of 
the buffer."
   (interactive)
   (flet ((widen () t))
     (if (interactive-p)
         (let ((prefix-arg  current-prefix-arg))
           (call-interactively 'goto-line))
       (apply 'goto-line args))))

Thanks,
-- 
Kevin Rodgers

Re: goto-line trouble with narrowing

[Johan Bockgård]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> OK, can anyone explain why this doesn't work:
>
> (eval-when-compile
>   (require 'cl-macs))                   ; flet
>
> (defun goto-line-in-narrowed-buffer (&rest args)
>   "Like `goto-line', but count from line 1 of the accessible part of
> the buffer."
>   (interactive)
>   (flet ((widen () t))
>     (if (interactive-p)
>         (let ((prefix-arg  current-prefix-arg))
>           (call-interactively 'goto-line))
>       (apply 'goto-line args))))


(byte-compile (lambda () (widen)))  =>  #[nil "~\207" [] 1]

-- 
Johan Bockgård

Re: goto-line trouble with narrowing

[Lennart Borgman]

Kevin Rodgers wrote:
> goto-line already takes a prefix arg to mean a different buffer,
> which is useful in the resulting *Shell Command Output* buffer, so I
> guess I need to roll my own goto-line-in-narrowed-buffer command that
> just omits the call to (widen).  :-(
This would be quite useful in many situations I believe. One such 
situations is editing part of a buffer in another mode in a cloned 
buffer narrowed to this part (multi-mode.el does this I think).

Why not include both variants in Emacs?

Re: goto-line trouble with narrowing

[Richard M. Stallman]

    Why not include both variants in Emacs?

It isn't worth the cost in added complexity.

Re: goto-line trouble with narrowing

[Kevin Rodgers]

Johan Bockgård wrote:
> Kevin Rodgers <ihs_4664@yahoo.com> writes:
>>OK, can anyone explain why this doesn't work:
>>
>>(eval-when-compile
>>  (require 'cl-macs))                   ; flet
>>
>>(defun goto-line-in-narrowed-buffer (&rest args)
>>  "Like `goto-line', but count from line 1 of the accessible part of
>>the buffer."
>>  (interactive)
>>  (flet ((widen () t))
>>    (if (interactive-p)
>>        (let ((prefix-arg  current-prefix-arg))
>>          (call-interactively 'goto-line))
>>      (apply 'goto-line args))))
> 
> (byte-compile (lambda () (widen)))  =>  #[nil "~\207" [] 1]

Thanks Johan, but you'll have to fill me in on a few details
since I can't read Emacs Lisp byte code.  Nor do I understand
why your example is relevant; isn't this what `flet' sets `widen's
symbol binding to:

(byte-compile (lambda () t)) => #[nil "\300\207" [t] 1]

-- 
Kevin Rodgers

Re: goto-line trouble with narrowing

[Johan Bockgård]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Johan Bockgård wrote:

>> (byte-compile (lambda () (widen)))  =>  #[nil "~\207" [] 1]
>
> Thanks Johan, but you'll have to fill me in on a few details since I
> can't read Emacs Lisp byte code.

No? Try disassemble :)

There is a special byte op-code for `widen' so the compiled function
call doesn't go through the symbol[1].

Compare it with this[2]:

    (byte-compile (lambda () (foo))) => #[nil "\300 \207" [foo] 1]

Note the `foo' here and the fact that `widen' isn't mentioned in the
right hand side above.

> Nor do I understand why your example is relevant; isn't this what
> `flet' sets `widen's symbol binding to:
>
> (byte-compile (lambda () t)) => #[nil "\300\207" [t] 1]

Indeed, but the symbol isn't involved.


[1] (disassemble #[nil "~\207" [] 1])
    byte code:
      args: nil
    0       widen     
    1       return    


[2] (disassemble #[nil "\300 \207" [foo] 1])
    byte code:
      args: nil
    0       constant  foo
    1       call      0
    2       return    


-- 
People do not write byte-code; that job is left to the byte compiler.
But we provide a disassembler to satisfy a cat-like curiosity. The
disassembler converts the byte-compiled code into humanly readable
form. -- (info "(elisp)Disassembly")