emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Release 6.17


From: Steven E. Harris
Subject: [Orgmode] Re: Release 6.17
Date: Sun, 04 Jan 2009 15:24:20 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (windows-nt)

Carsten Dominik <address@hidden> 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?
>
>  <<name>>    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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]