|
From: | Dmitry Gutov |
Subject: | Re: Generalizing find-definition |
Date: | Tue, 16 Dec 2014 00:54:43 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
On 12/16/2014 12:41 AM, Helmut Eller wrote:
Even if we could carry text properties through `completing-read', the user won't see them when choosing, so all strings in the table will have to be different anyway.What I'm saying is that my original proposal of having a read-identifier-form-minibuffer make sense as it allows backends to add text properties more easily than a completion table.
And I'm asking, why do we need text properties there?For example, for a hypothetical Ruby backend, the completion table will return fully qualified identifiers, like String#gsub, ActiveRecord::Base.first, or Hash#[]. A string like this can be send to the external process, and it'll return the source location, docstring, etc, without any additional data.
> And calling
completing-read isn't difficult for the backends if they already have the completion table.
That's a lot of responsibility we don't necessarily have to give them. And even though the method is called `read-identifier-from-minibuffer', what's stopping them from using any other possible interface to get the input from the user?
Rather than allow that, I'd rather we improve the input interface in centralized fashion, and ask the backends only for possible values.
So when we can read input in the middle of the frame in a nice popup (any day now, I'm sure), all backends will benefit.
[Prev in Thread] | Current Thread | [Next in Thread] |