bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Harald Maier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[David Engster]

Harald Maier <harald@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

> 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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[David Engster]

Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Harald Maier]

Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[David Engster]

Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[David Engster]

Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[David Engster]

Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Harald Maier]

Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 21 Feb 2009 05:56:18 +0100, Harald Maier <harald@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@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)

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Harald Maier]

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

>>>>>> On Sat, 21 Feb 2009 05:56:18 +0100, Harald Maier <harald@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 21 Feb 2009 10:30:50 +0100, Harald Maier <harald@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@math.s.chiba-u.ac.jp

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Harald Maier]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

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

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


[-- Attachment #2: Bild 1.png --]
[-- Type: image/png, Size: 49494 bytes --]

[-- Attachment #3: Type: text/plain, Size: 8 bytes --]


Harald

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 24 Feb 2009 06:00:22 +0100, Harald Maier <harald@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@math.s.chiba-u.ac.jp

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

> 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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 25 Feb 2009 11:25:17 -0500, Stefan Monnier <monnier@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@math.s.chiba-u.ac.jp

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 26 Feb 2009 10:21:11 -0500, Stefan Monnier <monnier@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@math.s.chiba-u.ac.jp

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 09 Mar 2009 09:25:59 -0400, Stefan Monnier <monnier@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@math.s.chiba-u.ac.jp

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Stefan Monnier]

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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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/

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[Alan Third]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@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

bug#2375: 23.0.90; ^ in gnus summary buffer does not work in the nextstep build

[David Engster]

Stefan Monnier <monnier@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