bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44466: 27.1; quail input fails at read-only boundary


From: lg . zevlg
Subject: bug#44466: 27.1; quail input fails at read-only boundary
Date: Sun, 8 Nov 2020 20:07:46 +0400

> 8 нояб. 2020 г., в 19:02, Eli Zaretskii <eliz@gnu.org> написал(а):
> 
> 
>> 
>> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> Date: Sun, 8 Nov 2020 09:42:23 +0300
>> Cc: dick.r.chiang@gmail.com, 44466@debbugs.gnu.org
>> 
>>> When an input method is used in a read-only buffer, Emacs barfs
>>> because it doesn't allow inserting text into such a buffer.  It
>>> doesn't insert the untranslated character, as what your patch did.
>>> 
>>>> Possible we need to check front-stickyness of the char at point along with 
>>>> 'read-only property:
>>>> 
>>>> ..
>>>>                  (and (get-char-property (point) 'read-only)
>>>>                       (get-char-property (point) 'front-sticky)))
>>> 
>>> Does this solve the problem in this case?
>> 
>> Yes, because this mimics what is done in
>> verify_interval_modification() function from textprop.c.
> 
> Any reason why pressing a key on a button should disregard the active
> input method?  What if the button needs the user to type the character
> which the input method would produce?  AFAIU, the patch we installed a
> year ago makes this impossible.

The reason is the same as for read-only buffers, making single char bindings 
work. For example if you change input method in image-mode and press “q” key 
this will kill buffer, because correct command is executed.

Writable buffer might have read-only region with local-keymap installed with 
single char binding. If input method is applied, then instead of executing 
corresponding command you will get “text is read-only” error, because 
self-insert command is executed.


> 
>> Possibly the best solution would be to make
>> verify_interval_modification() visible from elisp side and use it in
>> quail-input-method to check for writability at point.
> 
> I think this would be overkill.

—
lg






reply via email to

[Prev in Thread] Current Thread [Next in Thread]