--- Begin Message ---
|
Subject: |
29.1; line-prefix shown at the beginning of continuation line |
|
Date: |
Wed, 15 Nov 2023 16:33:46 +0900 |
Evaluate the form below, a logically long line is displayed with wrapping.
'[start]' should be displayed only at the beginning of the logical line.
Type 'C-u 1 C-v', the buffer scrolls up, but the '[start]' string stays
at the top-left of the window. Type one more 'C-u 1 C-v', '[start]'
string stays there, too.
Then type 'M-x C-g'(quit), the displayed characters are shifted a little,
and type 'C-p', the buffer scrolls down, and the '[start]' string is
displayed in two place, the beginning of the buffer and the beginning of
the physical line which was displayed at the top of the window.
And one more bug in the same buffer that the cursor gets invisible.
Move the point at the point one character to the end of the first
physical line and type 'C-f', then the cursor gets invisible.
Logically the point is at the beginning of the next physical line.
Type one more 'C-f', the cursor is shown at the second character of the
second physical line.
(let* ((buf (generate-new-buffer "test"))
(s (make-string 1000 ?-))
(v (concat "0123456789"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz")))
(switch-to-buffer buf)
(setq truncate-lines nil)
(dotimes (i (length s))
(put-text-property i (1+ i) 'display (string (aref v (% i 62))) s))
(add-text-properties 0 (length s)
`(line-prefix
,(propertize "[start]" 'face '(:background "red"))
wrap-prefix "[wrap]")
s)
(insert s))
In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3570)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: JPN
locale-coding-system: cp932
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(rect tabify help-fns radix-tree cl-print debug backtrace find-func
gnutls network-stream nsm mailalias smtpmail textsec uni-scripts url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs json map byte-opt gv bytecomp byte-compile
url-vars idna-mapping ucs-normalize uni-confusable textsec-check
jka-compr qp misearch multi-isearch help-mode pp shadow sort mail-extr
emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml
mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
term/bobcat japan-util rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
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 theme-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
w32notify w32 lcms2 multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 229566 31785)
(symbols 48 8424 2)
(strings 32 38538 3529)
(string-bytes 1 886486)
(vectors 16 46550)
(vector-slots 8 1528352 106868)
(floats 8 54 226)
(intervals 56 1659 0)
(buffers 984 17))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#67201: 29.1; line-prefix shown at the beginning of continuation line |
|
Date: |
Sat, 25 Nov 2023 11:36:07 +0200 |
> Cc: 67201@debbugs.gnu.org
> Date: Thu, 16 Nov 2023 11:24:47 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: awrhygty@outlook.com
> > Date: Wed, 15 Nov 2023 16:33:46 +0900
> >
> >
> > Evaluate the form below, a logically long line is displayed with wrapping.
> > '[start]' should be displayed only at the beginning of the logical line.
> > Type 'C-u 1 C-v', the buffer scrolls up, but the '[start]' string stays
> > at the top-left of the window. Type one more 'C-u 1 C-v', '[start]'
> > string stays there, too.
> > Then type 'M-x C-g'(quit), the displayed characters are shifted a little,
> > and type 'C-p', the buffer scrolls down, and the '[start]' string is
> > displayed in two place, the beginning of the buffer and the beginning of
> > the physical line which was displayed at the top of the window.
> >
> > And one more bug in the same buffer that the cursor gets invisible.
> > Move the point at the point one character to the end of the first
> > physical line and type 'C-f', then the cursor gets invisible.
> > Logically the point is at the beginning of the next physical line.
> > Type one more 'C-f', the cursor is shown at the second character of the
> > second physical line.
>
> Thanks, should be fixed now on the master branch.
No further comments, so I'm now closing this bug.
--- End Message ---