headers
Carsten Dominik | 4 Jan 09:10

Release 6.17

Hi,

I am releasing version 6.17 of Org-mode.

Besides the footnote support discussed already extensively here,
this release also contains a new feature to make Org-mode
more usable for writing tutorials and similar documents with
code examples.  Lines in code examples can now be numbered,
and you can link to specific lines with magical highlighting
of the line when hovering the moue over the link.

Enjoy.

- Carsten

Changes in Version 6.17
=======================

Overview
=========

- Footnote support
- Line numbers and references in literal examples
- New hooks for export preprocessing
- Capture column view into a different file

Details
========

Footnote support
(Continue reading)

Permalink | Reply |
headers
Carsten Dominik | 4 Jan 09:22
Favicon

Re: Release 6.17


On Jan 4, 2009, at 9:13 AM, Carsten Dominik wrote:

> Hi,
>
> I am releasing version 6.17 of Org-mode.

[...]

> Line numbers and references in literal examples
> ------------------------------------------------

[...]

> Here is an example:
>
>  #+begin_src emacs-lisp -n -r
>  (defmacro org-unmodified (&rest body)                   ((def))
>    "Execute body without changing `buffer-modified-p'."
>    `(set-buffer-modified-p                               ((back))
>      (prog1 (buffer-modified-p) ,@body)))
>  #+end_src
>  [[Line ((def))]] contains the macro name.  Later at line  
> [[((back))]],

This did not come out right, it must be

    [[((def))][Line ((def))]] contains the macro name.  Later at line  
[[((back))]]
(Continue reading)

Permalink | Reply |
headers
Steven E. Harris | 4 Jan 15:33

Re: Release 6.17

Carsten Dominik <carsten.dominik <at> 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 <at> gnu.org
(Continue reading)

Permalink | Reply |
headers
Carsten Dominik | 4 Jan 17:01
Favicon

Re: Re: Release 6.17


On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:

> Carsten Dominik <carsten.dominik <at> 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,
(Continue reading)

Permalink | Reply |
headers
Steven E. Harris | 4 Jan 21:24

Re: Release 6.17

Carsten Dominik <dominik <at> 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.
(Continue reading)

Permalink | Reply |
headers
Carsten Dominik | 5 Jan 13:32
Favicon

Re: 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:
(Continue reading)

Permalink | Reply |
headers
Steven E. Harris | 5 Jan 14:38

Re: Release 6.17

"Steven E. Harris" <seh <at> 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 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Permalink | Reply |
headers
Eddward DeVilla | 4 Jan 21:58

Re: Re: Release 6.17

On Sun, Jan 4, 2009 at 10:01 AM, Carsten Dominik <dominik <at> science.uva.nl> wrote:
>
> On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:
>
>> Carsten Dominik <carsten.dominik <at> 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,
(Continue reading)

Permalink | Reply |
headers
David Lord | 5 Jan 12:45

Re: Re: Release 6.17

Carsten,

2009/1/4 Carsten Dominik <dominik <at> science.uva.nl>:
>
>  <<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.

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 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Permalink | Reply |
headers
Rick Moynihan | 5 Jan 13:26

Re: Re: Release 6.17

Carsten Dominik wrote:
> On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:
> 
>> Carsten Dominik <carsten.dominik <at> 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?
> 
>   <<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?

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 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Permalink | Reply |

Gmane