From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Mon, 11 Nov 2013 19:45:45 -0500 Message-ID: <21121.31289.756325.564438@consult.pretender> References: <21089.32240.198931.971000@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <21096.24492.292723.589004@consult.pretender> <87eh7bj5no.fsf_-_@flea.lifelogs.com> <21097.10816.221279.461499@consult.pretender> <21097.27136.910137.181740@consult.pretender> <21098.31018.184128.497305@consult.pretender> <87y555socz.fsf@flea.lifelogs.com> <21110.26587.721061.28128@consult.pretender> <83fvrd9ysr.fsf@gnu.org> <877gcorv0r.fsf@flea.lifelogs.com> <83sivc85pe.fsf@gnu.org> <21121.11298.564313.363452@consult.pretender> <877gceiv2h.fsf@flea.lifelogs.com> <87k3ge7lon.fsf@Rainer.invalid> <8738n2ij8r.fsf_-_@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1384217235 28039 80.91.229.3 (12 Nov 2013 00:47:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2013 00:47:15 +0000 (UTC) Cc: emacs@kosowsky.org, Achim Gratz , 15648@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 12 01:47:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vg28T-0005SM-1t for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 01:47:17 +0100 Original-Received: from localhost ([::1]:40268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vg28S-00060g-DC for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Nov 2013 19:47:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vg28K-00060T-Df for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 19:47:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vg28F-0005u8-6I for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 19:47:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vg28F-0005u1-2f for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 19:47:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vg28E-0007OM-Ax for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 19:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2013 00:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138421718228284 (code B ref 15648); Tue, 12 Nov 2013 00:47:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 12 Nov 2013 00:46:22 +0000 Original-Received: from localhost ([127.0.0.1]:47614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vg27Z-0007M5-56 for submit@debbugs.gnu.org; Mon, 11 Nov 2013 19:46:21 -0500 Original-Received: from vms173007pub.verizon.net ([206.46.173.7]:58443) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vg27W-0007Ln-Ri for 15648@debbugs.gnu.org; Mon, 11 Nov 2013 19:46:19 -0500 Original-Received: from consult.pretender ([unknown] [72.93.211.153]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MW400L7YKSASIC0@vms173007.mailsrvcs.net> for 15648@debbugs.gnu.org; Mon, 11 Nov 2013 18:45:48 -0600 (CST) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id rAC0jjTa025380; Mon, 11 Nov 2013 19:45:46 -0500 In-reply-to: <8738n2ij8r.fsf_-_@flea.lifelogs.com> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80292 Archived-At: Ted Zlatanov wrote at about 18:58:12 -0500 on Monday, November 11, 2013: > On Mon, 11 Nov 2013 21:00:56 +0100 Achim Gratz wrote: > AG> Specifically for Emacs, the "-m" option to cygpath seems the most > AG> suitable. Please do not link to the Cygwin DLL from Windows Emacs > AG> (i.e. "using the equivalent C function"). The only reason to use a > AG> native Emacs on Windows (for me anyway) is that I can update Cygwin > AG> while I keep Emacs running and that wouldn't be possible if the DLL was > AG> locked because it was still in use. For anything else (if you don#t > AG> want to start an X server), there's emacs-w32 from Cygwin. > > OK, that sounds like a reasonable use case. That is very similar to my use case... Similarly, I tend to keep my Emacs windows open until I reboot. On the other hand, I not infrequently need to close all cygwin processes (including servers) either to upgrade (as AG notes) or to troubleshoot some cygwin issue since so long as the cygwin.dll is bound to one process, I can't completely restart the state of cygwin. PLUS on some computers, I might have emacs only, on others cygwin only, on others multiple version of cygwin (I used to have both Cygwin 1.5 and 1.7), and on others all combinations. Since both cygwin and emacs are workhorses for me, I actually prefer to not have them bound by dependencies whereby one requires the installation of the other to work... Nor do I want my emacs updates tied to the cygwin project (for example, I am currently using cygwin X_64 but many packages have not yet been ported there. I would hate to have to wait for an important package like Emacs to be ported every time cygwin issues a new branch) Indeed in my emacs-loving-centric world, emacs is more fundamental in some ways than cygwin. If cygwin ceased to exist for windows, I would still use Emacs on Windows. So, I like the fact that I can make Emacs adapt to cygwin via a library (cygwin-mount) rather than requiring a separate cygwin compile. Introducing a forced dependency to make things work just seems so unemacs-like. > On Mon, 11 Nov 2013 15:00:39 -0500 wrote: > > Ted Zlatanov wrote at about 14:42:46 -0500 on Monday, November 11, 2013: > >> Could we just call [cygpath]? > > > It would work for cygwin... but I see two limitations: > > > 1. The same problem that affects cygwin-mount, would affect any other > > magic file handler that translates file names, since once again > > file-exists-p would return true, while the path passed to the > > c-code would in general not point to an OS-recognizable file. > > Yes, right. There would have to be some logic somewhere in Emacs to > recognize magic Cygwin pathnames and treat them specially from a native > non-Cygwin W32 build. Then packages like gnutls.el that talk to system > libraries can use that logic. I don't think it can be accomplished > otherwise. One of the reasons I prefer cygwin-mount to a cygwin-specific build is that I can see, understand, and potentially modify the treatment of such pathnames straight in the elisp code rather than having it hidden in OS-specific C-code. And if I want to change the behavior I can patch it using standard elisp functions without having to patch the c-code and recompile. In my understanding of emacs, as much as possible should be done in elisp. C-code is best reserved only for direct system interface calls and/or for calls where interpreted (byte-compiled) elisp just runs too slow. > I honestly don't have a preference for cygpath vs. cygwin-mount but > would like to continue the discussion in a new ticket please. Could we > start a new ticket specifically for the generic problem we've found with > native Emacs W32 builds vs. Cygwin? Sure... though how broad vs. narrow would you like that thread to be? Again, in my world, emacs is fundamental -- I use it across platforms by choice. Cygwin to me is just a tool I use to make Windows more like Linux... but it's not something I would use by choice nor is it something I use across platforms. So, while I am totally supportive of cygwin compiling their own version of Emacs, I think that Emacs should also maintain a library for supporting cygwin in its standalone W32 version -- just like Emacs has modes for supporting just about anything -- just like if I were on an old mac, I would want Emacs to have modes for supporting the original mac os file system & hierarchy. > I should add here that I'm grateful for all the help and suggestions I > got from you, Eli, and the other participants. The bug in the GnuTLS > interface code affected potentially all users, not just this one case. > > Thanks > Ted