This is an alternative to setnu.el. It works incrementally and can
number large files fast. As it redraws all visible line numbers after
each command, it can also recover from potential layout glitches.

;;; linum.el --- Display line numbers to the left of buffers

;; Copyright (C) 2007  Markus Triska

;; Author: Markus Triska <markus.tri...@gmx.at>
;; Keywords: convenience

;; This file is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; This file is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:

;; Display line numbers for the current buffer. Copy linum.el to your
;; load-path and add to your .emacs:

;;    (require 'linum)

;; Then toggle display of line numbers with M-x linum.

;;; Code:

(defconst linum-version "0.8f")

(defvar linum-overlays nil)
(defvar linum-active nil)
(defvar linum-overlay-property (if (fboundp 'extent-property)
                                   'begin-glyph 'before-string))

(defgroup linum nil
  "Show line numbers to the left of buffers"
  :group 'convenience)

;;;###autoload
(defcustom linum-format "%6d  "
  "Format used to display line numbers. Either a format string like \"%6d  \",
or the symbol 'dynamic to adapt the width as needed. 'dynamic or
a format string that does not expand to a multiple of 8 can make
indentations look different if you indent using tab characters."
  :group 'linum
  :type 'sexp)

(when (< emacs-major-version 21)
    (require 'cl))

(when (fboundp 'make-extent)
  (fset 'make-overlay 'make-extent)
  (fset 'overlay-put 'set-extent-property)
  (fset 'overlay-get 'extent-property)
  (fset 'delete-overlay 'delete-extent)
  (fset 'move-overlay 'set-extent-endpoints)
  (fset 'overlays-in (lambda (from to)
                       (if (fboundp 'extent-list) ; suppress warning
                           (extent-list nil from to))))
  (fset 'overlay-start 'extent-start-position))

(mapc #'make-variable-buffer-local '(linum-overlays linum-active))

(unless (fboundp 'line-number-at-pos)
  (defun line-number-at-pos (&optional pos)
    "Compatibility definition for Emacs < 22, taken from CVS."
    (let ((opoint (or pos (point))) start)
      (save-excursion
        (goto-char (point-min))
        (setq start (point))
        (goto-char opoint)
        (forward-line 0)
        (1+ (count-lines start (point)))))))

;;;###autoload
(defun linum ()
  "Toggle display of line numbers."
  (interactive)
  (setq linum-active (not linum-active))
  (when (or (< emacs-major-version 21) (fboundp 'extent-property))
    (make-local-hook 'post-command-hook))
  (if linum-active
      (progn
        (add-hook 'post-command-hook 'linum-update nil t)
        (message "Linum enabled"))
    (remove-hook 'post-command-hook 'linum-update t)
    (mapc #'delete-overlay linum-overlays)
    (setq linum-overlays nil)
    (message "Linum disabled")))

(defun linum-dynamic-format ()
  "Compute a format string based on the number of lines in the
current buffer."
  (let ((lines (count-lines (point-min) (point-max)))
        (width 0))
    (while (> lines 0)
      (setq lines (/ lines 10))
      (setq width (1+ width)))
    (format "%%%dd  " width)))

(defun linum-update ()
  "Update displayed line numbers for the current buffer."
  (save-excursion
    (goto-char (window-start))
    (let ((line (line-number-at-pos))
          (limit (window-end nil t))
          (fmt (if (stringp linum-format) linum-format (linum-dynamic-format)))
          ov
          free)
      (unless (fboundp 'extent-property)
        (setq limit (1+ limit)))
      (dolist (ov (overlays-in (point) limit))
        (when (overlay-get ov 'linum)
          (push ov free)))
      ;; Create an overlay (or reuse an existing one) for each visible
      ;; line in this window.
      (while (and (not (eobp)) (< (point) limit))
        (if (null free)
            (progn
              (setq ov (make-overlay (point) (point)))
              (overlay-put ov 'linum t)
              (push ov linum-overlays))
          (setq ov (pop free))
          (move-overlay ov (point) (point)))
        (overlay-put ov linum-overlay-property
                     (funcall (if (fboundp 'extent-property)
                                'make-glyph 'identity) (format fmt line)))
        (forward-line)
        (setq line (1+ line)))
      (mapc #'delete-overlay free))))

;;;###autoload
(defun linum-version ()
  "Display version of linum."
  (interactive)
  (message "Using linum version %s" linum-version))

(provide 'linum)
;;; linum.el ends here

On 2007-03-24, Markus Triska said:

Compiler warning:
,----
| In linum:
| linum.el:87:6:Warning: `make-local-hook' is an obsolete function (as of Emacs
|     21.1); not necessary any more.
| Wrote /dev/shm/linum.elc
`----

Regards,
--
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Yes. The use of such obsolete functions enables libraries to work with older
versions of Emacs, as well as the latest version.

linum.el is a good library, and there is no reason to deprive Emacs 20 users
(and there are many) from using it. I hope Markus will continue to keep
linum.el version-agnostic as long as that doesn't sacrifice functionality.

Sometimes, a newer Emacs version offers features that are difficult to
reproduce in older versions. If a library depends on such a feature, then
there is no reason for it not to also use other new features. But, if other
things are equal, why not make the library available to more users, by
foregoing new features that are not really needed and exploited as such?

It's good that the byte-compiler makes us aware of obsolete functions and so
on, but that doesn't mean that we should always replace them by what is
currently recommended - it depends on the context and the need.

On 2007-03-24, Drew Adams said:

Another way of looking at it is that it will get more users to use the
newer versions of emacs and help with the development and testing. I
see no reason not to do that.

--
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

I agree.

Possible improvements:
- Put the line number in the left display margin.
- Use a smaller font for the line numbers.

Making such improvements would be much easier if the package
was targeted for GNU Emacs 22.

--
Kim F. Storm  http://www.cua.dk

no-s...@cua.dk (Kim F. Storm) writes:

Here is such a version:

;;; linum.el --- Display line numbers to the left of buffers

;; Copyright (C) 2007  Markus Triska

;; Author: Markus Triska <markus.tri...@gmx.at>
;; Keywords: convenience

;; This file is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; This file is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:

;; Display line numbers for the current buffer. Copy linum.el to your
;; load-path and add to your .emacs:

;;    (require 'linum)

;; Then toggle display of line numbers with M-x linum.

;;; Code:

(defconst linum-version "0.8f-emacs22")

(defvar linum-overlays nil)
(defvar linum-active nil)

(defgroup linum nil
  "Show line numbers to the left of buffers"
  :group 'convenience)

;;;###autoload
(defcustom linum-format "%6d  "
  "Format used to display line numbers. Either a format string like \"%6d  \",
or the symbol 'dynamic to adapt the width as needed. 'dynamic or
a format string that does not expand to a multiple of 8 can make
indentations look different if you indent using tab characters."
  :group 'linum
  :type 'sexp)

(mapc #'make-variable-buffer-local '(linum-overlays linum-active))

;;;###autoload
(defun linum ()
  "Toggle display of line numbers."
  (interactive)
  (setq linum-active (not linum-active))
  (if linum-active
      (progn
        (add-hook 'post-command-hook 'linum-update nil t)
        (message "Linum enabled"))
    (remove-hook 'post-command-hook 'linum-update t)
    (mapc #'delete-overlay linum-overlays)
    (setq linum-overlays nil)
    (message "Linum disabled")))

(defun linum-dynamic-format ()
  "Compute a format string based on the number of lines in the
current buffer."
  (let ((lines (count-lines (point-min) (point-max)))
        (width 0))
    (while (> lines 0)
      (setq lines (/ lines 10))
      (setq width (1+ width)))
    (format "%%%dd  " width)))

(defun linum-update ()
  "Update displayed line numbers for the current buffer."
  (save-excursion
    (goto-char (window-start))
    (let ((line (line-number-at-pos))
          (limit (1+ (window-end nil t)))
          (fmt (if (stringp linum-format) linum-format (linum-dynamic-format)))
          ov
          free)
      (dolist (ov (overlays-in (point) limit))
        (when (overlay-get ov 'linum)
          (push ov free)))
      ;; Create an overlay (or reuse an existing one) for each visible
      ;; line in this window.
      (while (and (not (eobp)) (< (point) limit))
        (if (null free)
            (progn
              (setq ov (make-overlay (point) (point)))
              (overlay-put ov 'linum t)
              (push ov linum-overlays))
          (setq ov (pop free))
          (move-overlay ov (point) (point)))
        (overlay-put ov 'before-string (format fmt line))
        (forward-line)
        (setq line (1+ line)))
      (mapc #'delete-overlay free))))

;;;###autoload
(defun linum-version ()
  "Display version of linum."
  (interactive)
  (message "Using linum version %s" linum-version))

(provide 'linum)
;;; linum.el ends here

Kim> Possible improvements:

The argument that you can do more with a newer Emacs release is an argument
I echoed. My point was that if you are *not* doing more, then it makes
little sense to gratuitously prevent users of older Emacs releases from
taking advantage of your library. The key phrase I used was "if other things
are equal". In this case, they are.

Leo> Another way of looking at it is that it will get more users to use the

A specious argument, IMO. Most people who use Emacs 20 have little choice;
it is mandated in their place of work or they have no way to install a later
version on a captive machine.

The obsolescence in question, as you pointed out, was introduced in release
*21.1* - many, many moon ago. Surely you don't suggest that we need to
encourage testing of that release? Not using `make-local-hook' is no special
support for Emacs 22, and it will in no way cause users to leave Emacs 21 to
test Emacs 22. Nothing is gained by losing Emacs 20 users of this library.

Show me a library that takes advantage of the truly new features of a new
release, and I'll likely agree that it should make no attempt to be backward
compatible - in fact I already said that.

And there are degrees of backward compatibility. Some library authors make
an attempt to at least allow some use by older Emacs releases, even as they
provide some features that can only be taken advantage of in recent
releases.

The Emacs user community is not synonymous with the Emacs developers. Emacs
developers such as Kim are primarily concerned with the latest and greatest
stuff they are developing - they don't often look back. Writers of libraries
that are not part of the Emacs distribution are often more concerned about
compatibility for users of different releases and even different flavors of
Emacs (e.g. XEmacs).

If Markus's library will become part of GNU Emacs someday (and I hope it
does), then it will in any case undergo a face lift at that time, to make
sure that it follows all recommended conventions. As long as it is not part
of the Emacs distribution, I'd recommend not locking out users gratuitously,
that is, when there is no real gain.

    Leo> Another way of looking at it is that it will get more users to use the
    >> newer versions of emacs and help with the development and testing. I see
    >> no reason not to do that.

    Drew> A specious argument, IMO. Most people who use Emacs 20 have little
    Drew> choice; it is mandated in their place of work or they have no way to
    Drew> install a later version on a captive machine.

So is it really true that we have no consensus about this question?

Forcing updates on users---who may not even be in a position to do so even if
they want---because of political instead of technical reasons?

Maybe one missing hour of sleep is making me aggressive but this sounds too Big
Bill at best and fascist at worst.

Toto

PS: In order to talk about linum.el again: Looks nice but makes scrolling nearly
    impossible on my box...

--
Contact information and PGP key at
http://www-users.rwth-aachen.de/thorsten.bonow

Germany 0 : Orwell 1984

Hi,

please let's move _discussions_ about packages posted to
gnu-emacs-sources/gnu.emacs.sources to help-gnu-emacs/gnu.emacs.help

gnu-emacs-sources is intended only for code and patches...

| List-Id: GNU Emacs source code postings and patches <gnu-emacs-sources.gnu.org>

I'd suggest to add...
| Followup-To: gnu.emacs.help
and/or
| Mail-Followup-To: help-gnu-em...@gnu.org
headers (and a note in the body[1]), ideally in the original source
posting or at least when following up.

It's easy to miss sources if they are buried deep in a discussion like
Markus' updated version (in article <87ps6ytc80....@gmx.at>).

Bye, Reiner.

[1] The fact that the lists/newsgroups are gated makes it harder to
    do this only on a technical basis.

Crosspost & Followup-To: gnu.emacs.help
--
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

I don't like this convention.  The name "gnu.emacs.help" does not
particularly suggest to me that discussion for posts to
gnu.emacs.sources should be followed up there -- that is, I have no
certainty that program authors who post to .sources are also
subscribed to .help, and little hope that they can find replies to
their code submissions in .help, due to the relatively high volume of
that group.

Also, even if I am totally mistaken about my other assertions, I think
if replies to posts in .sources include new/revised source code, it is
disingenuous to tell people to send them to a different list.

If we must insist on different destinations for source and comments,
how about a separate, low-volume list (measured relative to
gnu.emacs.help) called gnu.emacs.sources.discuss?

--
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

My understanding is that this group/list is for sources rather than discussion.
However, I think patches are probably OK, though its probably better to send
them directly to the author to prevent multiple patches for similar
bugs/features and leave it to the author to apply.

What I think definitely needs to be avoided is long threads debating particular
issues relating to a package, especially if that discussion moves away from
specific code issues to more philosophical ones. Part of the reason I have this
perspective is that a number of places I know of archive the contents of this
list and it can be a handy resource to find code. If it ends up with lots of
discussion posts and the ratio of code to posts drops, it would lose part of
this stremgth.

I don't think another list is a good idea. Discussion of package/code issues
could be done in g.e.h and in fact would possibly be a benefit there. Another
list would just dilute things further.

Of course, just my 2 cents worth. If the general consensus is different, I have
no problem with following that.

Tim

--
tcross (at) rapttech dot com dot au

That's true.  

I first wrote ido and cua for Emacs 20 and 21, and those versions are still
available and useful for users of those versions.  

However, my time only allows me to keep those packages updated for Emacs 22,
so if you want the latest and greatest versions of the packages I maintain,
you have to upgrade your Emacs too.

And there are no up-to-date XEmacs versions either, because I have
neither the time, nor the interest to provide them.

They might be concerned, yes, but I don't think anyone can dictate
that a package author mustkeep their code backwards compatible -- even
when it _is_ possible.

If the package author want to do so, it is ok, but for the specific
case of linum.el, alternative packages already exist which works ok
with older Emacsen, so why look back, rather than look forwards, and
provide some _new_ features for the latest and greatest Emacs?

--
Kim F. Storm  http://www.cua.dk

I certainly didn't mean to dictate any such thing to anyone.

Thanks!

As you say, it's up to the package writer. I'd say that what Markus did in
the latest version was what I would suggest, if a writer has the time and
the will: make the library useful with various versions, but let it take
advantage of recent features for recent versions.

It takes a little more work (sometimes a lot more work) to do that, but I,
for one, appreciate it. And, as I said before, for some libraries it makes
little sense to try to be backward compatible. I think linum.el might become
the general replacement for setnu.el and other packages, for old Emacs
versions as well as for new ones.

You are right that linum.el could take advantage of even more Emacs 22
features. And you (and Leo) are right that that would help test Emacs 22 and
would help us discover new things we can do with the new features. That
doesn't preclude making the basic functionality available also to users of
older Emacs versions - provided that Markus has the time and will to do
that.