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

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

bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to


From: emacs
Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely
Date: Tue, 12 Nov 2013 10:19:42 -0500

Stefan -- please pay attention to the hostile, unfriendly attitude and
ultimate arrogance of the Windows Emacs maintainer...

Eli Zaretskii wrote at about 05:56:06 +0200 on Tuesday, November 12, 2013:
 > > From: <address@hidden>
 > > Date: Mon, 11 Nov 2013 16:53:31 -0500
 > > Cc: address@hidden, address@hidden, address@hidden
 > > 
 > >  > > The absence of cygwin-mount magic file handling when a file name is
 > >  > > passed directly to the gnutls c-code without going through any of the
 > >  > > standard magic-file-handling file access routines is the crux of the
 > >  > > problem.
 > > 
 > >  > No, the crux of the problem is that you are trying to use a natively
 > >  > built Emacs with file names that make sense only for Cygwin programs.
 > > 
 > > No, the crux of the problem was and is a bug in the gnutls.el code,
 > > due to the inconsistency in which magic files are handled.
 > > 1. file-exists-p is enabled with magic file handling turned on
 > 
 > Only because you use cygwin-mount.

Or any other magic file handler...
where file-exists-p changes the file path from something not OS
recognizable to something OS recognizable.

The same error would occur with ange-ftp and tramp
should you use that style filename in gnutls-trustfiles.

Unless you want to document gnutls as disallowing magic file handler
(and write the code to disable file handlers), then you have a
problem. Otherwise, you are knowingly and intentionally writing code
that is incompatible with a core emacs feature set.

 > 
 > > 2. The pass to c-code ignores magic file handling
 > 
 > Only because you use cygwin-mount.

Or any other magic file handler...

 > 
 > > 3. This causes gnutls.el to crash with a totally incomprehensible
 > >    error message and an equally incomprehensible return code of '-64'
 > 
 > It no longer crashes.

It doesn't crash emacs... but the routine exist on error without
human-readable explanation (other than an obscure -64 return value).
Is this code? Is this user friendly?

 > > chooses to ignore magic file handling (in a consistent way), then
 > > such behavior should ideally be documented in the code.
 > 
 > Remove cygwin-mount, and that's what will happen.

Remove (almost) all file handlers actually... so let's just make magic
file handlers illegal or remove them from Emacs....

 > 
 > >  > If you want Cygwin semantics of file names, use a Cygwin build of
 > >  > Emacs, and this problem will immediately go away.  Alternatively, use
 > >  > file names for your certificates that native Windows programs can
 > >  > find, and the problem will also go away immediately.
 > > 
 > > That is your opinion. Your suggestions that I limit myself to using a
 > > cygwin-compiled version of emacs are just a workaround for poor
 > > coding. I'm sorry.
 > 
 > It's not an issue with code quality.  It's simply a consequence of the
 > fact that Cygwin file names _cannot_ be consistently supported in
 > native Windows programs.  You can solve perhaps 95% or 99% of that,
 > but not 100%.  If you are willing to live with those limitations,
 > please be free.  But it will never be supported all the way, it simply
 > cannot be.

The perfect is the enemy of the good enough.
I have offered a patch that substantially improves compatibility
without any downside other than your own unsubstantiated biases.

 > > Others have written cygwin-mount specifically for the use case that I
 > > have. Since when are the two choices you list, the only ones allowed?
 > > This whole idea of doing it just your way (or any way) goes against
 > > the entire emacs philosophy.
 > 
 > You are entitled to your opinions.  But I respectfully disagree, and
 > as long as I'm hold responsible for the Windows port of Emacs, I'm
 > sorry, but my opinions weigh slightly more.

You are being arrogant. Emacs is about more people than just yourself
and about more use cases than just you. Such an attitude is
incongruous with an open source project and discourages both users and
participants.

If such an attitude persists, I will regret helping with debugging
this and taking my precious time to test your c-code fix. I had
already fixed the problem myself, so with your attitude why would I
share my insights with you.

I am copying Stefan Monnier here to see if he agrees with your
arrogant attitude.

 > > Magic file handling is a core emacs feature. You have to take such
 > > functionality into account whether you choose to leverage it or
 > > not... or else you are contributing to making emacs buggy and
 > > inconsistent (along with limiting its power)
 > 
 > Except that Cygwin "magic" cannot be reliably handled that way.  The
 > difference is that for other magic file names, we have a handling
 > agent that is outside of Emacs.  By contrast, cygwin-mount pretends to
 > do that entirely in Emacs Lisp, which cannot work reliably enough.  As
 > this example shows.

It will happen with almost any file handler that uses file-exists-p.

 > >  >   3. Don't mix Cygwin file names with native Windows programs.
 > > 
 > > #3? Where did you come up with that restriction? Is it documented
 > > somewhere in the Emacs/Elisp manuals and/or in the release notes? Or
 > > did you invent that restriction out of thin air?
 > 
 > It's not an invention.  It's the result of many years using Emacs on
 > Windows and hacking it.  You are free to ignore that experience, of
 > course, but I assure you it is valid.

But why would you preclude this from working.
Please give me ONE use case where my patch either causes a failure
elsewhere or where it bogs down the code.
 > 
 > > I think you are missing the point that gnutls.el has an inherent
 > > inconsistency independent of cygwin or anything else...
 > 
 > It's not just gnutls.el, it's all of Emacs.  And for a good reason:
 > these file names cannot be supported by cygwin-mount or any similar
 > solutions.  You need an external agent that resolves all the Cygwin
 > file names, any time Emacs needs to access a file, be it in Lisp or in
 > C.

That is your opinion. I have been using cygwin-mount for about a
decade without any problems... until now.

 > 
 > > I have proposed a valid, workable, and very tiny patch. Moreover, my
 > > patch is totally consistent with the usage of expand-file-name in
 > > particular and magic file handlers in particular as used dozens of
 > > times in file.el
 > 
 > As long as the solution is plugging cygwin-mount into more places in
 > Emacs, such a solution will not be acceptable, sorry.

You are biased against cygwin-mount. A maintainer needs to check his
biases at the door.

 > 
 > > You have failed to give a single use case where my patch would cause
 > > any problems. My patch adds immeasurably trivial complexity and
 > > processing time to the routine. In contrast, all you have done is
 > > suggest one-off workarounds which do nothing to solve the problem for
 > > the next unsuspecting user...
 > 
 > I have enough use cases to fill a lecture, I just have no time to
 > write them all.  Sorry, please accept my judgment on this, even if you
 > disagree.

I am just asking for one (reasonable) failure case.

I call BS. You are clearly just posturing -- given that you have taken
hours to refute everything but the patch itself.

If you had a use case at your fingertips, surely you would happily
have suggested it long ago...





reply via email to

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