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

Previous Next

Package: emacs;

Reported by: Harald Maier <harald <at> maierh.de>

Date: Wed, 18 Feb 2009 18:30:04 UTC

Severity: normal

Tags: fixed

Fixed in version 25.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        Harald Maier <harald <at> maierh.de>, 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90;	^ in gnus summary buffer does not work in the nextstep build
Date: Thu, 26 Feb 2009 09:04:23 +0900
>>>>> On Wed, 25 Feb 2009 11:25:17 -0500, Stefan Monnier <monnier <at> IRO.UMontreal.CA> 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.

> Not knowing exactly how it's called, and not having the time to try
> and understand all thedetails, I'm not sure I understand what are
> the differences.  Could you try and explain what are the
> differences?  I see various "unimportant" details (such as the use
> of a display property or an overlay in order to avoid directly
> modifying the actual text), which might be good to integrate indeed,
> but what about the overall behavior, is it different?  E.g. what
> happens (with your code) when the user hits a dead-^ in a Gnus
> buffer?

> I get the impression that it ends up behaving like the current
> ns-win.el code (i.e. nothing is run after ^, but the Gnus command is
> called after ^+SPC), except that it displays a "^" in the Gnus
> buffer rather than signalling an error.  Is that right?

That's right.  But I don't think the difference is so unimportant with
respect to the current issue.

Also, the difference in the code length shows how the Cocoa/GNUstep
port oversimplifies the whole text input processing: it doesn't
respect attributes in the marked text (which corresponds to text
properties) or the selected range value.

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




This bug report was last modified 9 years and 109 days ago.

Previous Next


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