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 <domi...@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
_______________________________________________
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
