Re: Byte-compilation of custom themes

[Basil L. Contovounesios]

Eli Zaretskii <address@hidden> writes:

>> From: "Basil L. Contovounesios" <address@hidden>
>> Cc: <address@hidden>,  <address@hidden>
>> Date: Fri, 11 May 2018 16:16:09 +0100
>> 
>> > The original code carefully verified that the members in
>> > custom-theme--load-path are directories, whereas your proposal calls
>> > directory-files on each member unconditionally, which will barf if a
>> > file is not a directory.
>> 
>> The function custom-theme--load-path already incorporates the
>> file-directory-p check, so it is technically redundant here.
>> Would you rather it be kept regardless?
>
> We should at least have a comment there that we are relying on
> custom-theme--load-path to do the test, and perhaps also an assertion.

Do you mean a cl-assertion, or an emulation thereof?  E.g.:

(unless (file-directory-p dir)
  (signal 'file-missing
          (list "`custom-theme-load-path'" "No such directory" dir)))

(I'm unsure on the convention for file-missing errors.)

Either way, what is the benefit of barfing before directory-files does?
Wouldn't a docstring for custom-theme--load-path and a comment in
custom-available-themes suffice for the reader (they do for me)?  E.g.:

diff --git a/lisp/custom.el b/lisp/custom.el
index b3311a1783..d21e398646 100644
--- a/lisp/custom.el
+++ b/lisp/custom.el
@@ -1292,6 +1292,7 @@ custom-available-themes
   (let ((suffix "-theme\\.el\\'")
         themes)
     (dolist (dir (custom-theme--load-path))
+      ;; `custom-theme--load-path' promises DIR exists.
       (dolist (file (directory-files dir nil suffix))
         (let ((theme (intern (substring file 0 (string-match-p suffix file)))))
           (and (custom-theme-name-valid-p theme)
@@ -1300,6 +1301,8 @@ custom-available-themes
     (nreverse themes)))
 
 (defun custom-theme--load-path ()
+  "Expand `custom-theme-load-path' into list of directories.
+Only existing directories are included in the path returned."
   (let (lpath)
     (dolist (f custom-theme-load-path)
       (cond ((eq f 'custom-theme-directory)

>> >> -    (define-key map "\C-x\C-s" 'custom-theme-write)
>> >> -    (define-key map "q" 'Custom-buffer-done)
>> >> -    (define-key map "n" 'widget-forward)
>> >> -    (define-key map "p" 'widget-backward)
>> >> +    (define-key map "\C-x\C-s" #'custom-theme-write)
>> >> +    (define-key map "q" #'Custom-buffer-done)
>> >> +    (define-key map "n" #'widget-forward)
>> >> +    (define-key map "p" #'widget-backward)
>> >
>> > Really?  Are we going to switch to #'foo even in key bindings?
>> 
>> Though I personally prefer to consistently #'-quote function symbols in
>> my own code, both for the extra byte-compiler check and narrower
>> in-buffer completion, I have no strong opinion here; I was simply making
>> the change in a sweeping fashion, in line with what I had perceived as a
>> welcome style.  Out of curiosity, though, what makes key bindings
>> special w.r.t. quoting?
>
> Stefan gave one reason (with which I agree).  From POV, it's another
> stab into my heart of a veteran reader of Emacs Lisp code.  I recently
> find the code harder and harder to read due to all the new syntax and
> unfamiliar functions.  You can ignore me on that, though.

No, it's a respectable point and I appreciate it.  Besides, my original
intent was to change how themes are loaded, not how their libraries are
quoted; I simply got carried away, and I'm sure there's precedent on the
latter elsewhere.  Let me know whether any heart stabs remain in the
last patchset and I'll gladly revert them.

Thanks,

-- 
Basil