[Top][All Lists]

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

Re: Generalizing find-definition

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.

reply via email to

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