bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#994: Processed: severity 994 wishlist


From: Drew Adams
Subject: bug#994: Processed: severity 994 wishlist
Date: Mon, 29 Sep 2008 20:09:00 -0700

> > Why is this fodder for the wishlist? This bug is a regression!
> >
> > Stefan asked for a recipe to reproduce it, so no doubt this 
> > behavior is not intentional (not a design change). It is bad,
> > bugged behavior, and it is new. 
> >
> > Why on earth would such a bug report be classified as "wish 
> > list"? Perhaps you are simply wishing bugs away? ;-)
> 
> Please don't make a separate CC to bug-gnu-emacs; that 
> creates a new bug entry.  Just reply to NNN@emacsbugs.donarmstrong.com.

I used Reply All. mea culpa.

FYI, 994@emacsbugs.donarmstrong.com was not even in the list of recipients - I
had to add it manually. So neither Reply nor Reply All does the job.

> The bug in question is not a regression, unless you have a 
> rather broad definition of "regression".

Of course it is a regression. What is your definition? 

* No such crazy completion occurred in Emacs 22 or 21 or 20 or 19 or 18.

* And it is apparently not intentional behavior.

* And it is bad behavior - no rationale has been given for it, and the developer
was apparently surprised by it, asking for a recipe to reproduce it.

Why would you call behavior that is new, unintentional, and bad anything BUT a
regression? What would you call it?

> It is neither obviously buggy nor new, 

Of course it is new. Repeat the same recipe in Emacs 22, 21, or 20 - you will
not see anything like what I reported.

How can you say that `read-file-name' completing (with an existing file
`icicles-mcmd.el') the input `icicles-mcfoobar' to `icicles-mcicles-foobar' is
correct? There is no such file. Emacs should signal that there are no
completions.

How can you say that completing the same input to `icicles-mcfoobaricles' is
also correct? Again, there is no such file. Emacs should signal that there are
no completions.

Even if you adopt the point of view that only what is before point should be
completed, ignoring what comes after point, the result must be a valid
completion (existing file name). With that point of view, it might be correct to
*replace* the text to the right of point and leave the completed file name
`icicles-mcmd.el'. But there is no way that it makes sense to complete to
`icicles-mcicles-foobar' or `icicles-mcfoobaricles'. 

Please think about it. This is totally silly.

------------8<----------------------

Newsflash -

I just tried again, using this build:

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-09-18 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'

And the bug is fixed in that build. I retested using the version I reported it
in, just to be sure, and the bug does exist there, as reported:

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-09-03 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'

However, FWIW, the behavior now is not the same as in Emacs 22:

In GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600)
 of 2008-03-26 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

In Emacs 22.2 (I don't have 22.3, but I'm guessing it's the same):
icicles-mcfoobar completes to icicles-mcmd.elfoobar, when point is on the m.
When point is at the end (after the r), you get a [No match] message.

In Emacs 23, you get a [No match] message in both cases. I'm OK with that, but
see Andreas Schwab's reply - he might not be OK with it.

In addition to these examples being fixed, the other example I gave, of first
doing C-x C-f icicles-mc RET and then C-x C-v TAB seems also to be fixed - it
now completes to icicles-mcmd.el. (This part of the original report was stated
in terms of foo-bar.el, not icicles-mcmd.el.)

So if nothing changes (;-)), I'm OK with closing this bug - it seems to be
fixed. Thanks to whoever fixed it (probably Stefan).

However, this does represent a change in design (intentional user-visible
behavior change) wrt Emacs 22. I'm OK with this change, but it was not something
that was discussed in emacs-devel@gnu.org. There have been a lot of changes to
the completion behavior that were never discussed. That's not the right way to
run things, IMHO.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]