[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performance degradation from long lines
From: |
Michael Heerdegen |
Subject: |
Re: Performance degradation from long lines |
Date: |
Thu, 25 Oct 2018 19:18:40 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
> First, it isn't visiting the file (i.e. reading it into a buffer) that
> takes time; in fact, the time to visit is almost entirely unaffected
> by line length. What takes time is the display of the initial
> windowful of the file's text (and following redisplay as result of
> editing). So I guess the proposal is to have a time-out on that
> initial display and on redisplay cycles.
BTW (I already discussed this with Eli some time ago), we already have a
solution in Emacs: longlines.el. It's obsoleted and a bit complicated,
but something like
#+begin_src emacs-lisp
(add-hook 'find-file-hook
(defun my-find-file-care-about-long-lines ()
(save-excursion
(goto-char (point-min))
(when (and (not (eq major-mode 'image-mode))
(search-forward-regexp ".\\{2000\\}" 50000 t)
(y-or-n-p "Very long lines detected - enable
longlines-mode? "))
(require 'longlines)
(longlines-mode +1)))))
#+end_src
solves the problem (though, using a heuristic in this case).
If someone would want write a slim version of longlines, it could be
part of a solution.
Michael.
Re: Performance degradation from long lines, Phil Sainty, 2018/10/27
Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/25
- Re: Performance degradation from long lines,
Michael Heerdegen <=
Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26