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: Guidelines for the "symbol" syntax class Date: Mon, 4 Jan 2016 02:46:02 +0200 Message-ID: <5689C0CA.7050005@yandex.ru> References: <5688AD13.7050904@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 1451868388 29418 80.91.229.3 (4 Jan 2016 00:46:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 00:46:28 +0000 (UTC) To: emacs-devel , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 01:46:27 2016 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 1aFtI2-0003g9-A2 for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 01:46:26 +0100 Original-Received: from localhost ([::1]:43410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFtI1-0006sH-JL for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 19:46:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFtHo-0006rz-Cx for emacs-devel@gnu.org; Sun, 03 Jan 2016 19:46:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFtHh-00057n-Rz for emacs-devel@gnu.org; Sun, 03 Jan 2016 19:46:12 -0500 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:37497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFtHh-00057j-MD for emacs-devel@gnu.org; Sun, 03 Jan 2016 19:46:05 -0500 Original-Received: by mail-wm0-x22b.google.com with SMTP id f206so192360626wmf.0 for ; Sun, 03 Jan 2016 16:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=oUv0Tk5i0P8vB9qYevH4Z9Qj6pR21wP1hKEBszZBx5w=; b=Oo9XidGqvdNu1u5VfEXYTSDT8CkeMjBGETj/QjjtxnJMvm+vDGahhi0E4pGjn2YXoe 2fJWYb5pFj82QjWePwgIJw0sCA3+s7//55WrohVWFrfSRWvWESY4o5vyWnNhWXkpzrZQ iBaY+plgT5cDJx0cvVyRr4K/T9Ye3DsEmYXILmUdyqSYZSudEMimLKdvNSeRb+P8PkDC 6ztOOea39/3QyrOoevcAqU8S1Rz8How330MztUzo+G/g1zr4nAgvbd3HguWm2lUwpweq sJodQfbE6U2DyqlsxU3vXG34UHLjsUB6e72UK9VwDUCM7ULXi2S1G++Ke3O56BR/fEEq EAZA== X-Received: by 10.194.23.70 with SMTP id k6mr476498wjf.54.1451868365084; Sun, 03 Jan 2016 16:46:05 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id cv10sm33151578wjb.17.2016.01.03.16.46.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jan 2016 16:46:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22b 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:197539 Archived-At: On 01/04/2016 12:56 AM, John Wiegley wrote: > Does removing ':' from the symbol class for ruby solve all of your problems, > and create no new ones? :) I wish. With fewer (hopefully none) false negatives returned by xref-collect-references, there will come more false positive matches. One false negative comes to mind: if `:' is not a symbol constituent, and the user searches for all references to `:foo', using the current implementation, they will get none. The default input suggested by xref-find-references will be `foo', though (when point is on `:foo'). In completion, if we continue to simply collect all symbols from all buffers, the user will start typing a method name , try completion and will get offered the names of all method and Symbols they ever typed anywhere, in the code. While Symbols are used to refer to method names, they're also used for method keyword arguments (in Ruby 2.0+), and you even often see them in business logic. For instance, in most web applications there will be Symbols :username, :password, :account_id, and so on, referring to the HTTP request parameters. So, there will be a lot of false positives here as well. I don't know how to fight that, except by using a smarter program, one that loads the application and/or parses the code, etc, but there will always be some use cases that are not handled by "smart" logic already written, and being able to write a quick-and-simple solution is often handy. Further, I'm sure there are a lot of third-party packages out there, some of them language-agnostic, which deal with source code and use the notion of a symbol. One example that I do use is `easy-kill'. If my cursor is at the end of a Symbol :foo, currently calling this command will select `:foo', including the colon, which is handy to be able to copy and paste, or kill, that value as a whole. If `:' is no longer a symbol constituent, either I'll have to live with always additionally typing or deleting these colons in that kind of situations, or will have to provide the "boundary of thing" info to easy-kill additionally somehow. That's why I'm asking if there are any existing guidelines, formal or informal, that I can take into consideration. That might also inform changes to xref-collection-references and company-dabbrev-code; not just ruby-mode. Would anyone care for another wall of text?