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:58:56 +0200 Message-ID: <5689C3D0.1050708@yandex.ru> References: <5688AD13.7050904@yandex.ru> <5689C0CA.7050005@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 1451869151 7351 80.91.229.3 (4 Jan 2016 00:59:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 00:59:11 +0000 (UTC) Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 01:59:11 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 1aFtUM-0006yb-3v for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 01:59:10 +0100 Original-Received: from localhost ([::1]:43440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFtUL-0003ty-FT for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 19:59:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFtUH-0003to-Db for emacs-devel@gnu.org; Sun, 03 Jan 2016 19:59:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFtUE-0007qW-8T for emacs-devel@gnu.org; Sun, 03 Jan 2016 19:59:05 -0500 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:37276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFtUE-0007qC-25 for emacs-devel@gnu.org; Sun, 03 Jan 2016 19:59:02 -0500 Original-Received: by mail-wm0-x22c.google.com with SMTP id f206so192558161wmf.0 for ; Sun, 03 Jan 2016 16:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=7GQT/EEXWTMFxqqBKLldnFDPQRHoKcc02jQh5jsuYZw=; b=g2uGnFrIhW2EG+Ees6yMeehNwK1PWQNk/8g42Cx/0B6wWEgjmytN+EvLbPXEXMp5Z5 olG+tLkzy9pLXm/j2pDerpfubH9dpR0TtnaHBjTyqbSeEruU/nbdMCJn/oXQCdKNOXrq f102REY2a2E7T2oPhIHC39v/iyKCUk7/pjrrQiW7DY5PbnKNmxuHQFXCYWKCeSMkSyBX a8K2S+W477GASwbQaRvQYFV8N9R724Sz7pqgHvmPBRdZjmu6+tDh6hiWx7NIMWPWoLZ2 1I/73c8lwncE01HONjdmQAPb0pSdUCZ2mXdvPMHcJqZwuU92j3Eqr9kcFKAS2oEyRljk uAkg== X-Received: by 10.194.86.71 with SMTP id n7mr87189611wjz.107.1451869139302; Sun, 03 Jan 2016 16:58:59 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id e136sm75613247wma.23.2016.01.03.16.58.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jan 2016 16:58:58 -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::22c 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:197545 Archived-At: On 01/04/2016 02:51 AM, Stefan Monnier wrote: > With things like Foo:Bar (or Foo.bar or what have you), there are indeed > conflicting definitions of "symbol" and there's usually not a single one > that works everywhere. But as a major mode author, I *do* have to pick one. That's the main choice I'm asking about. Splitting Foo::Bar into two symbols is a done decision (`::' is a scope resolution operator anyway). Still undecided whether the symbol-at-point at instance variable (@var) should include the @ sign, and whether the symbol-at-point at a Symbol literal (:symbol) should include the colon. And what to do about syntax-sugared Symbol literals (symbol: value). > IOW you can't expect Emacs's notion of "symbol" > to cover all the use cases. More specifically, Emacs's notion of symbol > can only be used as a stepping stone on which to construct the things > you need, on a case by case basis. Naturally, the use cases left suboptimal by the eventual choice would need to be handled specially.