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

[Jambunathan K]

Juri Linkov <juri@jurta.org> writes:

>> 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.

The question was one of how `read-regexp' should behave?

If (car DEFAULTS) is nil should it offer (car SUGGESTIONS) as a default
or offer an empty string for default.

>
> 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 :-)