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

[Garreau\, Alexandre]

On 2018-10-31 at 12:41, Basil L. Contovounesios wrote:
> "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").

Okay thinking about it a little more I think I learnt about them in
`shell-command' docstring, which talk about both `call-process' and
`start-process', but not about `process-lines': this is probably why in
my mind these two looked “more advertised” than `process-lines'.  But as
Eli said in Emacs it’s better to use buffers rather than strings, so I
guess it is fine if this (and others) docstrings don’t advertise it as
well, and let it only in the manual, so not to encourage bad behavior
(for the same reason in an old thread I saw suggested there weren’t much
absolute-line-related functions so not to encourage
absolute-line-related behaviors that are in emacs, and keep encouraging
doing stuff at a character and relative level instead).

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

Below where?  did you forget it?

Anyway, if it was stated so, that can saves me frustration.

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

I’d 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’d prefer to a long
repetitive cond, or an ad-hoc assoc list).

I’d like as well adding an “update” 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'…  maybe even
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 “.emacs”, “init.el” or
“custom.el”/`custom-file' file, so it will be read and set 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.

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

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

This was what I was talking about: weren’t you saying it was too slow
and a side-effect to avoid?

> 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?  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’t see how to achieve that with those though)?

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

This is what I was describing.

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

Not the web browser, the xdg-user-dirs variable, through the
xdg-user-dir function.

> 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")))))

Yes, just as I could (more statically) put my correct download directory
as my custom value for this variable, or put that function in my
“custom.el” file inside my `custom-set-variables' call: but here the
problem is about the *default* value being broken, while it could
automagically get the default value that would fit both almost
everybody’s default and everybody global desktop-wide config (while
“~/Downloads” is not only statically local to emacs, but broken
internationalization).

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

That’s why I used “or”: notice how `xdg-user-dir' happily as hopefully
just returns nil in case it can’t apply.

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

Really?  Why citing both in the same message without warning about that
then?  Anyway it seems it didn’t arrive in ELPA either then: so a such
suggestion still applies.

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

So that still applies?