all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark Lillibridge <mark.lillibridge@hp.com>
To: lekktu@gmail.com
Cc: 5042@emacsbugs.donarmstrong.com, control@emacsbugs.donarmstrong.com
Subject: bug#5042: 23.1; linum-mode gives incorrect line numbers with  narrowed buffers
Date: Wed, 9 Dec 2009 21:34:28 -0800	[thread overview]
Message-ID: <200912100534.nBA5YSva008256@mailhub-pa1.hpl.hp.com> (raw)
In-Reply-To: <f7ccd24b0911301632n2418a309va8e70b0f4dceccf9@mail.gmail.com> (message from Juanma Barranquero on Tue, 1 Dec 2009 01:32:26 +0100)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]


>  On Thu, Nov 26, 2009 at 01:39, Mark Lillibridge <mark.lillibridge@hp.com> wrote:
>  
>  >    Linum-mode does not work correctly with buffers that have been
>  > narrowed.  As a simple example, type ^h i.  You will note that the first
>  > line is assigned line number one.  You can verify that this is wrong
>  > either by using goto-line
>  
>  Let's hear Markus' opinion, but IMHO that's not necessarily a bug.
>  Linum's function is to add line numbers, but these do not have to
>  correspond to buffer lines. For example, nothing stops you from doing
>  
>    (defvar my-num 1000)
>    (make-variable-buffer-local 'my-num)
>  
>    (setq linum-format (lambda (n) (format "%4d" (+ n my-num))))
>  
>  
>      Juanma

    The entire point of having line numbers is that they correspond to
something useful.  Either an external program's line number (e.g., a gcc
error number) or an internal Emacs notion such as that provided by
goto-line.  The current behavior does neither.

    Note that other line numbering modes like wb-line-number implement
the behavior that I describe as correct.

    I cannot see any useful circumstance where linum and goto-line
should disagree about what line number a given line has.  I can see an
argument that some buffers like RMAIL and info might want to start
numbering lines at one for the visible part of the buffer; I see this as
a possible feature request where say a buffer local variable specifies
this behavior.

    Note that that feature might be hard to implement correctly because
there is no hook for changing the buffer restriction visible to the
user.  That is, even if you believe that feature should be the
default/only behavior, the current code is still broken because changing
the restriction does not update the line numbers correctly.

- Mark






  reply	other threads:[~2009-12-10  5:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-26  0:39 bug#5042: 23.1; linum-mode gives incorrect line numbers with narrowed buffers Mark Lillibridge
2009-12-01  0:32 ` Juanma Barranquero
2009-12-10  5:34   ` Mark Lillibridge [this message]
2009-12-10 11:41     ` Juanma Barranquero
2009-12-21  6:59       ` Mark Lillibridge
2009-12-21 10:37         ` Juanma Barranquero
2009-12-21 15:50           ` Drew Adams
2009-12-23 20:49             ` Mark Lillibridge
2009-12-23 21:01               ` Drew Adams
2009-12-23 21:44                 ` Mark Lillibridge
2009-12-24  3:49             ` Stefan Monnier
2009-12-29  7:02               ` Kevin Rodgers
2010-01-07  5:38           ` Mark Lillibridge
2010-01-07 23:30             ` Markus Triska
2010-01-10  1:32               ` Mark Lillibridge
2010-01-10  1:56                 ` Juanma Barranquero
2010-01-16 22:08                   ` Mark Lillibridge
2010-01-16 23:03                     ` Juanma Barranquero
2010-01-23 23:28                       ` Mark Lillibridge
2010-01-24  0:07                         ` Drew Adams
2010-02-03  5:01                           ` Mark Lillibridge
2010-01-24  9:21                         ` Juanma Barranquero
2010-01-10  2:05                 ` Lennart Borgman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200912100534.nBA5YSva008256@mailhub-pa1.hpl.hp.com \
    --to=mark.lillibridge@hp.com \
    --cc=5042@emacsbugs.donarmstrong.com \
    --cc=control@emacsbugs.donarmstrong.com \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.