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

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…
> 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’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?

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’t 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’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?

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’t 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’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?

I don't know what you're referring to.

-- 
Basil