all-completions broken in 20.7.1?

all-completions broken in 20.7.1?

[Thierry Legras]

This bug report will be sent to the Free Software Foundation,
  not to your local site managers!!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

In GNU Emacs 20.7.1 (sparc-sun-solaris2.8, X toolkit)
  of Tue Aug 29 2000 on steel
configured using `configure  --prefix=/opt/sfw'

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hi,

all-completions function returns scarry things: i started a naked emacs 
with -q option, then just evaled (all-completions "" [foo] nil), result is:
("foo" "scroll-bar-drag-position" "nodelete" "r" "latin-iso8859-3" 
"mark-marker" "buffer-read-only")

???

Cheers,
Thierry.

Recent input:
M-: down-mouse-2 mouse-2 down-mouse-1 mouse-1 backspace
backspace backspace backspace backspace backspace backspace
backspace backspace backspace f o o C-e return menu-bar
help-menu report-emacs-bug

Recent messages:
For information about the GNU Project and its goals, type C-h C-p.
("foo" "scroll-bar-drag-position" "nodelete" "r" "latin-iso8859-3" 
"mark-marker" "buffer-read-only")
Loading emacsbug...
Loading emacsbug...done
Loading dabbrev...
Loading dabbrev...done
Scanning `*scratch*'
Scanning ` *Minibuf-0*'
Scanning ` *Minibuf-1*'
No dynamic expansion for `all-com' found

all-completions broken in 20.7.1?

[Luc Teirlinck]

Thierry Legras wrote:

    Hi,

    all-completions function returns scarry things: i started a naked
    emacs
    with -q option, then just evaled (all-completions "" [foo] nil),
    result is:
    ("foo" "scroll-bar-drag-position" "nodelete" "r" "latin-iso8859-3"
    "mark-marker" "buffer-read-only")

    ???

>From the documentation string of `all-completions', I do not get the
impression that you are supposed to pass an array as the second
argument.  If you use, say, an obarray instead, you get the expected
result:

ELISP> (emacs-version)
"GNU Emacs 21.3.50.26 (i686-pc-linux-gnu, X toolkit)\n of 2003-02-07
on swt40.swt.com"
ELISP> (all-completions "" [foo] nil)  ;; incorrect argument: array.
("foo" "dired-free-space-args" "PC-complete-word"
"scroll-bar-drag-position" "nodelete" "r" "latin-iso8859-3"
"mark-marker" "buffer-read-only")  ;; nonsensical answer 

;; (granted, error message would be better)

ELISP> (setq ob (make-vector 1 0))
[0]

ELISP> (intern "foo" ob)
foo
ELISP> ob
[foo]

ELISP> (all-completions "" ob nil)  ;; correct argument: obarray
("foo")  ;; correct answer.

Sincerely,

Luc.

Re: all-completions broken in 20.7.1?

[Richard Stallman]

    all-completions function returns scarry things: i started a naked emacs 
    with -q option, then just evaled (all-completions "" [foo] nil), result is:

The second argument should be an alist or an obarray or a function.
[foo] is not valid as any of those.


    Today, if I eval (using C-j) the following in *scratch*, I get:

	    ?S       => 83
	    ?SPC     => 83

I think this simply fails to notice that there were junk letters `PC'
after the expression that it read.

	    '(?SPC)  => (83 PC)

    but if I do
	    M-: ? S P C RET
    I get
	    list: Trailing garbage following expression

    so the current character syntax really is pretty obscure.

That does check for junk that it did not read.
The difference in behavior is simply that.

Since it is not reasonable practice to use a character constant
followed by a symbol and not put a space between, I think it would be
ok to define something like ?SPC.  But I am not sure we need to do
this.  If we do it, we should first release an Emacs version where
it is an error to write ?<LETTER><LETTER>.

Re: all-completions broken in 20.7.1?

[Kevin Rodgers]

Richard Stallman wrote:

>     all-completions function returns scarry things: i started a naked emacs 
>     with -q option, then just evaled (all-completions "" [foo] nil), result is:
> 
> The second argument should be an alist or an obarray or a function.
> [foo] is not valid as any of those.

Then an error should be signaled.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: all-completions broken in 20.7.1?

[Andreas Schwab]

Kevin Rodgers <kevin.rodgers@ihs.com> writes:

|> Richard Stallman wrote:
|> 
|> >     all-completions function returns scarry things: i started a naked
|> > emacs     with -q option, then just evaled (all-completions "" [foo]
|> > nil), result is:
|> > The second argument should be an alist or an obarray or a function.
|> > [foo] is not valid as any of those.
|> 
|> Then an error should be signaled.

It is expensive, if not impossible to distinguish an obarray from an
ordinary vector.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."