emacs-devel
[Top][All Lists]
Advanced

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

Re: GnuTLS for W32


From: Óscar Fuentes
Subject: Re: GnuTLS for W32
Date: Tue, 03 Jan 2012 19:34:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Óscar Fuentes <address@hidden>
>> Date: Tue, 03 Jan 2012 18:48:17 +0100
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> You are providing reasons for the package approach: if it is hard for
>> >> the user to put the dll in the correct directory, let Emacs do it.
>> >
>> > No, it is _not_ hard for the user to put the DLL in the correct
>> > directory.
>> 
>> The user needs to know the correct directory (where "correct" implies
>> "with write access to it and Emacs can find the dll there"). That's
>> anything but trivial even for a computer-savvy user
>
> The same user

Not necessarily the same user. But I admit that I'm nitpicking.

> already unzipped the Emacs binary distro, so why exactly
> would it be hard for her to unzip another zip file from the same
> place?

He must unzip the file on a very specific directory, not just on the
same directory where he installs every program.

BTW, zip files is a terrible way to install software on MS Windows. Only
geeks who already decided to try Emacs go through the process of
installing from a zip file. I find quite ironic that `make install'
creates the Emacs icon on the Start menu but with the standard binary
distribution the user need to figure out how to start Emacs.

>> (BTW, since when Emacs changed its policy and is targeted to geeks
>> only again?)
>
> Since about forever?

Then lots of time was wasted on writing documentation that is clearly
targeted to non-geeks.

>> > It is hard for _us_, the programmers of package.el, to
>> > select a fixed directory that would work for all users, so that we
>> > could hardcode its absolute file name in the Emacs sources.  An
>> > entirely different issue.
>> 
>> Elisp packages downloaded by package.el are already saved on a
>> well-known directory where Emacs has write access to. So the problem is
>> solved.
>
> Solved my foot! we need to know that directory's absolute file name in
> advance, to hardcode it into the C sources of Emacs.  How's that
> going to work, if package.el doesn't know where that directory will be
> until it is run by Emacs?

You don't need to know the directory at compile time. GnuTLS and
potentially other libraries (those that provide image support, for
instance) are perfectly fine if you load them on demand at run time. I
think that's what already happens with the GnuTLS on MS Windows.




reply via email to

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