Re: xdg.el and eww custom load [Was: Re: Automatically set eww-download-directory according xdg dir]

[Basil L. Contovounesios]

"Garreau, Alexandre" <address@hidden> writes:

> On 2018/10/30 at 02:25, Basil L. Contovounesios wrote:
>> I think the simplest (often too simple) way to synchronously get process
>> output without using the shell is via the function process-lines:
>>
>>   (car (process-lines "xdg-user-dir" "DOWNLOAD"))
>
> Oh I didn’t know it!  It’s pretty handy and I don’t understand why it
> isn’t more advertised (though I can’t judge formally as I forgot how I
> learnt `call-process').  I wouldn’t have thought to it either (as show
> the other followup of my OP).

It's documented along with call-process under
(info "(elisp) Synchronous Processes").

>> "Garreau, Alexandre" <address@hidden> writes:
>>> Or should, instead, a xdg.el file be created where to put variables (or
>>> functions) referring to correct (and up-to-date) names of XDG variables:
>>> desktop, download, templates, publicshare, documents, music, pictures,
>>> and videos, and maybe “xdg-settings get default-url-scheme-handler”.
>>> Maybe among other xdg stuff, such as localization language, or… dunno
>>> yet, but there must be things to get.
>>
>> FWIW, Emacs 26 includes the file lisp/xdg.el, which provides, amongst
>> other things, the function xdg-user-dir:
>>
>>   (require 'xdg)
>>   (xdg-user-dir "DOWNLOAD")
>
> Then that could be used (sorry to have forgotten the “or” first time,
> anyway it wouldn’t have worked if the program wasn’t here, as it would
> have, as you said, “caused other issues”, while xdg-user-dir returns nil
> if no config file to read):
>
> #+BEGIN_SRC emacs-lisp
>   (defcustom eww-download-directory
>     (or (xdg-user-dir "DOWNLOAD") "~/Downloads/")
>     "Directory where files will downloaded."
>     :version "24.4"
>     :require 'xdg
>     :group 'eww
>     :type 'string)
> #+END_SRC
>
> I find sad it doesn’t use the command xdg-user-dir per se, as I usually
> prefer to always use the highest level interface, in case lower level
> was changed.  But, if a that much complete xdg implementation use that,
> it must be as much standard… and anyway it saves time (which may be not
> that much important as it will lazily load it only once per session).

The merits of parsing in Emacs vs delegating to an external tool were
briefly discussed in the emacs-devel thread I linked below.

> It is also sad it takes a (especially *uppercase*, yuck) string as an
> argument, instead of a symbol.  That’s lower-level and avoid further
> processing (be it `symbol-name', an assoc-list or raw strings), but
> sound a lot less lispy to me: it’s like if xdg shell command syntax had
> began to intrusivly delve into emacs lisp!

I'm sure patches for more convenient APIs would be welcome.

>> 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.

> otherwise it’s 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 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.

>> as that would slow down or potentially cause other issues when loading
>> eww.el.  It would also need to handle the case where xdg-user-dir is
>> not found in exec-path.
>
> Maybe then using the *variable* xdg-user-dirs: if `xdg-user-dir' already
> have been called once, it will lazily use what it already stored in this
> variable, instead of rereading, so the I/O will stay constant.

That is the approach currently taken by the built-in function
xdg-user-dir.

> Maybe it should be loaded earlier in emacs startup?  But I guess either
> it is already the case, either it has been deemed too much for emacs
> startup speed: then I guess lazily making eww one of the applications
> that might trigger its first-time load in the session is acceptable, as
> it is so to save emacs initial startup time.

I think it will be hard to argue for a web browser to be preloaded.
Even if it were preloaded, though, I don't see how that would solve the
XDG issue.  Don't forget that there's nothing stopping users from adding
the following perfectly valid and reasonable customisation (or similar)
to their configuration:

  (with-eval-after-load 'eww
    (setq eww-download-directory
          (file-name-as-directory
           (car (process-lines "xdg-user-dir" "DOWNLOAD")))))

> Or, rather, maybe there should exist some facilities in custom.el so
> that xdg-user-dirs becomes a saved custom option, so it’s loaded once at
> first emacs startup and kept for further sessions: it may not be
> up-to-date but it’d be faster, with no load overhead, and anyway that
> value isn’t meant to change much in time (however that might confuse
> some users if they ran emacs before to change their xdg dir settings).

Again, I'm sure patches would be welcome.  Don't forget, though, that
XDG isn't universal.

>> See also the following thread for some discussion of XDG support:
>> https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00081.html
>
> Wow that’s awesome: replacing .emacs.d with something following xdg (why
> not .config/emacs/?) so to cleanse home, I’ve dreamt it (I also dreamt
> of an “external” customization method for defcustom where 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.
>
> 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’s 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.

-- 
Basil