|
»
« Return to Thread: New Link Format?
Re: New Link Format?
by Steve Litt
::
Rate this Message:
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
> 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
« Return to Thread: New Link Format?
| Free embeddable forum powered by Nabble | Forum Help |
