From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: Release 6.17 Date: Mon, 5 Jan 2009 13:32:41 +0100 Message-ID: <6D49AF80-79F0-4C96-A0BF-A5BF2A9A9AB2@uva.nl> References: <1AD01E3D-3A98-4811-A7A1-0491189CE5C0@uva.nl> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJodU-00063X-6P for emacs-orgmode@gnu.org; Mon, 05 Jan 2009 07:32:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJodS-00063L-Li for emacs-orgmode@gnu.org; Mon, 05 Jan 2009 07:32:46 -0500 Received: from [199.232.76.173] (port=52126 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJodS-00063I-Fh for emacs-orgmode@gnu.org; Mon, 05 Jan 2009 07:32:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]:35426) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJodR-0008E6-WC for emacs-orgmode@gnu.org; Mon, 05 Jan 2009 07:32:46 -0500 Received: by ug-out-1314.google.com with SMTP id 36so2046722uga.17 for ; Mon, 05 Jan 2009 04:32:44 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Steven E. Harris" Cc: emacs-orgmode@gnu.org Hi Steven, thank you for your thoughtful post and everyone else for chiming in with useful suggestions. I have just uploaded 6.17a which revamps the codeline references stuff, in the following way: 1. The default label now looks like (ref:name) 2. The default format is defined in org-coderef-label-format, with the default value "(ref:%s)". 3. You can change the format for each individual snippet with the -l switch: #+BEGIN_SRC pascal -n -r -l "((%s))" 4. Links to the labels have also changed, they are now [[(name)]] or [[(name)][in line (name)]] instead of [[((name))]] or [[((name))][in line ((name))]] i.e. only single parenthesis around the label name. 5. For technical reasons, there are currently some restrictions to what you can use as label format: - Do not use the character special in HTML: `<', `>', and `&'. - Use something that will not be split up into sections with different fonts by font-lock/htmlize. For example, in pascal-mode, "{{%s}}" will not work (I know nothing of Pascal, was just something I tried). The reason for both restrictions is that the current implementation looks for the labels only *after* htmlize has done its work on the example. Clearly it would be good to change this, but it is non-trivial and I won't do it until I see that it is really necessary. Let's see how ar we get with this. - Carsten On Jan 4, 2009, at 9:24 PM, Steven E. Harris wrote: > Carsten Dominik writes: > >> This idea is to make this work in a heuristic way, by using something >> that is unlikely enough to occur in real code. > > And that is a tough problem, as code is usually defined as stuff that > contains all kinds of weird (and often paired) delimiters. > > [...] > >> What would be safer? >> >> <> like the other Org-mode targets? That would make sense. >> Does anyone know a language where this would be used >> in real life? It would make it harder to write about >> Org-mode, though. >> >> Or do we need another option, so that, if needed, we could switch >> do a >> different syntax? > > This reminds me of the "leaning toothpick" problem with regular > expression syntax; Perl and some other languages adopted the > flexibility > to accept any "matching" delimiters (either the same character used > twice or a balancing pair) in lieu of the default '/' delimiter > character. There was the need to have the delimiters be able to "get > out > of the way" of the dominant syntax within that particular regular > expression. Here, too, I expect that we'd either need to define > language-specific escape hatches, or stop guessing and force the > user to > define the active delimiters. > > What if the user could specify before each code block some "dispatch > character" that then had to be followed by a more telling string, such > as "#line:def". In that example, the octothorpe is the dispatch > character, the "line:" is the belt-and-suspenders clarifying tag, and > the "def" is the named label for that line. Force it to be at the > end of > the line (perhaps modulo trailing space), as there should only be one > definition per line. > > A regular expression match would look for > > #line:([^)]+)\s*$ > ^ > | > + (not fixed) > > except that the dispatch character would need to be composed in and > regex-quoted appropriately. Also, that one would tolerate anything > but a > closing parenthesis in a label; it could be more restrictive to > tolerate > something more commonly expected of an identifier such as > alphanumerics, > dashes, and underscores. > > You could punt even further and just demand that the user provide a > suitable regex for finding the line labels unambiguously. I'm just > leery > of trying to pick a default that's expected to work not just within > natural language, but within program source code. > > -- > Steven E. Harris > > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode