From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Upcoming loss of usability of Emacs source files and Emacs. Date: Sun, 28 Jun 2015 23:37:14 +0200 Message-ID: <87y4j3y0ol.fsf@gnu.org> References: <557F3C22.4060909@cs.ucla.edu> <5580D356.4050708@cs.ucla.edu> <87si9qonxb.fsf@gnu.org> <5581C29E.1030101@yandex.ru> <558D6A3D.1070706@yandex.ru> <877fqnzpno.fsf@gnu.org> <20150628192741.GA5983@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1435527456 18687 80.91.229.3 (28 Jun 2015 21:37:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 21:37:36 +0000 (UTC) Cc: Paul Eggert , rms@gnu.org, emacs-devel@gnu.org, Stefan Monnier , Dmitry Gutov , stephen@xemacs.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 28 23:37:27 2015 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 1Z9KGT-0003Qi-Uu for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2015 23:37:26 +0200 Original-Received: from localhost ([::1]:39940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9KGT-0001fY-2v for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2015 17:37:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9KGP-0001fI-UX for emacs-devel@gnu.org; Sun, 28 Jun 2015 17:37:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9KGM-0002Ed-PF for emacs-devel@gnu.org; Sun, 28 Jun 2015 17:37:21 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:56127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9KGM-0002ET-LY for emacs-devel@gnu.org; Sun, 28 Jun 2015 17:37:18 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 376FC20B2A for ; Sun, 28 Jun 2015 17:37:18 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 28 Jun 2015 17:37:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sftSHSNlcGTwFP2 DT1NVlQXF3Rk=; b=hcQAPi80jgGPq4rRlhuf7ven9uhcqrsNxvVc/dN9OaW8c3N WpdR8qUeg/c4vytIAa/Af2Lp0yFL7k2+xbPaXRrtdDet5H1dvOBl7BLn59LG+Z+o CT4SCz6pcDRZkUhMDZ10k5nxy8Wqdmq6kKyZY+BjxpUEuKM/ccD+o7JnNd3Y= X-Sasl-enc: Z370fScwFmEJxRr4Y5p2HYXqVlzsOr1JUozguYQlytKa 1435527437 Original-Received: from thinkpad-t440p (unknown [2.160.147.237]) by mail.messagingengine.com (Postfix) with ESMTPA id 3F1FB6800DA; Sun, 28 Jun 2015 17:37:16 -0400 (EDT) Mail-Followup-To: Alan Mackenzie , emacs-devel@gnu.org, stephen@xemacs.org, Paul Eggert , Stefan Monnier , rms@gnu.org, Dmitry Gutov In-Reply-To: <20150628192741.GA5983@acm.fritz.box> (Alan Mackenzie's message of "Sun, 28 Jun 2015 19:27:41 +0000") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.27 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:187628 Archived-At: Alan Mackenzie writes: Hi Alan, >> After this discussion, I'm now pretty much indifferent on these >> changes and if they should apply to display only or also to actual >> source code. But if the main problem with `foo' is its ambiguity, >> and =E2=80=98foo=E2=80=99 is still ambiguous (but less so), why not use = something >> which is even less ambiguous? > > Because it might not be typeable, and it might not be displayable. With typing aids like electric-quote-mode any obscure quote/markup characters could be typeable. >> For example, I've seen uses of =E2=B8=A2foo=E2=B8=A5 for marking up sour= ce code >> snippets. That seems pretty unambiguous (although you can never be >> sure), .... > > Whatever those quoting characters might be, they display on my > terminal as inverted question marks. I haven't a clue what they might > be, and it would be a lot of work to find out. They don't need to be displayed as such. For example, they could be displayed with special faces with fallbacks for font-lock disabled/missing terminal capabilities, etc. The aim of the procedure is to be able to unambiguously refer to functions/variables and write code snippets in docstrings. Right now, this is all done using `...' and in some cases, that doesn't work too well because at least ` is not too uncommon to be part of snippets, too. So then we might use =E2=80=98...=E2=80=99 which is less ambiguous. =E2=B8= =A2...=E2=B8=A5 is completely unambiguous with respect to what we currently have. But the issue of how special parts of docstrings are enclosed is only one kind of ambiguity we have. For example, it would be very useful to be able to refer to foo-mode the function and not the variable. And my bar-mode global bar-method variable could have a possible value insert-char (the symbol, not the function). >> BTW: On a related note: I don't get why *Help* buffers display quotes >> at all when they are already displayed with a face that makes them >> distinguishable from "normal" text and are clickable. > > Help buffers traditionally display verbatim the text from the source > file (with the exception of explicit directives such as to display > bindings). The face might not always be distinguishable from normal > text (e.g. font-lock might be disabled). Anyhow, displaying the > quotes doesn't do any harm. No, and probably omitting them would break docstrings with ASCII tables which assume that a cell with `foo' is displayed 5 chars wide. Bye, Tassilo