emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

xdg.el and eww custom load [Was: Re: Automatically set eww-download-dire


From: Garreau\, Alexandre
Subject: xdg.el and eww custom load [Was: Re: Automatically set eww-download-directory according xdg dir]
Date: Tue, 30 Oct 2018 04:57:44 +0100
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian

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

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

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!

> But you wouldn't want to use this to set the value of
> eww-download-directory in its defcustom declaration

Why so? otherwise it’s just broken and by default wrongly put downloaded
files in the wrong dir, might create it, or fail.

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

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.

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]