GNU bug report logs -
#57669
29.0.50; C-n, C-p off under long lines
Previous Next
Reported by: dick.r.chiang <at> gmail.com
Date: Thu, 8 Sep 2022 06:33:01 UTC
Severity: normal
Found in version 29.0.50
Done: Gregory Heytings <gregory <at> heytings.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57669 in the body.
You can then email your comments to 57669 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Thu, 08 Sep 2022 06:33:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
dick.r.chiang <at> gmail.com:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 08 Sep 2022 06:33:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Try C-n through a file with long lines. It jumps around.
src/emacs -Q -l cl-lib --eval " \
(let ((long-line-threshold 10000) \
(file (make-temp-file \"baz\"))) \
(cl-assert (= 80 (window-width)) t) \
(with-temp-file file \
(insert (make-string (1+ long-line-threshold) ?x))) \
(dolist (toggle (list nil long-line-threshold)) \
(let* ((long-line-threshold toggle) \
(note (format \"long-line-threshold = %s\" \
long-line-threshold)) \
(buffer (find-file-literally file))) \
(with-current-buffer buffer \
(show-paren-mode -1) \
(goto-char (point-min)) \
(catch (quote done) \
(while (condition-case nil \
(prog1 t (call-interactively \
(function next-line))) \
(end-of-buffer)) \
(redisplay) \
(unless (zerop (% (current-column) (window-width))) \
(princ (format \"BAD under %s (column is %d)\n\" \
note (current-column)) \
(function external-debugging-output)) \
(throw (quote done) nil))) \
(princ (format \"GOOD under %s (column is %d)\n\" \
note (current-column)) \
(function external-debugging-output)))) \
(kill-buffer buffer))))"
In Commercial Emacs 0.3.1snapshot e6f9ecd in dev (upstream 29.0.50,
x86_64-pc-linux-gnu) built on dick
Repository revision: e6f9ecde2eaaa40ddb78b88b81f612b1e8ec1665
Repository branch: dev
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.4 LTS
Configured using:
'configure WERROR_CFLAGS=-Werror --prefix=/home/dick/.local
--with-tree-sitter'
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
TREE_SITTER LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Group
Minor modes in effect:
shell-dirtrack-mode: t
gnus-topic-mode: t
gnus-undo-mode: t
projectile-mode: t
flx-ido-mode: t
override-global-mode: t
global-hl-line-mode: t
hl-line-mode: t
winner-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/dick/gomacro-mode/gomacro-mode hides /home/dick/.emacs.d/elpa/gomacro-mode-20200326.1103/gomacro-mode
/home/dick/.emacs.d/elpa/go-rename-20190805.2101/go-rename hides /home/dick/.emacs.d/elpa/go-mode-1.6.0/go-rename
/home/dick/.emacs.d/elpa/go-guru-20181012.330/go-guru hides /home/dick/.emacs.d/elpa/go-mode-1.6.0/go-guru
/home/dick/org-gcal.el/org-gcal hides /home/dick/.emacs.d/elpa/org-gcal-0.3/org-gcal
/home/dick/.emacs.d/elpa/request-deferred-0.2.0/request-deferred hides /home/dick/.emacs.d/elpa/request-0.3.3/request-deferred
/home/dick/.emacs.d/elpa/chess-2.0.5/_pkg hides /home/dick/.local/share/emacs/site-lisp/_pkg
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-pos hides /home/dick/.local/share/emacs/site-lisp/chess-pos
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-module hides /home/dick/.local/share/emacs/site-lisp/chess-module
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-ucb hides /home/dick/.local/share/emacs/site-lisp/chess-ucb
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-scid hides /home/dick/.local/share/emacs/site-lisp/chess-scid
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-puzzle hides /home/dick/.local/share/emacs/site-lisp/chess-puzzle
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-irc hides /home/dick/.local/share/emacs/site-lisp/chess-irc
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-network hides /home/dick/.local/share/emacs/site-lisp/chess-network
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-autosave hides /home/dick/.local/share/emacs/site-lisp/chess-autosave
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-engine hides /home/dick/.local/share/emacs/site-lisp/chess-engine
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-tutorial hides /home/dick/.local/share/emacs/site-lisp/chess-tutorial
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-german hides /home/dick/.local/share/emacs/site-lisp/chess-german
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-file hides /home/dick/.local/share/emacs/site-lisp/chess-file
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-random hides /home/dick/.local/share/emacs/site-lisp/chess-random
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-stockfish hides /home/dick/.local/share/emacs/site-lisp/chess-stockfish
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-pgn hides /home/dick/.local/share/emacs/site-lisp/chess-pgn
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-kibitz hides /home/dick/.local/share/emacs/site-lisp/chess-kibitz
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-eco hides /home/dick/.local/share/emacs/site-lisp/chess-eco
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-display hides /home/dick/.local/share/emacs/site-lisp/chess-display
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-var hides /home/dick/.local/share/emacs/site-lisp/chess-var
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-test hides /home/dick/.local/share/emacs/site-lisp/chess-test
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-ply hides /home/dick/.local/share/emacs/site-lisp/chess-ply
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-message hides /home/dick/.local/share/emacs/site-lisp/chess-message
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-ics1 hides /home/dick/.local/share/emacs/site-lisp/chess-ics1
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-phalanx hides /home/dick/.local/share/emacs/site-lisp/chess-phalanx
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-game hides /home/dick/.local/share/emacs/site-lisp/chess-game
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-log hides /home/dick/.local/share/emacs/site-lisp/chess-log
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-plain hides /home/dick/.local/share/emacs/site-lisp/chess-plain
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-perft hides /home/dick/.local/share/emacs/site-lisp/chess-perft
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-glaurung hides /home/dick/.local/share/emacs/site-lisp/chess-glaurung
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-ai hides /home/dick/.local/share/emacs/site-lisp/chess-ai
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-fruit hides /home/dick/.local/share/emacs/site-lisp/chess-fruit
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-uci hides /home/dick/.local/share/emacs/site-lisp/chess-uci
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-epd hides /home/dick/.local/share/emacs/site-lisp/chess-epd
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-database hides /home/dick/.local/share/emacs/site-lisp/chess-database
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-link hides /home/dick/.local/share/emacs/site-lisp/chess-link
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-transport hides /home/dick/.local/share/emacs/site-lisp/chess-transport
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-none hides /home/dick/.local/share/emacs/site-lisp/chess-none
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-polyglot hides /home/dick/.local/share/emacs/site-lisp/chess-polyglot
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-crafty hides /home/dick/.local/share/emacs/site-lisp/chess-crafty
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-chat hides /home/dick/.local/share/emacs/site-lisp/chess-chat
/home/dick/.emacs.d/elpa/chess-2.0.5/chess hides /home/dick/.local/share/emacs/site-lisp/chess
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-images hides /home/dick/.local/share/emacs/site-lisp/chess-images
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-gnuchess hides /home/dick/.local/share/emacs/site-lisp/chess-gnuchess
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-fen hides /home/dick/.local/share/emacs/site-lisp/chess-fen
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-ics hides /home/dick/.local/share/emacs/site-lisp/chess-ics
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-ics2 hides /home/dick/.local/share/emacs/site-lisp/chess-ics2
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-common hides /home/dick/.local/share/emacs/site-lisp/chess-common
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-input hides /home/dick/.local/share/emacs/site-lisp/chess-input
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-announce hides /home/dick/.local/share/emacs/site-lisp/chess-announce
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-clock hides /home/dick/.local/share/emacs/site-lisp/chess-clock
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-sound hides /home/dick/.local/share/emacs/site-lisp/chess-sound
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-sjeng hides /home/dick/.local/share/emacs/site-lisp/chess-sjeng
/home/dick/.emacs.d/elpa/chess-2.0.5/chess-algebraic hides /home/dick/.local/share/emacs/site-lisp/chess-algebraic
/home/dick/.emacs.d/elpa/transient-0.3.7snapshot/transient hides /home/dick/.local/share/emacs/0.3.1/lisp/transient
Features:
(shadow sort bbdb-message footnote mail-extr emacsbug qp gnus-async
gnus-ml gnus-notifications gnus-fun notifications gnus-kill gnus-dup
disp-table utf-7 blamer a tramp tramp-loaddefs trampver
tramp-integration cus-start files-x tramp-compat shell pcomplete ls-lisp
url-cache benchmark nnrss nnfolder nndiscourse rbenv nnhackernews
nntwitter nntwitter-api bbdb-gnus gnus-demon nntp nnmairix nnml nnreddit
gnus-topic url-http url-auth url-gw network-stream nsm request
virtualenvwrapper gud s json-rpc python gnus-score score-mode gnus-bcklg
gnus-srvr gnus-cite anaphora bbdb-mua bbdb-com bbdb bbdb-site timezone
gnus-delay gnus-draft gnus-cache gnus-agent gnus-msg gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill
kinsoku url-file svg dom nndraft nnmh gnus-group mm-url gnus-undo
use-package use-package-delight use-package-diminish gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
parse-time iso8601 gnus-spec gnus-int gnus-range message sendmail
yank-media puny dired-x dired dired-loaddefs rfc822 mml mml-sec epa epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win
paredit-ext paredit inf-ruby ruby-mode smie company pcase
haskell-interactive-mode haskell-presentation-mode haskell-process
haskell-session haskell-compile haskell-mode haskell-cabal haskell-utils
haskell-font-lock haskell-indentation haskell-string
haskell-sort-imports haskell-lexeme haskell-align-imports
haskell-complete-module haskell-ghc-support noutline outline
flymake-proc flymake warnings etags fileloop generator dabbrev
haskell-customize hydra lv use-package-ensure solarized-theme
solarized-definitions projectile lisp-mnt ibuf-ext ibuffer
ibuffer-loaddefs thingatpt magit-autorevert autorevert filenotify
magit-git magit-base magit-section format-spec crm dash rx compat-27
compat-26 compat grep compile comint ansi-color gnus nnheader range
mail-utils mm-util mail-prsvr gnus-util text-property-search time-date
flx-ido flx google-translate-default-ui google-translate-core-ui
facemenu color ido google-translate-core google-translate-tk
google-translate-backend use-package-bind-key bind-key auto-complete
easy-mmode advice edmacro kmacro popup cus-edit pp cus-load icons
wid-edit emms-player-mplayer emms-player-simple emms emms-compat
cl-extra help-mode xref project use-package-core derived hl-line winner
ring acm-autoloads debbugs-autoloads eglot-autoloads
elpaso-disc-autoloads elpaso-autoloads find-func finder-inf
go-mode-autoloads json-reformat-autoloads json-snatcher-autoloads
lsp-bridge-autoloads magit-autoloads posframe-autoloads
projectile-autoloads markdown-mode-autoloads sml-mode-autoloads
epl-autoloads tornado-template-mode-autoloads typescript-mode-autoloads
request-autoloads info wordnut-autoloads yasnippet-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile cconv cldefs url-vars
cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)
Memory information:
((conses 16 531228 40963)
(symbols 48 34319 1)
(strings 32 131931 13242)
(string-bytes 1 4229331)
(vectors 16 48586)
(vector-slots 8 645891 28513)
(floats 8 997 358)
(intervals 56 511 0)
(buffers 1008 25))
Reply sent
to
Gregory Heytings <gregory <at> heytings.org>:
You have taken responsibility.
(Thu, 08 Sep 2022 07:39:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
dick.r.chiang <at> gmail.com:
bug acknowledged by developer.
(Thu, 08 Sep 2022 07:39:01 GMT)
Full text and
rfc822 format available.
Message #10 received at 57669-done <at> debbugs.gnu.org (full text, mbox):
>
> Try C-n through a file with long lines. It jumps around.
>
Thanks, but this is well-known, and is an (unavoidable) compromise.
Closing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Thu, 08 Sep 2022 08:18:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick.r.chiang <at> gmail.com
> Date: Thu, 08 Sep 2022 01:40:01 -0400
>
>
> Try C-n through a file with long lines. It jumps around.
That's expected, and is one of the prices we pay for reasonable
performance with such long lines: keeping the same column is no longer
guaranteed. I see no problem with that, FWIW.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Thu, 08 Sep 2022 16:59:04 GMT)
Full text and
rfc822 format available.
Message #16 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> I see no problem with that, FWIW.
No problem? None? The fortune you could have made had you pursued a
career in corporate messaging.
In all the reams of tail-chasing in Bug#56682 and Bug#56393, I managed
to locate just one preemptive mention by the proposer:
This feature comes at a (IMO) very little price, namely...
point sometimes moves to another column...
He is careful to minimize the issue, but he doesn't say "I see no
problem with that."
Emacs devs are fascinating. Even with no money or fame at stake, guys
choose the weirdest hills to die on. One guy repudiated the long lines
fix over some cc-mode regression. Another for imperfectly colorizing
json. Another for circumstantially forbidding "widen". But none of
them appeared to care the slightest about something as basic as "C-n"
and "C-p". A "very little price" indeed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Thu, 08 Sep 2022 17:13:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> No problem? None?
>
None, indeed. Even without long lines, C-n and C-p are not 100% accurate.
>
> This feature comes at a (IMO) very little price, namely... point
> sometimes moves to another column...
>
Indeed.
>
> He is careful to minimize the issue, but he doesn't say "I see no
> problem with that."
>
I wasn't "careful to minimize the issue", I state what it was black on
white. I was careful to minimize its impact, however: it could have been
much worse. What we now have is that sometimes, but rarely, point moves
to another column. That doesn't make Emacs unusable, does it?
>
> A "very little price" indeed.
>
Indeed. I'm glad to read you agree. Or are the quotation marks supposed
to convey something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Thu, 08 Sep 2022 18:27:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> This is an uncontrived, "in the wild" log file that I was C-n and
> C-p'ing when I discovered this "non-problem."
>
I'm not sure what that file is supposed to demonstrate? Yes, sometimes
point moves to another column. Why is that a problem while navigating
through that particular file? Is Emacs unusable?
>
> I speculate at least half your users would consider this a regression,
> although perhaps not one serious enough to revert your changes. Some of
> them would consider this a bug.
>
If you have ideas to improve the situation in one way or another, feel
free to share them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Thu, 08 Sep 2022 22:56:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 57669 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
DRC> No Problem? None?
GH> None, indeed.
[languageclient.out (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
This is an uncontrived, "in the wild" log file that I was C-n and
C-p'ing when I discovered this "non-problem."
I speculate at least half your users would consider this a regression,
although perhaps not one serious enough to revert your changes. Some of
them would consider this a bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 06:02:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Cc: 57669 <at> debbugs.gnu.org
> From: dick <dick.r.chiang <at> gmail.com>
> Date: Thu, 08 Sep 2022 14:13:29 -0400
>
> This is an uncontrived, "in the wild" log file that I was C-n and
> C-p'ing when I discovered this "non-problem."
Are you saying that this log file didn't have lines whose length is in
excess of the long-line-threshold value? Then it's a bug that we
would like to investigate, so please tell more details, and perhaps
post an example of such a file.
If the file did have such very long lines, then the question is: are
your Emacs and your patience capable of coping with editing this file
with the long-line optimizations disabled? If the answer is YES, all
you need to do is make the value of long-line-threshold higher, or
even set it to nil, and you get what Emacs did previously. C-n and
C-p will work correctly. It might take them forever to do their job,
but it will be done much more accurately.
> I speculate at least half your users would consider this a regression,
> although perhaps not one serious enough to revert your changes. Some of
> them would consider this a bug.
It is a regression if it happens in files with reasonable line length.
It is not a regression if it happens in files with very long lines,
because before the change Emacs couldn't cope with such files at all,
to the degree that would cause users kill the Emacs session. Now such
files _can_ be edited, but with some minor features working in
sub-optimal manner. Specifically, wrt C-n/C-p, let me remind you that
the line-move-visual = t operation that you say doesn't always work
with very long lines, didn't exist at all before Emacs 23, so at least
one solution is to turn it off, if its occasional misbehavior is
unacceptable for you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 13:39:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> When 29 goes mainstream, just be prepared to auto-reply "Does your file
> have a long line?" when feckless users ask, "Why did C-n go to a weird
> column?"
>
We are prepared.
>
> And to be clear, you're going from "ineffable" performance to just
> "underwhelming." As of cb036a7 you still need find-file-literally for
> some semblance of respectability.
>
Again your test case doesn't demonstrate anything useful, sorry. You use
a buffer with 100 lines, half of which are just one character above the
threshold. That's not at all representative, previous versions of Emacs
(I tried 24, 25, 26, 27 and 28) can already edit such buffers fine. Try
the same with a buffer with 10 lines, each of which is 10 MB long. Or
with a buffer with a single 100 MB long line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 14:13:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: gregory <at> heytings.org, 57669 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 09:08:46 -0400
>
> After all Commercial Emacs's original attempt at "making the best of
> a bad situation" was the impetus for your own poke at the pig.
This has NIH written all over it.
> And to be clear, you're going from "ineffable" performance to just
> "underwhelming." As of cb036a7 you still need find-file-literally for
> some semblance of respectability.
>
> OUTPUT:
>
> Under long-line-threshold=nil find-file 62s
> Under long-line-threshold=10000 find-file 27s
> Under long-line-threshold=nil find-file-literally 30s
> Under long-line-threshold=10000 find-file-literally 4s
It should be clear that comparing performance for 10000-character
lines with performance for 10001-character lines will produce only
mild speedups (but two-fold speedup is not to be ignored). In the
wild we see files with much longer lines, like tens of MBs. So if you
want to be fair, measure the performance when lines are much longer
than the threshold. For even more insight, see what happens to
performance as function of line length.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 14:40:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> I don't have the patience for 10MB. How about 0.1MB?
>
> OUTPUT:
>
> Under long-line-threshold=nil find-file ineffable
> Under long-line-threshold=10000 find-file 99s
> Under long-line-threshold=nil find-file-literally ineffable
> Under long-line-threshold=10000 find-file-literally 8s
>
And what's your conclusion now? BTW, actually calculating the time
instead of writing "ineffable" because it takes too long would be useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:14:03 GMT)
Full text and
rfc822 format available.
Message #40 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> because before the change Emacs couldn't cope with such files at all
Oh, I know what you're trying to do. After all Commercial Emacs's
original attempt at "making the best of a bad situation" was the impetus
for your own poke at the pig.
When 29 goes mainstream, just be prepared to auto-reply "Does your file
have a long line?" when feckless users ask, "Why did C-n go to a weird
column?"
And to be clear, you're going from "ineffable" performance to just
"underwhelming." As of cb036a7 you still need find-file-literally for
some semblance of respectability.
OUTPUT:
Under long-line-threshold=nil find-file 62s
Under long-line-threshold=10000 find-file 27s
Under long-line-threshold=nil find-file-literally 30s
Under long-line-threshold=10000 find-file-literally 4s
INPUT: C-n through file of alternating short and long lines.
src/emacs -Q -l cl-lib --eval " \
(let ((long-line-threshold 10000) \
(file (make-temp-file \"baz\"))) \
(cl-assert (= 80 (window-width)) t) \
(with-temp-file file \
(dotimes (i 100) \
(insert (make-string (if (zerop (% i 2)) \
200 \
(1+ long-line-threshold)) \
?x) \"\n\"))) \
(dolist (config (list (cons nil (function find-file)) \
(cons long-line-threshold (function find-file)) \
(cons nil (function find-file-literally)) \
(cons long-line-threshold (function find-file-literally)))) \
(let* ((long-line-threshold (car config)) \
(note (format \"long-line-threshold=%s %s\" \
(car config) (cdr config))) \
(buffer (funcall (cdr config) file))) \
(with-current-buffer buffer \
(show-paren-mode -1) \
(goto-char (point-min)) \
(princ (format \"Under %s %ds\n\" note \
(fround (car (benchmark-run \
(while (condition-case nil \
(prog1 t (call-interactively \
(function next-line)) \
(redisplay)) \
(end-of-buffer))))))) \
(function external-debugging-output))) \
(kill-buffer buffer))) \
(kill-emacs))"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:14:03 GMT)
Full text and
rfc822 format available.
Message #43 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Try the same with a buffer with 10 lines, each of which is 10 MB long.
I don't have the patience for 10MB. How about 0.1MB?
OUTPUT:
Under long-line-threshold=nil find-file ineffable
Under long-line-threshold=10000 find-file 99s
Under long-line-threshold=nil find-file-literally ineffable
Under long-line-threshold=10000 find-file-literally 8s
INPUT:
src/emacs -Q -l cl-lib --eval " \
(let ((large-file-warning-threshold (truncate 1e9)) \
(long-line-threshold 10000) \
(file (make-temp-file \"baz\"))) \
(cl-assert (= 80 (window-width)) t) \
(with-temp-file file \
(dotimes (i 10) \
(insert (make-string (truncate 1e5) ?x) \"\n\"))) \
(dolist (config (list (cons nil (function find-file)) \
(cons long-line-threshold (function find-file)) \
(cons nil (function find-file-literally)) \
(cons long-line-threshold (function find-file-literally)))) \
(let* ((long-line-threshold (car config)) \
(note (format \"long-line-threshold=%s %s\" \
(car config) (cdr config))) \
(buffer (funcall (cdr config) file))) \
(if (null (car config)) \
(princ (format \"Under %s ineffable\n\" note) \
(function external-debugging-output)) \
(with-current-buffer buffer \
(show-paren-mode -1) \
(goto-char (point-min)) \
(princ (format \"Under %s %ds\n\" note \
(fround (car (benchmark-run \
(while (condition-case nil \
(prog1 t (call-interactively \
(function next-line)) \
(redisplay)) \
(end-of-buffer))))))) \
(function external-debugging-output))) \
(kill-buffer buffer)))) \
(kill-emacs))"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:14:04 GMT)
Full text and
rfc822 format available.
Message #46 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> This has NIH written all over it.
You mean GNU Emacs suffers from NIH, or Commercial Emacs?
The Commercial Emacs long lines fix *preceded* GNU's by about six months
(and I might add, did so without resorting to the blunt instrument of
narrowing).
The proposer of the GNU Emacs fix even paraphrased Commercial Emacs
when he said:
Perfect is the enemy of good. Emacs users have been plagued for decades
by this bug.[1]
See [2],[3] from where his words might have found inspiration.
To be clear, I'm not aggrieved. I just want everyone to understand that
NIH is too unmeditated an accusation.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?msg=119;bug=56393
[2] https://youtu.be/5C3wB3xiMmU?t=80
[3] https://youtu.be/5C3wB3xiMmU?t=290
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:14:04 GMT)
Full text and
rfc822 format available.
Message #49 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> And what's your conclusion now?
The same? I'll repeat:
And to be clear, you're going from "ineffable" performance to just
"underwhelming." As of cb036a7 you still need find-file-literally for
some semblance of respectability.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:20:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> The Commercial Emacs long lines fix *preceded* GNU's by about six months
> (and I might add, did so without resorting to the blunt instrument of
> narrowing).
>
As I told you yesterday (privately), Commercial Emacs performs much worse
than what is now on master with respect to that bug.
>
> The proposer of the GNU Emacs fix even paraphrased Commercial Emacs
>
??? I did not even know that a proposed fix existed in "Commercial
Emacs". And how could your proposed fix have been an inspiration in any
way? As you yourself write two lines above you "do not resort to the
blunt instrument of narrowing".
>
> To be clear, I'm not aggrieved.
>
To be clear, you seem to be.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:42:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>> And what's your conclusion now?
>
> The same? I'll repeat:
>
> And to be clear, you're going from "ineffable" performance to just
> "underwhelming." As of cb036a7 you still need find-file-literally for
> some semblance of respectability.
>
A rather strange conclusion. Open a 1 MB file with short lines (under 80
chars) and use your benchmark on such a file. You'll see that scrolling
through the whole buffer, one line at a time, takes quite some time, too.
Here it takes about 20 seconds, and your benchmark (with find-file and 10
lines that are each 100K characters) takes 120 seconds. That's much
better than "just underwhelming", isn't it?
Not to mention that such a benchmark is itself not representative of an
actual use of an editor.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:50:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Cc: 57669 <at> debbugs.gnu.org
> From: dick <dick.r.chiang <at> gmail.com>
> Date: Fri, 09 Sep 2022 10:34:28 -0400
>
> > Try the same with a buffer with 10 lines, each of which is 10 MB long.
>
> I don't have the patience for 10MB. How about 0.1MB?
>
> OUTPUT:
>
> Under long-line-threshold=nil find-file ineffable
> Under long-line-threshold=10000 find-file 99s
This means on average 1 sec per C-n. Which is tolerable.
> Under long-line-threshold=nil find-file-literally ineffable
> Under long-line-threshold=10000 find-file-literally 8s
We know that visiting a file literally makes this much faster, but it
also loses a lot of features that we prefer not to lose. Like display
of non-ASCII characters, for example.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 15:59:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>> Under long-line-threshold=10000 find-file 99s
>
> This means on average 1 sec per C-n. Which is tolerable.
>
The buffer contains ten lines each of which is 100K long, so C-n is called
much more than 100 times, it is called ~10000 times. So that's actually
~10 ms per C-n.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 16:04:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 57669 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 11:52:00 -0400
>
> > Commercial Emacs performs much worse
>
> I dunno. As of 103caad, Commercial runs through the 100-line test in
> 3s, about the same as GNU with find-file-literally and non-nil
> long-lines-threshold.
I'm aware of your "solution", and it is unacceptable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 16:05:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 09 Sep 2022 15:58:50 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dick <dick.r.chiang <at> gmail.com>, 57669 <at> debbugs.gnu.org
>
>
> >> Under long-line-threshold=10000 find-file 99s
> >
> > This means on average 1 sec per C-n. Which is tolerable.
> >
>
> The buffer contains ten lines each of which is 100K long, so C-n is called
> much more than 100 times, it is called ~10000 times. So that's actually
> ~10 ms per C-n.
Even better.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 16:07:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>>> Commercial Emacs performs much worse
>>
>> I dunno. As of 103caad, Commercial runs through the 100-line test in
>> 3s, about the same as GNU with find-file-literally and non-nil
>> long-lines-threshold.
>
> I'm aware of your "solution", and it is unacceptable.
>
I'm not, I asked him a few pointers, and he replied with the hash of a
commit which disables what exists on master. Perhaps there's something
useful in his solution, even if it is unacceptable? If you already know
what it is, can you perhaps describe it in a few words?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 16:20:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 09 Sep 2022 16:06:57 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dick <dick.r.chiang <at> gmail.com>, 57669 <at> debbugs.gnu.org
>
> > I'm aware of your "solution", and it is unacceptable.
>
> I'm not, I asked him a few pointers, and he replied with the hash of a
> commit which disables what exists on master.
The code is there, you can read it. Don't just rely on my
conclusions, because I may be wrong.
> Perhaps there's something useful in his solution, even if it is
> unacceptable? If you already know what it is, can you perhaps
> describe it in a few words?
In a nutshell, his changes disable too many features of the GUI
display (the ones that make the Emacs display slow with long lines),
and they disable those features _always_, not just when the lines are
long.
And that is _after_ you factor out changes that are plain wrong,
because he simply didn't understand what the code does well enough.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 16:26:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>> I'm not, I asked him a few pointers, and he replied with the hash of a
>> commit which disables what exists on master.
>
> The code is there, you can read it.
>
I confess I don't have the patience to do that. I already don't have as
much free time as I'd like to devote to Emacs, so I'd better spend it
wisely.
>
> In a nutshell, his changes disable too many features of the GUI display
> (the ones that make the Emacs display slow with long lines), and they
> disable those features _always_, not just when the lines are long.
>
Okay, that's not the right way to do it, indeed.
Dick, if you feel the above doesn't do justice to your code, feel free to
elaborate on your chosen strategy, either here or privately.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 16:43:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> C-n'ing through a real-world logfile languageclient.out, which I attach
> again here, chops up at around line 44.
>
That line has lots of brackets. Try M-: (setq bidi-inhibit-bpa t) RET.
>
> This led me to write contrived tests, which of course are frowned upon
> in your school of measurement, whose modus operandi is interminable
> catechism between a complainant who laboriously and imprecisely
> describes slowness, and an inquisitor auto-replying "doesn't happen
> here."
>
What is on master does not claim to make Emacs equally fast in all
circumstances, which is simply impossible. Emacs remains responive, but
yes, it is still (a bit) slow in some cases, and that seems unavoidable
(without e.g. turning the BPA algorithm off unconditionally, which would
be unwise).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 18:07:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 13:44:16 -0400
>
> > and they disable those features _always_, not just lines are long.
>
> Must be nice having the title of "Maintainer." People just take your
> word for things.
They don't have to. The code is available for studying.
And if you think your code does something different from what I said,
feel free to describe what your code actually does, with enough
details for me and others to understand where I'm wrong.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 18:10:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 57669 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> That line has lots of brackets. Try M-: (setq bidi-inhibit-bpa t) RET.
>
> I'd rather find-file-literally, which does that and more.
>
The problem is that find-file-literally does too much.
>
> But "No!", you say, that's throwing the baby out the bathwater.
>
No, IMO the main problem is that doing that is not in any way a graceful
degradation.
>
> The baby in question is usually misshapen demon spawn, i.e, minified
> json or logfile.
>
Even in that case, it seems reasonable to believe that seeing "你好" is
way better than seeing "\344\275\240\345\245\275".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 18:59:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 14:22:32 -0400
>
> > feel free to describe what your code actually does, with enough
> > details for me and others to understand where I'm wrong.
>
> I find it asymmetric you can denigrate Commercial Emacs on a public
> forum without doing the research or showing a minimal reproducible
> example, and that I must go out of my way to fight a presumption of
> guilt.
I did the research. As long as you keep waving slogans, instead of
showing your code that deals with very long lines and explaining how
it solves that, I will maintain that my conclusions from studying your
changes are accurate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 19:11:03 GMT)
Full text and
rfc822 format available.
Message #91 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Commercial Emacs performs much worse
I dunno. As of 103caad, Commercial runs through the 100-line test in
3s, about the same as GNU with find-file-literally and non-nil
long-lines-threshold.
I never said your method was inspired by mine, merely your words
in describing the long lines situation, and your motivation to even
tackle the problem. I would have never thought to bring to bear a
seemingly unrelated thing like narrowing. I was impressed, although the
impedance mismatch of your creative solution is becoming more obvious.
You're right, though. Boy, am I am hopping mad.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 19:11:04 GMT)
Full text and
rfc822 format available.
Message #94 received at 57669 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> A rather strange conclusion.
[languageclient.out (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
I'm standing by my underwhelming characterization.
C-n'ing through a real-world logfile languageclient.out, which I attach
again here, chops up at around line 44. This led me to write contrived
tests, which of course are frowned upon in your school of measurement,
whose modus operandi is interminable catechism between a complainant who
laboriously and imprecisely describes slowness, and an inquisitor
auto-replying "doesn't happen here."
To your credit, underwhelming is far better than ineffable, so I've
largely been dismissive of the objections by the usual suspects in
Bug#56393.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 19:11:04 GMT)
Full text and
rfc822 format available.
Message #97 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> That line has lots of brackets. Try M-: (setq bidi-inhibit-bpa t)
> RET.
I'd rather find-file-literally, which does that and more. But "No!",
you say, that's throwing the baby out the bathwater. The baby in
question is usually misshapen demon spawn, i.e, minified json or
logfile. Much has been made of the so-called full solution, one that
doesn't crimp on syntax highlighting and other niceties. I think it's a
mistake to complicate the code for max preservation, and more cynically,
I think it's the peanut gallery not wanting to crown a giant slayer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 19:11:04 GMT)
Full text and
rfc822 format available.
Message #100 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> and they disable those features _always_, not just lines are long.
Must be nice having the title of "Maintainer." People just take your
word for things.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 19:11:05 GMT)
Full text and
rfc822 format available.
Message #103 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> feel free to describe what your code actually does, with enough
> details for me and others to understand where I'm wrong.
I find it asymmetric you can denigrate Commercial Emacs on a public
forum without doing the research or showing a minimal reproducible
example, and that I must go out of my way to fight a presumption of
guilt.
Then again, I'm constantly slamming you for incompetence, so I guess
all's fair in this sad, pathetic war over not money, not fame, but
being right on the internet (cue xkcd cartoon).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 19:40:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 15:28:47 -0400
>
> You want proof? Okay:
>
> src/emacs -Q src/xdisp.c
Sure, showing off display of a pure-ASCII file that uses a single font
proves your case! (It actually proves mine.)
> I trust you'll find no gui features missing between it and GNU Emacs. I
> would further show that my changes do not include ones which, and I
> quote, "are plain wrong," but it's much harder to prove the
> non-existence of bugs (wouldn't that be nice) than it is for you to
> prove their existence.
Once again, and for the last time: show your code which deals with
long lines; explain what it does and how. Then this discussion may
have some value.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 20:13:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> I did the research.
Good, I believe you. Given it took me six weeks to make those changes,
I suspect your research took at least a few hours. So it'd be an
additional hour of your copious time (you're a trust fund kid like me,
right?) to present a minimum reproducible example of Commercial Emacs
being guilty of, and I quote, "disabling those features _always_, not
just when lines are long."
Sheesh, I even made a goshdarn youtube video explaining my approach.
You want proof? Okay:
src/emacs -Q src/xdisp.c
I trust you'll find no gui features missing between it and GNU Emacs. I
would further show that my changes do not include ones which, and I
quote, "are plain wrong," but it's much harder to prove the
non-existence of bugs (wouldn't that be nice) than it is for you to
prove their existence.
I was being facetious earlier about being hopping mad. Now not as much.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 20:13:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> showing your code that deals with very long lines and explaining how
> it solves that
I can't believe I'm dignifying this. All line references from commit
beb489e.
xdisp.c[9319,9369]: Calculates dy algebraically without char-by-char.
xdisp.c[9537,9577]: Calculates CAPPED to limit char-by-char scan for
moving backwards (Blandy and Moellmann wrote xdisp like a singly linked
list -- fast and precise forwards, much less so going backwards).
A high-level description (which I understand is worthless to you, since
you're all about code not talk) can be found on YouTube. Cover the
right half of the screen if misshapen faces aggravate a heart condition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 21:29:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> xdisp.c[9319,9369]: Calculates dy algebraically without char-by-char.
>
> xdisp.c[9537,9577]: Calculates CAPPED to limit char-by-char scan for
> moving backwards (Blandy and Moellmann wrote xdisp like a singly linked
> list -- fast and precise forwards, much less so going backwards).
>
Thanks, finally we get an indication of what your code does and where.
I looked at it briefly, and the first thing I saw does not seem promising.
Your algebraic calculations are enabled when behaved_p, which depends on
buffer->text->monospace. That field is set (unconditionally) to true in
Fget_buffer_create, and reset only in only one place, in add_properties.
Can you please elaborate a bit and explain why doing that would be TRT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Fri, 09 Sep 2022 22:45:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> In add_properties, if I see anything that betrays monospaceness, like an
> image or a so-called display-string, I revert to character-by-character
> scanning, that is the buffer is no longer "behaved."
>
Yes, I understood that part of your reasoning. What I'm asking is why you
believe that doing that is enough. Aren't there other reasons besides
properties that "betray monospaceness"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 06:48:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 57669 <at> debbugs.gnu.org (full text, mbox):
In add_properties, if I see anything that betrays monospaceness, like an
image or a so-called display-string, I revert to character-by-character
scanning, that is the buffer is no longer "behaved."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 06:48:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 57669 <at> debbugs.gnu.org (full text, mbox):
There might be. I don't have enough user (that's right: I wasn't
presumptuous enough to use the plural) to know. My immediate response
however is your own,
"I bet that we won't have a single bug report about this."
First you would need to construct a pathological case, like lots of Urdu
and Hindi, then you would need the geometries to be sufficiently extreme
that a user would notice that the page didn't quite scroll up or down
the full page. Then you'd need me to renege on "perfect is the enemy of
the good."
I would add that unless you're seriously considering replacing narrowing
with my first-principles scheme (doubtful given how many hours you've
invested in narrowing), this is all an academic exercise in
oneupsmanship, which mind you, I am definitely game for. If that
suggests I believe I dealt with long lines better than you, you'd be
correct.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 07:47:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 15:55:07 -0400
>
> > showing your code that deals with very long lines and explaining how
> > it solves that
>
> I can't believe I'm dignifying this. All line references from commit
> beb489e.
>
> xdisp.c[9319,9369]: Calculates dy algebraically without char-by-char.
This uses state variables from 'struct it' which are _local_ and
_momentary_, i.e. they can change as result of processing any buffer
position, and reflect only the latest change, forgetting what was
before. Specifically, it->method is such a state variable. So making
global conclusions, such as that "all characters will have the same
metrics on display", based on it->method is fundamentally wrong, and
can only be true in very simple situations.
The buffer->text->monospace flag is likewise implemented based on
simplistic assumptions: that only text properties could violate the
"monospace-ness" attribute. Here's why this is simplistic:
. faces can be applied by overlays as well
. faces can be applied directly by C code
. faces can be applied by using glyphs from display-tables
. even if we only have the default face, fonts used for various
non-ASCII characters can have different metrics from the default
face's font, and in some cases they can even be variable-pitch
fonts
. portions of display can be made invisible by selective-display,
not just by 'invisible' properties
(I'm not claiming that the above is the exhaustive list of all the
reasons that the assumptions in behaved_p could be violated; there
could be more of them.)
> xdisp.c[9537,9577]: Calculates CAPPED to limit char-by-char scan for
> moving backwards (Blandy and Moellmann wrote xdisp like a singly linked
> list -- fast and precise forwards, much less so going backwards).
I cannot see how the above description is related to the actual code
in that part of xdisp.c: there's no char-by-char movement back in the
corresponding parts of our code; instead, we move back by lines, then
move forward by characters -- and that's what the code there does as
well. So I think this part of the code is equivalent to what we do,
in back_to_previous_visible_line_start, and should have the same
performance. But maybe I'm missing something -- was this change
profiled, and if so, what were the results? And if this code is
significantly faster, which of its changes is responsible for the
speedups? And in which kind of files under what major modes were
these speedups measured?
In any case, the replacement code uses behaved_p, whose problematic
assumptions I already explained above.
To comment on the above description: in general, moving the iterator
backwards needs to consider all the changes in the state variables of
'struct it' that eventually affect the metrics and the layout
calculations. It is _not_ the same as moving back by characters, and
the reason is that the state changes of 'struct it' are defined (in
set_iterator_to_next, get_next_display_element, and their subroutines)
only for moving forward, not for moving back. That is why all
move_it_* functions cannot move back, except by going to a preceding
newline and then coming forward.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 08:34:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Cc: 57669 <at> debbugs.gnu.org
> From: dick <dick.r.chiang <at> gmail.com>
> Date: Fri, 09 Sep 2022 19:27:13 -0400
>
> First you would need to construct a pathological case, like lots of Urdu
> and Hindi
There's nothing pathological about Hindi text. In fact, the JSON and
XML files with very long lines, which we are using for this work,
quite frequently have non-ASCII text from various scripts, including
R2L scripts. At least one of them I think went as far as showing
strings in every supported script.
> I would add that unless you're seriously considering replacing narrowing
> with my first-principles scheme (doubtful given how many hours you've
> invested in narrowing), this is all an academic exercise in
> oneupsmanship, which mind you, I am definitely game for. If that
> suggests I believe I dealt with long lines better than you, you'd be
> correct.
This is not a pissing contest, at least not on our part. We are
keenly interested in using any ideas that are correct, can be
implemented without too many complications, and provide significant
speedups, especially for very long lines.
For example, if the behaved_p idea, when implemented correctly
(i.e. when it takes into considerations _all_ the factors that violate
the monospace-ness assumption), can significantly speed up redisplay
in some situations, we would like to use it, at least when the
long_line_optimizations_p flag is set, if not always. However, both
the correct conditions for behaved_p and the actual speedups still
need to be coded and measured, before we can make that decision.
One fundamental problem with the behaved_p idea is that the conditions
it should test, when implemented correctly, can change at any buffer
position, and at least for some of them (e.g., when a character is
displayed by glyphs from a display-table), we don't have any way of
knowing that in advance, except by examining every character, which
basically annuls any advantages of this idea. So I'm not sure if this
idea is usable in a way that doesn't introduce subtle bugs. But maybe
such bugs could be tolerable when lines are very long (which means the
relevant optimizations should only be taken when the
long_line_optimizations_p flag is set)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 10:28:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> I would add that unless you're seriously considering replacing narrowing
> with my first-principles scheme (doubtful given how many hours you've
> invested in narrowing), this is all an academic exercise in
> oneupsmanship, which mind you, I am definitely game for.
>
My sole aim here is to improve Emacs, which is why I'm interested in all
good ideas. If it turned out that your scheme gives better results in
some cases, I don't see why it couldn't be included in Emacs. And if (but
that seems less likely) it turned out that your scheme gives better
results in all cases, I don't see why it wouldn't replace what is on
master.
>
> If that suggests I believe I dealt with long lines better than you,
> you'd be correct.
>
From what I see, you are a competent programmer. I find it regrettable
that you turn this (and other discussions) into an ego quarrel. As I
already said, your contributions and ideas are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 12:26:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Sat, 10 Sep 2022 08:07:24 -0400
>
> EZ> So I think this part of the code is equivalent to what we do, in
> EZ> back_to_previous_visible_line_start
>
> I'm glad you noticed! It means you're actually reading the code!
You cannot say anything of an essence without ad-hominem, can you?
> One difference is I gate line scanning (as opposed to character
> scanning) with behaved_p, whereas GNU crosses its fingers and hopes its
> POS_LIMIT estimate is far enough. So oddly enough, for all my cavailier
> assumptions, at least this part of the code [xdisp.c 9537:9577] is
> *more* conservative than GNU.
But since behaved_p is actually inaccurate at best, that doesn't
really matter, does it? It just trades one class of cases where the
shortcut doesn't work for another. You simply haven't yet met the
situations where those problems happen, most probably because you
tested only simple cases, like all-ASCII files which use a single
fixed-pitch font. The code on master went through much more testing,
by more users, during several years.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 13:09:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 57669 <at> debbugs.gnu.org (full text, mbox):
EZ> So I think this part of the code is equivalent to what we do, in
EZ> back_to_previous_visible_line_start
I'm glad you noticed! It means you're actually reading the code!
One difference is I gate line scanning (as opposed to character
scanning) with behaved_p, whereas GNU crosses its fingers and hopes its
POS_LIMIT estimate is far enough. So oddly enough, for all my cavailier
assumptions, at least this part of the code [xdisp.c 9537:9577] is
*more* conservative than GNU.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 13:09:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> [xdisp.c 9537:9577] is *more* conservative than GNU.
Ah, I'm wrong about this. My bad.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 13:09:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 57669 <at> debbugs.gnu.org (full text, mbox):
monospace-p I agree is an heuristic like narrowing. In the majority of
cases of long lines, it applies the algebraic shortcut when it thinks it
can get away with it.
What if it's wrong? Then it won't scroll up or down the full page.
What if it scrolls zero on a C-n? That'd be a degenerate case, one
which I'd have a hard time contriving, but that would only make it as
culpable as 29.0.50 which we already know can scroll zero on C-n.
But until Commercial can gather a following, my sanguinity is all
pissing-contest speculation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 13:10:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Sat, 10 Sep 2022 08:51:50 -0400
>
> monospace-p I agree is an heuristic like narrowing. In the majority of
> cases of long lines, it applies the algebraic shortcut when it thinks it
> can get away with it.
My guess is that it disables the shortcut in any buffer that has
font-lock turned on. Turning off font-lock is known to speed up
things significantly, even without the shortcut, but we thought that
turning it off would be asking too much. Thus, a satisfactory
solution must work in the presence of faces and in the presence of
different fonts, because the real-life use cases where we see very
long lines use both.
So I think we can only apply such shortcuts when lines are very long,
in which case the resulting inaccuracies in layout calculations could
be perhaps tolerated. I don't think it's feasible to apply them
always, because once we make behaved_p accurate enough (if that is at
all feasible), it will probably lose its attractiveness.
The other question is: if we apply these shortcuts when lines are very
long, what do we gain? If performance becomes significantly better,
it would perhaps mean we can enlarge long-line-threshold's value, or
make the default narrowing region larger. But I don't think we can
avoid the narrowing completely, because anything else will still scale
at least linearly with the line length, and so will at some point
become unbearably slow.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 13:23:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Sat, 10 Sep 2022 08:51:50 -0400
>
> monospace-p I agree is an heuristic like narrowing. In the majority of
> cases of long lines, it applies the algebraic shortcut when it thinks it
> can get away with it.
Btw, the way you reset the monospace flag in add_text_properties is
also problematic: the code is looking only at the specific face that
is the value of the property. But Emacs applies faces by merging them
with other sources of face information, not just by using the single
face named by the property. As the simplest example, consider a face
whose only non-unspecified attribute is :inherit -- in that case,
AFAIU your code will not reset the monospace flag, but when Emacs will
actually use the face for rendering, it will follow the inheritance
chain and might find there one of the face attributes your code does
care about.
Also, I don't see the monospace flag being reset if the face's font is
not a fixed-pitch one. Did I miss something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 13:31:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> Cc: 57669 <at> debbugs.gnu.org
> Date: Sat, 10 Sep 2022 16:09:04 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > From: dick <dick.r.chiang <at> gmail.com>
> > Cc: 57669 <at> debbugs.gnu.org
> > Date: Sat, 10 Sep 2022 08:51:50 -0400
> >
> > monospace-p I agree is an heuristic like narrowing. In the majority of
> > cases of long lines, it applies the algebraic shortcut when it thinks it
> > can get away with it.
>
> My guess is that it disables the shortcut in any buffer that has
> font-lock turned on.
I thought one thing, but wrote something that implies another. What I
meant was "any buffer that has font-lock turned on and uses
non-default fonts for the font-lock faces" -- the last part was
missing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 14:21:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 57669 <at> debbugs.gnu.org
> Date: Sat, 10 Sep 2022 10:03:55 -0400
>
> Like you, I largely dismiss prose but will begrudgingly run a minimum
> reproducible example. If it's so simple, please follow your own
> bug-reporting advice:
>
> Please describe exactly what actions triggered the bug...
> If you can, give a recipe starting from 'emacs -Q'
I'm not interested in reporting bugs for a fork of Emacs. I _am_
interested in discussing ideas for making display of long lines in
Emacs better, so if you are interested as well, you will respond in
kind. Otherwise, I guess this discussion has exhausted itself, at
least as far as your participation is concerned.
Fortunately, you are not the only participant, and others might be
interested in what I have to say.
> You'll find that I *always* do this in epic arguments of this scale.
> You, I noticed, traffic in hand-wavy refrains like "I've been doing this
> for years," "If you read the code, you'd know why," "He simply doesn't
> understand the code."
This kind of ad hominem usually means you've run out of real
arguments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 16:56:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 57669 <at> debbugs.gnu.org (full text, mbox):
>
> The buffer->text->monospace flag is likewise implemented based on
> simplistic assumptions: that only text properties could violate the
> "monospace-ness" attribute. Here's why this is simplistic:
>
> . faces can be applied by overlays as well
>
> . faces can be applied directly by C code
>
> . faces can be applied by using glyphs from display-tables
>
> . even if we only have the default face, fonts used for various
> non-ASCII characters can have different metrics from the default face's
> font, and in some cases they can even be variable-pitch fonts
>
> . portions of display can be made invisible by selective-display, not
> just by 'invisible' properties
>
> (I'm not claiming that the above is the exhaustive list of all the
> reasons that the assumptions in behaved_p could be violated; there could
> be more of them.)
>
FWIW, the simplest recipe for the fourth point above is to create a buffer
with a long line (with say C-u 10000 a) and to insert, somewhere in the
middle of that line, characters which have a width equal to zero (e.g. C-x
8 RET zero width space RET) and characters which have a width equal to two
(e.g. C-x 8 RET e i s s a). You'll see that your algebraic calculations
do not work anymore.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 17:47:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 57669 <at> debbugs.gnu.org (full text, mbox):
You've identified the weakest point and you continue to squeeze.
Fortunately my weakest point is monospace_p, an heuristic, one which
I feel makes the right compromises.
I wouldn't be surprised if "heuristic" didn't surface in your self-study
of programming. The narrowing in 29.0.50 is also an "heuristic."
> As the simplest example, consider a face whose only non-unspecified
Like you, I largely dismiss prose but will begrudgingly run a minimum
reproducible example. If it's so simple, please follow your own
bug-reporting advice:
Please describe exactly what actions triggered the bug...
If you can, give a recipe starting from 'emacs -Q'
You'll find that I *always* do this in epic arguments of this scale.
You, I noticed, traffic in hand-wavy refrains like "I've been doing this
for years," "If you read the code, you'd know why," "He simply doesn't
understand the code."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57669; Package
emacs.
(Sat, 10 Sep 2022 17:47:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 57669 <at> debbugs.gnu.org (full text, mbox):
> This kind of ad hominem usually means you've run out of real
> arguments.
Took the words right out of my mouth:
Bug#57212
If you'd read the code guarded by that flag and understand what it
does, you wouldn't have made such nonsensical proposals.
Bug#57669
And that is _after_ you factor out changes that are plain wrong,
because he simply didn't understand what the code does well enough.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 09 Oct 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 198 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.