Gnus development mailing list
 help / color / mirror / Atom feed
From: Lloyd Zusman <ljz@asfast.com>
Subject: Re: Inline MIME display -- when and when not?
Date: 30 Nov 1998 07:13:34 -0500	[thread overview]
Message-ID: <ltk90dgyz5.fsf@asfast.com> (raw)
In-Reply-To: Hrvoje Niksic's message of "30 Nov 1998 11:30:56 +0100"

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > [ ... ]
> 
> Related to crashes: some of the image code has been revamped for 21.x;
> you may wish to compile a 21.0 beta and see if the crashes disappear.

I'll give it a try.

> > [ ... ]
>
> The file descriptor leakage you describe sounds familiar.  I think
> this has also been fixed in 21.0.

Given these errors in XEmaces versions < 21.0 for images displayed
inline *and* via an external viewer, shouldn't perhaps the older
method for viewing images be used?  It doesn't seem right to be making
use of an image viewing method that only works in a beta version of
XEmacs.  Once XEmacs becomes "final", perhaps we could then start
using the newer method.

I never had problems with images when the older viewing method was
used, whether they showed up inline or were displayed via an external
viewer.

> > But prior to these errors occurring, taller-than-buffer images
> > display perfectly fine, both inline within my article buffer,
> 
> As explained elsewhere, this cannot be true, at least for the values
> of "perfectly fine" that I'm using.

Well, it is indeed true that we disagree on the meaning of "perfectly
fine", since as I mentioned earlier, the current behavior is OK with
me (as long as I can avoid the crashes and file descriptor leakage).
Given that some of us (one of us?) find the current behavior to be
acceptable, this does seem to indicate that an option controlling
taller-than-buffer images might be in order.  The default could be to
not display them inline.

Of course, I could always hack my own `mm-image-fit-p' via `defadvice'
or some other method, if no option is provided ... :)

-- 
 Lloyd Zusman
 ljz@asfast.com


  reply	other threads:[~1998-11-30 12:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-11-30  0:27 Lloyd Zusman
1998-11-30  2:49 ` Lars Magne Ingebrigtsen
1998-11-30  3:00   ` Lloyd Zusman
1998-11-30  3:03     ` Hrvoje Niksic
1998-11-30  3:25   ` Lloyd Zusman
1998-11-30  3:54     ` Hrvoje Niksic
1998-11-30  4:03       ` Lloyd Zusman
1998-11-30  4:22         ` Lloyd Zusman
1998-11-30 10:30           ` Hrvoje Niksic
1998-11-30 12:13             ` Lloyd Zusman [this message]
1998-11-30 12:32               ` Hrvoje Niksic
1998-11-30 13:41                 ` Lloyd Zusman
1998-11-30 15:37                   ` Lars Magne Ingebrigtsen
1998-11-30 10:28         ` Hrvoje Niksic
1998-11-30 12:01           ` Lloyd Zusman
1998-11-30 12:30             ` Hrvoje Niksic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ltk90dgyz5.fsf@asfast.com \
    --to=ljz@asfast.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).