From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: =?iso-8859-1?B?rCBub3RhdGlvbiBmb3Igbm90PyBSZWY6IEFkZCBhIGNvdXBsZQ==?= =?iso-8859-1?B?IGNlbGxzIHRvIGxpc3AtcHJldHRpZnktc3ltYm9scy1hbGlzdA==?= Date: Fri, 15 Jul 2016 09:14:13 -0700 (PDT) Message-ID: References: <578801A0.4040306@gmail.com> <87oa5zx35d.fsf@udel.edu> <87d1mfuh05.fsf@lifelogs.com> <87zipjszm7.fsf_-_@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1468599862 2661 80.91.229.3 (15 Jul 2016 16:24:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 16:24:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 15 18:24:05 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 1bO5uH-0007z2-2o for ged-emacs-devel@m.gmane.org; Fri, 15 Jul 2016 18:24:05 +0200 Original-Received: from localhost ([::1]:33679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO5uG-0001nA-Go for ged-emacs-devel@m.gmane.org; Fri, 15 Jul 2016 12:24:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO5ku-0002AG-Ko for emacs-devel@gnu.org; Fri, 15 Jul 2016 12:14:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO5kn-0000kv-Fc for emacs-devel@gnu.org; Fri, 15 Jul 2016 12:14:23 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO5kn-0000ke-5Q for emacs-devel@gnu.org; Fri, 15 Jul 2016 12:14:17 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6FGEFtR026046 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Jul 2016 16:14:16 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u6FGEF4I032684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Jul 2016 16:14:15 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6FGEEhc003137 for ; Fri, 15 Jul 2016 16:14:14 GMT In-Reply-To: <87zipjszm7.fsf_-_@lifelogs.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:205731 Archived-At: > DA> E.g., ensure that "=AC" does not name a symbol that has a > DA> function or variable value. If `=AC' is already bound to some > DA> function or variable then you probably do not want to alias > DA> function `not' to it. >=20 > That's not really related to my question about customizations, Irrelevant. This is a thread about showing "=AC notation for not?" (and similar), a thread started by that question from Cl=E9ment. My comment is about one consideration for such a proposed feature. My point is separate from _your_ question, but there is no reason to fork discussion off my point off from Cl=E9ment's proposed feature, with which it is concerned. I restored the Subject line. > and there is no aliasing going on in any case. The user will see =AC > in both cases, but they will be different underneath. Yes, of course. It is not aliasing of symbol values (function or variable). It is, as you say, a "visual clobbering". Visual name capture. > DA> Emacs allows most characters in function and variable names. > DA> Just because `prettify-symbols-alist' might have an entry for > DA> a given string, that does not mean that the user wants to > DA> clobber any existing function or variable that has that name. >=20 > It's a visual clobbering, but yeah, I know what you mean. Typically > users will not have such functions or variables, but it would be good to > distinguish them in a way that makes their ephemeral nature clear. Right > now they aren't. There is nothing inherently ephemeral in the nature of such functions or variables. This is not limited to any particular function or variable (e.g. `not'). Any function or variable could appear in `lisp-prettify-symbols-alist', and it could be associated with any prettifying string. The possibility of a visual name capture needs to be considered before this feature is rolled out.