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 23:40:05 +0200 Message-ID: <5490A6B5.7020308@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> <548F66B3.3050103@yandex.ru> <54901FEB.1090704@yandex.ru> <5490962D.7010105@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 1418766036 18584 80.91.229.3 (16 Dec 2014 21:40:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Dec 2014 21:40:36 +0000 (UTC) Cc: emacs-devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 16 22:40:29 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 1Y0zr2-0007zu-W3 for ged-emacs-devel@m.gmane.org; Tue, 16 Dec 2014 22:40:29 +0100 Original-Received: from localhost ([::1]:46934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zr1-0001vb-RT for ged-emacs-devel@m.gmane.org; Tue, 16 Dec 2014 16:40:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zqq-0001vJ-KK for emacs-devel@gnu.org; Tue, 16 Dec 2014 16:40:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0zqj-0005UG-Po for emacs-devel@gnu.org; Tue, 16 Dec 2014 16:40:16 -0500 Original-Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:51280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zqj-0005Rg-IF for emacs-devel@gnu.org; Tue, 16 Dec 2014 16:40:09 -0500 Original-Received: by mail-wi0-f180.google.com with SMTP id n3so14013904wiv.7 for ; Tue, 16 Dec 2014 13:40:08 -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=fHi67mZXgphRlTy154J0nyh6TgHi8G2hJfeqF4DX1jI=; b=q/rtRza1pNhjdSQAjkjoGKjzNiMHaAQlgp4AUhhFGwBNNJPVcZ7WLnj7qLPY1jwPzH sJZ7XTedFpw4HDJkc6y7Wng7Z7VUouW2r1jug2vX/9CJNgdK6VGtWyz5lUVXqyI86/+M bgwl2q23qaEzVhB2mKsnKTgaWcPUTcDSXEuj26G/culxHIsviG7HFaK8ZZ0Qev9j4ZGO BHRI0qampnmehucTcVssZLB8WHlGErfUPt9eKLLSAQmKxlIW9pRF+cJUcEaVOFbvl6ZN tdJMOmRduuW3OpjKxI6pQi7BQkVTSxfomEclhHeR18oeV9smGp4KM0GApgUBW1VaYInw IRHQ== X-Received: by 10.194.92.37 with SMTP id cj5mr65793601wjb.81.1418766008312; Tue, 16 Dec 2014 13:40:08 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.58]) by mx.google.com with ESMTPSA id ej10sm18445813wib.1.2014.12.16.13.40.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 13:40:07 -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::234 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:180204 Archived-At: On 12/16/2014 10:42 PM, Helmut Eller wrote: > Not everything needs to be entered by the user. The namespace part > could comes from the buffer (inferred) But what if they want to jump to a symbol defined in a different package/namespace? I would imagine that jumping to a symbol in the current package would be relatively infrequent (in one-file-per-class languages), or at least not as important (in other languages, where Imenu probably covers that). Admittedly, if the language requires all used external symbols (classes, or functions) to be declared at the top of the file, for all symbols mentioned in the current file "jump to definition" could just be based on the local name (maybe imported alias) and the name of the current unit of computation (package or class, like in Java), but that discounts all symbols that aren't referenced in the current file. I think allowing to jump to an arbitrary symbol (not just the one near point, or even in the same package) is the main goal for the identifier completion table. > and the user shouldn't be forced to type fully qualified names. Ideally, right. We want to offer the user defaults for both the package part (current), and the symbol name (symbol at point), both of which the user could override conveniently. But maybe offering current.package/symbol-at-point as one default value, in one completing-read invocation, would be good enough? The benefit of a backend being able to decide to call `completing-read' twice is being able to cleanly offer these two defaults, separately. The drawback: personally, I can't really choose which part to prompt for first. The best result probably depends on whether the user is looking for a symbol (and isn't sure about the package), or knows the package and wants to explore the symbols it it. If we're completing both a the same time, the user can choose which part to edit, with completion. I'm not sure, though, if the backend would be able to actually filter completions for the first part (package) based on the text of the second part (symbol name) thus far entered. But that's an implementation detail. To recount, here are arguments in favor of having identifier completion table as a part of the backend API, from the older discussion: - Partial-completion style will let you complete "js.fo" to anything that matches "js*.fo*". - It means the UI can use it for various kinds of completion (e.g. for completion-at-point-function). - ...the general rule that the backend should not do UI tasks and prompting is definitely a UI operation.