From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Garreau\, Alexandre" Newsgroups: gmane.emacs.devel Subject: Re: xdg.el and eww custom load Date: Thu, 01 Nov 2018 15:56:07 +0100 Message-ID: <87o9b8etiw.fsf@portable.galex-713.eu> References: <87woq0sf4a.fsf@portable.galex-713.eu> <87h8h4tblg.fsf@tcd.ie> <87va5km6h3.fsf_-_@portable.galex-713.eu> <87pnvqp9ti.fsf@tcd.ie> <875zxhsp8m.fsf@portable.galex-713.eu> <87a7msq3b6.fsf@tcd.ie> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1541084433 19191 195.159.176.226 (1 Nov 2018 15:00:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2018 15:00:33 +0000 (UTC) User-Agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian Cc: emacs-devel To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 01 16:00:29 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gIESS-0004sp-LP for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2018 16:00:28 +0100 Original-Received: from localhost ([::1]:42454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIEUZ-0004vh-2W for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2018 11:02:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIES9-0003H5-O6 for emacs-devel@gnu.org; Thu, 01 Nov 2018 11:00:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIEOJ-00034s-Qo for emacs-devel@gnu.org; Thu, 01 Nov 2018 10:56:13 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:46914) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gIEOI-00030q-Fw for emacs-devel@gnu.org; Thu, 01 Nov 2018 10:56:10 -0400 Original-Received: from localhost ([::1] helo=portable.galex-713.eu) by portable.galex-713.eu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gIEOF-0006bL-Ds; Thu, 01 Nov 2018 15:56:07 +0100 PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br In-Reply-To: <87a7msq3b6.fsf@tcd.ie> (Basil L. Contovounesios's message of "Thu, 01 Nov 2018 14:29:17 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:5884:8305::1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230951 Archived-At: Le 01/11/2018 =C3=A0 14h29, Basil L. Contovounesios a =C3=A9crit=C2=A0: > "Garreau, Alexandre" writes: > >> On 2018-10-31 at 12:41, Basil L. Contovounesios wrote: > >>> The merits of parsing in Emacs vs delegating to an external tool were >>> briefly discussed in the emacs-devel thread I linked below. >> >> Below where? did you forget it? > > No, I did not forget it. Here it is again: > >>> See also the following thread for some discussion of XDG support: >>> https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00081.html Ohh it was in the same thread okay! Sorry, I skiped over it last time. It seems an outcome of this discussion was in fact that using the command may be better and more standard. If it doesn=E2=80=99t work at some point that=E2=80=99d be an occasion to i= nvestigate why doesn=E2=80=99t it work and how to improve that. >>>> It is also sad it takes a (especially *uppercase*, yuck) string as an >>>> argument, instead of a symbol. That=E2=80=99s lower-level and avoid f= urther >>>> processing (be it `symbol-name', an assoc-list or raw strings), but >>>> sound a lot less lispy to me: it=E2=80=99s like if xdg shell command s= yntax had >>>> began to intrusivly delve into emacs lisp! >>> >>> I'm sure patches for more convenient APIs would be welcome. >> >> I=E2=80=99d like to try to then, as anyway it is trivial: but then would= it be >> preferable to use `symbol-name', or a `case' (which I=E2=80=99d prefer t= o a long >> repetitive cond, or an ad-hoc assoc list). >> >> I=E2=80=99d like as well adding an =E2=80=9Cupdate=E2=80=9D function (or= a dynamic, non-lazy >> version, so in case it is changed it will dynamically works), functions >> for each standard directory, accordingly call `setenv'=E2=80=A6 maybe e= ven >> custom values that would either override, or reflect, them. >> >> Would it be acceptable, to gain speed, if this is that crucial, to have >> something such as a custom that, when unset (for instance at first emacs >> startup), parse the user-dirs.dirs file and then call `Custom-save', to >> set its default value once for all (including next sessions), so its >> value is statically saved in =E2=80=9C.emacs=E2=80=9D, =E2=80=9Cinit.el= =E2=80=9D or >> =E2=80=9Ccustom.el=E2=80=9D/`custom-file' file, so it will be read and s= et accordingly >> along with other variables at each emacs startup, without additional >> overhead? This is the most static behavior I can imagine, but still >> less worse than hardcoded "~/Download/" here and there distributed >> around emacs. > > I don't know enough about the relevant machinery to advise on the > approach taken. I also haven't reviewed the XDG library proposed on > emacs-devel. I wonder, though, whether it already addresses your > concerns. > >>>>> But you wouldn't want to use this to set the value of >>>>> eww-download-directory in its defcustom declaration >>>> >>>> Why so? >>> >>> Simply loading a package should have as few effects and be as fast as >>> possible. Think, for example, of loading eww.el for the purposes of >>> testing on various environments both local and remote. I'm sure there >>> are more serious dangers than I'm letting on. >> >> But getting incorrect behavior is bad as well=E2=80=A6 >> Parameters/customizations are here for something, and enforcing a >> broken (I mean unrelevant, disadapted, arbitrary) default to the user, >> or require them to (arbitrarily and statically) replicate some external >> config (user dirs) into their custom emacs config seems wrong toward >> this, to me. > > I never said the default can't be improved; I merely cautioned against > invoking a subprocess in a defcustom. Obviously there are several > workarounds for this, e.g. by predicating some representative value on > the result of executable-find, as per mm-url-program. in > lisp/gnus/mm-url.el. I don=E2=80=99t understand how this is a workaround: they just store a comm= and name as is. and call it later. But we don=E2=80=99t want to call the comm= and each time we save something, do we? And if so what to do with `eww-download-directory'? obsolete it to replace it with a same-name function? Use it if `eww-download-directory' is nil? It would be the most dynamic behavior. Or rather, the most static one like I suggested: call it only at first emacs startup. >>>> otherwise it=E2=80=99s just broken and by default wrongly put download= ed >>>> files in the wrong dir, might create it, or fail. >>> >>> Alternative approaches include and are not limited to using the built-in >>> function xdg-user-dir >> >> This was what I was talking about: weren=E2=80=99t you saying it was too= slow >> and a side-effect to avoid? > > When I said that, I was referring to the external executable > xdg-user-dir. The built-in function xdg-user-dir could potentially be > used as an alternative, though I'm not sure how much better the latter > is compared to the former. The later, in the end, should use the former. >>> and/or adding a new customisation type to the defcustom which asks for >>> xdg-user-dir to be called when needed, rather than when eww.el is >>> being loaded. >> >> So :require for this is not okay? > > I didn't imply anything about using :require. > >> But are you talking about a new custom variable to be added in eww and >> used to conditionally lazily set and call `eww-download-directory', or >> something such as a keyword given to defcustom eww-download-directory? >> such as :set, :get, or :type (I don=E2=80=99t see how to achieve that wi= th >> those though)? > > My suggestion was just a shallow example, but what I meant is extending > :type to allow for more than just a string file name, e.g. by accepting > nil or 'xdg as valid values. Users of eww-download-directory could then > choose which course of action to take depending on the option's type and > value, as is done with many a user option in Emacs. Again, this was > just an example off the top of my head, not a concrete solution. This looks pretty concrete to me. >> Anyway it seems it didn=E2=80=99t arrive in ELPA either then: so a such >> suggestion still applies. > > Sure, but if the proposed package has the potential to address your > concerns, then perhaps getting it into ELPA would be an easier target > than reimplementing it in core. I have no strong feelings either way. The problem is that the package, to properly work, need to be put in site-lisp/data-dir. If installed along witho other ELPA packages it will have to be in the directory it want to avoid, =E2=80=9C~/.emacs.d=E2= =80=9D. While in core it would work out of the box. But then the question is how do you trigger its enabling or disabling: unless emacs acts to use XDG, as many other softwares, by default, either that=E2=80=99d require setting a system-wide option, as root, or, as I initially thought, do as many software and iteratively search for several places where to source config (as it is already with .emacs vs. .emacs.d): try each one, and if non-existing try the next. So maybe refinding the package and suggesting to merge it with current core xdg.el? >>>> Wow that=E2=80=99s awesome: replacing .emacs.d with something followin= g xdg (why >>>> not .config/emacs/?) so to cleanse home, I=E2=80=99ve dreamt it (I als= o dreamt >>>> of an =E2=80=9Cexternal=E2=80=9D customization method for defcustom wh= ere it would go >>>> get its default or saved custom values from external non-elisp files >>>> instead (or exteral programs), such as the xdg ones), but procrastinat= ed >>>> to suggest it. He did it. >> >> So that still applies? > > I don't know what you're referring to. To previous paragraph: suggesting to do that instead of .emacs/.emacs.d in ~. So in the end your config is in .config/emacs/*.el (or .config/emacs.el), your data is in .local/share/emacs/, etc. And your home is less bloated, and users are more aware of where are canonical programs config and data as they=E2=80=99re all in the same place (that oug= ht to be uniformized with other windows programs behavior, of course). Since it hasn=E2=80=99t been implemented it is still time to suggest it.