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

Previous Next

Full log

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.

Previous Next

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