bug#5704: Emacs 23.1 problem

bug#5704: Emacs 23.1 problem

[W.Rheinboldt]

I just upgraded from Emacs 21.3 to Emacs 23.1 running under Windows XP. 
When I try to open a
new file under the new Emacs version, I get the Windows error message 
stating that the file could
not be found and that I should check for the correct name. On Emacs 21.3 
there was no such problem
and such a file request indeed opened a new file with the stated name.

I presume there is some setting-problem. Can you point me in the right 
direction?

Thank you

W. Rjeinboldt
wkrhein@gmx.de

bug#5704: Emacs 23.1 problem

[Chong Yidong]

> I just upgraded from Emacs 21.3 to Emacs 23.1 running under Windows
> XP.  When I try to open a new file under the new Emacs version, I get
> the Windows error message stating that the file could not be found and
> that I should check for the correct name. On Emacs 21.3 there was no
> such problem and such a file request indeed opened a new file with the
> stated name.

First of all, what happens if you run using the `emacs -Q' option to
disable local customizations?

bug#5704: Emacs 23.1 problem

[Glenn Morris]

reassign 3969 emacs,w32
forcemerge 3969 5704
stop

Chong Yidong wrote:

> First of all, what happens if you run using the `emacs -Q' option to
> disable local customizations?

Jason sent the following message, but to the control address so it did
not appear on bug-gnu-emacs. This is a duplicate of 3969. He has been
having trouble merging it due to 3969 being archived and in different
packages.

    From: Jason Rumney <jasonr at gnu.org>
    Subject: Re: bug#5704: Emacs 23.1 problem
    To: "W.Rheinboldt" <wkrhein at gmx.de>
    Date: Fri, 12 Mar 2010 07:13:19 +0800

    forcemerge 3969 5704
    [...]

    It is a bug in Emacs, that has been fixed in the development sources.
    For 23.1, you need to create new files without using the file dialog (C-x
    C-f rather than the menu or toolbar).  Pretests for 23.2 are available.

bug#5704: Emacs 23.1 problem

[Jason Rumney]

Glenn Morris <rgm@gnu.org> writes:

> reassign 3969 emacs,w32

People keep doing this, which causes the bug to be in the wrong package
for merging with the bug this is a duplicate of, which is NOT Windows
specific.  There are a few other bugs which appear to have been tagged
like this merely because they mention Windows in the bug report.

The behaviour of GTK file dialog is different, it doesn't give you
a way of entering a name of a file that does not exist, but the bug is
the same - in 23.1 we were setting the mustmatch flag even when the
"Visit New File..." menu item or equivalent toolbar item was used.

bug#5704: Emacs 23.1 problem

[Glenn Morris]

Jason Rumney wrote:

>> reassign 3969 emacs,w32
>
> People keep doing this, which causes the bug to be in the wrong package
> for merging with the bug this is a duplicate of, which is NOT Windows
> specific.

It's probably almost always me, sorry. I'll try to do it less.

bug#5704: Emacs 23.1 problem

[Jan Djärv]

Jason Rumney skrev 2010-03-14 02.28:

> The behaviour of GTK file dialog is different, it doesn't give you
> a way of entering a name of a file that does not exist, but the bug is
> the same - in 23.1 we were setting the mustmatch flag even when the
> "Visit New File..." menu item or equivalent toolbar item was used.

Just type Ctrl-L in the file dialog and you can enter a name.

	Jan D.

bug#5704: Emacs 23.1 problem

[Jason Rumney]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Jason Rumney skrev 2010-03-14 02.28:
>
>> The behaviour of GTK file dialog is different, it doesn't give you
>> a way of entering a name of a file that does not exist, but the bug is
>> the same - in 23.1 we were setting the mustmatch flag even when the
>> "Visit New File..." menu item or equivalent toolbar item was used.
>
> Just type Ctrl-L in the file dialog and you can enter a name.

Right, but after the bug was fixed that is no longer necessary, which
is what users would expect from a New File dialog.

bug#5704: Emacs 23.1 problem

[Drew Adams]

> > I just upgraded from Emacs 21.3 to Emacs 23.1 running under Windows
> > XP.  When I try to open a new file under the new Emacs 
> > version, I get the Windows error message stating that the file
> > could not be found and that I should check for the correct name.
> > On Emacs 21.3 there was no such problem and such a file request
> > indeed opened a new file with the stated name.
> 
> First of all, what happens if you run using the `emacs -Q' option to
> disable local customizations?

I suspect this is just bug #3969, again.

bug#5704: Emacs 23.1 problem

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > I just upgraded from Emacs 21.3 to Emacs 23.1 running under Windows
>> > XP.  When I try to open a new file under the new Emacs 
>> > version, I get the Windows error message stating that the file
>> > could not be found and that I should check for the correct name.
>> > On Emacs 21.3 there was no such problem and such a file request
>> > indeed opened a new file with the stated name.
>> 
>> First of all, what happens if you run using the `emacs -Q' option to
>> disable local customizations?
>
> I suspect this is just bug #3969, again.

I see; in that case it's already fixed.  Thanks.

bug#5704: Emacs 23.1 problem

[W.Rheinboldt]

Evidently, I got into a loop of internal memos about this bug. I am now 
using
the C-x,C-f approach to get a new file and that works. But I trust there 
will
be in time a new corrected version of the system.

Thanks!

W. Rheinboldt

Chong Yidong schrieb:
> "Drew Adams" <drew.adams@oracle.com> writes:
>
>   
>>>> I just upgraded from Emacs 21.3 to Emacs 23.1 running under Windows
>>>> XP.  When I try to open a new file under the new Emacs 
>>>> version, I get the Windows error message stating that the file
>>>> could not be found and that I should check for the correct name.
>>>> On Emacs 21.3 there was no such problem and such a file request
>>>> indeed opened a new file with the stated name.
>>>>         
>>> First of all, what happens if you run using the `emacs -Q' option to
>>> disable local customizations?
>>>       
>> I suspect this is just bug #3969, again.
>>     
>
> I see; in that case it's already fixed.  Thanks.
>