Jason Rumney | 1 Feb 01:17 2008
Picon

Re: Windows: Documentation for bin\*.exe

Reiner Steib wrote:
>> Suggestions:
>>
>> (a) A README file explaining the purpose of the various *.exe files
>>     (especially *emacs*.exe) in the bin directory.
>>
>> (b) The description appearing in the "Open with..." dialog should tell
>>     about the purpose of the binary (or at least display name of the
>>     executable).
>>     

Hi Reiner,

Sorry for missing this the first time around. I have added a short 
description of each exe file to README.W32 with pointers to the 
appropriate section of the manual where appropriate. I'll look at your 
second suggestion later.

Jason Rumney | 1 Feb 01:28 2008
Picon

Re: chinese character displayed as hollow box in Emacs 22.1.90

Zhang Wei wrote:
> Yes, it happens with "emacs -Q".
>   

I've partially reverted the change below. It results in incomplete 
Chinese, Korean and Thai font specs being returned from w32-select-font 
and x-list-fonts, but that doesn't seem to cause any real problem, I 
just noticed the bogus names when fixing another font problem that was 
part of the same change. There appears to be a bug in the font matching 
code in w32fns.c, but since that will change substantially in Emacs 23 
and things work when the specs are missing the last field, I'll leave it 
as is.

>   
>> 2007-11-10 Jason Rumney <jasonr <at> gnu.org>
>>
>> * w32-fns.el: Sync charset names with setup-default-fontset.
>> Append "-1" where second part missin

Kenichi Handa | 1 Feb 02:21 2008
Picon

Re: CCL_WRITE_CHAR and CCL_WRITE_MULTIBYTE_CHAR

In article <20080131.213724.217838043.mituharu <at> math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> writes:

> [1  <text/plain; us-ascii (7bit)>]
>>>>>> On Thu, 31 Jan 2008 20:35:34 +0900, Kenichi Handa <handa <at> ni.aist.go.jp> said:

> > At least, in CCL_WRITE_CHAR, that change is not safe because
> > extra_bytes will be incremented after that check.

> But in the original code, extra_bytes is initialized to 1, not 0, in
> the case that increment occurs.

Ah, I recalled why I used that tricky logic.  Ok, I've just
installed your change in EMACS_22_BASE, and cancel the last
change in the trunk.  So, the change in EMACS_22_BASE will
propagate to the trunk eventually.

---
Kenichi Handa
handa <at> ni.aist.go.jp

Zhang Wei | 1 Feb 03:53 2008
Picon

Re: chinese character displayed as hollow box in Emacs 22.1.90

On 2/1/08, Jason Rumney <jasonr <at> gnu.org> wrote:
> I've partially reverted the change below. It results in incomplete
> Chinese, Korean and Thai font specs being returned from w32-select-font
> and x-list-fonts, but that doesn't seem to cause any real problem, I
> just noticed the bogus names when fixing another font problem that was
> part of the same change. There appears to be a bug in the font matching
> code in w32fns.c, but since that will change substantially in Emacs 23
> and things work when the specs are missing the last field, I'll leave it
> as is.
>
> >
> >> 2007-11-10 Jason Rumney <jasonr <at> gnu.org>
> >>
> >> * w32-fns.el: Sync charset names with setup-default-fontset.
> >> Append "-1" where second part missin

The bug has been fixed, thanks.

William Xu | 1 Feb 04:16 2008
Picon

Re: VC Dired Mode doesn't support recursive directory?

Dan Nicolaescu <dann <at> ics.uci.edu> writes:

> This seems to directly modify the dired buffer, so probably something
> goes wrong there.
>
> If you can reproduce the problem starting from emacs -Q without the code
> above, the please report back.

No, it doesn't happen with -Q or simply by removing that hook.

> Also vc-dired is very likely to get replaced soon...

Okay, then I will fall back on the command line at the moment..

--

-- 
William

http://williamxu.net9.org

T. V. Raman | 1 Feb 04:32 2008
Picon

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

and I can vouch for this, it  works well.
I use it all  the time

>>>>> "Eli" == Eli Zaretskii <eliz <at> gnu.org> writes:
    >> Date: Sun, 27 Jan 2008 19:55:38 +0000 From: Alan Mackenzie
    >> <acm <at> muc.de> Cc: nickrob <at> snap.net.nz, miles <at> gnu.org,
    >> emacs-devel <at> gnu.org
    >> 
    >> Actually, you may be right.  The mechanism for switching
    >> frames (C-x 5 o, repeated ad nauseam till you finally
    >> reach the frame you're looking for) is so broken as to be
    >> unusable, at least for me.
    Eli> 
    Eli> A solution has been in existence for that problem for a
    Eli> very long time: give your frame a name with "M-x
    Eli> set-frame-name RET FOO RET", then select it with "M-x
    Eli> select-frame-by-name RET FOO RET".  Puff!  problem gone.
    Eli> 
    Eli> 
    Eli> _______________________________________________
    Eli> Emacs-devel mailing list Emacs-devel <at> gnu.org
    Eli> http://lists.gnu.org/mailman/listinfo/emacs-devel

--

-- 
Best Regards,
--raman

      
Email:  raman <at> users.sf.net
WWW:    http://emacspeak.sf.net/raman/
(Continue reading)

T. V. Raman | 1 Feb 04:50 2008
Picon

Re: Tabbed buffers


Doing this on Linux would also have the nice side-effect of
allowing tty users to place  each frameset on a different virtual
console, something which would make it  easier to logically
separate out frames.

>>>>> "Stefan" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
    >>> But getting rid of them would just mean trouble.
    >> I would certainly object.
    Stefan> 
    Stefan> Richard was talking about a suggestion of mine, which
    Stefan> was not to remove the frame functionality on ttys.
    Stefan> How can people even expect me to suggest throwing
    Stefan> away such a feature?
    Stefan> 
    Stefan> All I was pointing out was that if we introduce
    Stefan> frame-level tabs, then it might make sense to treat
    Stefan> the current "multiple-frames on a single tty" as tabs
    Stefan> rather than as frames.  So we may want to refine the
    Stefan> notion of tty frames so that each tty gets exactly 1
    Stefan> frame, and it can then multiplex several tabs on that
    Stefan> frame: the end result is the same featureset as
    Stefan> before, but in a way that more closely matches the
    Stefan> semantics of frames&tabs under GUIs (where only one
    Stefan> of the tabs of a frame can be displayed at a time,
    Stefan> just like frames on a single tty).
    Stefan> 
    Stefan> 
    Stefan>         Stefan
    Stefan> 
(Continue reading)

Zhang Wei | 1 Feb 05:30 2008
Picon

Re: Emacs 22.1.90 can't save chinese-gb2312 file

On 2/1/08, Zhang Wei <id.brep <at> gmail.com> wrote:
> When I save a file in gb2312 coding system, I got the following
> compliant, all of the chinese punctuation characters can't be encoded
> with gb2312:
> ------------------------------------------------------------------------------
> These default coding systems were tried to encode text
> in the buffer `test':
>  chinese-iso-8bit
> However, each of them encountered characters it couldn't encode:
>  chinese-iso-8bit cannot encode these: , 。 、 ?
>
> Click on a character (or switch to this window by `C-x o'
> and select the characters by RET) to jump to the place it appears,
> where `C-u C-x =' will give information about it.
>
> Select one of the safe coding systems listed below,
> or cancel the writing with C-g and edit the buffer
>   to remove or modify the problematic characters,
> or specify any other coding system (and risk losing
>   the problematic characters).
>
>  utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> --------------------------------------------------------------------------
> C-u C-x = gives:
> --------------------------------------------------------------------------
>  character: 。 (302786, #o1117302, #x49ec2, U+3002)
>    charset: mule-unicode-2500-33ff (Unicode characters of the range
> U+2500..U+33FF.)
>  code point: #x3D #x42
>     syntax: w  which means: word
(Continue reading)

Dan Nicolaescu | 1 Feb 05:50 2008
Picon

vc-cvs-checkout bug


C-x C-f any_file_on_EMACS_22_BASE

C-x v +

Look at the mode-line [EMACS_22_BASE] is gone, the file is now from
trunk!  That is quite a bad idea.

The problem is in vc-cvs-checkout, it seems to clear the branch.

22.1 also had this issue.

I can't look at this right now, but it's probably not too complicated.

Can somebody please fix this?

Kenichi Handa | 1 Feb 06:00 2008
Picon

Re: Emacs 22.1.90 can't save chinese-gb2312 file

In article <ebaf065f0801312030x70d3fb7aj96368c58cb8763c7 <at> mail.gmail.com>, "Zhang Wei"
<id.brep <at> gmail.com> writes:

> On 2/1/08, Zhang Wei <id.brep <at> gmail.com> wrote:
> > When I save a file in gb2312 coding system, I got the following
> > compliant, all of the chinese punctuation characters can't be encoded
> > with gb2312:
> > ------------------------------------------------------------------------------
> > These default coding systems were tried to encode text
> > in the buffer `test':
> >  chinese-iso-8bit
> > However, each of them encountered characters it couldn't encode:
> >  chinese-iso-8bit cannot encode these: , 。 、 ?
> >
> > Click on a character (or switch to this window by `C-x o'
> > and select the characters by RET) to jump to the place it appears,
> > where `C-u C-x =' will give information about it.
> >
> > Select one of the safe coding systems listed below,
> > or cancel the writing with C-g and edit the buffer
> >   to remove or modify the problematic characters,
> > or specify any other coding system (and risk losing
> >   the problematic characters).
> >
> >  utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > --------------------------------------------------------------------------
> > C-u C-x = gives:
> > --------------------------------------------------------------------------
> >  character: 。 (302786, #o1117302, #x49ec2, U+3002)
> >    charset: mule-unicode-2500-33ff (Unicode characters of the range
(Continue reading)


Gmane