GNU bug report logs -
#57728
29.0.50; Emacs writes wrong glyph at the bottom-right corner of text terminals
Previous Next
To reply to this bug, email your comments to 57728 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 10:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Akib Azmain Turja <akib <at> disroot.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 11 Sep 2022 10:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Emacs often writes to the last character possibly by mistake. To
reproduce, run emacs -Q, hit M-: (eval-expression), write some garbage
until the minibuffer window scrolls (I used (+ (% (random) 26) ?a) to
generate the garbage), and hit C-p until you scroll down a line. You
should now see that the last character cell contains a continuation
('\') glyph. I think this is probably due to the use of any of 'il' or
'il1' or 'rin' terminal capabilities.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
System Description: Guix System
Configured using:
'configure
CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
--prefix=/gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b
--enable-fast-install --with-native-compilation --with-sqlite3
--with-xinput2 --with-xwidgets --with-modules --with-cairo
--disable-build-details'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3
ZLIB
Important settings:
value of $EMACSLOADPATH: /home/akib/.guix-profile/share/emacs/site-lisp:/gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
gcmh-mode: t
gpm-mouse-mode: t
gtags-mode: t
corfu-doc-terminal-mode: t
corfu-doc-mode: t
corfu-terminal-mode: t
corfu-history-mode: t
global-corfu-mode: t
global-anzu-mode: t
isearch-mb-mode: t
global-auto-revert-mode: t
save-place-mode: t
electric-pair-mode: t
gc-buffers-mode: t
which-key-mode: t
marginalia-mode: t
vertico-mode: t
minibar-mode: t
workroom-mode: t
xterm-mouse-mode: t
savehist-mode: t
recentf-mode: t
shackle-mode: t
blow-mode: t
leaf-key-override-global-mode: t
el-patch-use-package-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: linux
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/akib/.config/emacs/elpa/transient-20220806.2224/transient hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/transient
/home/akib/.config/emacs/elpa/jsonrpc-1.0.15.0.20220714.101331/jsonrpc hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/jsonrpc
/home/akib/.config/emacs/elpa/flymake-1.2.2.0.20220714.93742/flymake hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/progmodes/flymake
/home/akib/.config/emacs/elpa/xref-1.5.0.0.20220826.220947/xref hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/progmodes/xref
/home/akib/.config/emacs/elpa/project-0.8.1.0.20220617.122301/project hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/progmodes/project
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-desktop-notifications hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-desktop-notifications
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-speedbar hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-speedbar
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-imenu hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-imenu
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-pcomplete hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-pcomplete
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-compat hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-compat
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-replace hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-replace
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-notify hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-notify
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-stamp hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-stamp
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-capab hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-capab
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-lang hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-lang
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-loaddefs hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-loaddefs
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-match hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-match
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-list hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-list
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-truncate hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-truncate
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-services hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-services
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-sound hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-sound
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-button hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-button
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-dcc hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-dcc
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-page hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-page
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-log hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-log
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-goodies hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-goodies
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-ezbounce hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-ezbounce
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-menu hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-menu
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-join hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-join
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-xdcc hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-xdcc
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-ibuffer hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-ibuffer
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-status-sidebar hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-status-sidebar
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-netsplit hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-netsplit
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-spelling hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-spelling
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-networks hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-networks
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-autoaway hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-autoaway
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-track hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-track
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-backend hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-backend
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-ring hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-ring
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-identd hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-identd
/home/akib/.config/emacs/elpa/erc-5.4.1.0.20220727.51909/erc-fill hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/erc/erc-fill
/home/akib/.config/emacs/elpa/eldoc-1.13.0.0.20220802.95655/eldoc hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/emacs-lisp/eldoc
/home/akib/.config/emacs/elpa/seq-2.23.0.20210925.195432/seq hides /gnu/store/kbim2zycpr57xyj9dbh8r013srkaaif3-emacs-edge-29.0.50-1.686296b/share/emacs/29.0.50/lisp/emacs-lisp/seq
Features:
(shadow footnote flyspell ispell display-line-numbers
display-fill-column-indicator ws-butler hl-todo compat compat-macs
emacsbug iwindow ansi-color gnus-cite mm-archive mail-extr qp textsec
uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check
gnus-async gnus-bcklg sort gnus-ml lin hl-line face-remap nndraft nnmh
gnus-search eieio-opt speedbar ezimage dframe find-func nnselect
nnmaildir nnfolder nnnil gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig nntp gnus-cache gnus-sum shr pixel-fill kinsoku url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int gnus-range
message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec
epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus nnheader gnus-util mail-utils range mm-util
mail-prsvr mode-line-bell time mule-util orderless mb-depth time-date
battery dbus xml modus-vivendi-theme modus-themes gcmh t-mouse
term/linux init auth-source-pass gtags-mode files-x xref project
corfu-doc-terminal avl-tree generator corfu-doc corfu-terminal popon
corfu-history corfu anzu advice thingatpt isearch-mb autorevert
filenotify saveplace elec-pair gc-buffers which-key marginalia vertico
minibar workroom bookmark text-property-search xt-mouse savehist recentf
tree-widget shackle trace blow edmacro kmacro pcase cl-extra cus-edit pp
cus-load icons wid-edit leaf finder-inf vterm-autoloads guix-emacs
disp-table aggressive-indent-autoloads anzu-autoloads cape-autoloads
closql-autoloads consult-org-roam-autoloads corfu-autoloads
coterm-autoloads crux-autoloads easy-mmode diff-hl-autoloads
doom-modeline-autoloads doom-themes-autoloads eat-autoloads
ef-themes-autoloads el-patch el-patch-stub async-autoloads
elisp-demos-autoloads consult-autoloads
eshell-syntax-highlighting-autoloads flymake-autoloads eldoc-autoloads
geiser-guile-autoloads geiser-impl help-fns radix-tree help-mode
geiser-custom geiser-base ring ghub-autoloads rx helpful-autoloads
iwindow-autoloads ligature-autoloads lin-autoloads geiser-autoloads
magit-autoloads git-commit-autoloads marginalia-autoloads
mastodon-autoloads meow-autoloads modus-themes-autoloads
mood-line-autoloads mood-one-theme-autoloads moody-autoloads
multiple-cursors-autoloads notmuch-autoloads nov-autoloads
nubox-autoloads org-roam-ui-autoloads org-roam-autoloads
magit-section-autoloads paredit-autoloads request-autoloads
shrink-path-autoloads f-autoloads s-autoloads sx-autoloads
markdown-mode-autoloads transient-autoloads vertico-autoloads
which-key-autoloads with-editor-autoloads info compat-autoloads
xref-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 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 xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 678000 1332866)
(symbols 48 26573 249)
(strings 32 250861 595284)
(string-bytes 1 14264213)
(vectors 16 105215)
(vector-slots 8 1649199 1231194)
(floats 8 458 1709)
(intervals 56 1510 2860)
(buffers 992 22))
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 10:55:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sep 11 2022, Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Emacs often writes to the last character possibly by mistake.
Why do you think this is a mistake?
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 10:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 10:55:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> Emacs often writes to the last character possibly by mistake. To
> reproduce, run emacs -Q, hit M-: (eval-expression), write some garbage
> until the minibuffer window scrolls (I used (+ (% (random) 26) ?a) to
> generate the garbage), and hit C-p until you scroll down a line.
I'm not sure what you mean by "I used (+ (% (random) 26) ?a)". Do you
have a step-by-step recipe to reproduce the problem?
> You should now see that the last character cell contains a
> continuation ('\') glyph. I think this is probably due to the use of
> any of 'il' or 'il1' or 'rin' terminal capabilities.
If you type in something that's longer than a line, Emacs will display a
\ glyph, no matter whether it's in the minibuffer or not, so I don't
understand what you mean here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 11:40:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 11 Sep 2022 16:34:38 +0600
> From: Akib Azmain Turja via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Emacs often writes to the last character possibly by mistake. To
> reproduce, run emacs -Q, hit M-: (eval-expression), write some garbage
> until the minibuffer window scrolls (I used (+ (% (random) 26) ?a) to
> generate the garbage), and hit C-p until you scroll down a line. You
> should now see that the last character cell contains a continuation
> ('\') glyph. I think this is probably due to the use of any of 'il' or
> 'il1' or 'rin' terminal capabilities.
Thanks, but please provide more info:
. the exact recipe to try (I tried to follow the above, but
couldn't, I guess I misunderstand what you mean)
. on which terminal emulators this is known to happen, at least in
your case (and if you happen to know, also others)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 14:12:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 11 Sep 2022 16:34:38 +0600
>> From: Akib Azmain Turja via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Emacs often writes to the last character possibly by mistake. To
>> reproduce, run emacs -Q, hit M-: (eval-expression), write some garbage
>> until the minibuffer window scrolls (I used (+ (% (random) 26) ?a) to
>> generate the garbage), and hit C-p until you scroll down a line. You
>> should now see that the last character cell contains a continuation
>> ('\') glyph. I think this is probably due to the use of any of 'il' or
>> 'il1' or 'rin' terminal capabilities.
>
> Thanks, but please provide more info:
>
> . the exact recipe to try (I tried to follow the above, but
> couldn't, I guess I misunderstand what you mean)
> . on which terminal emulators this is known to happen, at least in
> your case (and if you happen to know, also others)
I don't why my first message confused everyone, but I'll try to give a
clearer explanation:
Emacs often writes to the last character cell (i.e. the character cell
on the bottom-left corner) possibly by mistake. To
reproduce:
1. Run emacs -Q.
2. M-: (or any other command that asks for a string).
3. Write some garbage until the minibuffer window scrolls. (I used
(dotimes (i 10000) (+ (% (random) 26) ?a)) to generate the garbage
in *scratch* buffer and copied to the minibuffer, but you can write
anything you want.)
4. Scroll down a line.
5. You should now see that the last character cell (i.e. the character
cell on the bottom-left corner) contains a continuation ('\')
glyph. But Emacs doesn't dare to write to that character cell when
'am' capability is defined, and my terminal have that capability
defined. I think this is probably due to the use of any of 'il' or
'il1' or 'rin' capabilities. Tested on Linux console, St, Xterm
and Kitty.
6. Scroll up two lines.
7. The continuation glyph on the line before the last one doesn't
appear. Tested on Linux console, St, Xterm and Kitty.
8. Scroll down more than two lines.
9. Exit minibuffer. The continuation glyph will still stay there on
some terminals. Tested on St, Kitty.
I hope this is clearer.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 14:34:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: 57728 <at> debbugs.gnu.org
> Date: Sun, 11 Sep 2022 19:38:45 +0600
>
> 1. Run emacs -Q.
"emacs -Q -nw", I guess? We are talking about TTY display, right?
> 2. M-: (or any other command that asks for a string).
> 3. Write some garbage until the minibuffer window scrolls. (I used
> (dotimes (i 10000) (+ (% (random) 26) ?a)) to generate the garbage
> in *scratch* buffer and copied to the minibuffer, but you can write
> anything you want.)
Will this do:
M-: ssssssssssssssssssssssssssssssssssssssssssssssssssss
(keep typing 's' until you get past the right edge of the window, and
the minibuffer resizes to be 2 screen lines instead of just one)?
> 4. Scroll down a line.
With C-n? or with something else?
> 5. You should now see that the last character cell (i.e. the character
> cell on the bottom-left corner) contains a continuation ('\')
> glyph.
Bottom-left corner or bottom-right corner? If bottom-right, then this
'\' is the continuation glyph, telling you that the line is continued
on the next screen line.
> 6. Scroll up two lines.
With C-p?
Also, I cannot scroll up two lines unless I first make the mini-window
at least lines high.
> 7. The continuation glyph on the line before the last one doesn't
> appear. Tested on Linux console, St, Xterm and Kitty.
I don't see this here, but maybe that's because my terminal isn't
kitty. It does behave like xterm, though.
> 8. Scroll down more than two lines.
> 9. Exit minibuffer. The continuation glyph will still stay there on
> some terminals. Tested on St, Kitty.
Here, it never goes away.
> I hope this is clearer.
Unfortunately, not really.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 15:46:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: 57728 <at> debbugs.gnu.org
>> Date: Sun, 11 Sep 2022 19:38:45 +0600
>>
>> 1. Run emacs -Q.
>
> "emacs -Q -nw", I guess? We are talking about TTY display, right?
Oh, yes. I first tried on Linux console, where just emacs -Q is enough.
>
>> 2. M-: (or any other command that asks for a string).
>> 3. Write some garbage until the minibuffer window scrolls. (I used
>> (dotimes (i 10000) (+ (% (random) 26) ?a)) to generate the garbage
>> in *scratch* buffer and copied to the minibuffer, but you can write
>> anything you want.)
>
> Will this do:
>
> M-: ssssssssssssssssssssssssssssssssssssssssssssssssssss
>
> (keep typing 's' until you get past the right edge of the window, and
> the minibuffer resizes to be 2 screen lines instead of just one)?
I don't think so. Emacs redisplay optimizations will optimize away many
things. Try to write random character like 'asn,csr,.jwsarcwasr,.cp'
and repeat it (kill and yank yank yank...) until the mini window fills
and scrolls some lines (maybe ten). Make sure that
(window-max-chars-per-line) is not a multiple of the length of the base
string (which you killed).
>
>> 4. Scroll down a line.
>
> With C-n? or with something else?
C-p, or possibly C-u 1 M-v.
>
>> 5. You should now see that the last character cell (i.e. the character
>> cell on the bottom-left corner) contains a continuation ('\')
>> glyph.
>
> Bottom-left corner or bottom-right corner? If bottom-right, then this
> '\' is the continuation glyph, telling you that the line is continued
> on the next screen line.
Ah, my mistake. It is the bottom-right corner.
>
>> 6. Scroll up two lines.
>
> With C-p?
>
> Also, I cannot scroll up two lines unless I first make the mini-window
> at least lines high.
C-n, or possibly C-u 2 C-v.
>
>> 7. The continuation glyph on the line before the last one doesn't
>> appear. Tested on Linux console, St, Xterm and Kitty.
>
> I don't see this here, but maybe that's because my terminal isn't
> kitty. It does behave like xterm, though.
What do mean?
>
>> 8. Scroll down more than two lines.
>> 9. Exit minibuffer. The continuation glyph will still stay there on
>> some terminals. Tested on St, Kitty.
>
> Here, it never goes away.
>
>> I hope this is clearer.
>
> Unfortunately, not really.
Is it clear enough now?
>
> Thanks.
>
>
>
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 17:25:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: 57728 <at> debbugs.gnu.org
> Date: Sun, 11 Sep 2022 21:44:11 +0600
>
> >> 2. M-: (or any other command that asks for a string).
> >> 3. Write some garbage until the minibuffer window scrolls. (I used
> >> (dotimes (i 10000) (+ (% (random) 26) ?a)) to generate the garbage
> >> in *scratch* buffer and copied to the minibuffer, but you can write
> >> anything you want.)
> >
> > Will this do:
> >
> > M-: ssssssssssssssssssssssssssssssssssssssssssssssssssss
> >
> > (keep typing 's' until you get past the right edge of the window, and
> > the minibuffer resizes to be 2 screen lines instead of just one)?
>
> I don't think so. Emacs redisplay optimizations will optimize away many
> things.
I don't understand why redisplay optimizations matter. No
optimizations can prevent me from typing enough characters to exceed
the width of the window, at which point the line will be continued on
the next screen line, and the mini-window will be resized.
> Try to write random character like 'asn,csr,.jwsarcwasr,.cp'
> and repeat it (kill and yank yank yank...) until the mini window fills
> and scrolls some lines (maybe ten). Make sure that
> (window-max-chars-per-line) is not a multiple of the length of the base
> string (which you killed).
I don't understand why this would be needed, because ...
> >> 5. You should now see that the last character cell (i.e. the character
> >> cell on the bottom-left corner) contains a continuation ('\')
> >> glyph.
> >
> > Bottom-left corner or bottom-right corner? If bottom-right, then this
> > '\' is the continuation glyph, telling you that the line is continued
> > on the next screen line.
>
> Ah, my mistake. It is the bottom-right corner.
Then that '\' is the continuation glyph. Why does it surprise you?
> >> I hope this is clearer.
> >
> > Unfortunately, not really.
>
> Is it clear enough now?
Not yet.
Let me turn the table and ask you: why do you think that '\' is not
the usual continuation glyph that Emacs always produces when the width
of a screen line on a TTY frame is exceeded?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 18:03:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Let me turn the table and ask you: why do you think that '\' is not
> the usual continuation glyph that Emacs always produces when the width
> of a screen line on a TTY frame is exceeded?
I think I finally understand what the reporter means. To reproduce:
emacs -Q -nw
M-: and then enter enough text that you have ten lines of stuff in the
minibuffer.
It'll look like this:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
So far so good. Then C-p six-ish times and then C-n a few times:
[Message part 4 (image/png, inline)]
[Message part 5 (text/plain, inline)]
Note that the continuation markers have gone missing from the last three
lines.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 18:14:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Akib Azmain Turja <akib <at> disroot.org>, 57728 <at> debbugs.gnu.org
> Date: Sun, 11 Sep 2022 20:02:45 +0200
>
> Note that the continuation markers have gone missing from the last three
> lines.
Doesn't happen here, neither on MS-Windows nor on GNU/Linux to which I
SSH-login via PuTTY (which AFAIK emulates xterm). I guess this really
is specific to some terminals.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 18:19:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Doesn't happen here, neither on MS-Windows nor on GNU/Linux to which I
> SSH-login via PuTTY (which AFAIK emulates xterm). I guess this really
> is specific to some terminals.
My example was with gnome-terminal on the current Ubuntu, for what it's
worth.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 18:31:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: akib <at> disroot.org, 57728 <at> debbugs.gnu.org
> Date: Sun, 11 Sep 2022 20:18:03 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Doesn't happen here, neither on MS-Windows nor on GNU/Linux to which I
> > SSH-login via PuTTY (which AFAIK emulates xterm). I guess this really
> > is specific to some terminals.
>
> My example was with gnome-terminal on the current Ubuntu, for what it's
> worth.
Someone with access to that terminal will have to debug this.
My guess is that something we do when we rewrite the lines while
scrolling the display erases those glyphs by side effect, but Emacs
doesn't know that. Since all the lines have the continuation glyph,
it makes sense for Emacs to rewrite only the part of each line up to
and excluding the continuation glyphs, relying on them to remain on
the glass.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Sun, 11 Sep 2022 20:37:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 57728 <at> debbugs.gnu.org (full text, mbox):
>
> Thanks, but please provide more info:
>
> . the exact recipe to try (I tried to follow the above, but couldn't, I
> guess I misunderstand what you mean)
>
> . on which terminal emulators this is known to happen, at least in your
> case (and if you happen to know, also others)
>
Here is (I think) a recipe to demonstrate what the OP has in mind (tested
with xterm, rxvt, st, kitty, alacritty, Linux console):
1. emacs -Q -nw
2a. if your terminal emulator has a light background: M-x load-theme RET
modus-vivendi RET
2b. if your terminal emulator has a dark background: M-x load-theme RET
modus-operandi RET
Observe at that point that the last character (the one at the bottom
right) does not have the background color of the chosen theme. So far so
good.
3. M-: (define-key minibuffer-mode-map (kbd "C-t") (defun bug57728 () (interactive) (dotimes (i 5000) (insert (+ (% (random) 26) ?a))))) RET
4. M-: C-t
5. Now hit C-p a few times, until you see the "\" continuation character
appear on the last character (the one at the bottom right). This should
not happen.
6. Now press C-g. The continuation character stays there. Again this
should not happen.
(Note that the "\" continuation character disappears with C-l, after step
5 and after step 6.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 06:39:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
> Here is (I think) a recipe to demonstrate what the OP has in mind
> (tested with xterm, rxvt, st, kitty, alacritty, Linux console):
>
> 1. emacs -Q -nw
>
> 2a. if your terminal emulator has a light background: M-x load-theme
> RET modus-vivendi RET
>
> 2b. if your terminal emulator has a dark background: M-x load-theme
> RET modus-operandi RET
>
> Observe at that point that the last character (the one at the bottom
> right) does not have the background color of the chosen theme. So far
> so good.
The OP filed a bug for this, and he might work on it he said.
This is because 'write' deliberatly leaves the bottom-right corner alone
if the terminal has "auto right margin" (autowrap).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 08:04:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 57728 <at> debbugs.gnu.org (full text, mbox):
>> Here is (I think) a recipe to demonstrate what the OP has in mind
>> (tested with xterm, rxvt, st, kitty, alacritty, Linux console):
>>
>> 1. emacs -Q -nw
>>
>> 2a. if your terminal emulator has a light background: M-x load-theme
>> RET modus-vivendi RET
>>
>> 2b. if your terminal emulator has a dark background: M-x load-theme RET
>> modus-operandi RET
>>
>> Observe at that point that the last character (the one at the bottom
>> right) does not have the background color of the chosen theme. So far
>> so good.
>
> The OP filed a bug for this, and he might work on it he said.
>
> This is because 'write' deliberatly leaves the bottom-right corner alone
> if the terminal has "auto right margin" (autowrap).
>
Yes, my understanding is that this bug (bug#57728) is a dependency for
bug#57607.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 08:24:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: akib <at> disroot.org, 57728 <at> debbugs.gnu.org
>> Date: Sun, 11 Sep 2022 20:18:03 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Doesn't happen here, neither on MS-Windows nor on GNU/Linux to which I
>> > SSH-login via PuTTY (which AFAIK emulates xterm). I guess this really
>> > is specific to some terminals.
>>
>> My example was with gnome-terminal on the current Ubuntu, for what it's
>> worth.
>
> Someone with access to that terminal will have to debug this.
I can reproduce on XTerm and Linux console, I hope you have access to
those.
>
> My guess is that something we do when we rewrite the lines while
> scrolling the display erases those glyphs by side effect, but Emacs
> doesn't know that. Since all the lines have the continuation glyph,
> it makes sense for Emacs to rewrite only the part of each line up to
> and excluding the continuation glyphs, relying on them to remain on
> the glass.
Yeah, tty_write_glyphs and tty_write_glyphs_with_face in term.c does the
magic, it doesn't dare to write to that (bottom-right corner) position.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 08:25:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gregory Heytings <gregory <at> heytings.org> writes:
>>
>> Thanks, but please provide more info:
>>
>> . the exact recipe to try (I tried to follow the above, but
>> couldn't, I guess I misunderstand what you mean)
>>
>> . on which terminal emulators this is known to happen, at least in
>> your case (and if you happen to know, also others)
>>
>
> Here is (I think) a recipe to demonstrate what the OP has in mind
> (tested with xterm, rxvt, st, kitty, alacritty, Linux console):
>
> 1. emacs -Q -nw
>
> 2a. if your terminal emulator has a light background: M-x load-theme
> RET modus-vivendi RET
>
> 2b. if your terminal emulator has a dark background: M-x load-theme
> RET modus-operandi RET
>
> Observe at that point that the last character (the one at the bottom
> right) does not have the background color of the chosen theme. So far
> so good.
>
> 3. M-: (define-key minibuffer-mode-map (kbd "C-t") (defun bug57728 () (interactive) (dotimes (i 5000) (insert (+ (% (random) 26) ?a))))) RET
But defun's docstring says "The return value is undefined".
>
> 4. M-: C-t
>
> 5. Now hit C-p a few times, until you see the "\" continuation
> character appear on the last character (the one at the bottom right).
> This should not happen.
>
> 6. Now press C-g. The continuation character stays there. Again this
> should not happen.
>
> (Note that the "\" continuation character disappears with C-l, after
> step 5 and after step 6.)
>
>
>
Yeah, you understood a part of my message, and Lars Ingebrigtsen
understood the other part.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 08:25:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Akib Azmain Turja <akib <at> disroot.org> writes:
> Perhaps I don't have the ability to express the problem in character, so
> I'm trying to pixel. Can you please spend some seven and half minutes
> to watch the bug in the video I attached?
Sorry for annoying you people with the 13M video who download their
emails and read offline. (This will also annoy me too, because I too
download email, and this will return to me just like a boomerang.)
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 09:10:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gregory Heytings <gregory <at> heytings.org> writes:
>>> Here is (I think) a recipe to demonstrate what the OP has in mind
>>> (tested with xterm, rxvt, st, kitty, alacritty, Linux console):
>>>
>>> 1. emacs -Q -nw
>>>
>>> 2a. if your terminal emulator has a light background: M-x
>>> load-theme RET modus-vivendi RET
>>>
>>> 2b. if your terminal emulator has a dark background: M-x load-theme
>>> RET modus-operandi RET
>>>
>>> Observe at that point that the last character (the one at the
>>> bottom right) does not have the background color of the chosen
>>> theme. So far so good.
>>
>> The OP filed a bug for this, and he might work on it he said.
>>
>> This is because 'write' deliberatly leaves the bottom-right corner
>> alone if the terminal has "auto right margin" (autowrap).
>>
>
> Yes, my understanding is that this bug (bug#57728) is a dependency for
> bug#57607.
>
>
>
No, I think fixing bug#57607 would also fix this bug (bug#57728).
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 09:10:03 GMT)
Full text and
rfc822 format available.
Message #65 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Akib Azmain Turja <akib <at> disroot.org> writes:
> Akib Azmain Turja <akib <at> disroot.org> writes:
>
>> Perhaps I don't have the ability to express the problem in character, so
>> I'm trying to pixel. Can you please spend some seven and half minutes
>> to watch the bug in the video I attached?
>
> Sorry for annoying you people with the 13M video who download their
> emails and read offline. (This will also annoy me too, because I too
> download email, and this will return to me just like a boomerang.)
But why the message is unavailable on the archive? It also wasn't
resend to me.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 09:21:01 GMT)
Full text and
rfc822 format available.
Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>>> Cc: akib <at> disroot.org, 57728 <at> debbugs.gnu.org
>>> Date: Sun, 11 Sep 2022 20:18:03 +0200
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> > Doesn't happen here, neither on MS-Windows nor on GNU/Linux to which I
>>> > SSH-login via PuTTY (which AFAIK emulates xterm). I guess this really
>>> > is specific to some terminals.
>>>
>>> My example was with gnome-terminal on the current Ubuntu, for what it's
>>> worth.
>>
>> Someone with access to that terminal will have to debug this.
>
> I can reproduce on XTerm and Linux console, I hope you have access to
> those.
I can even reproduce on term.el.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 09:21:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 11:32:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 57728 <at> debbugs.gnu.org, Akib Azmain Turja
> <akib <at> disroot.org>
> Date: Mon, 12 Sep 2022 08:38:31 +0200
>
> This is because 'write' deliberatly leaves the bottom-right corner alone
> if the terminal has "auto right margin" (autowrap).
But AFAIU, the bug actually shows that we somehow _do_ write there,
although the display engine assumes we don't. Right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 11:38:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: 57728 <at> debbugs.gnu.org
> Date: Mon, 12 Sep 2022 14:03:04 +0600
>
> > Let me turn the table and ask you: why do you think that '\' is not
> > the usual continuation glyph that Emacs always produces when the width
> > of a screen line on a TTY frame is exceeded?
> >
> >
> >
>
> OK, OK. This title is misleading. Showing the continuation glyph is
> not wrong, but it is unexpected, because Emacs doesn't write to the
> bottom-right corner.
I've seen these continuation glyphs on every TTY display where I ever
used Emacs, so I'd consider it a surprise, if not a bug, that on some
TTYs those continuation glyphs were absent. They should be there to
indicate to the user that the line is continued.
> Perhaps I don't have the ability to express the problem in character, so
> I'm trying to pixel. Can you please spend some seven and half minutes
> to watch the bug in the video I attached?
Sorry, I cannot want videos of this format.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 11:43:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 57728 <at> debbugs.gnu.org (full text, mbox):
>> This is because 'write' deliberatly leaves the bottom-right corner
>> alone if the terminal has "auto right margin" (autowrap).
>
> But AFAIU, the bug actually shows that we somehow _do_ write there,
> although the display engine assumes we don't. Right?
>
Yes, that's what the bug shows. We do (sometimes) write something there,
and we shouldn't. (And if the feature request in bug#57607 is
implemented, we should write something there, but always.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 11:59:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 11 Sep 2022 20:35:47 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Akib Azmain Turja <akib <at> disroot.org>, 57728 <at> debbugs.gnu.org
>
> 1. emacs -Q -nw
>
> 2a. if your terminal emulator has a light background: M-x load-theme RET
> modus-vivendi RET
>
> 2b. if your terminal emulator has a dark background: M-x load-theme RET
> modus-operandi RET
These do nothing in my case, but I don't think that's crucial.
> Observe at that point that the last character (the one at the bottom
> right) does not have the background color of the chosen theme. So far so
> good.
Doesn't happen here (and why "good"?).
> 3. M-: (define-key minibuffer-mode-map (kbd "C-t") (defun bug57728 () (interactive) (dotimes (i 5000) (insert (+ (% (random) 26) ?a))))) RET
>
> 4. M-: C-t
>
> 5. Now hit C-p a few times, until you see the "\" continuation character
> appear on the last character (the one at the bottom right). This should
> not happen.
It does happen. Why do you think it shouldn't? Those are all
continued lines, so they should all end with a '\'.
However, if I now C-n enough times to have the mini-window scroll, I
see that lines scrolled into the view don't have the '\' continuation
glyph. _That_ shouldn't happen. So I finally have something to work
with, thanks.
Curiously, this doesn't happen in a normal window, only in the
mini-window. Hmm...
> (Note that the "\" continuation character disappears with C-l, after step
> 5 and after step 6.)
Yes, because C-l redraws TTY frames.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:00:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> This is because 'write' deliberatly leaves the bottom-right corner alone
>> if the terminal has "auto right margin" (autowrap).
>
> But AFAIU, the bug actually shows that we somehow _do_ write there,
> although the display engine assumes we don't. Right?
My theory is that no-one but tty_write_glyphs knows that it didn't write
to the bottom-right corner. At least so far I couldn't find code that
takes this into account.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:04:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
>> But AFAIU, the bug actually shows that we somehow _do_ write there,
>> although the display engine assumes we don't. Right?
>
> Yes, that's what the bug shows. We do (sometimes) write something
> there, and we shouldn't. (And if the feature request in bug#57607 is
> implemented, we should write something there, but always.)
Perhaps insert_glyphs shifts something into the corner? Or clean_to_end
doesn't clear? If that's the case, then write_glyphs not writing to the
corner would be the culprit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:07:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: gregory <at> heytings.org, 57728 <at> debbugs.gnu.org, akib <at> disroot.org
> Date: Mon, 12 Sep 2022 13:59:05 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> This is because 'write' deliberatly leaves the bottom-right corner alone
> >> if the terminal has "auto right margin" (autowrap).
> >
> > But AFAIU, the bug actually shows that we somehow _do_ write there,
> > although the display engine assumes we don't. Right?
>
> My theory is that no-one but tty_write_glyphs knows that it didn't write
> to the bottom-right corner.
You are saying that update_frame_line tells tty_write_glyphs to write
the '\', but tty_write_glyphs doesn't in this case?
But why would we need to write that character if we know it's already
there (because all lines end with it)? That should only happen if we
scroll the region instead of rewriting lines one by one. Is that what
happens in this case?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:08:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 1. emacs -Q -nw
>>
>> 2a. if your terminal emulator has a light background: M-x load-theme
>> RET modus-vivendi RET
>>
>> 2b. if your terminal emulator has a dark background: M-x load-theme RET
>> modus-operandi RET
>
> These do nothing in my case,
>
What terminal do you use?
>
> but I don't think that's crucial.
>
It's not crucial, but it shows that Emacs doesn't write there, and it
makes the bug more apparent later.
>> Observe at that point that the last character (the one at the bottom
>> right) does not have the background color of the chosen theme. So far
>> so good.
>
> Doesn't happen here (and why "good"?).
>
That everything works as expected: the last character at the bottom right
is not touched.
>> 5. Now hit C-p a few times, until you see the "\" continuation
>> character appear on the last character (the one at the bottom right).
>> This should not happen.
>
> It does happen. Why do you think it shouldn't? Those are all continued
> lines, so they should all end with a '\'.
>
Because Emacs should never write on the last character at the bottom
right.
>
> However, if I now C-n enough times to have the mini-window scroll, I see
> that lines scrolled into the view don't have the '\' continuation glyph.
> _That_ shouldn't happen. So I finally have something to work with,
> thanks.
>
That shouldn't happen either, indeed. But that wasn't what the bug report
originally said.
>> (Note that the "\" continuation character disappears with C-l, after
>> step 5 and after step 6.)
>
> Yes, because C-l redraws TTY frames.
>
Yes, I know 😉 It was just a way to make it clearer that there's a bug:
when the frame is redrawn, the last character at the bottom right is
cleared.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:08:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> Cc: 57728 <at> debbugs.gnu.org, akib <at> disroot.org
> Date: Mon, 12 Sep 2022 14:58:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Curiously, this doesn't happen in a normal window, only in the
> mini-window. Hmm...
Of course: this only happens on the very last line. Silly me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:12:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 12 Sep 2022 12:07:12 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: akib <at> disroot.org, 57728 <at> debbugs.gnu.org
>
> >> 5. Now hit C-p a few times, until you see the "\" continuation
> >> character appear on the last character (the one at the bottom right).
> >> This should not happen.
> >
> > It does happen. Why do you think it shouldn't? Those are all continued
> > lines, so they should all end with a '\'.
>
> Because Emacs should never write on the last character at the bottom
> right.
That's immaterial: the user doesn't care what are Emacs's problems.
The user expects to see a continuation glyph at the end of every
continued line. How does Emacs accomplish that is our problem.
> > However, if I now C-n enough times to have the mini-window scroll, I see
> > that lines scrolled into the view don't have the '\' continuation glyph.
> > _That_ shouldn't happen. So I finally have something to work with,
> > thanks.
>
> That shouldn't happen either, indeed. But that wasn't what the bug report
> originally said.
I think it's exactly the same bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:21:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 57728 <at> debbugs.gnu.org (full text, mbox):
On Sep 12 2022, Eli Zaretskii wrote:
> But AFAIU, the bug actually shows that we somehow _do_ write there,
> although the display engine assumes we don't. Right?
I think it is the other way round. The display engine doesn't know that
sometimes the last character isn't written, and thus does not bother to
redraw it if the bottom line is scrolled up.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:24:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Because Emacs should never write on the last character at the bottom
>> right.
>
> That's immaterial: the user doesn't care what are Emacs's problems. The
> user expects to see a continuation glyph at the end of every continued
> line. How does Emacs accomplish that is our problem.
>
In that case, Emacs should _always_ write on the last character at the
bottom right (which is what the feature request in bug#57607 asks). Not
just in some more or less random situations. Here's a screenshot with
modus-vivendi, on which you see the white character at the bottom right.
[terminal.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:30:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> My theory is that no-one but tty_write_glyphs knows that it didn't write
>> to the bottom-right corner.
>
> You are saying that update_frame_line tells tty_write_glyphs to write
> the '\', but tty_write_glyphs doesn't in this case?
>
> But why would we need to write that character if we know it's already
> there (because all lines end with it)? That should only happen if we
> scroll the region instead of rewriting lines one by one. Is that what
> happens in this case?
I'm sorry, I don't know what exactly happens here.
Perhaps insert_glyphs, say in the middle of the line, shifts something
to the bottom-right corner, and write_glyphs is expected to overwrite
it, which it doesn't? Or something like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 12:30:03 GMT)
Full text and
rfc822 format available.
Message #113 received at 57728 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> suse.de> writes:
> On Sep 12 2022, Eli Zaretskii wrote:
>
>> But AFAIU, the bug actually shows that we somehow _do_ write there,
>> although the display engine assumes we don't. Right?
>
> I think it is the other way round. The display engine doesn't know that
> sometimes the last character isn't written, and thus does not bother to
> redraw it if the bottom line is scrolled up.
Yes, something like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 13:05:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: gregory <at> heytings.org, 57728 <at> debbugs.gnu.org, akib <at> disroot.org
>> Date: Mon, 12 Sep 2022 13:59:05 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >> This is because 'write' deliberatly leaves the bottom-right corner alone
>> >> if the terminal has "auto right margin" (autowrap).
>> >
>> > But AFAIU, the bug actually shows that we somehow _do_ write there,
>> > although the display engine assumes we don't. Right?
>>
>> My theory is that no-one but tty_write_glyphs knows that it didn't write
>> to the bottom-right corner.
>
> You are saying that update_frame_line tells tty_write_glyphs to write
> the '\', but tty_write_glyphs doesn't in this case?
>
> But why would we need to write that character if we know it's already
> there (because all lines end with it)? That should only happen if we
> scroll the region instead of rewriting lines one by one. Is that what
> happens in this case?
The symptoms indicate so.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 13:06:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: 57728 <at> debbugs.gnu.org
>> Date: Mon, 12 Sep 2022 14:03:04 +0600
>>
>> > Let me turn the table and ask you: why do you think that '\' is not
>> > the usual continuation glyph that Emacs always produces when the width
>> > of a screen line on a TTY frame is exceeded?
>> >
>> >
>> >
>>
>> OK, OK. This title is misleading. Showing the continuation glyph is
>> not wrong, but it is unexpected, because Emacs doesn't write to the
>> bottom-right corner.
>
> I've seen these continuation glyphs on every TTY display where I ever
> used Emacs, so I'd consider it a surprise, if not a bug, that on some
> TTYs those continuation glyphs were absent. They should be there to
> indicate to the user that the line is continued.
>
>> Perhaps I don't have the ability to express the problem in character, so
>> I'm trying to pixel. Can you please spend some seven and half minutes
>> to watch the bug in the video I attached?
>
> Sorry, I cannot want videos of this format.
What format should I use? AFAIK, ogv is a free format. How about
asciicast (made with asciinema)?
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 13:06:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Akib Azmain Turja <akib <at> disroot.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Akib Azmain Turja <akib <at> disroot.org>
>>> Cc: 57728 <at> debbugs.gnu.org
>>> Date: Mon, 12 Sep 2022 14:03:04 +0600
>>>
>>> > Let me turn the table and ask you: why do you think that '\' is not
>>> > the usual continuation glyph that Emacs always produces when the width
>>> > of a screen line on a TTY frame is exceeded?
>>> >
>>> >
>>> >
>>>
>>> OK, OK. This title is misleading. Showing the continuation glyph is
>>> not wrong, but it is unexpected, because Emacs doesn't write to the
>>> bottom-right corner.
>>
>> I've seen these continuation glyphs on every TTY display where I ever
>> used Emacs, so I'd consider it a surprise, if not a bug, that on some
>> TTYs those continuation glyphs were absent. They should be there to
>> indicate to the user that the line is continued.
>>
>>> Perhaps I don't have the ability to express the problem in character, so
>>> I'm trying to pixel. Can you please spend some seven and half minutes
>>> to watch the bug in the video I attached?
>>
>> Sorry, I cannot want videos of this format.
>
> What format should I use? AFAIK, ogv is a free format. How about
> asciicast (made with asciinema)?
Looks like others have figured out the problem; do I really need to
explain it?
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Mon, 12 Sep 2022 13:14:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: 57728 <at> debbugs.gnu.org
> Date: Mon, 12 Sep 2022 18:59:09 +0600
>
> > Sorry, I cannot want videos of this format.
>
> What format should I use? AFAIK, ogv is a free format. How about
> asciicast (made with asciinema)?
There's no need for you to bother with this anymore, as I've succeeded
to reproduce the problem using a variant of the recipe posted by
Gregory.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Tue, 13 Sep 2022 04:58:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 57728 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: 57728 <at> debbugs.gnu.org
>> Date: Mon, 12 Sep 2022 18:59:09 +0600
>>
>> > Sorry, I cannot want videos of this format.
>>
>> What format should I use? AFAIK, ogv is a free format. How about
>> asciicast (made with asciinema)?
>
> There's no need for you to bother with this anymore, as I've succeeded
> to reproduce the problem using a variant of the recipe posted by
> Gregory.
>
> Thanks.
OK, but where the message with the attachment gone? I can't find it in
bug-gnu-emacs archive.
--
Akib Azmain Turja
Find me on Mastodon at @akib <at> hostux.social.
This message is signed by me with my GnuPG key. Its fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57728; Package
emacs.
(Tue, 13 Sep 2022 11:32:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 57728 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: 57728 <at> debbugs.gnu.org
> Date: Tue, 13 Sep 2022 00:48:31 +0600
>
> OK, but where the message with the attachment gone?
To the trash bin, I suppose. The attachment was too large. You
shouldn't post such large attachments.
This bug report was last modified 2 years and 331 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.