From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Tue, 16 Dec 2014 00:03:02 +0100 Message-ID: References: <20141102151524.0d9c665c@forcix> <867fy0or7p.fsf@yandex.ru> <86ppbqn841.fsf@yandex.ru> <86mw6o3k28.fsf@yandex.ru> <548F5B60.8050509@yandex.ru> <548F5FFD.5010703@yandex.ru> <548F66B3.3050103@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418684624 4807 80.91.229.3 (15 Dec 2014 23:03:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Dec 2014 23:03:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 16 00:03:37 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 1Y0efx-0003oP-D9 for ged-emacs-devel@m.gmane.org; Tue, 16 Dec 2014 00:03:37 +0100 Original-Received: from localhost ([::1]:42272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0efx-0001Pp-0O for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 18:03:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0efa-0001PW-9v for emacs-devel@gnu.org; Mon, 15 Dec 2014 18:03:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0efR-0006kG-5D for emacs-devel@gnu.org; Mon, 15 Dec 2014 18:03:14 -0500 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:58556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0efQ-0006kC-US for emacs-devel@gnu.org; Mon, 15 Dec 2014 18:03:05 -0500 Original-Received: by mail-wi0-f177.google.com with SMTP id l15so10719069wiw.10 for ; Mon, 15 Dec 2014 15:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=hnXDlJSrGkabFYkxLdOYnwOFOP3nOzMVQXGrbAGg2JM=; b=a16hbQVEM3oEcqzCFjQwuKIdG7DFuXQC1SQTmqBiqcezOmh/m820pWsPP+PULDJfW+ MeGJoCw7Ft1Jh3vNLPKdVi4SlKW/drAfriDu4CuLiBFcVBQNRhVdrLxlhhoUbzB2y/+1 nqNVPs+F4JAaHqbsgW0x6i/n1zDsP2BPxVsZIBHZIDoA0F0p+kGdzLcd7QP/XE5gh5t+ sYFKDzgIO1UrArnKA+xTmt4vopeq05NDj7qO3+lbmDLnbWkph3oZLdFwR9Hjyzd8JHkx 6A/ywH4bNnTKjCi+3LmK5MDEz8qWuoe6TC6WYwRqosXzuCWFEM0v2kgYsLX+Zxfa4oVH hgPQ== X-Received: by 10.180.72.178 with SMTP id e18mr20091425wiv.23.1418684584069; Mon, 15 Dec 2014 15:03:04 -0800 (PST) Original-Received: from ix ([212.46.172.140]) by mx.google.com with ESMTPSA id j2sm14679316wjs.28.2014.12.15.15.03.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 15 Dec 2014 15:03:03 -0800 (PST) Original-Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y0efO-0001Zp-Vt; Tue, 16 Dec 2014 00:03:03 +0100 In-Reply-To: <548F66B3.3050103@yandex.ru> (Dmitry Gutov's message of "Tue, 16 Dec 2014 00:54:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:180189 Archived-At: On Tue, Dec 16 2014, Dmitry Gutov wrote: > 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? Because it feels right. >> 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. Feel free to disagree. Helmut