From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Thu, 11 Dec 2014 15:11:08 -0500 Message-ID: References: <20141102151524.0d9c665c@forcix> <85ppc0qf9a.fsf@stephe-leake.org> <85zjb3o09d.fsf@stephe-leake.org> <85tx1amnyg.fsf@stephe-leake.org> <85egsem1u2.fsf@stephe-leake.org> <867fy0or7p.fsf@yandex.ru> <86ppbqn841.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418328698 6725 80.91.229.3 (11 Dec 2014 20:11:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 20:11:38 +0000 (UTC) Cc: emacs-devel@gnu.org, Dmitry Gutov To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 11 21:11: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 1XzA5C-0005tv-IV for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 21:11:30 +0100 Original-Received: from localhost ([::1]:54164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzA5B-0000Ji-Ut for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 15:11:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzA50-0000IL-Us for emacs-devel@gnu.org; Thu, 11 Dec 2014 15:11:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzA4s-0004WE-4h for emacs-devel@gnu.org; Thu, 11 Dec 2014 15:11:18 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:38225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzA4s-0004Vn-0n for emacs-devel@gnu.org; Thu, 11 Dec 2014 15:11:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflTO+ILA/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQRWIxALNBIUGA0kiFPWWQEBAQEGAQEBAR6QbweESAWLAaQugXiEGSGCdwEBAQ X-IPAS-Result: AjsPAOwQflTO+ILA/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQRWIxALNBIUGA0kiFPWWQEBAQEGAQEBAR6QbweESAWLAaQugXiEGSGCdwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="100222688" Original-Received: from 206-248-130-192.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.192]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2014 15:11:08 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9A10812FD; Thu, 11 Dec 2014 15:11:08 -0500 (EST) In-Reply-To: (Helmut Eller's message of "Thu, 11 Dec 2014 19:43:15 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:179831 Archived-At: >> - If we restrict identifier to "a string or nil or t", then we can get >> rid of identifier-to-string. > Doesn't look like a great idea to me. identifier-to-string is used to > create error messages like: "No known definitions for: fooo". How would > the message look like for the t case? The message could look like "No known definition for ident at point". The use case for `t' is when the backend doesn't even know how to name the identifier at point. It just passes the whole file along with the position of point to some external program which returns the possible definitions. So there really might really be no good string representation, regardless of our API (maybe the external program could give us some kind of textual representation name for it, but then again maybe it doesn't support this functionality and maybe this description would be too long/complex). Stefan