bug#1453: 23.0.60; Dead keys do not work in dired and similar modes in Cocoa port

bug#1453: 23.0.60; Dead keys do not work in dired and similar modes in Cocoa port

[Wolfgang Lux]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org  
mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Dired mode binds ~ to dired-flag-backup-files. When one attempts  
entering
~ via the dead-key combination Alt-n (assuming the Alt key is not  
used as
a modifier key and Command is interpreted as Meta key), Emacs first  
reports
an error message "Buffer is read-only: #<buffer ~>" followed by an error
message "Wrong type argument: overlayp, nil" upon the next event.

In an attempt to fix this issue with some other Emacs version, I have  
added
the lines
   (define-key function-key-map [dead-tilde] "~")
   (put 'dead-tilde 'ascii-character ?~)
to .emacs, but these do not help (nor does removing them from .emacs).

Note that with a German keyboard layout, Alt-n is the only way to  
enter a
tilde character. The ASCII tilde is not bound to any key. (Actually, one
could enter ASCII tilde via key combinations Ctrl-Alt-n and Command- 
Alt-n,
respectively, but obviously this does not work for Emacs.)

In GNU Emacs 23.0.60.1 (powerpc-apple-darwin8.11.0, NS apple- 
appkit-824.48)
  of 2008-11-21 on Onyx.local
Windowing system distributor `Apple', version  
97.112.112.108.101.45.97.112.112.107.105.116.45.56.50.52.46.52.56
configured using `configure  '--with-ns''

bug#1453: 23.0.60; Dead keys do not work in dired and similar modes in Cocoa port

[Alan Third]

Wolfgang Lux <wolfgang.lux@gmail.com> writes:

> Dired mode binds ~ to dired-flag-backup-files. When one attempts
> entering
> ~ via the dead-key combination Alt-n (assuming the Alt key is not used
> as
> a modifier key and Command is interpreted as Meta key), Emacs first
> reports
> an error message "Buffer is read-only: #<buffer ~>" followed by an error
> message "Wrong type argument: overlayp, nil" upon the next event.

This is still sort of an issue in Emacs 25. As far as I can tell Emacs
still gives the "buffer is read-only" message, but as soon as another
key is hit actually executes dired-flag-backup-files.

I also suspect this won't be limited to the NS port, but will be an
issue anywhere you can use dead-keys in a read-only buffer.

I can't think of any reason to try and display the partially complete
input when the buffer's read-only, but I can't see where this dead-key
entry code is located to see if it's possible to do a check.
-- 
Alan Third

bug#1453: 23.0.60; Dead keys do not work in dired and similar modes in Cocoa port

[Alan Third]

Alan Third <alan@idiocy.org> writes:

> Wolfgang Lux <wolfgang.lux@gmail.com> writes:
>
>> Dired mode binds ~ to dired-flag-backup-files. When one attempts
>> entering
>> ~ via the dead-key combination Alt-n (assuming the Alt key is not used
>> as
>> a modifier key and Command is interpreted as Meta key), Emacs first
>> reports
>> an error message "Buffer is read-only: #<buffer ~>" followed by an error
>> message "Wrong type argument: overlayp, nil" upon the next event.
>
> This is still sort of an issue in Emacs 25. As far as I can tell Emacs
> still gives the "buffer is read-only" message, but as soon as another
> key is hit actually executes dired-flag-backup-files.
>
> I also suspect this won't be limited to the NS port, but will be an
> issue anywhere you can use dead-keys in a read-only buffer.
>
> I can't think of any reason to try and display the partially complete
> input when the buffer's read-only, but I can't see where this dead-key
> entry code is located to see if it's possible to do a check.

The fix for bug#23412 fixes this. It inserts the working text into the
buffer so you can see what's being typed, but once it completes it
deletes it and dired takes its action. It maybe looks a little weird,
but it works and I'm not sure what else we would do other than just not
display the working text at all.
-- 
Alan Third