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:54:43 +0200 Message-ID: <548F66B3.3050103@yandex.ru> References: <20141102151524.0d9c665c@forcix> <867fy0or7p.fsf@yandex.ru> <86ppbqn841.fsf@yandex.ru> <86mw6o3k28.fsf@yandex.ru> <548F5B60.8050509@yandex.ru> <548F5FFD.5010703@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 1418684117 29871 80.91.229.3 (15 Dec 2014 22:55:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Dec 2014 22:55:17 +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:55:10 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 1Y0eXj-0008VY-Kj for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 23:55:07 +0100 Original-Received: from localhost ([::1]:42246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0eXj-0007DO-AY for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 17:55:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0eXX-0007Bf-HE for emacs-devel@gnu.org; Mon, 15 Dec 2014 17:55:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0eXO-0003Fo-By for emacs-devel@gnu.org; Mon, 15 Dec 2014 17:54:55 -0500 Original-Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:47233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0eXO-0003Eb-50 for emacs-devel@gnu.org; Mon, 15 Dec 2014 17:54:46 -0500 Original-Received: by mail-wg0-f51.google.com with SMTP id x12so15904380wgg.10 for ; Mon, 15 Dec 2014 14:54:45 -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=BL2arCzcpS03v/ARMCHIP0hsjb+7mkoyE4ezjKeWPHU=; b=pcLjH/wvY5eKk70wRnzSlLN8CGguhoClnuxzfzAameagp6kN0U5kPViN7d5KBWSBZh Sov3uR2n0P0k6RZY1kCy/Al60W4PHsF5jXLIpCjMoyUlV2u5QbDR7rQxgaeBVWbOT0lB /TTEvt59IniyQORW+BXIsM6USZxGYuC44nFI7XXY1XRgiXghDkukXJZUnRuyd2FPx2Gt qMuKVVPo2+u68Y+jeGsFTih7WAAdaVKvEHQpLqnq8FgWFujVx6qbLvSP1YX4sloj2T8K tT70D2Uhg/ZAVc7nuLXRi+njcrAOfMnySM69d++qsiBsroFokoIrQjDNcQGytntEOU7d Ghlw== X-Received: by 10.194.189.138 with SMTP id gi10mr57860669wjc.86.1418684085357; Mon, 15 Dec 2014 14:54:45 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.58]) by mx.google.com with ESMTPSA id wz5sm14659378wjc.29.2014.12.15.14.54.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 14:54:44 -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:c00::233 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:180188 Archived-At: 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.