Relative Line Numbers

[ovidius72]

As a vim users oriented version of emacs, I think that in spacemacs one the most wanted feature is the ability to see relative line numbers. I know that it is possible by changing the spacemacs config file but I'm suffering of performance issues when line numbers are set to relative. I didn't know that this is a general problem of emacs but I just realized that most of the emacs users prefer to hide them completely to avoid slowness. I've tried using other packages such as linum and nlinum-relative but I'm still having problems in large files (~500 lines). Can you please suggest if there is any way to oprimize relative line number in emacs, mainly in spacemacs that is what I'm using right now.

[practicalli-johnny]

With Emacs version 26.3 (and newer) there are now native line numbers, replacing the need for linum or other similar packages. The native line numbers are noticeably faster.

Spacemacs develop branch uses Emacs native line numbers when available.

In .spacemacs I find the following configuration for relative line numbers to be very performant with native line numbers

   dotspacemacs-line-numbers '(:visual t
                               :disabled-for-modes dired-mode
                                                   doc-view-mode
                                                   pdf-view-mode
                               :size-limit-kb 1000)

[ovidius72]

Thank you @jr0cket . I've tried your suggested settings but the problem for me is still there. Absolute line numbers do not cause this problem while relative do. I'm not sure if setting visual should result in something like relative or absolute. When i have relative line numbers and I keep pressing j or k to scroll up/down, when i release the key I notice the cursor does not stop immediately, it moves one or two lines more from where I stopped pressing the key. This doesn't occur with absolute line numbers or with line numbers disabled.

[practicalli-johnny]

Can you share some more information, it may help replicate the problem. Currently I have no idea why you have this bug.

Is the issue specific to particular languages / modes? Some modes do more font locking that others.

Can you add your system information, use SPC h d s and paste it here.

To help find issues, you should raise issues from Spacemacs itself, using SPC s I, rather than in GitHub directly.

[ovidius72]

@jr0cket

I have found this kind of problem in php-mode, typescript-mode, org-mode and when editing the config file. Switching to absolute line number the problem disappear. Disabling line numbers completely make the navigation a lot smoother. I see this problem even in files with 80/100 lines of code after editing something and then undoing.

#### System Info :computer:
- OS: gnu/linux
- Emacs: 27.0.90
- Spacemacs: 0.300.0
- Spacemacs branch: develop (rev. 2049817b1)
- Graphic display: t
- Distribution: spacemacs
- Editing style: vim
- Completion: helm
- Layers:

((auto-completion :variables auto-completion/init-fuzzy t auto-completion-enable-sort-by-usage t auto-completion-enable-help-tooltip nil auto-completion-use-company-box t)
 emacs-lisp git helm
 (html :variables web-fmt-tool 'prettier css-enable-lsp t less-enable-lsp t scss-enable-lsp t html-enable-lsp t)
 yaml json
 (lsp :variables lsp-enable-file-watchers t lsp-file-watch-threshold 40000 lsp-ui-sideline-enable nil lsp-ui-doc-enable nil lsp-flycheck-live-reporting nil lsp-ui-sideline-show-diagnostics nil)
 themes-megapack markdown multiple-cursors gtags
 (ranger :variables ranger-parent-depth 1 ranger-show-preview nil)
 dap prettier rust
 (python :variables python-backend 'lsp python-lsp-server 'mspyls python-tab-width 2)
 (php :variables php-backend 'lsp)
 (typescript :variables typescript-fmt-tool 'prettier typescript-backend 'lsp)
 react
 (javascript :variables javascript-fmt-tool 'prettier javascript-backend 'lsp)
 (org :variables org-projectile-file "TODOs.org")
 (shell :variables shell-default-height 30 shell-default-position 'bottom)
 syntax-checking neotree
 (version-control :variables version-control-diff-side 'left))

- System configuration features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP

[ovidius72]

I'm closing this issue because it seems that spacemacs has nothing to do with the problem. After a long journey I've probably found that the problem is caused by compton used with i3wm. I apologize for wasting your time.

[duianto]

There's no need to apologize, and it's not a waste of time. You found an issue, and a possible cause.

Thanks for posting an update. 👍 It could help someone else that encounters the same issue.

[practicalli-johnny]

(Updated) I previously had an issue with my Linux desktop compositor, although rather than line numbers it was a delay redrawing the cursor. For example, I would press j to move the cursor down a line and it would take a few seconds to redraw.

I am using Regolith Linux desktop 1.3.1 . I installed the regolith-compositor-none package that replaces the default regolith-compositor-compton-glx package and after rebooting my desktop Spacemacs was instantly responsive.

The compositor-none is a package that does not run a Compositor, so its fast, although there may be some visual effects that are missing (e.g. I don't see guide lines when selecting an area with the Gnome screenshot tool). https://regolith-linux.org/docs/customize/compositors/

Picom is a fork of compton

[ovidius72]

@jr0cket What do you exactly mean with the 'no-compositor' package ? Maybe that you have uninstalled it? I have disabled it completely now and I've noticed an improvement not only with emacs but even when moving or resizing windows. I was using picom. I want to check if there is some way to optimize it otherwise I will get rid completely.

[practicalli-johnny]

@ovidius72 I updated my previous reply for clarity.

Optimizations are possible with Picom (which is fork of compton). I haven't looked into optomisations as I dont really miss any of the compositor features.

There is also the xcompmgr compositor, which is the project that compton was forked from.

I didn't notice any issues with Emacs UI slowdown when using Ubuntu and Gnome Shell desktop, which uses Mutter for the compositor.

[ovidius72]

Thanks for your clarification @jr0cket I used Picom because it seems compton is abandoned (if I'm not wrong). It offers a few bunch of more options. I used to have blur, opacity and shadows enabled and I think the problem most likely came from there. As far as I can tell after a couple of days without any compositor, I don't miss it too much. So I think I can live without some effects.