bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7789: cannot send smtpmail using gmail & tls on woe32


From: Eli Zaretskii
Subject: bug#7789: cannot send smtpmail using gmail & tls on woe32
Date: Tue, 18 Jan 2011 17:45:42 -0500

> From: claudio.bley@gmail.com (Claudio Bley)
> Date: Tue, 18 Jan 2011 16:33:41 +0100
> Cc: 
> 
> > > gnutls-cli waits for a SIGALRM to initiate the STARTTLS handshake --
> > > which Emacs isn't able to send -- or, alternatively, an EOF -- which
> > > doesn't work because communication is done over a pipe instead of a
> > > PTY.
> > 
> > Is this a bug in the ported gnutls, in Emacs, or in both?
> 
> I'd say it's a deficiency of the platform.

A port that doesn't take platform deficiencies into consideration is a
broken port.  I was asking where should the correction be: in gnutls
or in Emacs, or in both?

> Woe32 has no signal and no PTY support. So, the signal support
> has been ifdef'ed out in gnutls and Emacs for Woe32.

If it has been ifdefed out, how are users supposed to do on Windows
what they do on GNU/Linux by using signals?

> > > I'm using cygwin's gnutls-cli and have hacked ssl.el in order to
> > > replace the signal-process calls with (call-process "kill.exe" nil nil
> > > nil "-ALRM" PID). This works because cygwin provides its own layer of
> > > signal handling and is able to send / receive the SIGALRM signal.
> > 
> > How about making that hack part of Emacs?  It could be conditioned on
> > running on Windows.
> 
> You mean to distribute cygwin's kill.exe with Emacs and just using it
> instead of `signal-process' everywhere? Or to depend upon the user to
> install a cygwin environment along with Emacs?

The latter, and also that hack in ssl.el you need for that.

> I'd be a bit reluctant to do that since it seems a bit awkward...

Is there a better way that's practical?  It is more awkward to ask
users to change platforms, or tell them to fix gnutls by themselves,
no?

> IMHO, it would be better to let the programs work together on all
> platforms using different means of notification where necessary,
> e.g. using events on windows instead of signals...?! But that would
> indeed require an appropriate change on both sides.

Exactly.  I'm trying to establish whether there's a less painful way,
even if it's less elegant.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]