From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: xdg.el and eww custom load [Was: Re: Automatically set eww-download-directory according xdg dir] Date: Thu, 01 Nov 2018 14:29:17 +0000 Message-ID: <87a7msq3b6.fsf@tcd.ie> 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> 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 1541083193 25705 195.159.176.226 (1 Nov 2018 14:39:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2018 14:39:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel To: "Garreau\, Alexandre" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 01 15:39:49 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 1gIE8S-0006Ye-14 for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2018 15:39:48 +0100 Original-Received: from localhost ([::1]:42378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIEAY-0000je-GD for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2018 10:41:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIE7N-00058B-Fj for emacs-devel@gnu.org; Thu, 01 Nov 2018 10:38:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIDyZ-0000c3-27 for emacs-devel@gnu.org; Thu, 01 Nov 2018 10:29:40 -0400 Original-Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:46947) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gIDyN-0000TY-1Y for emacs-devel@gnu.org; Thu, 01 Nov 2018 10:29:25 -0400 Original-Received: by mail-ed1-x534.google.com with SMTP id f8-v6so4359844edt.13 for ; Thu, 01 Nov 2018 07:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Ll3AcrAS6oTpocrWzm2L5MJpHlPjUSbQ4b+8VUhBe9k=; b=qKwG1K5Zr+VqM2wt6C9bGheQLxbJyrgiE0SVWs85AkHfuNihuMUkf24jDjfwyLfkr8 G/DPzqH8oFmU7WXp/g5iWMg9DhTDIavf7LYbW+6uk9l8Oc5OLZ5y3bZTQib/S5aJiA2o QTLd8bgpXYdFW7rktWLLBCvxJdx5NvdLP86YcxBxJFofFFr0T6st9lDV7gdJVMITlWpu 3izXfQEP7idQTonQgB4opSWfJC8U5HiKMoETpTbp67zEqBvrKwWMiQl6IcLq7LJgu77/ fwNuZRihEE3Wz+2Ta7JzaamfNrfoRYY+rS+BxxZt8ihEig2DxRIXiPANIAsoSoktFt7P ubnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Ll3AcrAS6oTpocrWzm2L5MJpHlPjUSbQ4b+8VUhBe9k=; b=MjSO+zMsC/m52wTrknaJQ+A2qMV1WYj0ksS5D+c4E7R45Z9JckWLJrXqt290rr71mB EBATWHlQf9KbevpES/m49zSL3jUwjCxNMdCEMQo1Lq4eaXBpNHMCFxUVuo089yZkbura CapQdtQd7tub72B7U+qjmS0FyRpTwcHqIaIPcOhrPvXEqE/+Xu2BL9A6XaCWkBycSs2/ EWlkU8h4tnCyX8s0kN47s9/ObJbSPnPOpDSo5mPOL7/X/d9O7lP1OG0oGPogzdnnQkpR OHlm2dazAL3KgDmZXXCHoly3Jd+Gk+gh9ThPUEIJmMaQhSwKMfAqwUpKyyuvt9PMqMM3 YGIQ== X-Gm-Message-State: AGRZ1gJIpfSunBuJ+SojsaR6MQuDiVPdBKxxxhQhCCjQ0agriWU36JrM PQb3YrQYJtUQPoa+8+3pVb23LmSA/XE= X-Google-Smtp-Source: AJdET5cBMtOLBlhaQA2xDHwdZCg9PG7pjdNWCA2k/V+UlMdtGhbURVjk1QHEI750AQEXcoPAeR/3oQ== X-Received: by 2002:a50:b8c2:: with SMTP id l60-v6mr4983514ede.267.1541082559317; Thu, 01 Nov 2018 07:29:19 -0700 (PDT) Original-Received: from localhost (51-171-243-2-dynamic.agg2.clk.blp-srl.eircom.net. [51.171.243.2]) by smtp.gmail.com with ESMTPSA id v18-v6sm9052753eds.21.2018.11.01.07.29.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 01 Nov 2018 07:29:18 -0700 (PDT) In-Reply-To: <875zxhsp8m.fsf@portable.galex-713.eu> (Garreau, Alexandre's message of "Wed, 31 Oct 2018 23:52:41 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::534 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:230950 Archived-At: "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 >>> 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 fu= rther >>> 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 sy= ntax 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 to= 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 ev= en > 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 se= t 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. >>> otherwise it=E2=80=99s just broken and by default wrongly put downloaded >>> 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. >> 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 with > 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. >>>> See also the following thread for some discussion of XDG support: >>>> https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00081.html > >>> Strangly, the thread is about adding it to ELPA, but nowadays as you >>> tell it it is in mainline emacs 27, and not in ELPA: from the sources I >>> cloned, I tried to load it, and it worked out of the box, so it would >>> especially be useful in ELPA as it would right away provide it to older >>> emacsen (like mine, debian=E2=80=99s one). >> >> Just to be clear: the package proposed in that emacs-devel thread is >> different to the lisp/xdg.el library added to Emacs 26 core. > > Really? Why citing both in the same message without warning about > that then? Warning about what? In one paragraph I pointed to the Emacs 26 library lisp/xdg.el, and in another I linked to an emacs-devel thread for "some discussion of XDG support." Comprehension was left as an exercise for the reader. I'm sorry I wasn't clear enough. > 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. >>> Wow that=E2=80=99s awesome: replacing .emacs.d with something following= xdg (why >>> not .config/emacs/?) so to cleanse home, I=E2=80=99ve dreamt it (I also= dreamt >>> of an =E2=80=9Cexternal=E2=80=9D customization method for defcustom whe= re 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 procrastinated >>> to suggest it. He did it. > > So that still applies? I don't know what you're referring to. --=20 Basil