Re: Re: Release 6.17

[Carsten Dominik <dominik@science.uva.nl>]

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 <dominik@science.uva.nl> 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
>
>
>
> _______________________________________________
> 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