Arroon / vimwiki

Automatically exported from code.google.com/p/vimwiki
0 stars 1 forks source link

Wiki word link within pages ( anchor) #191

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Is it possible to make WikiWord link within wiki pages
just like the link anchor. 

In HTML: 
<a name="anchor">anchor</a>

<a href="#anchor">jump to anchor</a> 

In vimwiki ,for example

in index.wiki pages:
click [[#anchor]] 
will jump to[[@anchor]]

in extennal wiki pages:
click [[index#anchor]]
will jump to [[@anchor]] in index.wiki

Original issue reported on code.google.com by cst...@gmail.com on 14 Mar 2011 at 12:57

GoogleCodeExporter commented 8 years ago
No, not yet, but it is very much needed. The most important is the ability to 
link to headings, that way one can probably avoid defining anchors.

Original comment by tpospi...@gmail.com on 14 Mar 2011 at 1:16

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I'm not a vim scripter nor do I know the language to well but I put this 
together to hopefully get someone started on this and to help with it. Syntax 
highlighting and anything else, maybe vimwiki to html; needs to be updated.

Edit: updated base.diff to support anchor links that points to anchors in the 
same file.

Original comment by coolke...@gmail.com on 16 Jan 2012 at 1:36

Attachments:

GoogleCodeExporter commented 8 years ago
OK, the most difficult bit of design here is the anchors in other wiki files. 
Vimwiki has no database backend, so the issue of efficiently maintaining some 
consistency is non-trivial. And jumping around is not a big problem while you 
are in vimwiki, the problem is the consistency of the generated HTML files.

Maybe your solution serves the purpose in your case, but it does suggest what 
to do  with the bigger problems. It would be great to know why exactly you 
benefit from this ability to define anchors in the same file: do you need to 
refer to footnotes or bibliography, or is it something else?

Concerning your code, I have one suggestion. Whatever the real use case for 
those anchors is in your case, it is very likely you would still be able to use 
them if there was the additional constraint that the anchor can be defined at 
the beginning of the line only (meaning possibly after a whitespace). This 
makes a huge difference when it comes to implementing all the other "bits" (in 
practice, it corresponds to the difference between having a reasonable and 
having a preposterously inefficient/non-scalable implementation). And if 
someone implements the whole thing with a somewhat different syntax, you will 
have  a much easier time to safely find and replace all your "old" anchors.

I am not sure that your chosen syntax for anchor is the best one, but it is 
hard to say. [[..]] is already overloaded a bit, and the anchor is not really a 
link. But what you chose is much better than picking a new symbol (that vimwiki 
would need to recognize as special). I would just say do not allow any spaces 
between [[ and @, but that is just a detail.

One harmless syntax I can think of would be to use something like a 
"placeholder" syntax (this is how it is called in docs, it is a directive, 
really) 
%anchor: Name
this way many other "extensions" to the current syntax could be defined, 
without having to modify potentially many pieces of code that currently parses 
vimwiki.

Original comment by tpospi...@gmail.com on 3 Feb 2012 at 6:05

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
yes ,using placeholder is right. 
because we don't need to define the wikiword in that anchor place.
all we want to do is to jump to an anchor.
and, can we define the in-page jump to anchor syntax simpler? 
as [[#anchor]] for example.

ps: I'm the original poster of this issue.

Original comment by rykk...@gmail.com on 4 Feb 2012 at 8:02

GoogleCodeExporter commented 8 years ago
The syntax [[#Name]] for a link to the anchor on the same page is more or less 
standard among wikis, I see no reason to choose anything else (and there does 
not seem to be anyone suggesting something else either).

Original comment by tpospi...@gmail.com on 5 Feb 2012 at 6:42