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: Thu, 11 Dec 2014 21:31:31 +0100 Message-ID: References: <20141102151524.0d9c665c@forcix> <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 1418329946 27699 80.91.229.3 (11 Dec 2014 20:32:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 20:32:26 +0000 (UTC) Cc: emacs-devel@gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 11 21:32:13 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 1XzAP9-0007Ki-H1 for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 21:32:07 +0100 Original-Received: from localhost ([::1]:54256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzAP7-0006CK-0N for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 15:32:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzAOl-0006CE-PT for emacs-devel@gnu.org; Thu, 11 Dec 2014 15:31:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzAOc-0006KK-Ou for emacs-devel@gnu.org; Thu, 11 Dec 2014 15:31:43 -0500 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:55510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzAOc-0006KF-Ia for emacs-devel@gnu.org; Thu, 11 Dec 2014 15:31:34 -0500 Original-Received: by mail-wi0-f177.google.com with SMTP id l15so494552wiw.16 for ; Thu, 11 Dec 2014 12:31:33 -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=hzJc7jZKz0Drvg0ihJ32Uo0L/tWzyD1odrJBbWPPUcg=; b=Rf70PltaJvJHFsRPb3GdQrP8zNlSeHv+jfs869q8pjICppcHxvxdHVlrX7dsVxdEHY fPlawkZD7FfWtZQu/TOecdWcyFlXAxUMHb7jMJONDJisnUXt7CIBwdBL49bjeWX/SqcS ZZFveJ37rDbCBt5cd8nzd9J3J7Lqbi8KnbiSEd5LG4GWFEBeUUXBDnQNQbNCSqhqydvO 7HEHZL8NhQdtDafZELTdJTkX/qwDdDKV4QwFCkMNx/nk6vvT17RTI5J6sN+aqxpVo0DQ Qo8gjtkf9eP5x8VtQpKBey5AmLPok4qQs4ABr+RTyNEg+Iqjh0RLwGKJDtqjk4VYzOWM er9A== X-Received: by 10.194.88.169 with SMTP id bh9mr19511161wjb.99.1418329893876; Thu, 11 Dec 2014 12:31:33 -0800 (PST) Original-Received: from ix ([212.46.172.140]) by mx.google.com with ESMTPSA id mc10sm525676wic.24.2014.12.11.12.31.32 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 11 Dec 2014 12:31:33 -0800 (PST) Original-Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1XzAOZ-0002dn-Gt; Thu, 11 Dec 2014 21:31:31 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 11 Dec 2014 15:11:08 -0500") 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:179834 Archived-At: On Thu, Dec 11 2014, Stefan Monnier wrote: >>> - 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). A identifier representation like (list (thing-at-point 'line) (current-buffer) (point)) doesn't cost anything and would go a long way to give a better error message. If thing-at-point returns nil or an empty line then identifier-at-point should just return nil. Helmut