GNU bug report logs - #2375
23.0.90; ^ in gnus summary buffer does not work in the nextstep build

Previous Next

Full log

Message #87 received at 2375 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Harald Maier <harald <at> maierh.de>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Tue, 24 Feb 2009 14:09:02 +0900

>>>>> On Tue, 24 Feb 2009 06:00:22 +0100, Harald Maier <harald <at> maierh.de> said:

>>>> What do you think about the dead-key behavior in the Carbon port
>>>> (Emacs 22)?  If it is reasonable enough, maybe the Cocoa/GNUstep
>>>> port can adopt its strategy.
>> 
>>> That works but I don't like it. My preference is as in the X11
>>> build.
>> 
>> Could you explain more in detail how they are different and why you
>> don't like it?  Note that some distributions (such as Carbon Emacs
>> Package or Aquamacs Emacs) based on the Carbon port applies some
>> patch with respect to text input, and their behavior is not
>> strictly the same as the Carbon port I'm talking about.

> It really inserts a caret character into the gnus summary buffer as
> you can see in the attached image. That looks very strange.

That's the point in the implementation: i.e., it gives a visual
feedback that indicates dead-key is being processed even in the
read-only buffer using an overlay string.  Such kind of feedback can
also be seen in other Mac applications (modulo colors/underline, which
is customizable in the Carbon port) and even in X11 apps with XIM.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.