From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.devel Subject: Re: Raw strings (experimental patches inside) Date: Mon, 06 Aug 2012 12:55:56 +0200 Organization: Informatimago Message-ID: <871ujkthkz.fsf@kuiper.lan.informatimago.com> References: <87wr1gux4f.fsf@kuiper.lan.informatimago.com> <87lihutpfw.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344250583 30921 80.91.229.3 (6 Aug 2012 10:56:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Aug 2012 10:56:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 06 12:56:22 2012 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 1SyKyv-0005AI-Hx for ged-emacs-devel@m.gmane.org; Mon, 06 Aug 2012 12:56:17 +0200 Original-Received: from localhost ([::1]:51290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyKyu-0007a0-SZ for ged-emacs-devel@m.gmane.org; Mon, 06 Aug 2012 06:56:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyKyr-0007Zv-TI for emacs-devel@gnu.org; Mon, 06 Aug 2012 06:56:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyKyq-0000l2-LN for emacs-devel@gnu.org; Mon, 06 Aug 2012 06:56:13 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:58739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyKyq-0000kx-Dq for emacs-devel@gnu.org; Mon, 06 Aug 2012 06:56:12 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SyKyo-000533-C2 for emacs-devel@gnu.org; Mon, 06 Aug 2012 12:56:10 +0200 Original-Received: from 81.202.16.46.dyn.user.ono.com ([81.202.16.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Aug 2012 12:56:10 +0200 Original-Received: from pjb by 81.202.16.46.dyn.user.ono.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Aug 2012 12:56:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 81.202.16.46.dyn.user.ono.com Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:NmUyM2UyNGRjYTIwNDRiOTc1NTI4OGM1YTZjOTRmZjk3N2E3NTBiYQ== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:152214 Archived-At: Stefan Monnier writes: >> I have a CL reader, written in CL. One could port it to emacs-24 easily >> enough I'd say. It's AGPL3, I wouldn't mind assigning the copyright of >> a derived work of it to the FSF for inclusion in emacs. > > I think the problem is to get emacs-lisp-mode to understand it. Indeed, CL reader macros are a problem for editors. But the only practical solution involves having the CL reader (and thus the whole CL language) implemented in the editor. Therefore including emacs-cl would indeed be more indicated (bar a rewrite of emacs in Common Lisp). In general, you need to be able to read the reader macro to know where it starts and where it ends. Reading is recursive, and reading a reader macro may involve reading other embedded reader macros, thus you can obtain a tree of ranges. For indenting, we need in general more information, but this could be provided by a table mapping reader macros and indenting rules. To give a taste of the problem, here is an example of the kind of Common Lisp code I'm working with now: (with-handle (viewh view) [viewh setNeedsDisplayInRect:(nsrect #@(10 10) #@(200 100))]) Here, we have: - one standard CL reader macro for #\( - one non standardreader macro for #\[ - one non standard dispatching reader macro for #\# #\@. The syntax of the text inside [] is complex, similar to Objective-C, and we would like to have Objective-C-like font-locking and indenting, but the parts in parentheses in this reader macro are actually read by the standard CL reader macro for #\(, and here we want the normal Common Lisp font-locking and indenting. The dispatching reader macro for #\# #\@ here is a usual example of CL reader macros, where the syntax following it is read with the standard CL lisp reader (contrarily to what's read by the #\[ reader macro). That information however can only be learned by executing the reader macro and taking note of what reader macros are run. There are difficulties such as the fact that reader macros may seek in the stream and read some parts twice, but a conforming reader macro should not have side effects preventing its repeated use on the same text, so the editor itself can do that. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.