From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Tue, 16 Dec 2014 00:26:05 +0200 Message-ID: <548F5FFD.5010703@yandex.ru> References: <20141102151524.0d9c665c@forcix> <85egsem1u2.fsf@stephe-leake.org> <867fy0or7p.fsf@yandex.ru> <86ppbqn841.fsf@yandex.ru> <86mw6o3k28.fsf@yandex.ru> <548F5B60.8050509@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1418682398 3619 80.91.229.3 (15 Dec 2014 22:26:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Dec 2014 22:26:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 15 23:26:31 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y0e60-00042L-BO for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 23:26:28 +0100 Original-Received: from localhost ([::1]:42151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0e5z-0001JW-SP for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 17:26:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0e5p-0001Ij-6L for emacs-devel@gnu.org; Mon, 15 Dec 2014 17:26:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0e5g-0003DB-5x for emacs-devel@gnu.org; Mon, 15 Dec 2014 17:26:17 -0500 Original-Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:34292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0e5f-0003D5-VC for emacs-devel@gnu.org; Mon, 15 Dec 2014 17:26:08 -0500 Original-Received: by mail-wi0-f175.google.com with SMTP id l15so10464866wiw.2 for ; Mon, 15 Dec 2014 14:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9YvoKluOOp9FQxdw/O7qqGjTwiBQbc9EUKv85r/JssQ=; b=zapIwADV92XCA3TdfFEIwsv+AZV9rPIWQ1dfQwbkH7l1nJXp9UZK6nOzJZpY0S4R6K ZPhS8Hal1PjI6BCqkmkGGrEyppPnj6aBpSQ/O57+MqWCoLdR6uGqSlC3ppSqHGDK8Ty9 rQunEVMEAhu1SddawslzdKUMa+0gP3h7CDI3fNDfvL1E+KUa6cWyzPIn0BbgYo/oQfaI 4yGFzBcEIhf9juXpEIKb8PhdaN3BK70oebOqWI+CoCros5ykLFYbHj806iEF1629XTCL 5LCSVyPT55d2DMBngcFNu3o9lU2mSoaKmwyrWLcH7b09yvq3pSpOJbKOhv1Yibpbl40K QQNA== X-Received: by 10.194.157.4 with SMTP id wi4mr41059900wjb.54.1418682367384; Mon, 15 Dec 2014 14:26:07 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.58]) by mx.google.com with ESMTPSA id cz3sm14603717wjb.23.2014.12.15.14.26.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 14:26:06 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180186 Archived-At: 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 > completing-read. 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.