Re: [Orgmode] Re: Release 6.17
Carsten, 2009/1/4 Carsten Dominik domi...@science.uva.nl: namelike 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. Yes, Oracle pl/sql uses that for loop labels. You might also want to check ADA since pl/sql is based on it. -- David Lord ___ 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
Re: [Orgmode] Re: Release 6.17
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?
namelike 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
[Orgmode] Re: Release 6.17
Steven E. Harris s...@panix.com writes: Also, that one would tolerate anything but a closing parenthesis in a label; That was a mistake to propose. I had forgotten that I intended the label to run to the end of the line, not to a bounding parenthesis. So much for writing code in haste without testing it -- or thinking it through clearly. -- 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
Re: [Orgmode] Re: Release 6.17
Carsten Dominik wrote: On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote: Carsten Dominik carsten.domi...@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? Hi Steven, good question, and the answer is that is does not know, cannot know, because this is a feature that is supposed to work for any kind of example, an the parser cannot know all possible syntaxes :-) This idea is to make this work in a heuristic way, by using something that is unlikely enough to occur in real code. You are right that what I am using might be too dangerous for emacs lisp or other lisp dialects, and it could also show up in other languages like C. What would be safer? namelike 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? Is a good work around not to simply supply the marker inside an inline comment, e.g. , | '(a | ((b c) d) | (((e) f)) ;; ((def)) | g) ` The advantage to this approach is that you can keep your code executable, which is really nice if you're writing documentation and want to be able to make sure the code always runs and is never broken. This solution seems to be more sensible than supporting different link markers etc... though the def does seem more consistent. It might even be possible to link the ((def)) to the comment that describes it, so the links between code and comments are bidirectional. Just some food for thought! :-) R. ___ 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
Re: [Orgmode] Re: Release 6.17
On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote: Carsten Dominik carsten.domi...@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? Hi Steven, good question, and the answer is that is does not know, cannot know, because this is a feature that is supposed to work for any kind of example, an the parser cannot know all possible syntaxes :-) This idea is to make this work in a heuristic way, by using something that is unlikely enough to occur in real code. You are right that what I am using might be too dangerous for emacs lisp or other lisp dialects, and it could also show up in other languages like C. What would be safer? namelike 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? Comments are very welcome. - Carsten ___ 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
[Orgmode] Re: Release 6.17
Carsten Dominik carsten.domi...@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? -- 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
[Orgmode] Re: Release 6.17
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? namelike 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
Re: [Orgmode] Re: Release 6.17
On Sun, Jan 4, 2009 at 10:01 AM, Carsten Dominik domi...@science.uva.nl wrote: On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote: Carsten Dominik carsten.domi...@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? Hi Steven, good question, and the answer is that is does not know, cannot know, because this is a feature that is supposed to work for any kind of example, an the parser cannot know all possible syntaxes :-) This idea is to make this work in a heuristic way, by using something that is unlikely enough to occur in real code. You are right that what I am using might be too dangerous for emacs lisp or other lisp dialects, and it could also show up in other languages like C. What would be safer? namelike 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? Comments are very welcome. - Carsten I think that is quote words in perl 6. @list = $this is a 'list' of 7 strings # in perl 6 is @list = qw/$this is a 'list' of 7 strings/ # in perl 5. It's looking like perl 6 will be a reality and that syntax is recommend in several places like hash dereferences. %hashbareword # look up bareword in %hash I can't remember enough off the top of my head, but I think name will play merry heck with common(?) perl 6 code. I can look up more examples if needed. Edd ___ 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
Re: [Orgmode] Re: Release 6.17
On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote: [...] Without knowing what the enclosing `quote' form means, how do know that ((def)) is not part of it? Hi Steven, good question, and the answer is that is does not know, cannot know, because this is a feature that is supposed to work for any kind of example, an the parser cannot know all possible syntaxes :-) This idea is to make this work in a heuristic way, by using something that is unlikely enough to occur in real code. You are right that what I am using might be too dangerous for emacs lisp or other lisp dialects, and it could also show up in other languages like C. What would be safer? [...] Perhaps it would make sense to let the syntax vary by source language. Like, elisp could have something like ;;((def))\n and C something like /*((def))*/. Tom Breton ___ 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
Re: [Orgmode] Re: Release 6.17
I have a reply under the subject, extensible syntax. One possibility is this: if the syntax exists in a given language (fairly unlikely), then you simply escape like this: \c = c for all c (including \ itself). -- For personal gain, myalgic encephalomyelitis denialists are knowingly causing further suffering and death by grossly corrupting science. Do you care about the world? http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm ___ 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
