Re: Emacs-orgmode Digest, Vol 35, Issue 7

Re: Emacs-orgmode Digest, Vol 35, Issue 7

[Robert Goldman]

    Carsten> On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:
    >> > Carsten Dominik <carsten.dominik@gmail.com> writes: >
    >>> >> Code references use special labels embedded directly into the
source
    >>> >> code.  Such labels look like "((name))" and must be unique
within a
    >>> >> document.
    >> > > How does the parser know that, say, "((def))" is not a valid >
    >> expression > in the surrounding Lisp forms? Is it important that
it be
    >> separated by > space, or be the last token on the line?  > >
Trying to
    >> concoct a motivating example, consider a structure > represented > as
    >> nested lists: > > ,---- > | '(a > | ((b c) d) > | (((e) f))
((def)) > |
    >> g) > `---- > > Without knowing what the enclosing `quote' form
means, how
    >> do know > that > "((def))" is not part of it?

    Carsten> Hi Steven,

    Carsten> good question, and the answer is that is does not know, cannot
    Carsten> know, because this is a feature that is supposed to work
for any
    Carsten> kind of example, an the parser cannot know all possible
syntaxes
    Carsten> :-)

    Carsten> This idea is to make this work in a heuristic way, by using
    Carsten> something that is unlikely enough to occur in real code.

    Carsten> You are right that what I am using might be too dangerous
for emacs
    Carsten> lisp or other lisp dialects, and it could also show up in other
    Carsten> languages like C.

    Carsten> What would be safer?

    Carsten>   <<name>> like the other Org-mode targets?  That would
make sense.
    Carsten> Does anyone know a language where this would be used in
real life?
    Carsten> It would make it harder to write about Org-mode, though.

    Carsten> Or do we need another option, so that, if needed, we could
switch
    Carsten> do a different syntax?

    Carsten> Comments are very welcome.

Would it be possible to adopt an approach like that used in Latex
verbatim mode, where one could introduce a new delimeter for use in the
block in question (perhaps with default being << and >>)?