GNU bug report logs - #78859
31.0.50; Viewing mime part in Rmail sets truncate-lines

Previous Next

Package: emacs;

Reported by: rms <at> gnu.org

Date: Sat, 21 Jun 2025 23:22:02 UTC

Severity: normal

Found in version 31.0.50

To reply to this bug, email your comments to 78859 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sat, 21 Jun 2025 23:22:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to rms <at> gnu.org:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 21 Jun 2025 23:22:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sat, 21 Jun 2025 19:21:24 -0400
When I am looking at a message in Rmail, and it has a hidden
HTML mime part, and I activate the Show button, that sets
truncate-lines in te Rmail buffer, _permanently_.

It is done by this code in shr.el:

    ;; This probably won't work very well.
    (when (> (+ (cl-loop for width across sketch-widths
		         summing (1+ width))
		shr-indentation shr-table-separator-pixel-width)
	     (frame-width))
      (setq truncate-lines t))

I think the comment was prophetic.  This is a pain in the neck, as it
affects all other messages I look at in that buffer.  But I don't
understand this code enough to try to fix it.

Why, I wondered, does it use shr.el instead of running lynx?
Apparengly because of this in rmailmm.el:

    (defcustom rmail-mime-render-html-function
      (cond ((fboundp 'libxml-parse-html-region) #'rmail-mime-render-html-shr)
            ((executable-find "lynx") #'rmail-mime-render-html-lynx)
            (t nil))

That enabkes me to prevent the problem in my .emacs,
but it deserves a real fix that I can't wrote.



In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 2.24.33, cairo version 1.16.0) of 2024-08-01 built on freetop
Repository revision: a2c439db687774f7b57959c39560993579c5d1bd
Repository branch: master
System Description: Trisquel GNU/Linux Aramo (11.0.1)

Configured using:
 'configure 'CFLAGS=-O0 -g' --with-gnutls=ifavailable'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GPM GSETTINGS HARFBUZZ JPEG LIBOTF
LIBSELINUX LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2
XPM GTK2 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: RMAIL

Minor modes in effect:
  gpm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: linux
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug doc-view filenotify image-mode exif novice apropos
completion warnings cl-print debug backtrace find-func vc-git
vc-dispatcher bug-reference shortdoc comp-common ps-mode ps-samp
zeroconf printing man ps-mule ps-print ps-print-loaddefs lpr
display-line-numbers two-column kmacro rect format-spec battery dbus
jka-compr noutline outline help-fns radix-tree etags fileloop
generator xref project mule-util cal-move cal-menu calendar
cal-loaddefs epa-mail diff-mode track-changes diff sh-script rx
executable quail parse-time iso8601 vc-cvs vc-rcs log-view easy-mmode
pcvs-util mhtml-mode css-mode smie eww xdg url-queue mm-url gnus
nnheader range wid-edit color js c-ts-common treesit imenu cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs sgml-mode facemenu ispell shell pcomplete thingatpt
files-x grep compile comint ansi-osc ansi-color ring rmailkwd cl-extra
help-mode textsec uni-scripts idna-mapping ucs-normalize
uni-confusable textsec-check bookmark pp shr pixel-fill kinsoku
url-file svg xml dom rmailout dabbrev misearch multi-isearch mailalias
qp rmailmm message sendmail yank-media puny rfc822 mml mml-sec epa epg
epg-config gnus-util text-property-search time-date mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
dired-aux dired dired-loaddefs t-mouse term/linux view derived
disp-table advice rmailsum rmail rfc6068 rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils finder-inf info osm-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
icons password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd touch-screen 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 dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty
move-toolbar make-network-process emacs)

Memory information:
((conses 16 883551 159991) (symbols 48 35406 40)
 (strings 32 136764 12191) (string-bytes 1 3162774) (vectors 16 75645)
 (vector-slots 8 1646651 179463) (floats 8 558 486)
 (intervals 56 84322 3761) (buffers 984 116))
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sun, 22 Jun 2025 05:23:02 GMT) Full text and rfc822 format available.

Message #8 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sun, 22 Jun 2025 08:14:46 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Date: Sat, 21 Jun 2025 19:21:24 -0400
> 
> 
> When I am looking at a message in Rmail, and it has a hidden
> HTML mime part, and I activate the Show button, that sets
> truncate-lines in te Rmail buffer, _permanently_.

FTR: this doesn't seem to happen _every_ time I view HTML MIME message
in Rmail.  Which makes sense, since shr.el does that only when certain
conditions are true:

> It is done by this code in shr.el:
> 
>     ;; This probably won't work very well.
>     (when (> (+ (cl-loop for width across sketch-widths
> 		         summing (1+ width))
> 		shr-indentation shr-table-separator-pixel-width)
> 	     (frame-width))
>       (setq truncate-lines t))
> 
> I think the comment was prophetic.  This is a pain in the neck, as it
> affects all other messages I look at in that buffer.  But I don't
> understand this code enough to try to fix it.

I see no reason to fix shr.el, I have no reasons to believe it doesn't
DTRT in this case.  I think it should be enough to reset
truncate-lines back to its original value in rmail-show-message-1,
before showing the next message, so that the following messages aren't
affected.  Do you agree?

> Why, I wondered, does it use shr.el instead of running lynx?

Because it is always better to do something using Emacs' own
capabilities than rely on external programs (which may or may not be
available).  E.g., I don't have Lynx installed here.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sun, 22 Jun 2025 05:25:02 GMT) Full text and rfc822 format available.

Message #11 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sun, 22 Jun 2025 08:23:45 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Date: Sat, 21 Jun 2025 19:21:24 -0400
> 
> 
> When I am looking at a message in Rmail, and it has a hidden
> HTML mime part, and I activate the Show button, that sets
> truncate-lines in te Rmail buffer, _permanently_.

FTR: this doesn't seem to happen _every_ time I view HTML MIME message
in Rmail.  Which makes sense, since shr.el does that only when certain
conditions are true:

> It is done by this code in shr.el:
> 
>     ;; This probably won't work very well.
>     (when (> (+ (cl-loop for width across sketch-widths
> 		         summing (1+ width))
> 		shr-indentation shr-table-separator-pixel-width)
> 	     (frame-width))
>       (setq truncate-lines t))
> 
> I think the comment was prophetic.  This is a pain in the neck, as it
> affects all other messages I look at in that buffer.  But I don't
> understand this code enough to try to fix it.

I see no reason to fix shr.el, I have no reasons to believe it doesn't
DTRT in this case.  I think it should be enough to reset
truncate-lines back to its original value in rmail-show-message-1,
before showing the next message, so that the following messages aren't
affected.  Do you agree?

> Why, I wondered, does it use shr.el instead of running lynx?

Because it is always better to do something using Emacs' own
capabilities than rely on external programs (which may or may not be
available).  E.g., I don't have Lynx installed here, and neither do I
have it on my development account om gnu.org machines.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Wed, 25 Jun 2025 02:21:01 GMT) Full text and rfc822 format available.

Message #14 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Tue, 24 Jun 2025 22:20:01 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I need to point out that the problem is not limited to confusing dispay
of _other_ messages in the same buffer.  It also confuses display
of other mime parts in the same message, that are visible at the same time
as the decoded HTML part.

  > I see no reason to fix shr.el, I have no reasons to believe it doesn't
  > DTRT in this case.  I think it should be enough to reset
  > truncate-lines back to its original value in rmail-show-message-1,

Maybe it can be fixed by resetting truncate-lines.   But that will only fix
the simplest case. in which the only part of this message is that one
HTML mime part.  To avoid obscuring other plain text mime parts,
it would be necesary to reset truncate-lines in rmail-mime-render-html-shr,
immediately after calling shr-insert-document.

If it does that, then shr-insert-document might as well not set truncate-lines,
as that wouldn't affect any redisplsy.  I would be happy with that result,
but if there is a good reason to set truncate-lines, some more complex
fix would be required.

Basically, it looks like shr.el is assuming that what it isprocessing
will be the whole contents of the buffer, and that isn't so in cases
like this.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Wed, 25 Jun 2025 11:36:03 GMT) Full text and rfc822 format available.

Message #17 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Wed, 25 Jun 2025 14:34:40 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Cc: 78859 <at> debbugs.gnu.org
> Date: Tue, 24 Jun 2025 22:20:01 -0400
> 
> I need to point out that the problem is not limited to confusing dispay
> of _other_ messages in the same buffer.  It also confuses display
> of other mime parts in the same message, that are visible at the same time
> as the decoded HTML part.

Do you have an example of an email message where I could see this
problem?

In general, email messages with more than a single MIME part, not all
of them HTML, are quite rare.  I don't remember the last time I've
seen anything like that.

>   > I see no reason to fix shr.el, I have no reasons to believe it doesn't
>   > DTRT in this case.  I think it should be enough to reset
>   > truncate-lines back to its original value in rmail-show-message-1,
> 
> Maybe it can be fixed by resetting truncate-lines.   But that will only fix
> the simplest case. in which the only part of this message is that one
> HTML mime part.  To avoid obscuring other plain text mime parts,
> it would be necesary to reset truncate-lines in rmail-mime-render-html-shr,
> immediately after calling shr-insert-document.
> 
> If it does that, then shr-insert-document might as well not set truncate-lines,
> as that wouldn't affect any redisplsy.  I would be happy with that result,
> but if there is a good reason to set truncate-lines, some more complex
> fix would be required.

I think it sets truncate-lines because it uses functions that simulate
display, and so that setting affects how HTML is laid out in the
buffer by shr.el.  So maybe what you suggest above is the best fix we
can easily make.

> Basically, it looks like shr.el is assuming that what it isprocessing
> will be the whole contents of the buffer, and that isn't so in cases
> like this.

But in almost all the cases it is, IME.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sun, 29 Jun 2025 02:45:05 GMT) Full text and rfc822 format available.

Message #20 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sat, 28 Jun 2025 22:44:09 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In general, email messages with more than a single MIME part, not all
  > of them HTML, are quite rare.  I don't remember the last time I've
  > seen anything like that.

I received one a few days ago, and that is how I noticed this problem.
I could not find it again the next day, because I get hundreds of
emails per day and I don't know which day that one actually arrived.

In any case, I assure you it did happen.  And it is obvious why the code
caused that result.

  > I think it sets truncate-lines because it uses functions that simulate
  > display, and so that setting affects how HTML is laid out in the
  > buffer by shr.el.  So maybe what you suggest above is the best fix we
  > can easily make.

Are you saying that the value of truncate-lines that maters
is the value it has while shr.el is running?

If so, maybe binding truncate-lines only around the execution of
shr.el would give ideal results!



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sun, 29 Jun 2025 05:43:02 GMT) Full text and rfc822 format available.

Message #23 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sun, 29 Jun 2025 08:42:32 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Cc: 78859 <at> debbugs.gnu.org
> Date: Sat, 28 Jun 2025 22:44:09 -0400
> 
>   > In general, email messages with more than a single MIME part, not all
>   > of them HTML, are quite rare.  I don't remember the last time I've
>   > seen anything like that.
> 
> I received one a few days ago, and that is how I noticed this problem.
> I could not find it again the next day, because I get hundreds of
> emails per day and I don't know which day that one actually arrived.
> 
> In any case, I assure you it did happen.  And it is obvious why the code
> caused that result.

I'd like to have an example of such a message, if only to test the
proposed solutions.

>   > I think it sets truncate-lines because it uses functions that simulate
>   > display, and so that setting affects how HTML is laid out in the
>   > buffer by shr.el.  So maybe what you suggest above is the best fix we
>   > can easily make.
> 
> Are you saying that the value of truncate-lines that maters
> is the value it has while shr.el is running?

Yes.

> If so, maybe binding truncate-lines only around the execution of
> shr.el would give ideal results!

That's what I tend to think, yes.  But we need an example of such a
message to test these ideas.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sun, 29 Jun 2025 07:28:02 GMT) Full text and rfc822 format available.

Message #26 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Francesco Potortì <pot <at> potorti.it>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sun, 29 Jun 2025 09:27:28 +0200
Eli:
>> From: Richard Stallman <rms <at> gnu.org>
>> Cc: 78859 <at> debbugs.gnu.org
>> Date: Sat, 28 Jun 2025 22:44:09 -0400
>> 
>>   > In general, email messages with more than a single MIME part, not all
>>   > of them HTML, are quite rare.  I don't remember the last time I've
>>>   > seen anything like that.
>> 
>> I received one a few days ago, and that is how I noticed this problem.
>
>I'd like to have an example of such a message, if only to test the
>proposed solutions.

I use RMAIL and receive tons of emails per day.  I can try and look for such a message and keep it if I see one.  But I need to understand what is an email message with "more than a single MIME part, not all of them HTML".  If an email with a text/plain part followed by a text/html part, not embedded into a multipart container, satisfies your definition, I think I can easily find one.

-- fp




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Mon, 30 Jun 2025 11:44:02 GMT) Full text and rfc822 format available.

Message #29 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Mon, 30 Jun 2025 14:42:54 +0300
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Sun, 29 Jun 2025 09:27:28 +0200
> Cc: 78859 <at> debbugs.gnu.org,
> 	rms <at> gnu.org
> 
> Eli:
> >> From: Richard Stallman <rms <at> gnu.org>
> >> Cc: 78859 <at> debbugs.gnu.org
> >> Date: Sat, 28 Jun 2025 22:44:09 -0400
> >> 
> >>   > In general, email messages with more than a single MIME part, not all
> >>   > of them HTML, are quite rare.  I don't remember the last time I've
> >>>   > seen anything like that.
> >> 
> >> I received one a few days ago, and that is how I noticed this problem.
> >
> >I'd like to have an example of such a message, if only to test the
> >proposed solutions.
> 
> I use RMAIL and receive tons of emails per day.  I can try and look for such a message and keep it if I see one.  But I need to understand what is an email message with "more than a single MIME part, not all of them HTML".  If an email with a text/plain part followed by a text/html part, not embedded into a multipart container, satisfies your definition, I think I can easily find one.

I'd love to have such an email.  The telltale sign that an email
message is a good example of what's being discussed here is that Emacs
sets truncate-lines = t in the RMAIL buffer when viewing the message.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Mon, 30 Jun 2025 13:13:02 GMT) Full text and rfc822 format available.

Message #32 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Francesco Potortì <pot <at> potorti.it>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Mon, 30 Jun 2025 15:12:21 +0200
>
>> From: Francesco Potortì <pot <at> potorti.it>
>> Date: Sun, 29 Jun 2025 09:27:28 +0200
>> Cc: 78859 <at> debbugs.gnu.org,
>> 	rms <at> gnu.org
>> 
>> Eli:
>> >> From: Richard Stallman <rms <at> gnu.org>
>> >> Cc: 78859 <at> debbugs.gnu.org
>> >> Date: Sat, 28 Jun 2025 22:44:09 -0400
>> >> 
>> >>   > In general, email messages with more than a single MIME part, not all
>> >>   > of them HTML, are quite rare.  I don't remember the last time I've
>> >>>   > seen anything like that.
>> >> 
>> >> I received one a few days ago, and that is how I noticed this problem.
>> >
>> >I'd like to have an example of such a message, if only to test the
>> >proposed solutions.
>> 
>> If an email with a text/plain part followed by a text/html part, not embedded into a multipart container, satisfies your definition, I think I can easily find one.
>
>I'd love to have such an email.

I am sure there's a function in Emacs that garbles text to obtain a mild obfuscation effect, but I can't find it, can you point me to it?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Mon, 30 Jun 2025 13:35:03 GMT) Full text and rfc822 format available.

Message #35 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Mon, 30 Jun 2025 16:33:28 +0300
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Mon, 30 Jun 2025 15:12:21 +0200
> Cc: rms <at> gnu.org,
> 	78859 <at> debbugs.gnu.org
> 
> >> If an email with a text/plain part followed by a text/html part, not embedded into a multipart container, satisfies your definition, I think I can easily find one.
> >
> >I'd love to have such an email.
> 
> I am sure there's a function in Emacs that garbles text to obtain a mild obfuscation effect, but I can't find it, can you point me to it?

rot13, I guess?  But be sure not to obfuscate the HTML markup...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Wed, 02 Jul 2025 02:16:01 GMT) Full text and rfc822 format available.

Message #38 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: eliz <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Tue, 01 Jul 2025 22:15:30 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I use RMAIL and receive tons of emails per day.  I can try and
  > look for such a message and keep it if I see one.  But I need to
  > understand what is an email message with "more than a single MIME
  > part, not all of them HTML".  If an email with a text/plain part
  > followed by a text/html part, not embedded into a multipart
  > container, satisfies your definition, I think I can easily find
  > one.

that's exactly what I mean.  But in order to manifest this bug,
it needs to have some lines that are long enough to be continued
or truncated.

The bug causes those lines to be truncated, though
normally they would have been continued.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Wed, 02 Jul 2025 20:41:01 GMT) Full text and rfc822 format available.

Message #41 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Francesco Potortì <pot <at> potorti.it>
To: rms <at> gnu.org
Cc: eliz <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Wed, 02 Jul 2025 22:40:03 +0200
[Message part 1 (text/plain, inline)]
>  > I use RMAIL and receive tons of emails per day.  I can try and
>  > look for such a message and keep it if I see one.  But I need to
>  > understand what is an email message with "more than a single MIME
>  > part, not all of them HTML".  If an email with a text/plain part
>  > followed by a text/html part, not embedded into a multipart
>  > container, satisfies your definition, I think I can easily find
>  > one.
>
>that's exactly what I mean.  But in order to manifest this bug,
>it needs to have some lines that are long enough to be continued
>or truncated.

Let's try with this one.

[emacs-rmail-bug2.mbox (raw, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Thu, 03 Jul 2025 04:53:02 GMT) Full text and rfc822 format available.

Message #44 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Thu, 03 Jul 2025 07:52:30 +0300
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Wed, 02 Jul 2025 22:40:03 +0200
> Cc: 78859 <at> debbugs.gnu.org,
> 	eliz <at> gnu.org
> 
> >  > I use RMAIL and receive tons of emails per day.  I can try and
> >  > look for such a message and keep it if I see one.  But I need to
> >  > understand what is an email message with "more than a single MIME
> >  > part, not all of them HTML".  If an email with a text/plain part
> >  > followed by a text/html part, not embedded into a multipart
> >  > container, satisfies your definition, I think I can easily find
> >  > one.
> >
> >that's exactly what I mean.  But in order to manifest this bug,
> >it needs to have some lines that are long enough to be continued
> >or truncated.
> 
> Let's try with this one.

Thanks.  But visiting this mbox in Rmail leaves me with an Rmail
buffer where truncate-lines is nil.  Do you see the value of t on your
system?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Thu, 03 Jul 2025 08:34:02 GMT) Full text and rfc822 format available.

Message #47 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Francesco Potortì <pot <at> potorti.it>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Thu, 03 Jul 2025 10:33:09 +0200
>> From: Francesco Potortì <pot <at> potorti.it>
>> Date: Wed, 02 Jul 2025 22:40:03 +0200
>> 
>> >  > I use RMAIL and receive tons of emails per day.  I can try and
>> >  > look for such a message and keep it if I see one.  But I need to
>> >  > understand what is an email message with "more than a single MIME
>> >  > part, not all of them HTML".  If an email with a text/plain part
>> >  > followed by a text/html part, not embedded into a multipart
>> >  > container, satisfies your definition, I think I can easily find
>> >  > one.
>> >
>> >that's exactly what I mean.  But in order to manifest this bug,
>> >it needs to have some lines that are long enough to be continued
>> >or truncated.
>> 
>> Let's try with this one.
>
>Thanks.  But visiting this mbox in Rmail leaves me with an Rmail
>buffer where truncate-lines is nil.  Do you see the value of t on your
>system?

I tried with emacs -Q -nw and truncate-lines is nil, on this mbox file and on any other email that I have in my RMAIL.  As you can see, there are two separate text/plain and text/email parts and there are long lines, but I see no bad effect.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Thu, 03 Jul 2025 09:45:02 GMT) Full text and rfc822 format available.

Message #50 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Thu, 03 Jul 2025 12:43:43 +0300
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Thu, 03 Jul 2025 10:33:09 +0200
> Cc: 78859 <at> debbugs.gnu.org,
> 	rms <at> gnu.org
> 
> >> From: Francesco Potortì <pot <at> potorti.it>
> >> Date: Wed, 02 Jul 2025 22:40:03 +0200
> >> 
> >> >  > I use RMAIL and receive tons of emails per day.  I can try and
> >> >  > look for such a message and keep it if I see one.  But I need to
> >> >  > understand what is an email message with "more than a single MIME
> >> >  > part, not all of them HTML".  If an email with a text/plain part
> >> >  > followed by a text/html part, not embedded into a multipart
> >> >  > container, satisfies your definition, I think I can easily find
> >> >  > one.
> >> >
> >> >that's exactly what I mean.  But in order to manifest this bug,
> >> >it needs to have some lines that are long enough to be continued
> >> >or truncated.
> >> 
> >> Let's try with this one.
> >
> >Thanks.  But visiting this mbox in Rmail leaves me with an Rmail
> >buffer where truncate-lines is nil.  Do you see the value of t on your
> >system?
> 
> I tried with emacs -Q -nw and truncate-lines is nil, on this mbox file and on any other email that I have in my RMAIL.  As you can see, there are two separate text/plain and text/email parts and there are long lines, but I see no bad effect.

Thanks, this matches my experience.

But this bug report is about the cases where Emacs does set
truncate-lines to a non-nil value, as side effect of rendering a
message with HTML body using shr.el.  So I need an example of such a
message to (a) see the issue in action, and (b) test potential
solutions.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Thu, 03 Jul 2025 11:47:02 GMT) Full text and rfc822 format available.

Message #53 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Francesco Potortì <pot <at> potorti.it>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Thu, 03 Jul 2025 13:46:45 +0200
>> From: Francesco Potortì <pot <at> potorti.it>
>> Date: Thu, 03 Jul 2025 10:33:09 +0200
>> 
>> >> From: Francesco Potortì <pot <at> potorti.it>
>> >> Date: Wed, 02 Jul 2025 22:40:03 +0200
>> >> 
>> >> >  > I use RMAIL and receive tons of emails per day.  I can try and
>> >> >  > look for such a message and keep it if I see one.  But I need to
>> >> >  > understand what is an email message with "more than a single MIME
>> >> >  > part, not all of them HTML".  If an email with a text/plain part
>> >> >  > followed by a text/html part, not embedded into a multipart
>> >> >  > container, satisfies your definition, I think I can easily find
>> >> >  > one.
>> >> >
>> >> >that's exactly what I mean.  But in order to manifest this bug,
>> >> >it needs to have some lines that are long enough to be continued
>> >> >or truncated.
>> >> 
>> >> Let's try with this one.
>> >
>> >Thanks.  But visiting this mbox in Rmail leaves me with an Rmail
>> >buffer where truncate-lines is nil.  Do you see the value of t on your
>> >system?
>> 
>> I tried with emacs -Q -nw and truncate-lines is nil, on this mbox file and on any other email that I have in my RMAIL.  As you can see, there are two separate text/plain and text/email parts and there are long lines, but I see no bad effect.
>
>Thanks, this matches my experience.
>
>But this bug report is about the cases where Emacs does set
>truncate-lines to a non-nil value, as side effect of rendering a
>message with HTML body using shr.el.  So I need an example of such a
>message to (a) see the issue in action, and (b) test potential
>solutions.

I tried to craft a message based on the previous one, where I removed the Mime line-continuation "=C-j" sequences, but still I see truncate-lines set to nil.

Anyway, I will keep an eye on this issue and see if I can find one instance where this happens.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Thu, 03 Jul 2025 13:26:02 GMT) Full text and rfc822 format available.

Message #56 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: rms <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Thu, 03 Jul 2025 16:25:27 +0300
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Thu, 03 Jul 2025 13:46:45 +0200
> Cc: 78859 <at> debbugs.gnu.org,
> 	rms <at> gnu.org
> 
> >> I tried with emacs -Q -nw and truncate-lines is nil, on this mbox file and on any other email that I have in my RMAIL.  As you can see, there are two separate text/plain and text/email parts and there are long lines, but I see no bad effect.
> >
> >Thanks, this matches my experience.
> >
> >But this bug report is about the cases where Emacs does set
> >truncate-lines to a non-nil value, as side effect of rendering a
> >message with HTML body using shr.el.  So I need an example of such a
> >message to (a) see the issue in action, and (b) test potential
> >solutions.
> 
> I tried to craft a message based on the previous one, where I removed the Mime line-continuation "=C-j" sequences, but still I see truncate-lines set to nil.
> 
> Anyway, I will keep an eye on this issue and see if I can find one instance where this happens.

Thanks, let's hope it will happen soon enough.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Fri, 04 Jul 2025 02:49:02 GMT) Full text and rfc822 format available.

Message #59 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: eliz <at> gnu.org, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Thu, 03 Jul 2025 22:48:33 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >  > I use RMAIL and receive tons of emails per day.  I can try and
  > >  > look for such a message and keep it if I see one.  But I need to
  > >  > understand what is an email message with "more than a single MIME
  > >  > part, not all of them HTML".  If an email with a text/plain part
  > >  > followed by a text/html part, not embedded into a multipart
  > >  > container, satisfies your definition, I think I can easily find
  > >  > one.
  > >
  > >that's exactly what I mean.  But in order to manifest this bug,
  > >it needs to have some lines that are long enough to be continued
  > >or truncated.

  > Let's try with this one.

When I did 
(set-frame-width nil 65)
some of those lines became continued.  But the problem I reported
did not occur, because I've patched that bug here.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Fri, 04 Jul 2025 07:25:02 GMT) Full text and rfc822 format available.

Message #62 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: pot <at> potorti.it, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Fri, 04 Jul 2025 10:24:17 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Cc: 78859 <at> debbugs.gnu.org, eliz <at> gnu.org
> Date: Thu, 03 Jul 2025 22:48:33 -0400
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > >  > I use RMAIL and receive tons of emails per day.  I can try and
>   > >  > look for such a message and keep it if I see one.  But I need to
>   > >  > understand what is an email message with "more than a single MIME
>   > >  > part, not all of them HTML".  If an email with a text/plain part
>   > >  > followed by a text/html part, not embedded into a multipart
>   > >  > container, satisfies your definition, I think I can easily find
>   > >  > one.
>   > >
>   > >that's exactly what I mean.  But in order to manifest this bug,
>   > >it needs to have some lines that are long enough to be continued
>   > >or truncated.
> 
>   > Let's try with this one.
> 
> When I did 
> (set-frame-width nil 65)
> some of those lines became continued.  But the problem I reported
> did not occur, because I've patched that bug here.

I tried with set-frame-width of 60 now, and I still get truncate-lines
of nil.  This is with unpatched Emacs.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Mon, 07 Jul 2025 02:20:02 GMT) Full text and rfc822 format available.

Message #65 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pot <at> potorti.it, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sun, 06 Jul 2025 22:19:20 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I tried with set-frame-width of 60 now, and I still get truncate-lines
  > of nil.  This is with unpatched Emacs.

I don't understand why.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sat, 12 Jul 2025 07:19:02 GMT) Full text and rfc822 format available.

Message #68 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sat, 12 Jul 2025 10:17:46 +0300
> Cc: 78859 <at> debbugs.gnu.org
> Date: Sun, 29 Jun 2025 08:42:32 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Richard Stallman <rms <at> gnu.org>
> > Cc: 78859 <at> debbugs.gnu.org
> > Date: Sat, 28 Jun 2025 22:44:09 -0400
> > 
> >   > I think it sets truncate-lines because it uses functions that simulate
> >   > display, and so that setting affects how HTML is laid out in the
> >   > buffer by shr.el.  So maybe what you suggest above is the best fix we
> >   > can easily make.
> > 
> > Are you saying that the value of truncate-lines that maters
> > is the value it has while shr.el is running?
> 
> Yes.
> 
> > If so, maybe binding truncate-lines only around the execution of
> > shr.el would give ideal results!
> 
> That's what I tend to think, yes.  But we need an example of such a
> message to test these ideas.

I now see that I was wrong, and just let-binding truncate-lines will
not do the job.  But I'm still unable to find an email message where I
am left with truncate-lines non-nil after rendering it with shr, so an
example of such a message will be appreciated.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78859; Package emacs. (Sat, 12 Jul 2025 08:20:01 GMT) Full text and rfc822 format available.

Message #71 received at 78859 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: pot <at> potorti.it, 78859 <at> debbugs.gnu.org
Subject: Re: bug#78859: 31.0.50; Viewing mime part in Rmail sets truncate-lines
Date: Sat, 12 Jul 2025 11:19:15 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Cc: pot <at> potorti.it, 78859 <at> debbugs.gnu.org
> Date: Sun, 06 Jul 2025 22:19:20 -0400
> 
>   > I tried with set-frame-width of 60 now, and I still get truncate-lines
>   > of nil.  This is with unpatched Emacs.
> 
> I don't understand why.

Neither do I.

Did you visit the mbox file in "emacs -Q"?  If not, perhaps some of
your customizations will help me reproduce the issue on my system?




This bug report was last modified 4 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.