unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: phillip.lord@russet.org.uk (Phillip Lord)
Cc: emacs-devel@gnu.org
Subject: Timing of input-method output (was: [Emacs-diffs] master 7b31de4: Add hook for all events)
Date: Sat, 02 Feb 2019 11:13:14 -0500	[thread overview]
Message-ID: <jwvr2cqtcei.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87munlumyn.fsf@russet.org.uk> (Phillip Lord's message of "Mon, 28 Jan 2019 09:54:08 +0000")

>> Hmm... this is a bummer (in some input methods, many/most chars are
>> prefixes of something else).  IIUC this is not a new problem introduced
>> by the use of input-event-functions, tho, right?
> My experience is that completion doesn't work when an input method is
> half way through, although I only use simple input methods.

Right: so this is not a new problem.

> Anyway, I checked (should have done this before I sent the last email,
> sorry). The buffer is not changed by an input method half way through
> (or at least "before-change-function" is not called, which I am assuming
> is the same thing). So, when the buffer appears to say "pizza_[`]", if
> it does offer a completion at all, it's going to offer one based on
> "pizz" because they "a" is not in the buffer.

Actually, quail.el does insert the "a", but it does so only temporarily,
within a with-silent-modification, and it removes it as soon as we know
what will actually be the next result of the input method (to the user,
that's basically when the underscore is (re)moved).

IOW, the underlined text behaves more or less like it's not in the
buffer (technically it is, but it's transient and the *-change-functions
aren't notified).

For latin-based input methods (especially postfix-style ones) where it's
extremely frequent for the first char passed to an input method to end up
passed through unmodified, it would make sense to try and change the
behavior of quail so it really inserts the first char right away, even
if it may later modify it because of some subsequent user input.

E.g. currently, in latin-postfix methods, when I type

    Time0   Time1
    -----   -----
    e       n

the input looks (to the rest of Emacs) as if I had typed

    Time0   Time1
    -----   -----
            e n

this is so that when I type

    Time0   Time1
    -----   -----
    e       '

Emacs only sees

    Time0   Time1
    -----   -----
            é

but we it would make sense to try and make it behave such that an input like:

    Time0   Time1   Time2   Time3
    -----   -----   -----   -----
    e       n       e       '

results in the following (decoded) input events:

    Time0   Time1   Time2   Time3
    -----   -----   -----   -----
    e       n       e       DEL é

[ More or less: the DEL there can't be right since the user can bind it
  to anything else, so we'd have to delete the previous char "manually"
  rather than by emitting a DEL event.  ]

This would be a pretty significant change in quail.el (which is likely
to require experimentation before we can find something that works
well), and is likely to only make sense in some input methods.

I think it'd be nice for someone to play with such a quail variant
(it's probably easiest to do it be adding a config var to quail.el to
control that new behavior) to see if it can fly.


        Stefan



  reply	other threads:[~2019-02-02 16:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190122214637.25164.20429@vcs0.savannah.gnu.org>
     [not found] ` <20190122214639.B2E13203DD@vcs0.savannah.gnu.org>
2019-01-22 23:17   ` master 7b31de4: Add hook for all events Michael Albinus
2019-01-23 22:56     ` Phillip Lord
2019-01-24  3:36       ` Eli Zaretskii
2019-01-23  1:30   ` [Emacs-diffs] " Daniel Colascione
2019-01-23 23:10     ` Phillip Lord
2019-01-24  2:06       ` Stefan Monnier
2019-01-24 10:41         ` Phillip Lord
2019-01-25 13:56           ` Stefan Monnier
2019-01-28  9:42             ` Phillip Lord
2019-01-26  0:50           ` Stefan Monnier
2019-01-28  9:54             ` Phillip Lord
2019-02-02 16:13               ` Stefan Monnier [this message]
2019-02-03 22:06                 ` Timing of input-method output Phillip Lord
2019-02-05 14:49                   ` Stefan Monnier
2019-02-06 22:18                     ` Phillip Lord
2019-02-06 22:55                       ` Stefan Monnier
2019-02-11 22:10                         ` Phillip Lord
2019-02-11 22:20                           ` Stefan Monnier
2019-02-12 12:21                             ` Phillip Lord
2019-03-25 21:48                               ` Phillip Lord
2019-03-26 15:12                                 ` Stefan Monnier
2019-03-28 13:54                                   ` Phillip Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvr2cqtcei.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=phillip.lord@russet.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).