bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el (read-regexp): Let-bind `default' to the first

[Juri Linkov <juri@jurta.org>]

> emacs -Q
> M-s h r
>
> I find the following error
>
> ,----
> | Debugger entered--Lisp error: (error "Regexp cannot match an empty string")
> |   signal(error ("Regexp cannot match an empty string"))
> |   error("Regexp cannot match an empty string")
> |   hi-lock-regexp-okay("")
> |   byte-code("..." [regexp-history hi-lock-regexp-okay read-regexp "Regexp to highlight" hi-lock-read-face-name] 4)
> |   call-interactively(highlight-regexp nil nil)
> |   command-execute(highlight-regexp)
> `----
>
> So, if one does
>         (read-regexp something) ;; something is nil or evals to nil
>
> what should the interpretation be.
>
> With your change, a `nil' default will provide an empty string as input
> and force user to enter a regexp or rely on M-n.
>
> We seem to be bumping in to each other in this area.  Comments ...?
>
> ,---- Stefan @ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13687#11
> | I disagree: read-regexp is a generic function which can be used in
> | various contexts, some of which might not care at all about the text
> | around point.  So the caller should have control over the first default
> | (of course, it's perfectly fine to always add the current tag in the
> | subsequent defaults).
> |
> | This said your patch seems to leave the caller's provided `defaults' at
> | the beginning of the minibuffer's `defaults', so I think your patch is
> | fine, feel free to install it.
> `----
>
> I am wondering how we can resolve the contex-free read-regexp and
> context-dependent regexp.  Any suggestions?

It's a responsibility of the caller to provide the default value.
`M-s h r' (`highlight-regexp') provides the default value as
`(car regexp-history)'.  When it is called the first time after
`emacs -Q', the history is empty, so its default value is nil
(this fact is indicated with missing default value in the prompt,
so the user is aware that RET with empty input will do nothing.)

When `highlight-regexp' is called the second time and more,
it gets the default value from `regexp-history', so you can't
provide the tag at point as the default for later invocations
of `highlight-regexp' anyway.

So the question is: should the default value in the caller
`highlight-regexp' be changed from `(car regexp-history)'
to code that gets the tag at point?  You could propose
such a change, but since it changes the long-standing behavior,
expect some disagreement (not from me :-)