New Link Format?

[Noel Henson]

Just a (repeated) thought about a net link format inter-outline linking.  
The idea is to replace the current _tag_filename link with something
a little more flexible and simpler. It would also encompass the _exe_ tag.

The idea would be to include a tags file creator written in vim-script that
could be executed at any time to refresh the local tags file.

I was thinking that something like this would work well:

[filename.otl] - for just a link to a file
[filename.otl:125] - for a link to a line number in a file
[filename.otl:Project 1] - for a link to a heading (regex) in a file
[exe filename parameterlist] - to execute an external command
[x filename parameterlist] - better way to execute an external command?

Or, <> could be used as delimiters instead of []. For that matter even {}
could be used.

Another way to do it would be to have implicit links. These would just be
words with certain preset and user-settable suffixes. They could look
something like this:

filename.otl
filename.otl:125
filename.otl:Project 1

But executable files would not be supported.

So, what are your thoughts?

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Steve Litt]

On Saturday 26 September 2009 16:57:26 Noel Henson wrote:

> Just a (repeated) thought about a net link format inter-outline linking.
> The idea is to replace the current _tag_filename link with something
> a little more flexible and simpler. It would also encompass the _exe_ tag.
>
> The idea would be to include a tags file creator written in vim-script that
> could be executed at any time to refresh the local tags file.
>
> I was thinking that something like this would work well:
>
> [filename.otl] - for just a link to a file
> [filename.otl:125] - for a link to a line number in a file
> [filename.otl:Project 1] - for a link to a heading (regex) in a file
> [exe filename parameterlist] - to execute an external command
> [x filename parameterlist] - better way to execute an external command?

I see some benefit in some of these, but the format itself doesn't appeal to
me. Starting with executable lines, [exe] is the same number of keystrokes as
_exe_, so why bother. Also, a huge benefit of _exe_ is that it's searchable
with a simple, non-regex pattern. No need to worry about greedy matching and
the like. Even [x] just isn't enough keystroke saving to change things around
and make finding executable lines more difficult. I'd vote to leave executable
lines exactly how they are.

Interoutline links are something different. Their current and historical 2 line
syntax was based on the need to interoperate with ctags, and even then was
unnecessary. It seemed like a good idea at the time (2003), but that time is
gone. It's a hassle and needs to change. I don't like the [] for the reason
stated above -- difficult searching. Once again I'd recommend a simple tag like
_lnk_ combined with a filename, colon, and line number or search term. Like
_exe_, I think it's fair to require the rest of the line be assumed devoted to
the link.

Whatever we do, we can't immediately discontinue the 2 line _tag_ syntax,
because there are probably thousands or tens of thousands of outlines using
that, some of which are by people not on this list, and we don't want them to
break. I'd suggest deprecating them now, and discontinuing them in 2 to 3
years. Obviously the new 1 link syntax cannot use _tag_, but instead must use
something like _lnk_ or even (ugh) [filename].

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Saturday 26 September 2009, Steve Litt wrote:
> On Saturday 26 September 2009 16:57:26 Noel Henson wrote:
>
> I see some benefit in some of these, but the format itself doesn't
> appeal to me. Starting with executable lines, [exe] is the same number
> of keystrokes as _exe_, so why bother. Also, a huge benefit of _exe_ is
> that it's searchable with a simple, non-regex pattern. No need to worry
> about greedy matching and the like. Even [x] just isn't enough keystroke
> saving to change things around and make finding executable lines more
> difficult. I'd vote to leave executable lines exactly how they are.

I don't understand the trouble with regex searching. '/\[exe' works just
fine. And it won't be done too often. I believe it would be one of those
activities that occurs infrequently.

>
> Interoutline links are something different. Their current and historical
> 2 line syntax was based on the need to interoperate with ctags, and even
> then was unnecessary. It seemed like a good idea at the time (2003), but
> that time is gone. It's a hassle and needs to change. I don't like the
> [] for the reason stated above -- difficult searching. Once again I'd
> recommend a simple tag like _lnk_ combined with a filename, colon, and
> line number or search term. Like _exe_, I think it's fair to require the
> rest of the line be assumed devoted to the link.
>
> Whatever we do, we can't immediately discontinue the 2 line _tag_
> syntax, because there are probably thousands or tens of thousands of
> outlines using that, some of which are by people not on this list, and
> we don't want them to break. I'd suggest deprecating them now, and
> discontinuing them in 2 to 3 years. Obviously the new 1 link syntax
> cannot use _tag_, but instead must use something like _lnk_ or even
> (ugh) [filename].
>

They should be deprecated and still supported in 0.4. But the reasons for
a new link (and possibly executable) syntax is that it would be a single
line that is obviously a link. The delimiters are no real problem to
process. I do this in otl2html.py without issue.

Just my thoughts.

Noel


--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[David J Patrick-2]

Noel Henson wrote:
> Just a (repeated) thought about a net link format inter-outline linking.  
> The idea is to replace the current _tag_filename link with something
> a little more flexible and simpler. It would also encompass the _exe_ tag.

I'd really like to see;
(copied from)
http://www.maplefish.com/todd/aft-refman.html#Targets and References
because
a) I think it's comprehensive, simple and well thought out, and
b) I use otl2aft.awk, and this would make for seamless transformation to
print and html,  for me, at least ;-)

Targets and References

HyperText is supported for HTML and References are supported for printed
output such as LaTeX. Both use the same command sequences.
Targets

Targets are anchor points in a document, often referenced by References.
Targets take the form:

=[text]=

or

=[(text)]=

The difference being that the former inserts the text at the point of
the target while the latter (with parenthesis), provides just a
reference point without inserting the text.

The text is used by References.

Here are a couple of examples:

=[Does your dog bite?]=  No, my dog doesn't bite.

=[(Ow, he bit me!)]= That... is not my dog.

produces

Does your dog bite? No, my dog doesn't bite.

   That... is not my dog.
References

A reference takes one of three forms:

Form #1 [text]
Form #2 [text (reference_text)]
Form #3 [text (url:reference_text)] or [text (:reference_text)]

where text references target, unless specific reference_text is is
supplied (and in that case, reference_text refers to target.

The first form (#1) is the simplest. It refers to a target in the same
document file. The second form (#2) allows arbitrary text to be used.
The third form (#3) allows arbitrary text to refer to outside URLs. url
may be ftp, http, https, mailto just omit it (leaving the ':') for
relative http references. If you want to embed URLs directly into your
document, you can dispose of the brackets altogether. (See URL Targets).

Here we refer to targets set up in Targets:

  [Ask about the dog (Does your dog bite?)]!

  [Ow, he bit me!]

See [how to avoid dog bites (http://www.hsus.org/ace/11858)].

produces

Ask about the dog!

Ow, he bit me!

See how to avoid dog bites.

But, what if you want to include plain old bracketed text like [Coram97]
that isn't a link? You can break the bracketed text into two lines:

  [Coram97
  ]

but that many introduce unwanted space after 97 (i.e. [Coram97 ]).

So, you probably want to escape the bracket with a backslash \ :

\[not a link nor does it have any unwanted spaces]

Because, this is [not a link nor does it have any unwanted spaces].
URL Targets

If you want to just want to supply plain old URL targets, you don't need
to use any special markup. You just type in the address. AFT doesn't
recognize sophisticated URL naming when using this feature. You need to
keep it simple (e.g. URLs containing parens or complex http parameters
should be avoided).

For example:

  * http://www.maplefish.com/todd is my home page.
  * (http://www.maplefish.com/todd)

produces

     * http://www.maplefish.com/todd is my home page.
     * (http://www.maplefish.com/todd)
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Saturday 26 September 2009, David J Patrick wrote:

> Noel Henson wrote:
> > Just a (repeated) thought about a net link format inter-outline
> > linking. The idea is to replace the current _tag_filename link with
> > something a little more flexible and simpler. It would also encompass
> > the _exe_ tag.
>
> I'd really like to see;
> (copied from)
> http://www.maplefish.com/todd/aft-refman.html#Targets and References
> because
> a) I think it's comprehensive, simple and well thought out, and
> b) I use otl2aft.awk, and this would make for seamless transformation to
> print and html,  for me, at least ;-)
>
> Targets and References
>
> HyperText is supported for HTML and References are supported for printed
> output such as LaTeX. Both use the same command sequences.
> Targets
>
> Targets are anchor points in a document, often referenced by References.
> Targets take the form:
>
> =[text]=
>
> or
>
> =[(text)]=
>
> The difference being that the former inserts the text at the point of
> the target while the latter (with parenthesis), provides just a
> reference point without inserting the text.
>
> The text is used by References.
>
> Here are a couple of examples:
>
> =[Does your dog bite?]=  No, my dog doesn't bite.
>
> =[(Ow, he bit me!)]= That... is not my dog.
>
> produces
>
> Does your dog bite? No, my dog doesn't bite.
>
>    That... is not my dog.
> References
>
> A reference takes one of three forms:
>
> Form #1 [text]
> Form #2 [text (reference_text)]
> Form #3 [text (url:reference_text)] or [text (:reference_text)]
>
> where text references target, unless specific reference_text is is
> supplied (and in that case, reference_text refers to target.
>
> The first form (#1) is the simplest. It refers to a target in the same
> document file. The second form (#2) allows arbitrary text to be used.
> The third form (#3) allows arbitrary text to refer to outside URLs. url
> may be ftp, http, https, mailto just omit it (leaving the ':') for
> relative http references. If you want to embed URLs directly into your
> document, you can dispose of the brackets altogether. (See URL Targets).
>
> Here we refer to targets set up in Targets:
>
>   [Ask about the dog (Does your dog bite?)]!
>
>   [Ow, he bit me!]
>
> See [how to avoid dog bites (http://www.hsus.org/ace/11858)].
>
> produces
>
> Ask about the dog!
>
> Ow, he bit me!
>
> See how to avoid dog bites.
>
> But, what if you want to include plain old bracketed text like [Coram97]
> that isn't a link? You can break the bracketed text into two lines:
>
>   [Coram97
>   ]
>
> but that many introduce unwanted space after 97 (i.e. [Coram97 ]).
>
> So, you probably want to escape the bracket with a backslash \ :
>
> \[not a link nor does it have any unwanted spaces]
>
> Because, this is [not a link nor does it have any unwanted spaces].
> URL Targets
>
> If you want to just want to supply plain old URL targets, you don't need
> to use any special markup. You just type in the address. AFT doesn't
> recognize sophisticated URL naming when using this feature. You need to
> keep it simple (e.g. URLs containing parens or complex http parameters
> should be avoided).
>
> For example:
>
>   * http://www.maplefish.com/todd is my home page.
>   * (http://www.maplefish.com/todd)
>
> produces
>
>      * http://www.maplefish.com/todd is my home page.
>      * (http://www.maplefish.com/todd)

David,

I see what you mean. I use a different but similar method in otl2html.py.  
I used freetext though I can't seem to find a link to it anymore. Clearly
one can implement which ever they want as the additional syntax is most
likely to be handled by a postprocessor of the user's choice.

The real problem I'd like to resolve is a simpler inter-outline link
format. Steve's original solution works: _tag_rest of the line. But it has
it's issues: only one tag per line, regex phrases that create an atomic tag
can be complicated or impossible (for multiple tags per line), syntax
highlighting can be difficult because of the lack of atomicity. I'd like to
use the [] delimiters that otl2html.py uses for obvious reasons. But I'm
open to other delimiter pairs. Perhaps AFT offers some examples. I'll look
into it more.

[...time passes...]

AFT does indeed have some cool ways to tag and specify blocks of different
types. Though cool, I believe that these features should be left up to the
user and their postprocessor, in this case, AFT.

I have fired-off an email to Todd (AFT creator) to see if he would like
references to AFT in the VO documentation and possibly have a VO command
and menu entry to invoke it.

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[David J Patrick-2]

Noel Henson wrote:
> On Saturday 26 September 2009, David J Patrick wrote:
>> I'd really like to see;
>> (copied from)
>> http://www.maplefish.com/todd/aft-refman.html#Targets and References
>> because
>> a) I think it's comprehensive, simple and well thought out, and
>> b) I use otl2aft.awk, and this would make for seamless transformation to
>> print and html,  for me, at least ;-)

[snip]
>
> David,
>
> I see what you mean. I use a different but similar method in otl2html.py.  
> I used freetext though I can't seem to find a link to it anymore. Clearly
> one can implement which ever they want as the additional syntax is most
> likely to be handled by a postprocessor of the user's choice.
so true, and my choice is aft. I've tested and fiddles with all sorts of
things, and have been wiki gardener more than I'd care to admit, and aft
stands above the rest for a few reasons;

1) It is the lightest and most forgiving markup I know of

2) it is the only markup/postprocessor package (that I know of) that is
designed for multiple output formats. It may not be the most glorious
output, but I will happily convert to .tex .rtf .lout .html and can be
coerced to output almost anything, really, if you're good at that sort
of thing. We are presently enhancing the LaTeX output in-house.

3) it's in active development (after a 5 year rest)

4) a working conversion tool from VO exists.

5) is is a good compromise between comprehensive and over-complicated,
offering sections/headers/levels, links and targets, image support, font
faces, list styles, footnotes, tables, paragraphs and pages and
generates a pretty good Table of Contents, effectively a superset of
vimoutliner.
>
> The real problem I'd like to resolve is a simpler inter-outline link
> format. Steve's original solution works: _tag_rest of the line. But it has
> it's issues:
I haven't given that code much of a workout, but I agree that it's
important functionality. I don't know if it would actually work in aft
(yet) but if it did, the format would be
[textforlink(file:otheroutline.otl:target)]

ok, this is ONE thing that aft doesn't do yet, but I bet Todd would
consider making it so.


> [...time passes...]
>
> AFT does indeed have some cool ways to tag and specify blocks of different
> types. Though cool, I believe that these features should be left up to the
> user and their postprocessor, in this case, AFT.

if there's a better post-processing solution, tell me, and if it has to
be "invented here" then I'll work around whatever you come up with, but
if we want to go directly to a rich superset of features in a mature
package, we could do that too, by simply turning to the aft
documentation as syntax reference.
>
> I have fired-off an email to Todd (AFT creator) to see if he would like
> references to AFT in the VO documentation and possibly have a VO command
> and menu entry to invoke it.
He's a good guy, and those are good suggestions.

I know nothing is going to please everyone, and we all have a
considerable amount invested in our current methods, but in my
oh-so-humble opinion, this could provide quite a springboard for VO,
djp
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Sunday 27 September 2009, David J Patrick wrote:

> Noel Henson wrote:
> > On Saturday 26 September 2009, David J Patrick wrote:
> >> I'd really like to see;
> >> (copied from)
> >> http://www.maplefish.com/todd/aft-refman.html#Targets and References
> >> because
> >> a) I think it's comprehensive, simple and well thought out, and
> >> b) I use otl2aft.awk, and this would make for seamless transformation
> >> to print and html,  for me, at least ;-)
>
> [snip]
>
> > David,
> >
> > I see what you mean. I use a different but similar method in
> > otl2html.py. I used freetext though I can't seem to find a link to it
> > anymore. Clearly one can implement which ever they want as the
> > additional syntax is most likely to be handled by a postprocessor of
> > the user's choice.
>
> so true, and my choice is aft. I've tested and fiddles with all sorts of
> things, and have been wiki gardener more than I'd care to admit, and aft
> stands above the rest for a few reasons;
>
> 1) It is the lightest and most forgiving markup I know of
>
> 2) it is the only markup/postprocessor package (that I know of) that is
> designed for multiple output formats. It may not be the most glorious
> output, but I will happily convert to .tex .rtf .lout .html and can be
> coerced to output almost anything, really, if you're good at that sort
> of thing. We are presently enhancing the LaTeX output in-house.
>
> 3) it's in active development (after a 5 year rest)
>
> 4) a working conversion tool from VO exists.
>
> 5) is is a good compromise between comprehensive and over-complicated,
> offering sections/headers/levels, links and targets, image support, font
> faces, list styles, footnotes, tables, paragraphs and pages and
> generates a pretty good Table of Contents, effectively a superset of
> vimoutliner.
>

Perhaps you took my meaning the wrong way. What I meant was that VO is just
the outline processor. If a user has a particular postprocessor they want
to use, they can. Some like otl2html.py. Some like otl2html.pl. Some like
AFT. These particular syntaxes that can be included in a VO document are
left up to the user. I don't think it would be proper for VO to dictate
a tool or prefer one tool over another. Also, I believe that old, old
version of AFT is the syntax that I based otl2html.py on originally.

> > The real problem I'd like to resolve is a simpler inter-outline link
> > format. Steve's original solution works: _tag_rest of the line. But it
> > has it's issues:
>
> I haven't given that code much of a workout, but I agree that it's
> important functionality. I don't know if it would actually work in aft
> (yet) but if it did, the format would be
> [textforlink(file:otheroutline.otl:target)]

From a VO standpoint, the user can do what you suggest. I would prefer
a simpler syntax for inclusion into VO as a default. That way a simple
vim-script can create the proper tags file for inter-outline linking.

>
> ok, this is ONE thing that aft doesn't do yet, but I bet Todd would
> consider making it so.
>
> > [...time passes...]
> >
> > AFT does indeed have some cool ways to tag and specify blocks of
> > different types. Though cool, I believe that these features should be
> > left up to the user and their postprocessor, in this case, AFT.
>
> if there's a better post-processing solution, tell me, and if it has to
> be "invented here" then I'll work around whatever you come up with, but
> if we want to go directly to a rich superset of features in a mature
> package, we could do that too, by simply turning to the aft
> documentation as syntax reference.

See above. I don't think that VO will ever dictate a particular method of
doing things that doesn't relate the the structure of a VO file. So freedom
still reigns.

> > I have fired-off an email to Todd (AFT creator) to see if he would
> > like references to AFT in the VO documentation and possibly have a VO
> > command and menu entry to invoke it.
>
> He's a good guy, and those are good suggestions.
>
> I know nothing is going to please everyone, and we all have a
> considerable amount invested in our current methods, but in my
> oh-so-humble opinion, this could provide quite a springboard for VO,
> djp

I have communicated with Todd. We will include some AFT support for VO much
the same way that other scripts are supported. I hope to add a menu item
and command to export a VO file through AFT.

> _______________________________________________
> VimOutliner mailing list
> VimOutliner@...
> http://www.lists.vimoutliner.org/mailman/listinfo

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Matthew Pressly]

There is a vim plugin (UTL) that also works well for inter-document linking:

http://www.vim.org/scripts/script.php?script_id=293

It supports linking between documents, linking to a specific anchor in the current file or another text file, links that search forward or backward for matching text, and linking to non-text files or web pages. It does not use or depend on tags.

Links to other files are formatted like this: <url:Absolute/Or/Relative/Path/To/File.otl>, with an optional fragment following the URL.

--
Matthew

Noel Henson wrote:

On Sunday 27 September 2009, David J Patrick wrote:
  

Noel Henson wrote:
    

On Saturday 26 September 2009, David J Patrick wrote:
      

I'd really like to see;
(copied from)
http://www.maplefish.com/todd/aft-refman.html#Targets and References
because
a) I think it's comprehensive, simple and well thought out, and
b) I use otl2aft.awk, and this would make for seamless transformation
to print and html,  for me, at least ;-)
        

[snip]

    

David,

I see what you mean. I use a different but similar method in
otl2html.py. I used freetext though I can't seem to find a link to it
anymore. Clearly one can implement which ever they want as the
additional syntax is most likely to be handled by a postprocessor of
the user's choice.
      

so true, and my choice is aft. I've tested and fiddles with all sorts of
things, and have been wiki gardener more than I'd care to admit, and aft
stands above the rest for a few reasons;

1) It is the lightest and most forgiving markup I know of

2) it is the only markup/postprocessor package (that I know of) that is
designed for multiple output formats. It may not be the most glorious
output, but I will happily convert to .tex .rtf .lout .html and can be
coerced to output almost anything, really, if you're good at that sort
of thing. We are presently enhancing the LaTeX output in-house.

3) it's in active development (after a 5 year rest)

4) a working conversion tool from VO exists.

5) is is a good compromise between comprehensive and over-complicated,
offering sections/headers/levels, links and targets, image support, font
faces, list styles, footnotes, tables, paragraphs and pages and
generates a pretty good Table of Contents, effectively a superset of
vimoutliner.

    

Perhaps you took my meaning the wrong way. What I meant was that VO is just 
the outline processor. If a user has a particular postprocessor they want 
to use, they can. Some like otl2html.py. Some like otl2html.pl. Some like 
AFT. These particular syntaxes that can be included in a VO document are 
left up to the user. I don't think it would be proper for VO to dictate 
a tool or prefer one tool over another. Also, I believe that old, old 
version of AFT is the syntax that I based otl2html.py on originally.

  

The real problem I'd like to resolve is a simpler inter-outline link
format. Steve's original solution works: _tag_rest of the line. But it
has it's issues:
      

I haven't given that code much of a workout, but I agree that it's
important functionality. I don't know if it would actually work in aft
(yet) but if it did, the format would be
[textforlink(file:otheroutline.otl:target)]
    

>From a VO standpoint, the user can do what you suggest. I would prefer 
a simpler syntax for inclusion into VO as a default. That way a simple 
vim-script can create the proper tags file for inter-outline linking.

  

ok, this is ONE thing that aft doesn't do yet, but I bet Todd would
consider making it so.

    

[...time passes...]

AFT does indeed have some cool ways to tag and specify blocks of
different types. Though cool, I believe that these features should be
left up to the user and their postprocessor, in this case, AFT.
      

if there's a better post-processing solution, tell me, and if it has to
be "invented here" then I'll work around whatever you come up with, but
if we want to go directly to a rich superset of features in a mature
package, we could do that too, by simply turning to the aft
documentation as syntax reference.
    

See above. I don't think that VO will ever dictate a particular method of 
doing things that doesn't relate the the structure of a VO file. So freedom 
still reigns.

  

I have fired-off an email to Todd (AFT creator) to see if he would
like references to AFT in the VO documentation and possibly have a VO
command and menu entry to invoke it.
      

He's a good guy, and those are good suggestions.

I know nothing is going to please everyone, and we all have a
considerable amount invested in our current methods, but in my
oh-so-humble opinion, this could provide quite a springboard for VO,
djp
    

I have communicated with Todd. We will include some AFT support for VO much 
the same way that other scripts are supported. I hope to add a menu item 
and command to export a VO file through AFT.

  

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo
    

Noel

  

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Herbert Sitz]

Matthew Pressly wrote:

There is a vim plugin (UTL) that also works well for inter-document linking:

http://www.vim.org/scripts/script.php?script_id=293

It supports linking between documents, linking to a specific anchor in
the current file or another text file, links that search forward or
backward for matching text, and linking to non-text files or web pages.
It does not use or depend on tags.

That's what I use.  Works fine, not sure why I'd want anything else.  Has everything I want:  linking, linking to line number in another file, linking to marker in another file, ability to configure for launching apps to load non-vim files.  I see no reason to reinvent the wheel.  -- Herb

[David J Patrick-2]

hsitz wrote:
>
> Matthew Pressly wrote:
>> There is a vim plugin (UTL) that also works well for inter-document
>> linking:
>>
>> http://www.vim.org/scripts/script.php?script_id=293

upon inspection, installation and experimentation, I agree.
this wheel has been invented, and I'm bolting it to my cart.
djp
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Steve Litt]

On Saturday 26 September 2009 16:57:26 Noel Henson wrote:

> Just a (repeated) thought about a net link format inter-outline linking.
> The idea is to replace the current _tag_filename link with something
> a little more flexible and simpler. It would also encompass the _exe_ tag.
>
> The idea would be to include a tags file creator written in vim-script that
> could be executed at any time to refresh the local tags file.
>
> I was thinking that something like this would work well:
>
> [filename.otl] - for just a link to a file
> [filename.otl:125] - for a link to a line number in a file
> [filename.otl:Project 1] - for a link to a heading (regex) in a file
> [exe filename parameterlist] - to execute an external command
> [x filename parameterlist] - better way to execute an external command?
>
> Or, <> could be used as delimiters instead of []. For that matter even {}
> could be used.
>
> Another way to do it would be to have implicit links. These would just be
> words with certain preset and user-settable suffixes. They could look
> something like this:
>
> filename.otl
> filename.otl:125
> filename.otl:Project 1
>
> But executable files would not be supported.
>
> So, what are your thoughts?

I think any change to executable lines is a solution seeking a problem.
Executable lines are currently simple, easily recognized by the user, and work
every time.

Obviously 2 line interoutline links are silly, ugly, and have no redeeming
value. They were the result of a two hour thought process by one person. I
originally put the linked file as a subhead because my thought was that the
link might someday have other metadata, and so it didn't stretch beyond column
80. Well, the metadata never happened, and as far as column 80, so what -- it
would only matter in a wrapping environment. And besides, now that we're doing
away with ctags, we don't have to name links, so that cuts down on line real
estate considerably.

The new Interoutline links need to be immediately obvious, from the user
viewpoint, as to what they are. They must be constructed so there's no
reasonable way someone could accidentally create one. Filenames are used as
pure data in outlines all the time, so some sort of keyword structure is
vitally necessary, and as I mentioned they must be obvious to a human at a
glance. To prevent confusion, that keyword structure must not include _tag_,
as that is the old way and future conversion scripts will need to confidently
know _tag_ represents an old link to be converted.

When changing to the new link style, I believe the behavior should not change.
Pressing Ctrl+K should still go to the linked file, and if the linked file
doesn't exist, it should still be created. This instant creation is part of
the theory of fast, realtime authoring. Pressing Ctrl+K should NOT bring up a
new instance of Vim (or else we could have used executable lines for
interoutline linking). Pressing Ctrl+N should still bring you back to the
outline from which you linked (ascent after decent).

Interoutline links should still be able to be either absolute or relative. If
they start with a slash, they're absolute and open the file on that path. If
they don't start with a slash, they open a file relative to the file from which
they link. In other words:

_tag_etc_otl
        /etc/master.otl

The preceding opens /etc/master.otl. Then /etc/master.otl could contain the
following:

_tag_fstab
        fstab.otl

In that case, because /etc/master.otl is in the /etc directory, the referred
fstab.otl would be in the /etc directory. This current behavior is extremely
convenient, and keeping it that way would continue the convenience. If this
feature goes away, mass conversion of oldstyle to newstyle links would be much
more difficult, and could only occur in reference to specific trees rather than
on a file by file basis.

As far as a syntax like [file:///data/programming/master.otl] or  
[file://master.otl] (or would that be [file:master.otl]), or the same constructs
but with <> instead of [], I see the value and think the [file or [email or
whatever is sufficiently human recognizeable. It's more keystrokes than _lnk_
/data/programming/master.otl but not obnoxiously so given that link creation
is a relatively rare activity. Personally I'd like an option to type it as
[file@/data/programming/master.otl] or [file@...]. That knocks off a
couple keystrokes and more importantly, makes it more instantaneously obvious
what's going on and eliminates problems with people leaving out a slash or
adding one too many.

If you have multiple links per line, there needs to be a way to recognize
which link you're standing over. Personally I can't forsee myself using
multiple links per line so this wouldn't be an issue for me, but it needs to
be reliable and non-confusing to reduce bug reports.

As I mentioned several times, I'll be more than happy to create mass
conversion scripts, and assuming the new method continues to respect relative
links, individual file conversion scripts. I'll do them in whatever language
the VO project thinks is best, and I could probably have them within 2 to 3
days of receiving the final link specification.

Thanks for all your hard work Noel! Thanks to the rest of you for all this
energy and input.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo