Automatically set eww-download-directory according xdg dir

Automatically set eww-download-directory according xdg dir

[Garreau, Alexandre]

I guess this is the right place to ask about Eww.

Currently `eww-download-directory' is unconditionally set to
“~/Downloads”, which, I guess, is the default download directory most
desktop and file-managers will create and read when the installation is
set up in english.  But XDG (and most systems nowadays, except Mac OS X
if I’m right, which translate directory names in applications display
iirc) tends to localize directories in the user language set up at
installation.  So, after installation, by default, my directory was
“~/Téléchargements/”, except then, I tweaked “~/.config/user-dirs.dirs”,
so now I have short dir names in my home, like “~/dl/”.  Instead of
reading (or rather, sourcing it from bashrc then using the env var… but
on my system by default this isn’t done so it won’t work in most configs
I guess) that last config file, I guess the canonical way to get the
appropriate XDG directories is first to call the “xdg-user-dir” command,
like this:

#+BEGIN_SRC emacs-lisp
  (defcustom eww-download-directory
    (substring
     (with-temp-buffer
       (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
       (buffer-string))
     0 -1)
    "Directory where files will downloaded."
    :version "24.4"
    :group 'eww
    :type 'string)
#+END_SRC

I am not sure this is the simplest way to call a process and get its
output as string, without using the shell (there seem to be a
shell-command-to-string, but no call-process-to-string, writing another
mail about this).

May I suggest to change Eww so it acts according XDG?

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.

`call-process', to a string [Was: Re: Automatically set eww-download-directory according xdg dir]

[Garreau, Alexandre]

On 2018-10-29 at 20:54, Garreau, Alexandre wrote:
>     (substring
>      (with-temp-buffer
>        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
>        (buffer-string))
>      0 -1)
>
> I am not sure this is the simplest way to call a process and get its
> output as string, without using the shell (there seem to be a
> shell-command-to-string, but no call-process-to-string, writing another
> mail about this).

What would it be?

In the `call-process' docstring related to the argument about output,
there’s nothing related to a string:

> Insert output in DESTINATION before point; t means current buffer; nil for DESTINATION
>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
>  FILE is a file name string, means that it should be written to that file
>  (if the file already exists it is overwritten).
> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
> REAL-BUFFER says what to do with standard output, as above,
> while STDERR-FILE says what to do with standard error in the child.
> STDERR-FILE may be nil (discard standard error output),
> t (mix it with ordinary output), or a file name string.

I also notice it is not documented that DESTINATION may be a buffer, in
which case the output is inserted in the said buffer (I checked).

Wouldn’t it be useful and reasonable if `call-process' DESTINATION may
have a value that makes `call-process' return a string, rather than the
exit code?

I’d prefer to use that instead of `shell-command-to-string', as it is
less heavy than invoking the shell, and all its parsing (with
`call-process' it is easier and clearer to specify arguments with spaces
in them, for instance, or other special characters (will only require
elisp escapes, not foreign shell escpaes)), for that, and
`shell-command' docstring seems to reflect that idea:
> In Elisp, you will often be better served by calling ‘call-process’ or
> ‘start-process’ directly, since it offers more control and does not impose
> the use of a shell (with its need to quote arguments).

`with-temp-buffer', `with-output-to-string': `with-temp-buffer-to-string' / `with-current-buffer-to-string' [Was: Re: `call-process', to a string]

[Garreau, Alexandre]

On 2018-10-29 at 21:08, Garreau, Alexandre wrote:
> On 2018-10-29 at 20:54, Garreau, Alexandre wrote:
>>     (substring
>>      (with-temp-buffer
>>        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
>>        (buffer-string))
>>      0 -1)
>>
>> I am not sure this is the simplest way to call a process and get its
>> output as string, without using the shell (there seem to be a
>> shell-command-to-string, but no call-process-to-string, writing another
>> mail about this).

Searching for a better form, I found `with-output-to-string', which, in
name, looks like what I want, but is for standard-output, for when emacs
is ran without a frame I guess.

May I suggest a new form `with-temp-buffer-to-string', inspired from
`with-output-to-string', but for what programs might see as current
buffer: 

#+BEGIN_SRC emacs-lisp
  (defmacro with-temp-buffer-to-string (&rest body)
    "Execute BODY, return the text it sent to current-buffer, as a string."
    (declare (indent 0) (debug t))
    `(with-temp-buffer
       (progn
         ,@body
         (goto-char (point-max))
         (when (= ?\n (char-before))
           (delete-char -1))
         (buffer-string))))
#+END_SRC

Btw, in `with-output-to-string', instead of just using
`generate-new-buffer', it directly does “(get-buffer-create
(generate-new-buffer-name " *string-output*"))”: is there a reason for
that?  otherwise it’s just longer and less readable.

Re: Automatically set eww-download-directory according xdg dir

[Basil L. Contovounesios]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> #+BEGIN_SRC emacs-lisp
>   (defcustom eww-download-directory
>     (substring
>      (with-temp-buffer
>        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
>        (buffer-string))
>      0 -1)
>     "Directory where files will downloaded."
>     :version "24.4"
>     :group 'eww
>     :type 'string)
> #+END_SRC
>
> I am not sure this is the simplest way to call a process and get its
> output as string, without using the shell (there seem to be a
> shell-command-to-string, but no call-process-to-string, writing another
> mail about this).

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

But you wouldn't want to use this to set the value of
eww-download-directory in its defcustom declaration 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.

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

See also the following thread for some discussion of XDG support:
https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00081.html

-- 
Basil

Re: `call-process', to a string [Was: Re: Automatically set eww-download-directory according xdg dir]

[Basil L. Contovounesios]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> In the `call-process' docstring related to the argument about output,
> there’s nothing related to a string:
>
>> Insert output in DESTINATION before point; t means current buffer; nil for DESTINATION
>>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
>>  FILE is a file name string, means that it should be written to that file
>>  (if the file already exists it is overwritten).
>> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
>> REAL-BUFFER says what to do with standard output, as above,
>> while STDERR-FILE says what to do with standard error in the child.
>> STDERR-FILE may be nil (discard standard error output),
>> t (mix it with ordinary output), or a file name string.
>
> I also notice it is not documented that DESTINATION may be a buffer, in
> which case the output is inserted in the said buffer (I checked).

Indeed this does not seem to be documented in the docstring of
call-process, but it is documented in the manual under
'(elisp) Synchronous Processes'.

-- 
Basil

Re: `with-temp-buffer', `with-output-to-string': `with-temp-buffer-to-string' / `with-current-buffer-to-string' [Was: Re: `call-process', to a string]

[Basil L. Contovounesios]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> On 2018-10-29 at 21:08, Garreau, Alexandre wrote:
>> On 2018-10-29 at 20:54, Garreau, Alexandre wrote:
>>>     (substring
>>>      (with-temp-buffer
>>>        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
>>>        (buffer-string))
>>>      0 -1)
>>>
>>> I am not sure this is the simplest way to call a process and get its
>>> output as string, without using the shell (there seem to be a
>>> shell-command-to-string, but no call-process-to-string, writing another
>>> mail about this).
>
> Searching for a better form, I found `with-output-to-string', which, in
> name, looks like what I want, but is for standard-output, for when emacs
> is ran without a frame I guess.

No, standard-output is just bound to a buffer, which is always a valid
input or output stream:

  (with-output-to-string
    (call-process "xdg-user-dir" nil standard-output nil "DOWNLOAD"))

-- 
Basil

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

[Garreau, Alexandre]

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" <galex-713@galex-713.eu> 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).

Re: `call-process', to a string

[Garreau, Alexandre]

On 2018/10/30 at 02:25, Basil L. Contovounesios wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>
>> In the `call-process' docstring related to the argument about output,
>> there’s nothing related to a string:
>>
>>> Insert output in DESTINATION before point; t means current buffer; nil for DESTINATION
>>>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
>>>  FILE is a file name string, means that it should be written to that file
>>>  (if the file already exists it is overwritten).
>>> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
>>> REAL-BUFFER says what to do with standard output, as above,
>>> while STDERR-FILE says what to do with standard error in the child.
>>> STDERR-FILE may be nil (discard standard error output),
>>> t (mix it with ordinary output), or a file name string.
>>
>> I also notice it is not documented that DESTINATION may be a buffer, in
>> which case the output is inserted in the said buffer (I checked).
>
> Indeed this does not seem to be documented in the docstring of
> call-process, but it is documented in the manual under
> '(elisp) Synchronous Processes'.

It’s odd.

Re: `call-process', to a string [Was: Re: Automatically set eww-download-directory according xdg dir]

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> Date: Mon, 29 Oct 2018 21:08:32 +0100
> 
> On 2018-10-29 at 20:54, Garreau, Alexandre wrote:
> >     (substring
> >      (with-temp-buffer
> >        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
> >        (buffer-string))
> >      0 -1)
> >
> > I am not sure this is the simplest way to call a process and get its
> > output as string, without using the shell (there seem to be a
> > shell-command-to-string, but no call-process-to-string, writing another
> > mail about this).
> 
> What would it be?
> 
> In the `call-process' docstring related to the argument about output,
> there’s nothing related to a string:

My advice: don't build your process-related applications around
strings, build them around buffers, temporary or otherwise.  Emacs is
much better with buffers than with strings, notably in the
memory-management department; and making a string from a (portion of
a) buffer is trivial, if you for some reason do need a string
eventually.

Re: Automatically set eww-download-directory according xdg dir

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Tue, 30 Oct 2018 02:25:15 +0000
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
> 
> > #+BEGIN_SRC emacs-lisp
> >   (defcustom eww-download-directory
> >     (substring
> >      (with-temp-buffer
> >        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
> >        (buffer-string))
> >      0 -1)
> >     "Directory where files will downloaded."
> >     :version "24.4"
> >     :group 'eww
> >     :type 'string)
> > #+END_SRC
> >
> > I am not sure this is the simplest way to call a process and get its
> > output as string, without using the shell (there seem to be a
> > shell-command-to-string, but no call-process-to-string, writing another
> > mail about this).
> 
> 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"))
> 
> But you wouldn't want to use this to set the value of
> eww-download-directory in its defcustom declaration as that would slow
> down or potentially cause other issues when loading eww.el.

Indeed, calling a subprocess in a defcustom should be avoided, to put
it mildly.

> FWIW, Emacs 26 includes the file lisp/xdg.el, which provides, amongst
> other things, the function xdg-user-dir:

Right, so that facility should be used if we want EWW to default to
that place (which I'm not sure we should, btw; Lars?).

Re: `call-process', to a string [Was: Re: Automatically set eww-download-directory according xdg dir]

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Tue, 30 Oct 2018 02:25:36 +0000
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> >> Insert output in DESTINATION before point; t means current buffer; nil for DESTINATION
> >>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
> >>  FILE is a file name string, means that it should be written to that file
> >>  (if the file already exists it is overwritten).
> >> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
> >> REAL-BUFFER says what to do with standard output, as above,
> >> while STDERR-FILE says what to do with standard error in the child.
> >> STDERR-FILE may be nil (discard standard error output),
> >> t (mix it with ordinary output), or a file name string.
> >
> > I also notice it is not documented that DESTINATION may be a buffer, in
> > which case the output is inserted in the said buffer (I checked).
> 
> Indeed this does not seem to be documented in the docstring of
> call-process

??? You have just quoted the part where it does document that:

 Insert output in DESTINATION before point; t means current buffer;

Will the following minor change make that abundantly clear?

 Insert output in buffer DESTINATION before point; t means current buffer;

(What else can "insert in ... before point" mean, in Emacs?)

Re: `call-process', to a string

[Garreau, Alexandre]

Le 30/10/2018 à 09h19, Eli Zaretskii a écrit :
>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Date: Tue, 30 Oct 2018 02:25:36 +0000
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> >> Insert output in DESTINATION before point; t means current buffer; nil for DESTINATION
>> >>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
>> >>  FILE is a file name string, means that it should be written to that file
>> >>  (if the file already exists it is overwritten).
>> >> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
>> >> REAL-BUFFER says what to do with standard output, as above,
>> >> while STDERR-FILE says what to do with standard error in the child.
>> >> STDERR-FILE may be nil (discard standard error output),
>> >> t (mix it with ordinary output), or a file name string.
>> >
>> > I also notice it is not documented that DESTINATION may be a buffer, in
>> > which case the output is inserted in the said buffer (I checked).
>> 
>> Indeed this does not seem to be documented in the docstring of
>> call-process
>
> ??? You have just quoted the part where it does document that:
>
>  Insert output in DESTINATION before point; t means current buffer;
>
> Will the following minor change make that abundantly clear?
>
>  Insert output in buffer DESTINATION before point; t means current buffer;

Yes it does.

> (What else can "insert in ... before point" mean, in Emacs?)

In this docstring, it may be interpreted as a filename referred by a
string, or something referred by another value (the two-streams list).
I find it more clear if precising anyway, at this function may not
output to buffer.

Re: `call-process', to a string

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  emacs-devel@gnu.org
> Date: Tue, 30 Oct 2018 11:21:57 +0100
> 
> > Will the following minor change make that abundantly clear?
> >
> >  Insert output in buffer DESTINATION before point; t means current buffer;
> 
> Yes it does.

Fixed.

> > (What else can "insert in ... before point" mean, in Emacs?)
> 
> In this docstring, it may be interpreted as a filename referred by a
> string, or something referred by another value (the two-streams list).

"Point" only ever refers to Emacs buffers, never to anything else.

Re: `call-process', to a string

[Garreau, Alexandre]

On 2018/10/30 at 13:10, Eli Zaretskii wrote:
>> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
>> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  emacs-devel@gnu.org
>> Date: Tue, 30 Oct 2018 11:21:57 +0100
>> 
>> > Will the following minor change make that abundantly clear?
>> >
>> >  Insert output in buffer DESTINATION before point; t means current buffer;
>> 
>> Yes it does.
>
> Fixed.

>> > (What else can "insert in ... before point" mean, in Emacs?)
>> 
>> In this docstring, it may be interpreted as a filename referred by a
>> string, or something referred by another value (the two-streams list).
>
> "Point" only ever refers to Emacs buffers, never to anything else.

Oh you’re right!  Then with some context-sensitive deduction, you would
guess DESTINATION as a buffer.

However having to rely on deduction and context to understand a piece of
doc looks silly, and if it does stuff with buffers it looks better to me
to clearly have the word “buffer” within near.  So I believe it is
better with a such fix: thank you!

Re: `call-process', to a string

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
> Date: Tue, 30 Oct 2018 12:32:16 +0100
> 
> > "Point" only ever refers to Emacs buffers, never to anything else.
> 
> Oh you’re right!  Then with some context-sensitive deduction, you would
> guess DESTINATION as a buffer.
> 
> However having to rely on deduction and context to understand a piece of
> doc looks silly, and if it does stuff with buffers it looks better to me
> to clearly have the word “buffer” within near.  So I believe it is
> better with a such fix: thank you!

You are welcome.  However, it's still worth to make yourself familiar
with "point" and its significance in Emacs, because you will see
similar text all over the place.

`call-process', to a string

[Garreau, Alexandre]

Le 30/10/2018 à 14h32, Eli Zaretskii a écrit :
>> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
>> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
>> Date: Tue, 30 Oct 2018 12:32:16 +0100
>> 
>> > "Point" only ever refers to Emacs buffers, never to anything else.
>> 
>> Oh you’re right!  Then with some context-sensitive deduction, you would
>> guess DESTINATION as a buffer.
>> 
>> However having to rely on deduction and context to understand a piece of
>> doc looks silly, and if it does stuff with buffers it looks better to me
>> to clearly have the word “buffer” within near.  So I believe it is
>> better with a such fix: thank you!
>
> You are welcome.  However, it's still worth to make yourself familiar
> with "point" and its significance in Emacs, because you will see
> similar text all over the place.

I am, my eyes just slipped over it being mentioned in the docstring, as
they were searching for the word “buffer”.  Even knowing what the point
is, it still ask a deduction to go from seeing the word “point” to
acknowledging the thing is about a buffer, while other things
(current-buffer, file, etc.) has been mentioned as destinations.

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

[Basil L. Contovounesios]

"Garreau, Alexandre" <galex-713@galex-713.eu> 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" <galex-713@galex-713.eu> 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

Re: `call-process', to a string [Was: Re: Automatically set eww-download-directory according xdg dir]

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Date: Tue, 30 Oct 2018 02:25:36 +0000
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> >> Insert output in DESTINATION before point; t means current buffer; nil for DESTINATION
>> >>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
>> >>  FILE is a file name string, means that it should be written to that file
>> >>  (if the file already exists it is overwritten).
>> >> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
>> >> REAL-BUFFER says what to do with standard output, as above,
>> >> while STDERR-FILE says what to do with standard error in the child.
>> >> STDERR-FILE may be nil (discard standard error output),
>> >> t (mix it with ordinary output), or a file name string.
>> >
>> > I also notice it is not documented that DESTINATION may be a buffer, in
>> > which case the output is inserted in the said buffer (I checked).
>> 
>> Indeed this does not seem to be documented in the docstring of
>> call-process
>
> ??? You have just quoted the part where it does document that:
>
>  Insert output in DESTINATION before point; t means current buffer;

Mea culpa.  That's what I get for writing emails past 02:00.

> Will the following minor change make that abundantly clear?
>
>  Insert output in buffer DESTINATION before point; t means current buffer;
>
> (What else can "insert in ... before point" mean, in Emacs?)

You're right, it's unambiguous.  Either way, thank you for clarifying
the docstring on the emacs-26 branch; it's a welcome improvement.

-- 
Basil

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" <galex-713@galex-713.eu> 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" <galex-713@galex-713.eu> 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?

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

[Basil L. Contovounesios]

"Garreau, Alexandre" <galex-713@galex-713.eu> 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

Re: xdg.el and eww custom load

[Garreau, Alexandre]

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

Re: xdg.el and eww custom load

[Basil L. Contovounesios]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> Le 01/11/2018 à 14h29, Basil L. Contovounesios a écrit :
>> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>>> On 2018-10-31 at 12:41, Basil L. Contovounesios wrote:
>>>>>> 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.

It defers invoking a subprocess until it is actually needed, rather than
during evaluation of a defcustom.

> But we don’t want to call the command each time we save something, do
> we?

I don't see why the result can't be saved for subsequent reuse.

> And if so what to do with `eww-download-directory'?  obsolete it to
> replace it with a same-name function?

I don't see what would make it obsolete.

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

Sure, you can always revive the aforementioned emacs-devel thread.

-- 
Basil