headers
Drew Adams | 1 Sep 2008 01:16
Picon
Favicon

bug#842: 23.0.60; find-file prompt is case sensitive on w32

> >> Try for example
> >>   C-x C-f cha TAB
> >> in emacs/src.
> >> This should be case insensitive on w32 since the file 
> >> system is case insensitive.
> >>
> >> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
> >>  of 2008-08-29
> >> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> >> configured using `configure --with-gcc (3.4) --no-opt --cflags
> >> -Ic:/g/include -fno-crossjumping'
> > 
> > I don't see that. emacs -Q with:
> > 
> > In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
> >  of 2008-08-29 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'
> > 
> > I dont' have a src directory, but I tried it in a directory 
> > with uppercase, lowercase, and mixed case files, and C-x C-f
> > is case insensitive.
> 
> Strange, this should be the same binaries that I am using ...

Dunno - your lines above don't include "on LENNART-69DE564"; mine do.

> Is it perhaps the first character that matters? I am trying
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lennart Borgman (gmail | 1 Sep 2008 01:29
Picon
Gravatar

bug#842: 23.0.60; find-file prompt is case sensitive on w32

Drew Adams wrote:
>>>> Try for example
>>>>   C-x C-f cha TAB
>>>> in emacs/src.
>>>> This should be case insensitive on w32 since the file 
>>>> system is case insensitive.
>>>>
>>>> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>>>>  of 2008-08-29
>>>> Windowing system distributor `Microsoft Corp.', version 5.1.2600
>>>> configured using `configure --with-gcc (3.4) --no-opt --cflags
>>>> -Ic:/g/include -fno-crossjumping'
>>> I don't see that. emacs -Q with:
>>>
>>> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>>>  of 2008-08-29 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'
>>>
>>> I dont' have a src directory, but I tried it in a directory 
>>> with uppercase, lowercase, and mixed case files, and C-x C-f
>>> is case insensitive.
>> Strange, this should be the same binaries that I am using ...
> 
> Dunno - your lines above don't include "on LENNART-69DE564"; mine do.

It is the same.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lennart Borgman (gmail | 1 Sep 2008 01:26
Picon
Gravatar

bug#842: 23.0.60; find-file prompt is case sensitive on w32

Drew Adams wrote:
>>> Trying in emacs/lisp C-x C-f CVS TAB
>>> I get [complete but not unique] and CVS/ is shown as only 
>>> alternative.
> 
> What is your value of `completion-ignored-extensions'? Mine includes ".elc". You
> no doubt have a file cvs-status.elc, in addition to .el.

The default value. This is with "emacs -Q".

>> For me it is completed to c:/.../lisp/cvs-status.el, with no 
>> minibuffer message.
> 
>
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Sep 2008 01:20
Picon
Favicon

bug#842: 23.0.60; find-file prompt is case sensitive on w32

> > Trying in emacs/lisp C-x C-f CVS TAB
> > I get [complete but not unique] and CVS/ is shown as only 
> > alternative.

What is your value of `completion-ignored-extensions'? Mine includes ".elc". You
no doubt have a file cvs-status.elc, in addition to .el.

> For me it is completed to c:/.../lisp/cvs-status.el, with no 
> minibuffer message.
Permalink | Reply | 1 comment |
headers
Drew Adams | 1 Sep 2008 01:46
Picon
Favicon

bug#842: 23.0.60; find-file prompt is case sensitive on w32

> Maybe if you create a file named CVS and try again?

Yes, I confirm that I see the same thing as you.

With files CVS and cvs-status.lisp present, C-x C-f CVS TAB and C-x C-f cvs TAB
both do as you said: They show the minibuffer message "Complete but not unique",
and a second TAB shows only the file name CVS, not both file names as possible
completions. Looks like a bug.
Permalink | Reply | 0 comments |
headers
Emacs bug Tracking System | 1 Sep 2008 02:35
Gravatar

Processed: your mail

Processing commands for control <at> emacsbugs.donarmstrong.com:

> merge 837 841 843 844
bug#837: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
bug#841: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
bug#843: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
bug#844: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
Merged 837 841 843 844.

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)
Permalink | Reply | 0 comments |
headers
Michael Kifer | 1 Sep 2008 02:57
Picon
Favicon

bug#844: (no subject)

This bug is not reproducible.
Permalink | Reply | 0 comments |
headers
Emacs bug Tracking System | 1 Sep 2008 03:20
Gravatar

Processed: your mail

Processing commands for control <at> emacsbugs.donarmstrong.com:

> tags 844 unreproducible
bug#844: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
There were no tags set.
bug#837: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
bug#841: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
bug#843: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
Tags added: unreproducible

>
End of message, stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)
Permalink | Reply | 0 comments |
headers
Kenichi Handa | 1 Sep 2008 04:53

bug#613: 23.0.60; Unicode display problems

In article <18614.49466.916241.572583 <at> priss.frightenedpiglet.com>, sand <at> blarg.net writes:

> Neep Alt was originally designed for ISO8859-1 encodings,
> and my installation still has iso18859-1 fonts that
> definitely lack LEFT SINGLE QUOTE.  However, I constructed
> additional fonts to support ISO10646-1, by extracting the
> Misc Fixed glyphs outside of ISO8859-1, and appending them
> to the Neep Alt font definitions.  Those fonts are defined
> to have the iso10646-1 encoding.

Ah, I see.

> Adding LEFT SINGLE QUOTE and a couple of others as
> "symbol" representatives let Emacs filter out the
> ISO8859-1 fonts earlier in the code path, leaving the
> ISO10646-1 fonts for Emacs to use.  The Misc Fixed fonts
> had the same problem, as they also included ISO8859-1 and
> ISO10646-1 encodings, and this solution worked for them as
> well.

I re-added `symbol' entry to script-representative-chars but
with vector of characters as this:

	(symbol . [#x201C #x2200 #x2500])

and modified ftfont.c to handle that kind of format to
fileter out fonts that have none of characters in the
vector.

Please you try again with the latest code.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard M. Stallman | 1 Sep 2008 08:11
Picon
Picon

bug#846: Bug in handling invisible text, and bug in Pmail.

In Pmail I had a message that looked like this
(I changed his host name for privacy's sake):

----------------------------------------------------------------------
To: rms <at> gnu.org
Subject: sorry that I was distracted with phone calls 
From: Brand <at> xyzxysxysbb.com
Reply-to: brand <at> xyzxysxysbb.com
Date: Thu, 21 Aug 2008 18:46:37 -0700
X-BABYL-V6-ATTRIBUTES: A------

Two other ideas to run past you when time permits.

/w

----------------------------------------------------------------------

and I wanted to copy that into an outgoing message.
So I typed C-x h M-w, went to *mail* and inserted it.
What this inserted appears below.  It was quite a surprise.

It seems there is a lot of invisible text at the beginning of
the buffer, and two different values of point display at the same
place on the screen.  These places are 934995 and 9351405.
(point-min) returns 934995, and that's where M-< moves point to.
Typing C-f C-b moves point to 9351405.  I gather that those two
positions surround the invisible text.	

I think this is a bug in the command loop's handling of invisible
text -- it should not be the case that C-f C-b changes point.
(Continue reading)

Permalink | Reply | 15 comments |

Gmane