* bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings @ 2021-11-30 16:59 Matt Armstrong 2021-11-30 19:18 ` bug#52202: [PATCH] " Matt Armstrong 0 siblings, 1 reply; 8+ messages in thread From: Matt Armstrong @ 2021-11-30 16:59 UTC (permalink / raw) To: 52202 `try-completion' and `all-completions' support a completion COLLECTION of a list of strings. This is not documented in their docstrings. This is confusing because every other supported data structure is mentioned. This support was added around 20 years ago. See Stefan's commit 695deb1857 or https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=695deb1857dd95239df0139894e40719699a6cc8 I'm assuming this was just an oversight, since `test-completion' mentions "list of strings" as does the description of `try-completion' in the elisp manual. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52202: [PATCH] try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-11-30 16:59 bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings Matt Armstrong @ 2021-11-30 19:18 ` Matt Armstrong 2021-11-30 19:30 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Matt Armstrong @ 2021-11-30 19:18 UTC (permalink / raw) To: bug#52202 [-- Attachment #1: Type: text/plain, Size: 266 bytes --] Attached is a docstring patch against the emacs-28 branch for this issue. Note/question: I wonder if the `all-completions' docstring should refer to `try-completion' rather than copy much of the text. The same approach works well in the lisp ref manual, I think. [-- Attachment #2: 0001-Improve-the-try-completion-and-all-completions-docst.patch --] [-- Type: text/x-diff, Size: 8288 bytes --] From 8bc1bee134f0626513efd00f4a283cf5a2d2a359 Mon Sep 17 00:00:00 2001 From: Matt Armstrong <matt@rfc20.org> Date: Tue, 30 Nov 2021 10:54:17 -0800 Subject: [PATCH] Improve the `try-completion' and `all-completions' docstrings * src/minibuf.c (Ftry_completion): (Fall_completions): Use language from the Emacs lisp manual when talking about the COLLECTION and PREDICATE arguments. Most notably, the way completion tables may be passed is now more clear. The prior docstring did not mention lists of strings/symbols at all. Bug#52202 --- src/minibuf.c | 124 +++++++++++++++++++++++++++++++------------------- 1 file changed, 77 insertions(+), 47 deletions(-) diff --git a/src/minibuf.c b/src/minibuf.c index 6c0cd358c5..f1ee7b2453 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -1569,34 +1569,49 @@ match_regexps (Lisp_Object string, Lisp_Object regexps, DEFUN ("try-completion", Ftry_completion, Stry_completion, 2, 3, 0, doc: /* Return common substring of all completions of STRING in COLLECTION. Test each possible completion specified by COLLECTION -to see if it begins with STRING. The possible completions may be -strings or symbols. Symbols are converted to strings before testing, -see `symbol-name'. -All that match STRING are compared together; the longest initial sequence -common to all these matches is the return value. -If there is no match at all, the return value is nil. -For a unique match which is exact, the return value is t. - -If COLLECTION is an alist, the keys (cars of elements) are the -possible completions. If an element is not a cons cell, then the -element itself is the possible completion. -If COLLECTION is a hash-table, all the keys that are strings or symbols -are the possible completions. -If COLLECTION is an obarray, the names of all symbols in the obarray -are the possible completions. +to see if it begins with STRING. -COLLECTION can also be a function to do the completion itself. -It receives three arguments: the values STRING, PREDICATE and nil. +All completions that match STRING are compared together; the longest +initial sequence common to all these matches is the return value. If +there is no match at all, the return value is nil. For a unique match +which is exact, the return value is t. + +COLLECTION is called the "completion table." Its value must be a +list, a hash table, an obarray, or a completion function. + +If COLLECTION is a list, the possible completions are specified by the +elements of the list, each of which should be either a string, a +symbol, or a cons cell whose CAR is either a string or a symbol. If +the list contains elements of any other type, those are ignored. + +If COLLECTION is a hash-table, all the keys that are strings or +symbols are the possible completions. + +If COLLECTION is an obarray, all the symbols in the obarray are the +possible completions. + +The possible completions from COLLECTION that are symbols are +converted to strings before testing, see `symbol-name'. + +COLLECTION can also be a function to do the completion itself. It +receives three arguments: the values STRING, PREDICATE and nil (the +third argument is so that the same function can be used in +‘all-completions’ and do the appropriate thing in either case). Whatever it returns becomes the value of `try-completion'. -If optional third argument PREDICATE is non-nil, -it is used to test each possible match. -The match is a candidate only if PREDICATE returns non-nil. -The argument given to PREDICATE is the alist element -or the symbol from the obarray. If COLLECTION is a hash-table, -predicate is called with two arguments: the key and the value. -Additionally to this predicate, `completion-regexp-list' -is used to further constrain the set of candidates. */) +If optional third argument PREDICATE is non-nil, it is used to test +each possible match. The match is a candidate only if PREDICATE +returns non-nil. The argument given to PREDICATE is an element from +COLLECTION. If COLLECTION is a list it is a list element (either a +symbol, string, or cons cell whose CAR is a symbol or string). If +COLLECTION is an obarray, a symbol from it. If COLLECTION is a +hash-table, predicate is called with two arguments: a key and the +value. + +In addition, to be acceptable, a completion must also match all the +regular expressions in ‘completion-regexp-list’. (Unless COLLECTION +is a function, in which case that function has to handle +‘completion-regexp-list’ itself.) */) (Lisp_Object string, Lisp_Object collection, Lisp_Object predicate) { @@ -1808,31 +1823,46 @@ DEFUN ("try-completion", Ftry_completion, Stry_completion, 2, 3, 0, DEFUN ("all-completions", Fall_completions, Sall_completions, 2, 4, 0, doc: /* Search for partial matches to STRING in COLLECTION. Test each of the possible completions specified by COLLECTION -to see if it begins with STRING. The possible completions may be -strings or symbols. Symbols are converted to strings before testing, -see `symbol-name'. -The value is a list of all the possible completions that match STRING. - -If COLLECTION is an alist, the keys (cars of elements) are the -possible completions. If an element is not a cons cell, then the -element itself is the possible completion. -If COLLECTION is a hash-table, all the keys that are strings or symbols -are the possible completions. -If COLLECTION is an obarray, the names of all symbols in the obarray -are the possible completions. +to see if it begins with STRING. +The value is a list of strings for all the possible completions that +match STRING. -COLLECTION can also be a function to do the completion itself. -It receives three arguments: the values STRING, PREDICATE and t. +COLLECTION is called the "completion table." Its value must be a +list, a hash table, an obarray, or a completion function. + +If COLLECTION is a list, the permissible completions are specified by +the elements of the list, each of which should be either a string, a +symbol, or a cons cell whose CAR is either a string or a symbol. If +the list contains elements of any other type, those are ignored. + +If COLLECTION is a hash-table, all the keys that are strings or +symbols are the possible completions. + +If COLLECTION is an obarray, all the symbols in the obarray are the +possible completions. + +The possible completions from COLLECTION that are symbols are +converted to strings before testing, see `symbol-name'. + +COLLECTION can also be a function to do the completion itself. It +receives three arguments: the values STRING, PREDICATE and t (the +third argument is so that the same function can be used in +‘try-completion’ and do the appropriate thing in either case). Whatever it returns becomes the value of `all-completions'. -If optional third argument PREDICATE is non-nil, -it is used to test each possible match. -The match is a candidate only if PREDICATE returns non-nil. -The argument given to PREDICATE is the alist element -or the symbol from the obarray. If COLLECTION is a hash-table, -predicate is called with two arguments: the key and the value. -Additionally to this predicate, `completion-regexp-list' -is used to further constrain the set of candidates. +If optional third argument PREDICATE is non-nil, it is used to test +each possible match. The match is a candidate only if PREDICATE +returns non-nil. The argument given to PREDICATE is an element from +COLLECTION. If COLLECTION is a list it is a list element (either a +symbol, string, or cons cell whose CAR is a symbol or string). If +COLLECTION is an obarray, a symbol from it. If COLLECTION is a +hash-table, predicate is called with two arguments: a key and the +value. + +In addition, to be acceptable, a completion must also match all the +regular expressions in ‘completion-regexp-list’. (Unless COLLECTION +is a function, in which case that function has to handle +‘completion-regexp-list’ itself.) An obsolete optional fourth argument HIDE-SPACES is still accepted for backward compatibility. If non-nil, strings in COLLECTION that start -- 2.33.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#52202: [PATCH] try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-11-30 19:18 ` bug#52202: [PATCH] " Matt Armstrong @ 2021-11-30 19:30 ` Eli Zaretskii 2021-11-30 20:39 ` bug#52202: 29.0.50; " Matt Armstrong 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2021-11-30 19:30 UTC (permalink / raw) To: Matt Armstrong; +Cc: 52202 > From: Matt Armstrong <matt@rfc20.org> > Date: Tue, 30 Nov 2021 11:18:05 -0800 > > Attached is a docstring patch against the emacs-28 branch for this > issue. Thanks, but ... all these changes just to say that a list of strings can also be a COLLECTION? This looks like a complete rewrite, and comparing it with the existing doc string is a lot of work. Is the current doc string really that awful and requires such a complete rewrite? Why can't we get away with a smaller, simpler change (that would be easier to review and approve)? > Note/question: I wonder if the `all-completions' docstring should refer > to `try-completion' rather than copy much of the text. The same > approach works well in the lisp ref manual, I think. ELisp manual describes both one next to the other, so it can get away with such a technique. Doc strings don't have that luxury; referring the user to another complex doc string generally raises the bar and makes the documentation harder to use, because one needs to constantly go back to the original function to figure out how the arguments described in the other function are used in the original one. It's annoying. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-11-30 19:30 ` Eli Zaretskii @ 2021-11-30 20:39 ` Matt Armstrong 2021-12-01 3:36 ` Eli Zaretskii 2021-12-01 3:57 ` Lars Ingebrigtsen 0 siblings, 2 replies; 8+ messages in thread From: Matt Armstrong @ 2021-11-30 20:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 52202 Eli Zaretskii <eliz@gnu.org> writes: >> From: Matt Armstrong <matt@rfc20.org> >> Date: Tue, 30 Nov 2021 11:18:05 -0800 >> >> Attached is a docstring patch against the emacs-28 branch for this >> issue. > > Thanks, but ... all these changes just to say that a list of strings > can also be a COLLECTION? This looks like a complete rewrite, and > comparing it with the existing doc string is a lot of work. Is the > current doc string really that awful and requires such a complete > rewrite? Why can't we get away with a smaller, simpler change (that > would be easier to review and approve)? Thanks Eli, I can sympathize with respect to the review difficulty, but I couldn't find a simple edit that did a good job. It is more than just "list of strings", but I did not realize when I filed the bug. This became clear only after I started reading code and trying to document the current behavior. Then I realized that the lisp reference manual is in good shape. This patch copies text almost verbatim from it. So, the diff is both large but hopefully not hard to verify in review. Another issue is that these function provide extension points that pass COLLECTION or elements from it directly to caller-supplied functions. To write those functions correctly the programmer has to know all the details of how the default C implementation works if the callbacks are to work in a robust way. In other words, this docstring is for completion extension implementers as much as it is for callers. I figure an exhaustively pedantic approach is justifiable here. One problem is the semantic complexity of how these functions interpret COLLECTION. They defy a simple and concise explanation. E.g. COLLECTION can be... ...a list of strings ...a list of symbols ...an alist whose keys are strings ...an alist whose keys are symbols ...a list whose elements are a mixture of any of the above four possibilities. And we have hash tables whose keys are strings, symbols, or a mix... Also, any PREDICATE is passed the list elements (or hash key/values) directly, without any symbol->string normalization. Little of this is clear from the current docstrings, but the lisp ref does a good job with it. >> Note/question: I wonder if the `all-completions' docstring should refer >> to `try-completion' rather than copy much of the text. The same >> approach works well in the lisp ref manual, I think. > > ELisp manual describes both one next to the other, so it can get away > with such a technique. Doc strings don't have that luxury; referring > the user to another complex doc string generally raises the bar and > makes the documentation harder to use, because one needs to constantly > go back to the original function to figure out how the arguments > described in the other function are used in the original one. It's > annoying. That makes sense, thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-11-30 20:39 ` bug#52202: 29.0.50; " Matt Armstrong @ 2021-12-01 3:36 ` Eli Zaretskii 2021-12-01 19:43 ` Matt Armstrong 2021-12-01 3:57 ` Lars Ingebrigtsen 1 sibling, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2021-12-01 3:36 UTC (permalink / raw) To: Matt Armstrong; +Cc: 52202 > From: Matt Armstrong <matt@rfc20.org> > Cc: 52202@debbugs.gnu.org > Date: Tue, 30 Nov 2021 12:39:45 -0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Matt Armstrong <matt@rfc20.org> > >> Date: Tue, 30 Nov 2021 11:18:05 -0800 > >> > >> Attached is a docstring patch against the emacs-28 branch for this > >> issue. > > > > Thanks, but ... all these changes just to say that a list of strings > > can also be a COLLECTION? This looks like a complete rewrite, and > > comparing it with the existing doc string is a lot of work. Is the > > current doc string really that awful and requires such a complete > > rewrite? Why can't we get away with a smaller, simpler change (that > > would be easier to review and approve)? > > Thanks Eli, I can sympathize with respect to the review difficulty, but > I couldn't find a simple edit that did a good job. It is more than just > "list of strings", but I did not realize when I filed the bug. This > became clear only after I started reading code and trying to document > the current behavior. Can you list the aspects which the current doc string doesn't describe, or describes inaccurately or incorrectly? Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-12-01 3:36 ` Eli Zaretskii @ 2021-12-01 19:43 ` Matt Armstrong 0 siblings, 0 replies; 8+ messages in thread From: Matt Armstrong @ 2021-12-01 19:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 52202 Eli Zaretskii <eliz@gnu.org> writes: >> Thanks Eli, I can sympathize with respect to the review difficulty, but >> I couldn't find a simple edit that did a good job. It is more than just >> "list of strings", but I did not realize when I filed the bug. This >> became clear only after I started reading code and trying to document >> the current behavior. > > Can you list the aspects which the current doc string doesn't > describe, or describes inaccurately or incorrectly? Good question; maybe I went overboard. Quotes below are from the current docstring: > If COLLECTION is an alist, the keys (cars of elements) are the > possible completions. If an element is not a cons cell, then the > element itself is the possible completion. I find this confusing because "If COLLECTION is an alist" strongly leads the reader away from the idea that "COLLECTION may also be a list of symbols/strings." So perhaps replace this paragraph with slightly edited text from the manual: If COLLECTION is a list (or alist), the permissible completions are specified by the elements of the list, each of which should be either a string, or a cons cell whose CAR is either a string or a symbol. If the list contains elements of any other type, those are ignored. > The argument given to PREDICATE is the alist element or the symbol > from the obarray. I found this confusing too, for the same reason. So how about: The argument given to PREDICATE is either a string, symbol or a cons cell (the CAR of which is a string or symbol) from the list (or alist), or a symbol (_not_ a symbol name) from the obarray. If COLLECTION is a hash table, PREDICATE is called with two arguments, the string or symbol key and the associated value. These two blurbs are slight edits from the elisp manual. I think this new wording would be good in both the doc string and the manual. If these smaller edits seem good I'm happy to reformulate the patch (I can update the manual as well). ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-11-30 20:39 ` bug#52202: 29.0.50; " Matt Armstrong 2021-12-01 3:36 ` Eli Zaretskii @ 2021-12-01 3:57 ` Lars Ingebrigtsen 2021-12-01 19:49 ` Matt Armstrong 1 sibling, 1 reply; 8+ messages in thread From: Lars Ingebrigtsen @ 2021-12-01 3:57 UTC (permalink / raw) To: Matt Armstrong; +Cc: 52202 Matt Armstrong <matt@rfc20.org> writes: > Then I realized that the lisp reference manual is in good shape. This > patch copies text almost verbatim from it. So, the diff is both large > but hopefully not hard to verify in review. In these cases, we usually just say "See (elisp)Section" in the doc strings, and leave the description of the complex data structures to the manual. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings 2021-12-01 3:57 ` Lars Ingebrigtsen @ 2021-12-01 19:49 ` Matt Armstrong 0 siblings, 0 replies; 8+ messages in thread From: Matt Armstrong @ 2021-12-01 19:49 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 52202 Lars Ingebrigtsen <larsi@gnus.org> writes: > Matt Armstrong <matt@rfc20.org> writes: > >> Then I realized that the lisp reference manual is in good shape. This >> patch copies text almost verbatim from it. So, the diff is both large >> but hopefully not hard to verify in review. > > In these cases, we usually just say "See (elisp)Section" in the doc > strings, and leave the description of the complex data structures to > the manual. I can see it both ways. Eli suggested that a complete docstring would be more handy (up thread), and I now think this might be achievable with simpler edits, so absent a different consensus I'll go that direction for now. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-12-01 19:49 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-11-30 16:59 bug#52202: 29.0.50; try-completion, all-completions support for a list of strings COLLECTION is not documented in their docstrings Matt Armstrong 2021-11-30 19:18 ` bug#52202: [PATCH] " Matt Armstrong 2021-11-30 19:30 ` Eli Zaretskii 2021-11-30 20:39 ` bug#52202: 29.0.50; " Matt Armstrong 2021-12-01 3:36 ` Eli Zaretskii 2021-12-01 19:43 ` Matt Armstrong 2021-12-01 3:57 ` Lars Ingebrigtsen 2021-12-01 19:49 ` Matt Armstrong
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.