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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2375 in the body.
You can then email your comments to 2375 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Harald Maier <harald <at> maierh.de>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Wed, 18 Feb 2009 19:27:24 +0100 (CET)

In the OS X nextstep build the GNUS function

  gnus-summary-refer-parent-article (^)

always raises the following error:

  Debugger entered--Lisp error: (wrong-type-argument overlayp nil)
    delete-overlay(nil)
    ns-delete-working-text()
    ns-unput-working-text()
    call-interactively(ns-unput-working-text nil [(ns-unput-working-text)])

This problem does not happen with the OS X X11 build. There the
funktion works always fine, so it seems only a nextstep build problem.

Harald


In GNU Emacs 23.0.90.3 (i386-apple-darwin9.6.0, NS apple-appkit-949.43)
 of 2009-02-18 on ate.maierh
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  show-paren-mode: t
  desktop-save-mode: t
  cua-mode: t
  recentf-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> M-x e v a <tab> <backspace> <backspace> <backspace> 
d <backspace> e <backspace> <backspace> d e <tab> d 
e f <tab> <return> M-x g n u s <return> <down> C-u 
2 0 <return> <up> M-x z <backspace> t o o <tab> <backspace> 
<backspace> g g <tab> d e b <tab> <return> e r <tab> 
<return> ^ <up> <S-down> <S-down> <S-down> <S-down> 
<S-down> <escape> w <down-mouse-1> <mouse-1> <down-mouse-1> 
<mouse-1> M-x e m a c <tab> b <tab> u <tab> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> r e p o <tab> r t - <tab> <return>

Recent messages:
Fetching headers for nntp+news.gmane.org:gmane.emacs.devel...done
Suppressing duplicates...done
Generating summary...done
ns-put-working-text: Buffer is read-only: #<buffer *Summary nntp+news.gmane.org:gmane.emacs.devel*>
ns-delete-working-text: Wrong type argument: overlayp, nil
Making completion list...
Debug on Error enabled globally
ns-put-working-text: Buffer is read-only: #<buffer *Summary nntp+news.gmane.org:gmane.emacs.devel*>
Entering debugger...
Making completion list...

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

From: David Engster <deng <at> randomsample.de>
To: 2375 <at> debbugs.gnu.org
Cc: Harald Maier <harald <at> maierh.de>
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Wed, 18 Feb 2009 22:15:12 +0100

Harald Maier <harald <at> maierh.de> writes:
> In the OS X nextstep build the GNUS function
>
>   gnus-summary-refer-parent-article (^)
>
> always raises the following error:
>
>   Debugger entered--Lisp error: (wrong-type-argument overlayp nil)
>     delete-overlay(nil)
>     ns-delete-working-text()
>     ns-unput-working-text()
>     call-interactively(ns-unput-working-text nil [(ns-unput-working-text)])
>
> This problem does not happen with the OS X X11 build. There the
> funktion works always fine, so it seems only a nextstep build problem.

I can confirm this. I don't know a solution, but a few remarks which
might help tracking down this bug:

First of all, this is not a Gnus issue, since doing M-x
gnus-summary-refer-parent-article works. Also, this problem effects any
binding for "^". For example, in the Gnus group buffer, where "^" runs
gnus-group-enter-server-mode, the same error occurs.

This only happens with keyboard layouts where "^" is a dead key on Mac
OS X, e.g. the German layout. When I switch to US layout, the "^" is not
a dead key and this error does not happen. Therefore, this issue seems
to be a problem with the NS port not correctly handling dead keys. My
guess would be that the problem lies in this piece of code in
src/keyboard.c:

if defined (HAVE_NS)
      else if (event->kind == NS_TEXT_EVENT)
        {
          if (event->code == KEY_NS_PUT_WORKING_TEXT)
            obj = Fcons (intern ("ns-put-working-text"), Qnil);
          else
            obj = Fcons (intern ("ns-unput-working-text"), Qnil);
          kbd_fetch_ptr = event + 1;
        }
#endif

-David

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 2375 <at> debbugs.gnu.org
Cc: Harald Maier <harald <at> maierh.de>
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Wed, 18 Feb 2009 18:51:01 -0500

> if defined (HAVE_NS)
>       else if (event->kind == NS_TEXT_EVENT)
>         {
>           if (event->code == KEY_NS_PUT_WORKING_TEXT)
>             obj = Fcons (intern ("ns-put-working-text"), Qnil);
>           else
>             obj = Fcons (intern ("ns-unput-working-text"), Qnil);
>           kbd_fetch_ptr = event + 1;
>         }
> #endif

I think the bug is in the definition of ns-unput-working-text (or in
the way ns-unput-working-text and ns-unput-working-text (both events
and functions) interact).

Not sure why ns-working-overlay was nil in your case, so either
ns-unput-working-text should be careful to handle the case where that
variable is nil, or some other code should make sure that it can't be
nil when we reach ns-unput-working-text.


        Stefan

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

From: David Engster <deng <at> randomsample.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2375 <at> debbugs.gnu.org, Harald Maier <harald <at> maierh.de>
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Thu, 19 Feb 2009 13:35:17 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I think the bug is in the definition of ns-unput-working-text (or in
> the way ns-unput-working-text and ns-unput-working-text (both events
> and functions) interact).
>
> Not sure why ns-working-overlay was nil in your case, so either
> ns-unput-working-text should be careful to handle the case where that
> variable is nil, or some other code should make sure that it can't be
> nil when we reach ns-unput-working-text.

It seems this is a bug in ns-insert-working-text, and it's already
mentioned there in a FIXME comment:

;; FIXME: if buffer is read-only, don't try to insert anything
;;  and if text is bound to a command, execute that instead (Bug#1453)

The Gnus group and summary buffers are read only, so what we're dealing
here seems to be a duplicate of Bug #1453.

-David

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 2375 <at> debbugs.gnu.org
Cc: Harald Maier <harald <at> maierh.de>
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Thu, 19 Feb 2009 13:29:55 -0500

>> I think the bug is in the definition of ns-unput-working-text (or in
>> the way ns-unput-working-text and ns-unput-working-text (both events
>> and functions) interact).
>> 
>> Not sure why ns-working-overlay was nil in your case, so either
>> ns-unput-working-text should be careful to handle the case where that
>> variable is nil, or some other code should make sure that it can't be
>> nil when we reach ns-unput-working-text.

> It seems this is a bug in ns-insert-working-text, and it's already
> mentioned there in a FIXME comment:

> ;; FIXME: if buffer is read-only, don't try to insert anything
> ;;  and if text is bound to a command, execute that instead (Bug#1453)

> The Gnus group and summary buffers are read only, so what we're dealing
> here seems to be a duplicate of Bug #1453.

What happens after the patch below?  It's not intended to fix #1453.


        Stefan


--- ns-win.el.~1.36.~	2009-02-07 11:23:03.000000000 -0500
+++ ns-win.el	2009-02-19 13:21:57.000000000 -0500
@@ -779,11 +779,11 @@
 
 
 
-;;;; Composed key sequence handling for Nextstep system input methods.
-;;;; (On Nextstep systems, input methods are provided for CJK
-;;;; characters, etc. which require multiple keystrokes, and during
-;;;; entry a partial ("working") result is typically shown in the
-;;;; editing window.)
+;; Composed key sequence handling for Nextstep system input methods.
+;; (On Nextstep systems, input methods are provided for CJK
+;; characters, etc. which require multiple keystrokes, and during
+;; entry a partial ("working") result is typically shown in the
+;; editing window.)
 
 (defface ns-working-text-face
   '((t :underline t))
@@ -791,11 +791,8 @@
   :group 'ns)
 
 (defvar ns-working-overlay nil
-  "Overlay used to highlight working text during compose sequence insert.")
-(make-variable-buffer-local 'ns-working-overlay)
-(defvar ns-working-overlay-len 0
-  "Length of working text during compose sequence insert.")
-(make-variable-buffer-local 'ns-working-overlay-len)
+  "Overlay used to highlight working text during compose sequence insert.
+When text is in th echo area, this just stores the length of the working text.")
 
 (defvar ns-working-text)		; nsterm.m
 
@@ -825,52 +822,52 @@
   (if (ns-in-echo-area) (ns-echo-working-text) (ns-insert-working-text)))
 (defun ns-unput-working-text ()
   (interactive)
-  (if (ns-in-echo-area) (ns-unecho-working-text) (ns-delete-working-text)))
+  (ns-delete-working-text))
 
 (defun ns-insert-working-text ()
-  "Insert contents of ns-working-text as UTF8 string and mark with
-ns-working-overlay.  Any previously existing working text is cleared first.
-The overlay is assigned the face ns-working-text-face."
-;; FIXME: if buffer is read-only, don't try to insert anything
-;;  and if text is bound to a command, execute that instead (Bug#1453)
+  "Insert contents of `ns-working-text' as UTF8 string and mark with
+`ns-working-overlay'.  Any previously existing working text is cleared first.
+The overlay is assigned the face `ns-working-text-face'."
+  ;; FIXME: if buffer is read-only, don't try to insert anything
+  ;;  and if text is bound to a command, execute that instead (Bug#1453)
   (interactive)
-  (if ns-working-overlay (ns-delete-working-text))
+  (ns-delete-working-text)
   (let ((start (point)))
     (insert ns-working-text)
     (overlay-put (setq ns-working-overlay (make-overlay start (point)
 							(current-buffer) nil t))
-		 'face 'ns-working-text-face)
-    (setq ns-working-overlay-len (+ ns-working-overlay-len (- (point) start)))))
+		 'face 'ns-working-text-face)))
 
 (defun ns-echo-working-text ()
   "Echo contents of ns-working-text in message display area.
-See ns-insert-working-text."
-  (if ns-working-overlay (ns-unecho-working-text))
+See `ns-insert-working-text'."
+  (ns-delete-working-text)
   (let* ((msg (current-message))
 	 (msglen (length msg))
 	 message-log-max)
-    (setq ns-working-overlay-len (length ns-working-text))
+    (setq ns-working-overlay (length ns-working-text))
     (setq msg (concat msg ns-working-text))
-    (put-text-property msglen (+ msglen ns-working-overlay-len)
+    (put-text-property msglen (+ msglen ns-working-overlay)
 		       'face 'ns-working-text-face msg)
-    (message "%s" msg)
-    (setq ns-working-overlay t)))
+    (message "%s" msg)))
 
 (defun ns-delete-working-text()
-  "Delete working text and clear ns-working-overlay."
+  "Delete working text and clear `ns-working-overlay'."
   (interactive)
-  (delete-backward-char ns-working-overlay-len)
-  (setq ns-working-overlay-len 0)
-  (delete-overlay ns-working-overlay))
-
-(defun ns-unecho-working-text()
-  "Delete working text from echo area and clear ns-working-overlay."
+  (cond
+   ((and (overlayp ns-working-overlay)
+         ;; Still alive?
+         (overlay-buffer ns-working-overlay))
+    (with-current-buffer (overlay-buffer ns-working-overlay)
+      (delete-region (overlay-start ns-working-overlay)
+                     (overlay-end ns-working-overlay))
+      (delete-overlay ns-working-overlay)))
+   ((integerp ns-working-overlay)
   (let ((msg (current-message))
 	message-log-max)
-    (setq msg (substring msg 0 (- (length msg) ns-working-overlay-len)))
-    (message "%s" msg)
-    (setq ns-working-overlay-len 0)
-    (setq ns-working-overlay nil)))
+      (setq msg (substring msg 0 (- (length msg) ns-working-overlay)))
+      (message "%s" msg))))
+  (setq ns-working-overlay nil))
 
 
 (declare-function ns-convert-utf8-nfd-to-nfc "nsfns.m" (str))

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

From: Harald Maier <harald <at> maierh.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Fri, 20 Feb 2009 04:46:36 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> I think the bug is in the definition of ns-unput-working-text (or in
>>> the way ns-unput-working-text and ns-unput-working-text (both events
>>> and functions) interact).
>>> 
>>> Not sure why ns-working-overlay was nil in your case, so either
>>> ns-unput-working-text should be careful to handle the case where that
>>> variable is nil, or some other code should make sure that it can't be
>>> nil when we reach ns-unput-working-text.
>
>> It seems this is a bug in ns-insert-working-text, and it's already
>> mentioned there in a FIXME comment:
>
>> ;; FIXME: if buffer is read-only, don't try to insert anything
>> ;;  and if text is bound to a command, execute that instead (Bug#1453)
>
>> The Gnus group and summary buffers are read only, so what we're dealing
>> here seems to be a duplicate of Bug #1453.
>
> What happens after the patch below?  It's not intended to fix #1453.
>
>
>         Stefan
>
> --- ns-win.el.~1.36.~ 2009-02-07 11:23:03.000000000 -0500
> +++ ns-win.el 2009-02-19 13:21:57.000000000 -0500

Yes, I can confirm that the patch fixes the caret character (^) in the
gnus group and summary buffer. 

Harald

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

From: David Engster <deng <at> randomsample.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Fri, 20 Feb 2009 14:03:09 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> I think the bug is in the definition of ns-unput-working-text (or in
>>> the way ns-unput-working-text and ns-unput-working-text (both events
>>> and functions) interact).
>>> 
>>> Not sure why ns-working-overlay was nil in your case, so either
>>> ns-unput-working-text should be careful to handle the case where that
>>> variable is nil, or some other code should make sure that it can't be
>>> nil when we reach ns-unput-working-text.
>
>> It seems this is a bug in ns-insert-working-text, and it's already
>> mentioned there in a FIXME comment:
>
>> ;; FIXME: if buffer is read-only, don't try to insert anything
>> ;;  and if text is bound to a command, execute that instead (Bug#1453)
>
>> The Gnus group and summary buffers are read only, so what we're dealing
>> here seems to be a duplicate of Bug #1453.
>
> What happens after the patch below?  

The patch makes "^" bindings work in Gnus. Thanks!

> It's not intended to fix #1453.

Yes, there's still a warning issued about the current buffer being
read-only.

-David

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Engster <deng <at> randomsample.de>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Fri, 20 Feb 2009 10:18:43 -0500

>> What happens after the patch below?
> The patch makes "^" bindings work in Gnus. Thanks!

Now I didn't expect that.  I guess that's good, tho.
But does the ^ character still behave properly as a dead-key in normal
editing buffers?

>> It's not intended to fix #1453.
> Yes, there's still a warning issued about the current buffer being
> read-only.

That's expected yes.


        Stefan

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

From: David Engster <deng <at> randomsample.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Fri, 20 Feb 2009 16:41:32 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> What happens after the patch below?
>> The patch makes "^" bindings work in Gnus. Thanks!
>
> Now I didn't expect that.  I guess that's good, tho.

Hitting ^+space works. I'd say that's good. :-)

> But does the ^ character still behave properly as a dead-key in normal
> editing buffers?

Yes, it does.

-David

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: David Engster <deng <at> randomsample.de>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Fri, 20 Feb 2009 16:14:20 -0500

>>>> What happens after the patch below?
>>> The patch makes "^" bindings work in Gnus. Thanks!
>> Now I didn't expect that.  I guess that's good, tho.
> Hitting ^+space works. I'd say that's good. :-)

Oh, I get it: so hitting ^ doesn't do anything, but hitting ^ SPC
does trigger the Gnus command bount to ^.
Yes, that makes sense.  We could supposedly improve this to actually
make ^ call the proper Gnus command directly, but the patch doesn't try
to do that.

>> But does the ^ character still behave properly as a dead-key in normal
>> editing buffers?
> Yes, it does.

Good.  I'll install it as soon as I get back to the machine on which
I wrote it ;-)


        Stefan

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

From: David Engster <deng <at> randomsample.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Sat, 21 Feb 2009 01:45:10 +0100

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>>>>> What happens after the patch below?
>>>> The patch makes "^" bindings work in Gnus. Thanks!
>>> Now I didn't expect that.  I guess that's good, tho.
>> Hitting ^+space works. I'd say that's good. :-)
>
> Oh, I get it: so hitting ^ doesn't do anything, but hitting ^ SPC
> does trigger the Gnus command bount to ^.

Exactly, since dead-key+space enters the compose character
itself. Hitting ^ does trigger the "buffer read-only" warning though,
since the code tries to insert the overlay at that point.

> Yes, that makes sense.  We could supposedly improve this to actually
> make ^ call the proper Gnus command directly, but the patch doesn't
> try to do that.

Yes, while playing around with the code I implemented that (it still did
"swallow" the next keypress though, so it's not really usable), and I
wondered if this behaviour could be confusing to some people, since they
might expect that the "^" _character_ and not the keypress itself
triggers a command? (I usually use the US layout, so I don't have a
strong opinion on that anyway :-) ).

>>> But does the ^ character still behave properly as a dead-key in normal
>>> editing buffers?
>> Yes, it does.
>
> Good.  I'll install it as soon as I get back to the machine on which
> I wrote it ;-)

OK, thanks again!

-David

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

From: Harald Maier <harald <at> maierh.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Sat, 21 Feb 2009 05:56:18 +0100

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>>>>> What happens after the patch below?
>>>> The patch makes "^" bindings work in Gnus. Thanks!
>>> Now I didn't expect that.  I guess that's good, tho.
>> Hitting ^+space works. I'd say that's good. :-)
>
> Oh, I get it: so hitting ^ doesn't do anything, but hitting ^ SPC
> does trigger the Gnus command bount to ^.
> Yes, that makes sense.  We could supposedly improve this to actually
> make ^ call the proper Gnus command directly, but the patch doesn't try
> to do that.

On a German keyboard this behaviour would be confusing. ^ is a dead key
so we always use the SPACE key to force it. It should be similar to the
X11 build and there I have too to press the SPACE character to force the
dead key. As David mentioned the only small problem is the "buffer read
only" warning.

Harald

Message #65 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>, 2375 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#2375: 23.0.90;	^ in gnus summary buffer does not work in the nextstep build
Date: Sat, 21 Feb 2009 15:38:07 +0900

>>>>> On Sat, 21 Feb 2009 05:56:18 +0100, Harald Maier <harald <at> maierh.de> said:

>> Oh, I get it: so hitting ^ doesn't do anything, but hitting ^ SPC
>> does trigger the Gnus command bount to ^.  Yes, that makes sense.
>> We could supposedly improve this to actually make ^ call the proper
>> Gnus command directly, but the patch doesn't try to do that.

> On a German keyboard this behaviour would be confusing. ^ is a dead
> key so we always use the SPACE key to force it. It should be similar
> to the X11 build and there I have too to press the SPACE character
> to force the dead key. As David mentioned the only small problem is
> the "buffer read only" warning.

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.

Below is the code from the Carbon+AppKit port(*), which also uses the
NSTextInput protocol.

(*) ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.2.tar.gz

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

(defconst mac-marked-text-underline-style-faces
  '((0 . mac-ts-raw-text)		  ; NSUnderlineStyleNone
    (1 . mac-ts-converted-text)		  ; NSUnderlineStyleSingle
    (2 . mac-ts-selected-converted-text)) ; NSUnderlineStyleThick
  "Alist of NSUnderlineStyle vs Emacs face in marked text.")

(defun mac-text-input-set-marked-text (event)
  (interactive "e")
  (let* ((ae (mac-event-ae event))
	 (text (cdr (mac-ae-parameter ae)))
	 (selected-range (cdr (mac-ae-parameter ae "selectedRange")))
	 (script-language (mac-ae-script-language ae "tssl"))
	 (coding (or (cdr (assq (car script-language)
				mac-script-code-coding-systems))
		     'mac-roman)))
    (let ((use-echo-area
	   (or isearch-mode
	       (and cursor-in-echo-area (current-message))
	       ;; Overlay strings are not shown in some cases.
	       (get-char-property (point) 'invisible)
	       (and (not (bobp))
		    (or (and (get-char-property (point) 'display)
			     (eq (get-char-property (1- (point)) 'display)
				 (get-char-property (point) 'display)))
			(and (get-char-property (point) 'composition)
			     (eq (get-char-property (1- (point)) 'composition)
				 (get-char-property (point) 'composition)))))))
	  active-input-string caret-seen)
      ;; Decode the active input area text with inheriting faces and
      ;; the caret position.
      (put-text-property (* (car selected-range) 2) (length text)
			 'cursor t text)
      (setq active-input-string
	    (mapconcat
	     (lambda (str)
	       (let* ((decoded (mac-utxt-to-string str coding))
		      (underline-style
		       (or (cdr (get-text-property 0 'NSUnderline str)) 0))
		      (face
		       (cdr (assq underline-style
				  mac-marked-text-underline-style-faces))))
		 (put-text-property 0 (length decoded) 'face face decoded)
		 (when (and (not caret-seen)
			    (get-text-property 0 'cursor str))
		   (setq caret-seen t)
		   (if (or use-echo-area (null cursor-type))
		       (put-text-property 0 1 'face 'mac-ts-caret-position
					  decoded)
		     (put-text-property 0 1 'cursor t decoded)))
		 decoded))
	     (mac-split-string-by-property-change text)
	     ""))
      (put-text-property 0 (length active-input-string)
			 'mac-ts-active-input-string t active-input-string)
      (if use-echo-area
	  (let ((msg (current-message))
		message-log-max)
	    (if (and msg
		     ;; Don't get confused by previously displayed
		     ;; `active-input-string'.
		     (null (get-text-property 0 'mac-ts-active-input-string
					      msg)))
		(setq msg (propertize msg 'display
				      (concat msg active-input-string)))
	      (setq msg active-input-string))
	    (message "%s" msg)
	    (overlay-put mac-ts-active-input-overlay 'before-string nil))
	(move-overlay mac-ts-active-input-overlay
		      (point) (point) (current-buffer))
	(overlay-put mac-ts-active-input-overlay 'before-string
		     active-input-string)))))

(defun mac-text-input-insert-text (event)
  (interactive "e")
  (let* ((ae (mac-event-ae event))
	 (text (cdr (mac-ae-parameter ae)))
	 (script-language (mac-ae-script-language ae "tssl"))
	 (coding (or (cdr (assq (car script-language)
				mac-script-code-coding-systems))
		     'mac-roman)))
    (overlay-put mac-ts-active-input-overlay 'before-string nil)
    (let ((msg (current-message))
	  message-log-max)
      (when msg
	(if (get-text-property 0 'mac-ts-active-input-string msg)
	    (message nil)
	  (let ((disp-prop (get-text-property 0 'display msg)))
	    (when (and (stringp disp-prop)
		       (> (length disp-prop) 1)
		       (get-text-property (1- (length disp-prop))
					  'mac-ts-active-input-string))
	      (remove-text-properties 0 (length disp-prop)
				      '(mac-ts-active-input-string nil)
				      msg)
	      (message "%s" msg))))))
    (mac-unread-string (mac-utxt-to-string text coding))))

(define-key mac-apple-event-map [text-input set-marked-text]
  'mac-text-input-set-marked-text)
(define-key mac-apple-event-map [text-input insert-text]
  'mac-text-input-insert-text)

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

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

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

>>>>>> On Sat, 21 Feb 2009 05:56:18 +0100, Harald Maier <harald <at> maierh.de> said:
>
>>> Oh, I get it: so hitting ^ doesn't do anything, but hitting ^ SPC
>>> does trigger the Gnus command bount to ^.  Yes, that makes sense.
>>> We could supposedly improve this to actually make ^ call the proper
>>> Gnus command directly, but the patch doesn't try to do that.
>
>> On a German keyboard this behaviour would be confusing. ^ is a dead
>> key so we always use the SPACE key to force it. It should be similar
>> to the X11 build and there I have too to press the SPACE character
>> to force the dead key. As David mentioned the only small problem is
>> the "buffer read only" warning.
>
> 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. 

I see now that the caret character (^) as dead key in the X11 build also
makes some problem. E.g. "C-c ^" (org-sort).

Harald

Message #77 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: 2375 <at> debbugs.gnu.org
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Sun, 22 Feb 2009 10:39:35 +0900

>>>>> On Sat, 21 Feb 2009 10:30:50 +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.

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

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

From: Harald Maier <harald <at> maierh.de>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 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 06:00:22 +0100

[Message part 1 (text/plain, inline)]

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

>>>>>> On Sat, 21 Feb 2009 10:30:50 +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.

[Bild 1.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

Harald

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

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 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: Wed, 25 Feb 2009 11:25:17 -0500

> 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?


        Stefan

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 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 10:21:11 -0500

>> 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.

I never use dead keys like those, so I wouldn't know [a US keyboard plus
a compose key is all I need, plus the TeX input method, of course ;-)].
But I'll happily believe you.
It still leaves open the question of whether it would be desirable to
shortcut this so that pressing ^ in the Gnus summary immediately calls
the Gnus command, without having to press a subsequent SPC.

> 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.

I don't know what is "the marked text" nor what is "the selected range
value".


        Stefan

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

From: David Engster <deng <at> randomsample.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 2375 <at> debbugs.gnu.org,
        YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        Harald Maier <harald <at> maierh.de>
Subject: Re: bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build
Date: Thu, 26 Feb 2009 17:49:17 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> It still leaves open the question of whether it would be desirable to
> shortcut this so that pressing ^ in the Gnus summary immediately calls
> the Gnus command, without having to press a subsequent SPC.

I now agree with Harald that this would be confusing. A dead key is
essentially a compose key for one character, and I think it shouldn't
call commands by itself. Pressing ^+space enters "^", so that key
sequence should call commands bound to "^", just like I have to press
^+a to execute a command bound to "â".

-David

Message #112 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: 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: Fri, 27 Feb 2009 09:09:44 +0900

>>>>> On Thu, 26 Feb 2009 10:21:11 -0500, Stefan Monnier <monnier <at> iro.umontreal.ca> said:

> It still leaves open the question of whether it would be desirable
> to shortcut this so that pressing ^ in the Gnus summary immediately
> calls the Gnus command, without having to press a subsequent SPC.

Besides a matter of taste, the marked text (corresponding to preedit
in XIM) is not necessarily identical to the pressed key (e.g.,
Japanese input methods).

>> 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.

> I don't know what is "the marked text" nor what is "the selected
> range value".

They are in the Cocoa NSTextInput terminology.  The "marked text"
corresponds to "preedit" in XIM as above or "active input" in Carbon
TSM.  I don't know why the Cocoa/GNUstep port call it "working text".
The "selected range" represents the caret position in the marked text.

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 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: Mon, 09 Mar 2009 09:25:59 -0400

>> It still leaves open the question of whether it would be desirable
>> to shortcut this so that pressing ^ in the Gnus summary immediately
>> calls the Gnus command, without having to press a subsequent SPC.
> Besides a matter of taste, the marked text (corresponding to preedit
> in XIM) is not necessarily identical to the pressed key (e.g.,
> Japanese input methods).
>>> 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.
>> I don't know what is "the marked text" nor what is "the selected
>> range value".
> They are in the Cocoa NSTextInput terminology.  The "marked text"
> corresponds to "preedit" in XIM as above or "active input" in Carbon
> TSM.  I don't know why the Cocoa/GNUstep port call it "working text".
> The "selected range" represents the caret position in the marked text.

I don't know what "preedit" or "caret" are either :-(


        Stefan

Message #122 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: Tue, 10 Mar 2009 09:05:45 +0900

>>>>> On Mon, 09 Mar 2009 09:25:59 -0400, Stefan Monnier <monnier <at> iro.umontreal.ca> said:

>>> It still leaves open the question of whether it would be desirable
>>> to shortcut this so that pressing ^ in the Gnus summary
>>> immediately calls the Gnus command, without having to press a
>>> subsequent SPC.
>> Besides a matter of taste, the marked text (corresponding to
>> preedit in XIM) is not necessarily identical to the pressed key
>> (e.g., Japanese input methods).
>>>> 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.
>>> I don't know what is "the marked text" nor what is "the selected
>>> range value".
>> They are in the Cocoa NSTextInput terminology.  The "marked text"
>> corresponds to "preedit" in XIM as above or "active input" in
>> Carbon TSM.  I don't know why the Cocoa/GNUstep port call it
>> "working text".  The "selected range" represents the caret position
>> in the marked text.

> I don't know what "preedit" or "caret" are either :-(

"Preedit" is an intermediate text.  It is used for showing partial
result of composition.  In Japanese input methods, it is also used for
showing phonetic characters to be converted to ideographic characters,
or the current selection of ideographic characters among homonyms.

The "caret" corresponds to the cursor and it represents the current
insertion/deletion point in the preedit text.  For example, one can
erase a phonetic character in the middle of the preedit text before
the phonetic-to-ideographic (kana-kanji) conversion.

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 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: Tue, 10 Mar 2009 13:18:43 -0400

>> I don't know what "preedit" or "caret" are either :-(

> "Preedit" is an intermediate text.  It is used for showing partial
> result of composition.  In Japanese input methods, it is also used for
> showing phonetic characters to be converted to ideographic characters,
> or the current selection of ideographic characters among homonyms.

> The "caret" corresponds to the cursor and it represents the current
> insertion/deletion point in the preedit text.  For example, one can
> erase a phonetic character in the middle of the preedit text before
> the phonetic-to-ideographic (kana-kanji) conversion.

I see.  Looking at Emacs-22's mac-win.el, it looks like some of the
functionality you describe was there in Emacs-22 already and it got lost
when we switched to Emacs.app.
Could someone try to adapt that code to ns-win.el?

        Stefan

Message #130 received at 2375 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Harald Maier <harald <at> maierh.de>, 2375 <at> debbugs.gnu.org,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#2375: 23.0.90;
 ^ in gnus summary buffer does not work in the nextstep build
Date: Fri, 13 Feb 2015 18:18:38 +1100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> It still leaves open the question of whether it would be desirable to
> shortcut this so that pressing ^ in the Gnus summary immediately calls
> the Gnus command, without having to press a subsequent SPC.

I think that would be confusing.  When you have a keyboard with dead
keys, you're used to them being just composing characters that needs
another keystroke for something to happen.  So `^ SPC' is fine in Gnus.

The patch in question seems to give visual feedback that you're in the
middle of a composing character, which might be nice, though.

But is this still an issue five years later?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #133 received at 2375 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Harald Maier <harald <at> maierh.de>, 2375 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#2375: 23.0.90;
 ^ in gnus summary buffer does not work in the nextstep build
Date: Thu, 21 Jan 2016 23:31:58 +0000

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> It still leaves open the question of whether it would be desirable to
>> shortcut this so that pressing ^ in the Gnus summary immediately calls
>> the Gnus command, without having to press a subsequent SPC.
>
> I think that would be confusing.  When you have a keyboard with dead
> keys, you're used to them being just composing characters that needs
> another keystroke for something to happen.  So `^ SPC' is fine in Gnus.
>
> The patch in question seems to give visual feedback that you're in the
> middle of a composing character, which might be nice, though.
>
> But is this still an issue five years later?  :-)

It looks like the bug is fixed, so unless anyone disagrees I'll close
this bug in a few days.

-- 
Alan Third

Previous Next

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