Re: xdg.el and eww custom load

[Garreau\, Alexandre]

Le 01/11/2018 à 14h29, Basil L. Contovounesios a écrit :
> "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

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’t work at some point that’d be an occasion to investigate
why doesn’t 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’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.

I don’t understand how this is a workaround: they just store a command
name as is.  and call it later.  But we don’t want to call the command
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’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.

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

This looks pretty concrete to me.

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

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, “~/.emacs.d”.  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’d 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’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.

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’re all in the same place (that ought to
be uniformized with other windows programs behavior, of course).

Since it hasn’t been implemented it is still time to suggest it.