Subject: bug#65459: completing-read INITIAL-VALUE unaware of COLLECTION and REQUIRE-MATCH

From: Eli Zaretskii <[email-masked]>
Date: Thu, 31 Aug 2023 12:42:54 +0300

> Date: Sat, 26 Aug 2023 08:06:39 +0000
> From: Gregory Heytings <[email-masked]>
> cc: Heime <[email-masked]>, Eli Zaretskii <[email-masked]>, 
>     [email-masked]
> 
> 
> >
> > The issue is not "don't use `(n)advice.el`", but "don't modify functions 
> > on the sly".  And by "functions" this refers to those things stored in 
> > the `symbol-function` slot of symbols in the global obarray.  This is 
> > because code that does `(my-foo ...)` usually expects to execute the 
> > code found in `(defun my-foo ...)` and not something else, and readers 
> > of that code often make the same assumption, so it can make debugging 
> > really nasty.
> >
> > Changing a function with `fset` (or `cl-letf` or `defalias`) is worse 
> > than using `advice-add`, for that reason: at least `advice-add` sets up 
> > the help system such that `C-h f` will (hopefully) warn you about the 
> > presence of an advice.
> >
> > For variables containing functions (such as 
> > `minibuffer-default-add-function`), there is no such expectation that 
> > calling this function will run some known piece of code, on the 
> > contrary: the whole point of the variable is to run difference pieces of 
> > code in different contexts, so modifying the function is perfectly OK, 
> > regardless whether you do it with `setq` or `add-function`.  Here I'd 
> > use `add-function` because it's simpler.
> >
> 
> Thanks, that clarifies that question!  Perhaps a paragraph along those 
> lines could be added to "(elisp)Advising Functions"?

Feel free to suggest a clarification for the manual, and thanks in
advance.