[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:26:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 12/16/2014 12:17 AM, Helmut Eller wrote:

Apparently I missed that.  The last patch I looked at had a number of
(eq id t) tests.

Ok, sorry. I misunderstood. So, only strings? That's not bad, the string can be that "imprecise" value, and a property will signal that the backend will have to find out what the identifier is, maybe using the value of that property (likely marker), or the current value of point.

There's still the problem of how to put text properties on the result of

Do we really need to? I think the identifier-completion-table can manage to contain only unambiguous entries.

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.

reply via email to

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