bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Nicolas Richard]

Hi,

Reproduce:
emacs -Q -f toggle-debug-on-error --eval '(execute-kbd-macro (kbd "M-x f o o C-a <tab>"))'

backtrace:
Debugger entered--Lisp error: (wrong-type-argument numberp nil)
  zerop(nil)
  minibuffer-completion-help(5 8)
[the rest is of no particular interest]

Possible fix (i.e. Work© Fo® Me™):

--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1753,7 +1753,7 @@ variables.")
            (if completions "Sole completion" "No completions")))
 
       (let* ((last (last completions))
-             (base-size (cdr last))
+             (base-size (or (cdr last) 0))
              (prefix (unless (zerop base-size) (substring string 0 base-size)))
              (all-md (completion--metadata (buffer-substring-no-properties
                                             start (point))


-- 
Nico.

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Leo Liu]

On 2014-03-04 22:12 +0800, Nicolas Richard wrote:
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -1753,7 +1753,7 @@ variables.")
>             (if completions "Sole completion" "No completions")))
>  
>        (let* ((last (last completions))
> -             (base-size (cdr last))
> +             (base-size (or (cdr last) 0))
>               (prefix (unless (zerop base-size) (substring string 0 base-size)))
>               (all-md (completion--metadata (buffer-substring-no-properties
>                                              start (point))

I noticed this error too. (base-size (cdr last)) is used in 24.3 and no
errors there. So it will be good to know where the problem originated
and fix it.

Leo

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Bastien]

Leo Liu <sdl.web@gmail.com> writes:

> On 2014-03-04 22:12 +0800, Nicolas Richard wrote:
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -1753,7 +1753,7 @@ variables.")
>>             (if completions "Sole completion" "No completions")))
>>  
>>        (let* ((last (last completions))
>> -             (base-size (cdr last))
>> +             (base-size (or (cdr last) 0))
>>               (prefix (unless (zerop base-size) (substring string 0 base-size)))
>>               (all-md (completion--metadata (buffer-substring-no-properties
>>                                              start (point))
>
> I noticed this error too. (base-size (cdr last)) is used in 24.3 and no
> errors there. So it will be good to know where the problem originated
> and fix it.

Sorry -- I just saw Nicolas email and yours.  Hopefully, I came up
with the same fix.

The error originated here:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=66c5fecc

The commit makes `base-size' optional, so we need to ensure it
falls back to 0 instead of nil.

-- 
 Bastien

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Nicolas Richard]

Bastien <bzg@altern.org> writes:
> Leo Liu <sdl.web@gmail.com> writes:
>> I noticed this error too. (base-size (cdr last)) is used in 24.3 and no
>> errors there. So it will be good to know where the problem originated
>> and fix it.
> The commit makes `base-size' optional, so we need to ensure it
> falls back to 0 instead of nil.

Shouldn't base-size default to 0 in completion-hilit-commonality then,
to avoid having to fix code that relies on base-size being an integer
everywhere else ? Or were all such occurrences found already ?

--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1595,11 +1595,12 @@ This adds the face `completions-common-part' to the first
 `completions-first-difference' to the first character after that.
 
 It returns a list with font-lock properties applied to each element,
-and with BASE-SIZE appended as the last element."
+and with BASE-SIZE (or zero) appended as the last element."
+  (or base-size (setq base-size 0))
   (when completions
     (if (zerop prefix-len)
         completions
-      (let ((com-str-len (- prefix-len (or base-size 0))))
+      (let ((com-str-len (- prefix-len base-size)))
         (nconc
          (mapcar
           (lambda (elem)


-- 
Nico.

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Bastien]

Hi Nicolas,

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Shouldn't base-size default to 0 in completion-hilit-commonality then,
> to avoid having to fix code that relies on base-size being an integer
> everywhere else ? Or were all such occurrences found already ?

I checked occurrences of `base-size' in minibuffer.el and we're
covered.  Other occurrences in simple.el are explicitely bound to
`completion-base-size', so I don't think there is a problem here.

-- 
 Bastien

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Glenn Morris]

Bastien wrote:

> The error originated here:
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=66c5fecc
>
> The commit makes `base-size' optional, so we need to ensure it
> falls back to 0 instead of nil.

Making an argument optional couldn't cause this. It was the other part
of that commit, just now reverted.

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> Making an argument optional couldn't cause this. It was the other part
> of that commit, just now reverted.

Thanks,

-- 
 Bastien

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Leo Liu]

On 2014-03-05 01:03 +0800, Glenn Morris wrote:
> Making an argument optional couldn't cause this. It was the other part
> of that commit, just now reverted.

Seems Bastien's fix can be reverted as well. If data is corrupted, the
error can help identify the real cause.

Thanks,
Leo

bug#16935: 24.3.50; when tab-completing in 'M-x' : "Wrong type argument: numberp, nil"

[Bastien]

Leo Liu <sdl.web@gmail.com> writes:

> On 2014-03-05 01:03 +0800, Glenn Morris wrote:
>> Making an argument optional couldn't cause this. It was the other part
>> of that commit, just now reverted.
>
> Seems Bastien's fix can be reverted as well. If data is corrupted, the
> error can help identify the real cause.

Agreed and done.  (I made the revert manually as I wasn't sure on how
to use bzr merge to revert a single commit.)

-- 
 Bastien