Emacs only displays current line number once I type something. How do I make it display it before like in vim?

I am used to seeing the current line number before typing in it as in vim. And this is very offputting.

Not an expert yet, but sounds like something with your configs, or some activated mode. Also, do you mean you don't see line number column at all until you start typing? Or are you seeing a number of the active line only? In latter case try switching to a different theme.

I think they mean that the line number for a hypothetical next line of the file (following the lines which actually exist) is not displayed until such time as the line comes into existence. The cursor is allowed to be at that position in order to create a new line; but if the final character in the buffer is a newline character then that's the "end of line" (rather than the beginning of a new one) and so there isn't actually any line *after* it, even when the cursor is in that position.

I am seeing line numbers of all the lines except the active line. Line number for the active line only appears when I type something into it. This happens with every theme, not just any one.

But vim shows line number for this. How can I make it similar to vim? Is there a setting I can use?

So, indeed, Emacs doesn't display a line number for an empty newline at the end of a file. The recommended way to do line numbers at the moment is a C package, which makes it more difficult to modify behaviour not exposed through Emacs Lisp. I'm sure there's a way, but I'd rather not recompile Emacs for it. The old line-numbering method is a built-in package called Linum. It had problems with big files but since you seem to be opening a lot of empty ones, I think it should manage just fine ;) Define this function after you've `require`'d the `linum` package in your config: (defun linum-update-window (win) "Update line numbers for the portion visible in window WIN." (goto-char (window-start win)) (let* ((line (line-number-at-pos)) (limit (window-end win t)) ;; set empty-line-at-eob flag (empty-line-at-eob (or (equal ?\n (char-before (point-max))) (equal (point-min) (point-max)))) ;; we will automatically number the line at eob if it's not empty ;; (so we'll say it's already done) (numbered-line-at-eob (not empty-line-at-eob)) (fmt (cond ((stringp linum-format) linum-format) ((eq linum-format 'dynamic) (let* ((c (count-lines (point-min) (point-max))) (w (length (number-to-string (+ c (if empty-line-at-eob 1 0)))))) (concat "%" (number-to-string w) "d"))))) (width 0)) (run-hooks 'linum-before-numbering-hook) ;; Create an overlay (or reuse an existing one) for each ;; line visible in this window, if necessary. ;; stop if point>limit, or if eobp and numbered-line-at-eob (while (and (not (and (eobp) numbered-line-at-eob)) (<= (point) limit)) (let* ((str (if fmt (propertize (format fmt line) 'face 'linum) (funcall linum-format line))) (visited (catch 'visited (dolist (o (overlays-in (point) (point))) (when (equal-including-properties (overlay-get o 'linum-str) str) (unless (memq o linum-overlays) (push o linum-overlays)) (setq linum-available (delq o linum-available)) (throw 'visited t)))))) (setq width (max width (length str))) (unless visited (let ((ov (if (null linum-available) (make-overlay (point) (point)) (move-overlay (pop linum-available) (point) (point))))) (push ov linum-overlays) (overlay-put ov 'before-string (propertize " " 'display `((margin left-margin) ,str))) (overlay-put ov 'linum-str str)))) ;; before moving forward, if we're already at eob (if (eobp) ;; then we've numbered the empty line (setq numbered-line-at-eob t)) ;; Text may contain those nasty intangible properties, but that ;; shouldn't prevent us from counting those lines. (let ((inhibit-point-motion-hooks t)) (forward-line)) (setq line (1+ line))) (when (display-graphic-p) (setq width (ceiling (/ (* width 1.0 (linum--face-width 'linum)) (frame-char-width))))) ;; open up space in the left margin, if needed, and record that ;; fact as the window-parameter `linum--set-margins' (let ((existing-margins (window-margins win))) (when (> width (or (car existing-margins) 0)) (set-window-margins win width (cdr existing-margins)) (set-window-parameter win 'linum--set-margins (window-margins win)))))) ***N.B.*** This isn't my modification, but one from the EmacsWiki ([https://www.emacswiki.org/emacs/LineNumbers#h5o-9](https://www.emacswiki.org/emacs/LineNumbers#h5o-9)). For the record, I'd recommend trying to get along with the 'standard' Emacs way if you can. Really it's only a small difference that you only ever notice before you've typed the first character, and the C version has some big quality-of-life improvements over Linum. (imo the behaviour is quite intuitive: by ad-hoc definition, text files on Unix-y systems end with a newline, so it makes some amount of sense to ignore this when editing)

> but since you seem to be opening a lot of empty ones, I think it should manage just fine made me LOL

I don't haver any (require linum) etc in my init.el. I just use global-display-line-numbers-mode and global-visual-line-mode.

`display-line-numbers-mode` does not appear to have any such option.

> I don't haver any (require linum) etc in my init.el. Imagine if you did, though.

Yes, so `display-line-numbers-mode` is the method implemented in C that I mentioned. You can check this by pressing `C-h v display-line-numbers` and seeing that the variable is defined in "*C source code*". Instead of using `(global-display-line-numbers-mode 1)` in your config, you'd want something like: (require 'linum) (defun linum-update-window (win) ; ... see the function in above answer ) (global-linum-mode 1) (But again, please do note the last parts of my answer.)

Oh wow, it works. Thank you so much. But I ran into two other issues doing this, sorry. 1. The linum mode lags, it doesn't update numbers immediately. It seems less smooth than the C function somehow. 2. I have huge functions like these copy-pasted into my init.el, which is making my init.el difficult to read. How do I put all these self defined functions in a separate file and link that file in init.el?

1. Linum is implemented in Emacs Lisp, the `display-line-numbers` is much faster as it's well-formed C code. 1. You might be able to add a smidge of performance by playing with the `gc-cons-*` variables, but I wouldn't bet on it. 2. If you're running a very recent version of Emacs (v28.1), then you could native-compile your Emacs packages, which can make them run faster. 2. There are many ways to organise code into multiple files, but the simplest way that I'd do this is using: &#8203; (load (locate-user-emacs-file "my-linum-config") nil 'nomessage nil 'must-suffix) Inside your Emacs configuration directory, you should create a file named `my-linum-config.el` and paste in the changes.

I am on version 28.1 yes, what is meant by native compiliing packages and how do I do that? I want to keep all my self defined functions in a seperate file called for eg. self-defined-functions.el. I can just put it in my .emacs.d folder and then write (require 'self-defined-functions.el) in my init.el. That should work, right?

> You might be able to add a smidge of performance by playing with the gc-cons-* variables, but I wouldn't bet on it. Best not to touch those -- there's a lot of extremely dubious advice floating around about them, and you could easily make things worse. The defaults are fine.

> 1. The linum mode lags, it doesn't update numbers immediately. It seems less smooth than the C function somehow. Yes, compiled C code will invariably be massively faster than interpreted lisp code. `display-line-numbers-mode` was written in order to provide line numbering with good performance, *because* linum is slow by comparison. This is the trade-off you're making if you're dead set on having that single extra number for a line that doesn't exist, and also why people have politely suggested that not worrying about it is probably a better option.

There is a real phenomenon known as "GCGC", garbage collection greybeard consensus, whereby one greybeard in 1997 speculates about the adequacy of defaults, which is echoed years later by another greybeard without investigation or regard to hardware improvements, and on down through time until the original speculation becomes a rule of thumb. See also conventional wisdom.

`display-line-numbers-mode` is much faster not just because it's in C, but because it is part of the display code, i.e. lines are numbered *as they are displayed*. By contrast, `linum.el` must wait until the window is redisplayed, and only after that it can number the lines on the screen and display the numbers. So with `linum.el` each redisplay of a window is immediately followed by another redisplay, which updates the line numbers. *That* is what makes it slow.

Oh ok Thank you but then aren't most of all packages in melpa or elpa written in elsip? So wouldn't using many of them massively slow emacs? Why not then write all the core functions and packages in C and use elisp only for some quick settings or functions?

If most of Emacs was written in C, it wouldn't be remotely so extensible. You'd have to recompile it to make almost any change. It wouldn't be anything like what we think of as Emacs -- hackers couldn't hack on it trivially, or come up with great new packages easily. It would be missing the point, basically. There are any number of editors which are entirely written in C (or some other compiled language) and not easily hackable, but they might be very fast. So people who want speed over anything else can have it. No one who likes Emacs would ever consider switching to an editor like that. In any case, most elisp doesn't *need* C-like speed. It just needs to be fast enough for the much, much slower human who is using the program.

Funnily enough, I've had this phenomena (or something very similar) referred to me as MMCC, or the memory-management cargo-cult, which refers to both those who write complex code to suit the garbage collector, or those who needlessly adjust the garbage collector to try and make questionable code run better (often to elsewhere's detriment).

If you're on 28.1 and native-compilation was included, then it should be enabled already. Check that `native-comp-deferred-compilation` is non-nil, and it should all be automatic. No more performance to be realistically gained after that, I'm afraid. Why not give it a go and find out? Write that line into, say, the scratch buffer and `C-x C-e` to run it. I'd expect an error, not lest because you aren't `provide`ing a feature in that file, nor would I expect it to be in your `load-path`. In any case, `require` uses `load` internally, so I'm not too sure what you're expecting to be different.

Maybe off topic, but why would anyone need line displaying to be faster than with linum? I mean. Do you really rely on knowing the line numbers just a few milliseconds before?

It's not about speed but the aesthetic. Your line numbers keep changing (in a non smooth way) in the middle. It feels clunky and weird. Hard to describe exactly.