Subject: bug#26672: 25.2; Flyspell overlay conflicts with table.el

From: Allen Li <[email-masked]>
Date: Fri, 28 Apr 2017 21:19:38 -0700

1. emacs -Q
2. M-x flyspell-mode
3. M-x table-insert RET RET RET ... (the defaults are fine)
4. apple M-b TAB (apple is spelled correctly, TAB works)
5. asdf M-b TAB (wait for flyspell to mark the misspelling, TAB doesn't work)

On Fri, Apr 28, 2017 at 2:10 AM, Eli Zaretskii <[email-masked]> wrote:
>> From: Allen Li <[email-masked]>
>> Date: Wed, 26 Apr 2017 15:00:05 -0700
>>
>> Flyspell's overlay for misspelled words conflicts with table.el
>>
>> table.el adds its keymap as a text property to the text in table cells.
>> When Flyspell detects a misspelled word, it adds an overlay with a
>> keymap binding mouse2 to ‘flyspell-correct-word’.  Apparently, this
>> overlay keymap overrides table.el’s ‘keymap’ text property.
>>
>> The effect of this is that pressing TAB to move between table cells will
>> instead insert a literal tab character if your cursor happens to be on a
>> misspelled word.  This is extremely annoying.
>
> Thank you for your report.
>
> Could you please provide a complete recipe for reproducing the
> problem, starting with "emacs -Q", and loading all the necessary
> packages and visiting files if needed?  I think I know how to fix
> this, but I need a clear-cut test case, and I don't use table.el to
> easily know how to do that.
>
> Also, is the problem only with TAB, or are there other keys which
> conflict with the Flyspell overlay keymap?
>
>> More generally, I’m not sure that an overlay keymap replacing the
>> ‘keymap’ text property is desired behavior.  At the very least, there
>> should be an escape hatch option on the overlay keymap that defers to
>> the ‘keymap’ text property for cases like Flyspell where replacing the
>> ‘keymap’ text property is not desired behavior.
>
> I think we do have the necessary infrastructure in Emacs to achieve
> the effect you want, it's just a matter of using it.  Whether to use
> it in any given case is a decision that should be made on a case by
> case basis, since the user and/or application could want one or the
> other.