flim email send: break with C-g?
Katsumi Yamaoka
yamaoka at jpl.org
Tue Jul 13 10:50:05 JST 2004
>>>>> In [emacs-mime-en : No.00143]
>>>>> John Owens <wl.20.jowens at spamgourmet.com> wrote:
> I send mail through flim from home (on a DSL connection). Sometimes I
> assemble a large message, start to send it, and then realize it's
> going to take a long long time to send because it's big. Then I'd like
> to hit control-g to cancel the send.
What modules of FLIM are you using and how are you using them
incorporated with VM and XEmacs? There is no information for
helping you. As far as I know, there is no code which blocks
C-g in FLIM.
> However, C-g does not seem to work during a message send. It would
> seem like hitting C-g during a message send would be a useful feature,
> and would simply return to the buffer from which the mail was being
> sent (and would leave the message unchanged).
> Currently, I can't break out of a message send at all and have to quit
> emacs and restart.
What is likely is XEmacs is being caught by an external process,
which is for communicating to a SMTP server for example.
Otherwise, after connecting to a server, when it is late to
begin to send data, I experienced that a server didn't respond.
A body encoder or something may waste time then for a big mail.
(If you should be using T-gnus, I recommend you check out the
latest version from CVS. It has been much improved for that.)
In such a case, you might need to use ELP to analyze Emacs
processes. Here is an extract from the Gnus manual:
A fancier approach is to use the elisp profiler, ELP. The profiler
is (or should be) fully documented elsewhere, but to get you started
there are a few steps that need to be followed. First, instrument the
part of Gnus you are interested in for profiling, e.g. `M-x
elp-instrument-package RET gnus' or `M-x elp-instrument-package RET
message'. Then perform the operation that is slow and press `M-x
elp-results'. You will then see which operations that takes time, and
can debug them further. If the entire operation takes much longer than
the time spent in the slowest function in the profiler output, you
probably profiled the wrong part of Gnus. To reset profiling
statistics, use `M-x elp-reset-all'. `M-x elp-restore-all' is supposed
to remove profiling, but given the complexities and dynamic code
generation in Gnus, it might not always work perfectly.
P.S. I will be absent on business from Wednesday to the weekend.
--
Katsumi Yamaoka <yamaoka at jpl.org>
More information about the Emacs-mime-en
mailing list