bug#7206: 24.0.50; Bugs with minibuffer completion

bug#7206: 24.0.50; Bugs with minibuffer completion

[Tim Van Holder]

Current bzr (r101947) has 2 issues with completion in the minibuffer:

Recipe:

$ emacs -Q
  C-x C-f

Issue #1:

  Enter anything that has a non-unique completion (or don't enter
  anything at all after ther default directory name prompt), and press
  [tab]. Instead of getting the "[Complete, but not unique]" prompt, you
  get an error instead:
    minibuffer-completion-help: Wrong type argument: listp, 0
  (the integer varies).
  This also happens with non-path completions (e.g. C-h f).

Issue #2:

  Put point inside the path prompt and delete the trailing part of a
  path component, taking care to still keep a unique prefix to avoid
  hitting issue #1. Pressing [tab] to re-complete the path component
  works fine, but point "jumps back" several positions. This does not
  happen for completions at the end of the path, nor does it seem to
  heppen for non-path completions (at least for [C-h f] the problem does
  not seem to exist).


In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2010-10-13 on leeloo
Windowing system distributor `The Cygwin/X Project', version 11.0.10503000
configured using `configure  '--with-x''

bug#7206: 24.0.50; Bugs with minibuffer completion

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Wed, 13 Oct 2010 11:12:59 +0200 Tim Van Holder <tim.vanholder@gmail.com> wrote:

> Current bzr (r101947) has 2 issues with completion in the minibuffer:
>
> Recipe:
>
> $ emacs -Q
>   C-x C-f
>
> Issue #1:
>
>   Enter anything that has a non-unique completion (or don't enter
>   anything at all after ther default directory name prompt), and press
>   [tab]. Instead of getting the "[Complete, but not unique]" prompt, you
>   get an error instead:
>     minibuffer-completion-help: Wrong type argument: listp, 0
>   (the integer varies).
>   This also happens with non-path completions (e.g. C-h f).

This is due to this change:

2010-10-13  IRIE Shinsuke  <irieshinsuke@yahoo.co.jp>  (tiny change)

	* subr.el (last): Make it faster.  (Bug#7174)

Here is a fix:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fix for last --]
[-- Type: text/x-patch, Size: 919 bytes --]

*** /data/steve/bzr/emacs/trunk/lisp/subr.el	2010-10-13 14:41:39.000000000 +0200
--- /data/steve/bzr/emacs/quickfixes/lisp/subr.el	2010-10-13 20:34:46.000000000 +0200
***************
*** 290,299 ****
  If N is bigger than the length of LIST, return LIST."
    (if n
        (and (> n 0)
!            (let ((m (length list)))
               (if (< n m) (nthcdr (- m n) list) list)))
      (and list
!          (nthcdr (1- (length list)) list))))
  
  (defun butlast (list &optional n)
    "Return a copy of LIST with the last N elements removed."
--- 290,299 ----
  If N is bigger than the length of LIST, return LIST."
    (if n
        (and (> n 0)
!            (let ((m (safe-length list)))
               (if (< n m) (nthcdr (- m n) list) list)))
      (and list
!          (nthcdr (1- (safe-length list)) list))))
  
  (defun butlast (list &optional n)
    "Return a copy of LIST with the last N elements removed."

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


Steve Berman

bug#7206: 24.0.50; Bugs with minibuffer completion

[Juanma Barranquero]

On Wed, Oct 13, 2010 at 20:40, Stephen Berman <stephen.berman@gmx.net> wrote:

> Here is a fix:

Applied, thanks.

    Juanma

bug#7206: 24.0.50; Bugs with minibuffer completion

[Tim Van Holder]

On 14 October 2010 01:14, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Oct 13, 2010 at 20:40, Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> Here is a fix:
>
> Applied, thanks.

That indeed fixes issue #1, but issue #2 remains in bzr 101960. Should
I file a separate report for that one (so this one can stay closed),
or will you reopen this one?

bug#7206: 24.0.50; Bugs with minibuffer completion

[Juanma Barranquero]

On Thu, Oct 14, 2010 at 10:20, Tim Van Holder <tim.vanholder@gmail.com> wrote:

> That indeed fixes issue #1, but issue #2 remains in bzr 101960. Should
> I file a separate report for that one (so this one can stay closed),
> or will you reopen this one?

Please file another bug report.

Thanks,

    Juanma