Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Glenn Morris]

Eli Zaretskii wrote:

>     * lisp/server.el (server-name): Add autoload cookie.  (Bug#23576)
[...]
> +;;;###autoload
>  (defcustom server-name "server"

Autoloading defcustoms just so people can set them interactively before
the associated package is loaded is a Bad Thing. There's nothing special
about this variable AFAICS. IMO it would have been better to simply
remove the bit about set-variable from the manual.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 19 May 2016 12:44:49 -0400
> 
> Eli Zaretskii wrote:
> 
> >     * lisp/server.el (server-name): Add autoload cookie.  (Bug#23576)
> [...]
> > +;;;###autoload
> >  (defcustom server-name "server"
> 
> Autoloading defcustoms just so people can set them interactively before
> the associated package is loaded is a Bad Thing.

I don't understand why.  Can you explain?  That's not the only
defcustom that is marked as autoloaded.

> IMO it would have been better to simply remove the bit about
> set-variable from the manual.

I don't see why we should remove useful advice from the manual, just
because it's inconvenient to make it work.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Leo Liu]

On 2016-05-19 20:13 +0300, Eli Zaretskii wrote:
> I don't understand why.  Can you explain?  That's not the only
> defcustom that is marked as autoloaded.

autoload definitions other than macros or functions has the worst effect
of duplicating them. Yes I agree with Glenn that if it can be avoided it
avoid it by all means.

Leo

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Fri, 20 May 2016 12:07:04 +0800
> 
> On 2016-05-19 20:13 +0300, Eli Zaretskii wrote:
> > I don't understand why.  Can you explain?  That's not the only
> > defcustom that is marked as autoloaded.
> 
> autoload definitions other than macros or functions has the worst effect
> of duplicating them.

Sorry, I don't think I understand what that means.  What duplication
do you allude to here?

> Yes I agree with Glenn that if it can be avoided it avoid it by all
> means.

I added the autoload for a reason for which I didn't see a better
solution.  If you can suggest a better solution that allows users to
specify the name before starting the first server, please do.

Thanks.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Leo Liu]

On 2016-05-20 08:51 +0300, Eli Zaretskii wrote:
> Sorry, I don't think I understand what that means.  What duplication
> do you allude to here?

For example if you autoload server-name, the whole

(defcustom server-name "server"
  "The name of the Emacs server, if this Emacs process creates one.
The command `server-start' makes use of this.  It should not be
changed while a server is running."
  :group 'server
  :type 'string
  :version "23.1")

is duplicated to the loaddefs file and now you have two definitions in
two separate files.

> I added the autoload for a reason for which I didn't see a better
> solution.  If you can suggest a better solution that allows users to
> specify the name before starting the first server, please do.

Get rid of the set-variable. Nowhere else uses it to demonstrate how to
change a defcustom'd variable. Otherwise we have a lot more autoloads to
do.

Leo

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Fri, 20 May 2016 15:11:45 +0800
> 
> On 2016-05-20 08:51 +0300, Eli Zaretskii wrote:
> > Sorry, I don't think I understand what that means.  What duplication
> > do you allude to here?
> 
> For example if you autoload server-name, the whole
> 
> (defcustom server-name "server"
>   "The name of the Emacs server, if this Emacs process creates one.
> The command `server-start' makes use of this.  It should not be
> changed while a server is running."
>   :group 'server
>   :type 'string
>   :version "23.1")
> 
> is duplicated to the loaddefs file and now you have two definitions in
> two separate files.

And why is that a problem?  loaddefs.el is auto-generated, so no one
needs to maintain it.

> > I added the autoload for a reason for which I didn't see a better
> > solution.  If you can suggest a better solution that allows users to
> > specify the name before starting the first server, please do.
> 
> Get rid of the set-variable.

Sorry, no.  I use that command myself a lot, so I see no reason why it
should be avoided.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 05/20/2016 10:46 AM, Eli Zaretskii wrote:

>> Get rid of the set-variable.
>
> Sorry, no.  I use that command myself a lot, so I see no reason why it
> should be avoided.

I don't think Leo means to delete the command, just update the manual to 
note that the package should be loaded first.

Otherwise, we'd have to autoload _all_ the defcustoms. Why should this 
one be different?

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 20 May 2016 11:48:35 +0300
> 
> On 05/20/2016 10:46 AM, Eli Zaretskii wrote:
> 
> >> Get rid of the set-variable.
> >
> > Sorry, no.  I use that command myself a lot, so I see no reason why it
> > should be avoided.
> 
> I don't think Leo means to delete the command, just update the manual to 
> note that the package should be loaded first.

It's nuisance to load a package before you can set a variable which
should be used on the first use of the package's functionality.  It's
easy to forget to load first, and then seeing "No match" or some such
is an annoyance.

> Otherwise, we'd have to autoload _all_ the defcustoms. Why should this 
> one be different?

Because the value should be set before the first invocation of
server-start.  If you set it after starting the server, it's too late.
That's not something that happens with _all_ the other defcustoms.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> It's nuisance to load a package before you can set a variable which
> should be used on the first use of the package's functionality.  It's
> easy to forget to load first, and then seeing "No match" or some such
> is an annoyance.

Right, but that's true of many other variables.
It's a known problem that shouldn't be fixed by preloading every
variable, but by making completion more clever.

> Because the value should be set before the first invocation of
> server-start.  If you set it after starting the server, it's too late.
> That's not something that happens with _all_ the other defcustoms.

Maybe not all, but many.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 20 May 2016 08:12:48 -0400
> 
> > It's nuisance to load a package before you can set a variable which
> > should be used on the first use of the package's functionality.  It's
> > easy to forget to load first, and then seeing "No match" or some such
> > is an annoyance.
> 
> Right, but that's true of many other variables.
> It's a known problem that shouldn't be fixed by preloading every
> variable, but by making completion more clever.

I'm all for it.  But as long as no one is working on that, I see no
better way than autoloading the variables.  Users shouldn't suffer
from our lack of resources or motivation.

> > Because the value should be set before the first invocation of
> > server-start.  If you set it after starting the server, it's too late.
> > That's not something that happens with _all_ the other defcustoms.
> 
> Maybe not all, but many.

We should handle that on a per-variable basis.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> I'm all for it.  But as long as no one is working on that, I see no
> better way than autoloading the variables.

All of them?
Because if not "all" of them, then you only solve 1% of the problem.

BTW, I have worked on that.  I have code which adds statements of the form

   (register-definition-prefixes "find-dired"
                                 '("find-" "lookfor-dired" "kill-find"))

in the loaddefs.el file (these are auto-generated by autoloads.el), and
which indicate that if we need something that starts with "find-" we
may find it in "find-dired".

Then things like set-variable (and C-h f, C-h v ...) can use this data
to load the relevant packages during completion.  Note that for server.el,
my code generates nothing at all, since we can instead rely on the
principle that "foo-bar" definitions can usually be found in foo.el.

The fact that it integrates with autoloads.el means that it could also
work with packages installed via package.el, rather than only for
core packages.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Fri, 20 May 2016 14:29:42 -0400
> 
> > I'm all for it.  But as long as no one is working on that, I see no
> > better way than autoloading the variables.
> 
> All of them?

No, just those that annoy someone.

> BTW, I have worked on that.  I have code which adds statements of the form
> 
>    (register-definition-prefixes "find-dired"
>                                  '("find-" "lookfor-dired" "kill-find"))
> 
> in the loaddefs.el file (these are auto-generated by autoloads.el), and
> which indicate that if we need something that starts with "find-" we
> may find it in "find-dired".
> 
> Then things like set-variable (and C-h f, C-h v ...) can use this data
> to load the relevant packages during completion.

Is that available on master?  If not, please push, and let's start
using this.

Thanks.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> Is that available on master?

I just pushed it, yes.

> If not, please push, and let's start using this.

The code I pushed just populates a new hash table `definition-prefixes'.
We still need to change help-fns.el (and various other places) to make
use of it.

I've used the patch below (which makes `C-h f' use that table during
completion), but it's just the temporary result of my experimentation
with it: it's fundamentally incorrect and hence needs to be rewritten.


        Stefan


diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 040152a..0f9ab0e 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -43,6 +43,43 @@ help-fns-describe-function-functions
 
 ;; Functions
 
+(defun help--load-files (files)
+  (dolist (file files)
+    ;; FIXME: this regexp business is not good enough: for file
+    ;; `toto', it will say `toto' is loaded when in reality it was
+    ;; just cedet/semantic/toto that has been loaded.
+    (let ((re (load-history-regexp file))
+          (done nil))
+      (dolist (x load-history)
+        (if (string-match re (car x)) (setq done t)))
+      (maphash (lambda (prefix files)
+                 (when (member file files)
+                   (if (not (cdr files))
+                       (remhash prefix definition-prefixes)
+                     (puthash prefix (remove file files)
+                              definition-prefixes))))
+               definition-prefixes)
+      (unless done
+        (load file 'noerror)))))
+
+(defun help--symbol-completion-table (string pred action)
+  ;; FIXME: To minimize the size of the definition-prefixes table,
+  ;; we should/could use the rule that "foo-bar" can likely be found in file
+  ;; foo.el (or foo-mode.el).
+  (unless (eq 'lambda action)
+    (string-match "\\`[^-:/_]*[-:/_]*" string)
+    (let* ((prefix1 (match-string 0 string))
+           (prefixes (all-completions prefix1 definition-prefixes)))
+      (dolist (prefix (prog1 prefixes (setq prefixes nil)))
+        (when (string-prefix-p prefix string)
+          (help--load-files (gethash prefix definition-prefixes))))))
+  (let ((prefix-completions
+         (mapcar #'intern (all-completions string definition-prefixes))))
+    (complete-with-action action obarray string
+                          (if pred (lambda (sym)
+                                     (or (funcall pred sym)
+                                         (memq sym prefix-completions)))))))
+
 (defvar describe-function-orig-buffer nil
   "Buffer that was current when `describe-function' was invoked.
 Functions on `help-fns-describe-function-functions' can use this
@@ -58,13 +95,14 @@ describe-function
      (setq val (completing-read (if fn
 				    (format "Describe function (default %s): " fn)
 				  "Describe function: ")
-				obarray 'fboundp t nil nil
-				(and fn (symbol-name fn))))
+				#'help--symbol-completion-table
+                                #'fboundp
+                                'confirm nil nil (and fn (symbol-name fn))))
      (list (if (equal val "")
 	       fn (intern val)))))
   (or (and function (symbolp function))
       (user-error "You didn't specify a function symbol"))
-  (or (fboundp function)
+  (or (help--symbol-function function)
       (user-error "Symbol's function definition is void: %s" function))
 
   ;; We save describe-function-orig-buffer on the help xref stack, so
@@ -299,6 +337,32 @@ find-lisp-object-file-name
 	     (src-file (locate-library file-name t nil 'readable)))
 	(and src-file (file-readable-p src-file) src-file))))))
 
+(defun help--try-load-symbol (sym)
+  ;; FIXME: Here we use the rule that "foo-bar" can be found in "foo.el", but
+  ;; we should extend it to include "foo-mode.el", and we should additionally
+  ;; use `definition-prefixes'.
+  (let ((name (symbol-name sym)))
+    (while (not (zerop (length name)))
+      (let ((file (locate-file name load-path (get-load-suffixes))))
+        (if (and file (not (assoc (file-truename file) load-history)))
+            (progn (load file) (setq name ""))
+          (setq name
+                (if (string-match "[-:/][^-:/]*\\'" name)
+                    (substring name 0 (match-beginning 0))
+                  (message "Cannot find file for symbol %s" sym)
+                  "")))))))
+
+(defun help--symbol-function (sym)
+  "Like `symbol-function' except it may try to load files to find the function."
+  (or (symbol-function sym)
+      (progn
+        ;; The function either doesn't exist or is not loaded yet.
+        ;; Try to find it.
+        (help--try-load-symbol sym)
+        ;; We did find some file to load, but we don't know if it did provide
+        ;; the function we're looking for.
+        (symbol-function sym))))
+
 (defun help-fns--key-bindings (function)
   (when (commandp function)
     (let ((pt2 (with-current-buffer standard-output (point)))
@@ -329,12 +393,12 @@ help-fns--key-bindings
               ;; If lots of ordinary text characters run this command,
               ;; don't mention them one by one.
               (if (< (length non-modified-keys) 10)
-                  (princ (mapconcat 'key-description keys ", "))
+                  (princ (mapconcat #'key-description keys ", "))
                 (dolist (key non-modified-keys)
                   (setq keys (delq key keys)))
                 (if keys
                     (progn
-                      (princ (mapconcat 'key-description keys ", "))
+                      (princ (mapconcat #'key-description keys ", "))
                       (princ ", and many ordinary text characters"))
                   (princ "many ordinary text characters"))))
             (when (or remapped keys non-modified-keys)
@@ -509,17 +573,16 @@ describe-function-1
 	      function))
 	 ;; Get the real definition.
 	 (def (if (symbolp real-function)
-		  (or (symbol-function real-function)
-		      (signal 'void-function (list real-function)))
+		  (help--symbol-function real-function)
 		real-function))
 	 (aliased (or (symbolp def)
 		      ;; Advised & aliased function.
 		      (and advised (symbolp real-function))))
 	 (real-def (cond
 		    (aliased (let ((f real-function))
-			       (while (and (fboundp f)
-					   (symbolp (symbol-function f)))
-				 (setq f (symbol-function f)))
+			 (while (and (fboundp f)
+				     (symbolp (symbol-function f)))
+			   (setq f (symbol-function f)))
 			       f))
 		    ((subrp def) (intern (subr-name def)))
 		    (t def)))
@@ -706,7 +769,7 @@ describe-variable
                     (format
                      "Describe variable (default %s): " v)
                   "Describe variable: ")
-                obarray
+                #'help--symbol-completion-table
                 (lambda (vv)
                   ;; In case the variable only exists in the buffer
                   ;; the command we switch back to that buffer before

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> The code I pushed just populates a new hash table `definition-prefixes'.
> We still need to change help-fns.el (and various other places) to make
> use of it.

BTW, there could be other uses for it:
- detect and warn about prefix-conflicts (when two packages use the same
  prefix).  The main difficulty here could be to figure out if two files
  are part of the same package or not, tho a good heuristic could be to
  check if they're in the same directory.
- emit warnings about packages that are not namespace clean which we
  can define as "use more than one prefix".  There are some non-trivial
  issues to handle, tho, such as the issue of exceptions like
  "define-<foo>", or the issue of files which have very few definitions
  (say 3), in which case my algorithm may decide that the file uses
  3 separate prefixes.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 25 May 2016 23:01:51 -0400
> 
> > Is that available on master?
> 
> I just pushed it, yes.

Thanks.

> > If not, please push, and let's start using this.
> 
> The code I pushed just populates a new hash table `definition-prefixes'.
> We still need to change help-fns.el (and various other places) to make
> use of it.
> 
> I've used the patch below (which makes `C-h f' use that table during
> completion), but it's just the temporary result of my experimentation
> with it: it's fundamentally incorrect and hence needs to be rewritten.

So I guess we need more coding to get rid of autoloaded defcustoms.

Btw, it would be nice to have this machinery documented, so that its
usage would be more clear to the uninitiated.  We could then point to
that docs when such issues arise.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> So I guess we need more coding to get rid of autoloaded defcustoms.
> Btw, it would be nice to have this machinery documented, so that its
> usage would be more clear to the uninitiated.  We could then point to
> that docs when such issues arise.

I added a NEWS entry as well as a more precise docstring for
definition-prefixes.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 27 May 2016 15:51:55 -0400
> 
> > So I guess we need more coding to get rid of autoloaded defcustoms.
> > Btw, it would be nice to have this machinery documented, so that its
> > usage would be more clear to the uninitiated.  We could then point to
> > that docs when such issues arise.
> 
> I added a NEWS entry as well as a more precise docstring for
> definition-prefixes.

Thanks.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

>> I've used the patch below (which makes `C-h f' use that table during
>> completion), but it's just the temporary result of my experimentation
>> with it: it's fundamentally incorrect and hence needs to be rewritten.
> So I guess we need more coding to get rid of autoloaded defcustoms.

I pushed a further patch recently which should make it work for C-f and
C-h v:

    emacs -Q
    C-h v server- TAB

will load server.el and show all the variables defined there in.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 276 bytes --]

On 2016-06-17 12:42, Stefan Monnier wrote:
>     emacs -Q
>     C-h v server- TAB
> 
> will load server.el and show all the variables defined there in.

Sounds neat. I wonder, though: how does this interact with ido? What about M-x completion (and smex)?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

>> emacs -Q
>> C-h v server- TAB
>> will load server.el and show all the variables defined there in.
> Sounds neat. I wonder, though: how does this interact with ido?

It "just works" with icomplete-mode and I guess it should work just as
well with ido-everywhere: i.e., as soon as you type the "-" after
"server", server.el will be loaded and extra entries will appear.

> What about M-x completion (and smex)?

Currently only C-h f and C-h v have been changed to make use of
the functionality.  Every place where we want this auto-loading to
happen needs to be modified so as to use #'help--symbol-completion-table
instead of `obarray' as completion table.  See below the two hunks that
do that for C-h f and C-h v.


        Stefan


@@ -58,8 +114,9 @@ describe-function
      (setq val (completing-read (if fn
 				    (format "Describe function (default %s): " fn)
 				  "Describe function: ")
-				obarray 'fboundp t nil nil
-				(and fn (symbol-name fn))))
+				#'help--symbol-completion-table
+                                #'fboundp
+                                t nil nil (and fn (symbol-name fn))))
      (list (if (equal val "")
 	       fn (intern val)))))
   (or (and function (symbolp function))
@@ -706,7 +763,7 @@ describe-variable
                     (format
                      "Describe variable (default %s): " v)
                   "Describe variable: ")
-                obarray
+                #'help--symbol-completion-table
                 (lambda (vv)
                   ;; In case the variable only exists in the buffer
                   ;; the command we switch back to that buffer before

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 309 bytes --]

On 2016-06-17 18:35, Stefan Monnier wrote:
> It "just works" with icomplete-mode and I guess it should work just as
> well with ido-everywhere: i.e., as soon as you type the "-" after
> "server", server.el will be loaded and extra entries will appear.

This sounds very nice (awesome, even!). Thanks!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 06/18/2016 01:35 AM, Stefan Monnier wrote:

> I guess it should work just as
> well with ido-everywhere: i.e., as soon as you type the "-" after
> "server", server.el will be loaded and extra entries will appear.

Probably not. Last I checked, Ido only supported "simple" completion 
tables, such as lists and alists (and maybe obarray). Which is a shame, 
in this and other use cases.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> Probably not. Last I checked, Ido only supported "simple" completion tables,
> such as lists and alists (and maybe obarray). Which is a shame, in this and
> other use cases.

Indeed, it's too bad and it's actually surprising since the main two
cases where ido is used (buffers and files) both use functions as
completion table.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 06/18/2016 09:09 PM, Stefan Monnier wrote:

> Indeed, it's too bad and it's actually surprising since the main two
> cases where ido is used (buffers and files) both use functions as
> completion table.

Not in Ido, though. It uses dedicates functions for each command which 
reimplement the completions tables in its own way.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 541 bytes --]

On 2016-06-18 14:09, Stefan Monnier wrote:
>> Probably not. Last I checked, Ido only supported "simple" completion tables,
>> such as lists and alists (and maybe obarray). Which is a shame, in this and
>> other use cases.
> 
> Indeed, it's too bad and it's actually surprising since the main two
> cases where ido is used (buffers and files) both use functions as
> completion table.

Btw, ido-ubiquitous seems broken in the latest master; is this expected? Even in ido-ubiquitous-mode, C-h f doesn't use ido completion anymore.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]

On 2016-06-23 09:45, Clément Pit--Claudel wrote:
> On 2016-06-18 14:09, Stefan Monnier wrote:
>>> Probably not. Last I checked, Ido only supported "simple" completion tables,
>>> such as lists and alists (and maybe obarray). Which is a shame, in this and
>>> other use cases.
>>
>> Indeed, it's too bad and it's actually surprising since the main two
>> cases where ido is used (buffers and files) both use functions as
>> completion table.
> 
> Btw, ido-ubiquitous seems broken in the latest master; is this expected? Even in ido-ubiquitous-mode, C-h f doesn't use ido completion anymore.

C-h v is broken as well, but not C-h o.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 06/23/2016 04:45 PM, Clément Pit--Claudel wrote:

> Btw, ido-ubiquitous seems broken in the latest master; is this expected? Even in ido-ubiquitous-mode, C-h f doesn't use ido completion anymore.

You should update, it got kind-of fixed, but see 
https://github.com/DarwinAwardWinner/ido-ubiquitous/issues/110.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 419 bytes --]

On 2016-06-23 10:27, Dmitry Gutov wrote:
> On 06/23/2016 04:45 PM, Clément Pit--Claudel wrote:
> 
>> Btw, ido-ubiquitous seems broken in the latest master; is this expected? Even in ido-ubiquitous-mode, C-h f doesn't use ido completion anymore.
> 
> You should update, it got kind-of fixed, but see https://github.com/DarwinAwardWinner/ido-ubiquitous/issues/110.

Thanks! And thanks for the explanation, too.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 06/18/2016 09:09 PM, Stefan Monnier wrote:

> Indeed, it's too bad and it's actually surprising since the main two
> cases where ido is used (buffers and files) both use functions as
> completion table.

ido-ubiquitous uses a whitelist to determine which completion tables can 
be easily converted to plain lists (actually, they have a whole 
configuration framework for that now).

I wish they spent all these efforts on making Ido work with completions 
tables properly instead. :-(

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

> I wish they spent all these efforts on making Ido work with completions
> tables properly instead. :-(

Actually, I wish they worked on providing the ido UI on top of
the standard completion code, along the lines of icomplete-mode.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 06/23/2016 06:35 PM, Stefan Monnier wrote:

> Actually, I wish they worked on providing the ido UI on top of
> the standard completion code, along the lines of icomplete-mode.

Reimplementing ido-find-file on top of it seems rather hard, doesn't it?

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

>> Actually, I wish they worked on providing the ido UI on top of
>> the standard completion code, along the lines of icomplete-mode.
> Reimplementing ido-find-file on top of it seems rather hard, doesn't it?

Could be.  It probably depends on whether you want to reproduce 100% of
the details of IDO's behavior, or you want to "simply" add some of the
functionality.


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Robert Weiner]

On Fri, Jun 17, 2016 at 6:35 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Every place where we want this auto-loading to
> happen needs to be modified so as to use #'help--symbol-completion-table
> instead of `obarray' as completion table.

Then shouldn't this be a public rather than private name (two dashes)?
I would think other modes would utilize this feature as well.

Bob

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Stefan Monnier]

>> Every place where we want this auto-loading to happen needs to be
>> modified so as to use #'help--symbol-completion-table instead of
>> `obarray' as completion table.

> Then shouldn't this be a public rather than private name (two dashes)?
> I would think other modes would utilize this feature as well.

Yes, probably.  The current code is still tentative and will surely
require some changes such as this one (and probably others as well,
such as moving the code elsewhere).


        Stefan

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Glenn Morris]

Eli Zaretskii wrote:

>> Autoloading defcustoms just so people can set them interactively before
>> the associated package is loaded is a Bad Thing.
>
> I don't understand why.  Can you explain?  That's not the only
> defcustom that is marked as autoloaded.

It's the Emacs policy, and has been for years, to not autoload
defcustoms unless it's really needed for some special reason. Eg

http://lists.gnu.org/archive/html/help-gnu-emacs/2007-06/msg00360.html
http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01145.html

I agree with Stefan. It's just wrong. Don't try to solve a generic
issue by autoloading the world one piece at a time.

>> IMO it would have been better to simply remove the bit about
>> set-variable from the manual.
>
> I don't see why we should remove useful advice from the manual, just
> because it's inconvenient to make it work.

It's not useful advice. This is the only instance of M-x set-variable in
the entire manual! No-one using multiple servers (a relatively advanced
feature) needs that crutch. It adds nothing to the manual to have it
there, and it should be taken out.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 20 May 2016 13:30:04 -0400
> 
> Eli Zaretskii wrote:
> 
> >> Autoloading defcustoms just so people can set them interactively before
> >> the associated package is loaded is a Bad Thing.
> >
> > I don't understand why.  Can you explain?  That's not the only
> > defcustom that is marked as autoloaded.
> 
> It's the Emacs policy, and has been for years, to not autoload
> defcustoms unless it's really needed for some special reason. Eg

Well, heck, I guess I'm against that policy.

> I agree with Stefan. It's just wrong. Don't try to solve a generic
> issue by autoloading the world one piece at a time.

We must solve the problems that annoy users (and me as well).  If we
cannot put our money where our mouth is, we should solve the problems
in some less clean way, but solve them we must.  Refusing to solve
problems because the available solutions are not clean enough, and
then doing nothing to provide a more clean one, is not a good modus
operandi for a project, IMO.

> >> IMO it would have been better to simply remove the bit about
> >> set-variable from the manual.
> >
> > I don't see why we should remove useful advice from the manual, just
> > because it's inconvenient to make it work.
> 
> It's not useful advice. This is the only instance of M-x set-variable in
> the entire manual! No-one using multiple servers (a relatively advanced
> feature) needs that crutch. It adds nothing to the manual to have it
> there, and it should be taken out.

I obviously disagree.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 05/20/2016 08:47 PM, Eli Zaretskii wrote:

> We must solve the problems that annoy users (and me as well).

Have you ever experienced an actual need to modify the variable 
`server-name' using `set-variable' yourself?

Like Glenn says, it looks like a pretty niche feature. If so, it would 
not be unreasonable to expect that the user is familiar with `setq'.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 20 May 2016 21:15:59 +0300
> 
> On 05/20/2016 08:47 PM, Eli Zaretskii wrote:
> 
> > We must solve the problems that annoy users (and me as well).
> 
> Have you ever experienced an actual need to modify the variable 
> `server-name' using `set-variable' yourself?

I honestly don't remember.  I did get annoyed by set-variable not
working for the same reasons with other variables, though, so I am
sympathetic with the OP's annoyance.

> Like Glenn says, it looks like a pretty niche feature.

Then why are we arguing about it so much?

> If so, it would not be unreasonable to expect that the user is
> familiar with `setq'.

We don't advise using setq in the user manual, in general.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Leo Liu]

On 2016-05-20 21:55 +0300, Eli Zaretskii wrote:
> Then why are we arguing about it so much?

Because it defeats years of discipline people have put into (not)
autoload defcustom's.

Leo

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 21 May 2016 12:25:36 +0800
> 
> On 2016-05-20 21:55 +0300, Eli Zaretskii wrote:
> > Then why are we arguing about it so much?
> 
> Because it defeats years of discipline people have put into (not)
> autoload defcustom's.

I don't see how a single autoload could produce such a dramatic
effect.  Avoiding such autoloading unless strictly necessary is still
good practice, IMO.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Dmitry Gutov]

On 05/21/2016 09:52 AM, Eli Zaretskii wrote:

> I don't see how a single autoload could produce such a dramatic
> effect.

I guess that depends on the kinds of problems that having autoloaded 
defcustoms would bring up.

> Avoiding such autoloading unless strictly necessary is still
> good practice, IMO.

Right. And since the issue is marginal, the "strictly necessary" is 
under dispute here.

Re: master f995fbd: * lisp/server.el (server-name): Add autoload cookie. (Bug#23576)

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 21 May 2016 10:05:13 +0300
> 
> On 05/21/2016 09:52 AM, Eli Zaretskii wrote:
> 
> > I don't see how a single autoload could produce such a dramatic
> > effect.
> 
> I guess that depends on the kinds of problems that having autoloaded 
> defcustoms would bring up.

I agree, but the only specific problem I heard about in this and other
related discussions is with duplication in loaddefs.el.  I must say I
don't really understand that problem, since what I see in loaddefs.el
is this:

  (defvar server-name "server" "\
  The name of the Emacs server, if this Emacs process creates one.
  The command `server-start' makes use of this.  It should not be
  changed while a server is running.")

  (custom-autoload 'server-name "server" t)

Why this is a problem in a file that is auto-generated is not clear to
me.

No other practical problems were brought up.  The past discussions
Glenn pointed to say nothing except "don't do that, EOD".  Not very
helpful for trying to make up my own mind about the issue.

> > Avoiding such autoloading unless strictly necessary is still
> > good practice, IMO.
> 
> Right. And since the issue is marginal, the "strictly necessary" is 
> under dispute here.

Like anything else discussed on this list.  And like everything else,
for marginal issues, we must at some point trust the judgment of each
other, even when we don't necessarily agree.