Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago Can you be more specific about what input syntax is generating this link?
Is this a link that you have written yourself, or one that is automatically
generated as part of the diary index?Original comment by stu.andrews on 23 Mar 2012 at 4:09
GoogleCodeExporter
commented
8 years ago This is the automatically generated link. In the main vimwiki index I have this
link:
[[diary:diary][Personal Log]]
If I delete the index.html file, then run vimwikiall2html, it regenerates the
index.html with the absolute file path link that I referenced in my initial
post.
Thanks!
Scott
Incidentally, after I run vimwikiall2html, vimwiki stops working until I exit
the current file and re-open it.Original comment by firecat4...@gmail.com on 23 Mar 2012 at 4:11
GoogleCodeExporter
commented
8 years ago Ok, so the links contained in the automatically generated diary index are okay.
However, the link:
[[diary:diary][Personal Log]]
converts to a universal file:///... link rather than a relative link.
This issue relates to ongoing discussions about the behavior of interwiki
links. Please see the wiki page:
http://code.google.com/p/vimwiki/wiki/MultiWikiModel
@Tomas, Maxim: Should we convert all diary:-scheme links into relative links?
If so, please check the following logic for accomplishing this ...
If the example link above appears on wiki/subwiki/Page.wiki, then the
appropriate prefix is:
"../" . diary_rel_path
And likewise, if it appears on wiki/subwiki/subsubwiki/Page.wiki, then the
appropriate prefix is:
"../../" . diary_rel_path
Programmatically, this could be achieved in resolve_scheme() using something
like:
substitute(subdir . '/', '[^/\.]\+/', '../', 'g') . diary_rel_path
Original comment by stu.andrews on 23 Mar 2012 at 10:51
GoogleCodeExporter
commented
8 years ago Yes, the links inside the same wiki should be relative (in HTML), even in the
current model. The problem with the current model of many wikis is that this is
difficult to extend to interwiki links. This also means that in the current
model, one has to decide whether from wiki5, the link to wiki5:... should be
relative in HTML (consistent with no scheme), or absolute (consistent with
wiki#:...). In other words, it is not going to be very consistent anyway.
Similarly with diary:... But for the time being, it would be better to do the
first (consistent with no scheme).
I see no reason to predefine diary: and wiki: (which is the same as "no scheme"
now?), they are not necessary. Later (much later, when basic things work
reliably), one could implement custom schemes (and diary:.. will be a special
case for those that want it; it has some practical use only for people who have
a deep hierarchy inside a wiki anyway).
All the link handling needs to be much simpler, all unneeded complexity taken
out. I do not see any reason to have
* four different syntax markings for links
* a lot of other duplication in "schemes"
* relatively complicated "separators" like "][" or "}{" (or poorly reusable
ones ones like " "), when the much simpler "|" (that major wikis use) will do
the job
* a massive amount of configuration variable for various files and paths, all
just to support a single output format (!)
and some perhaps also well meant, but questionable decision to allow "Windows
path separators" in the input file (when non-medieval versions of Windows
accept the standard ones just fine), and all the bad-symbol replacements (that
serves whom exactly?), which all just makes the code handling paths very
brittle and difficult to follow.
Yes, for "inverting" the subdir path, one could use
substitute(vimwiki#base#current_subdir(),'[^/]\+','..','g')
but there is no reason to do this more than once per buffer, and currently one
needs quite some luck for getting base#current_subdir() to return the correct
path.
Original comment by tpospi...@gmail.com on 24 Mar 2012 at 9:24
GoogleCodeExporter
commented
8 years ago Just curios, Tomas, how would you create a link with one of the "bad_symbols"?
As far as I know windows filesystem cannot has it in filenames.
I am not against | separator, if someone update table auto formatting.
[http://asdfa.com description] type of links are really not nesessary, that is
right. But it is Stuart who did a lot of work on links and (correct me if I am
wrong) he needs that type of links in markdown syntax. They are transformed to
[description](http://asdf.com) there.
But I agree with Tomas here, this is not good to have 2 different link types in
one syntax. vimwiki should have [[..]] and markdown [..](...). More or less.Original comment by habamax on 25 Mar 2012 at 6:51
GoogleCodeExporter
commented
8 years ago I had previously tried to improve the behavior of links, while maintaining
backwards-compatibility as much as possible. Including the 'syntax' option.
I think that Vimwiki will be of much greater value to the community if we make
some effort to support a few popular syntaxes (including markdown). The
lessons learned by supporting more than one syntax (for example, as I/we have
learned with links) suggest that it is possible, although not necessarily easy,
to do this in a somewhat general way. At the same time, I do not want to
constrain the future development of Vimwiki. Especially if there is a
consistent vision that is an improvement over any existing wiki. (Tomas has
outlined several great ideas which seem well thought out and very useful, but
it is not clear to me what demand there is for such extensions ... e.g.
MultiWikiModel).
How do you feel about the 'syntax' option, and backwards compatibility? Does
this present too many difficulties? Can we design the future Vimwiki so that
it remains backwards compatible with markdown (and 1-2 other popular syntaxes),
assuming new features are not all used?
In this spirit, yes, we can reduce 4 link types down to 2 link types, and use
the | separator in the default syntax. i.e. [[-wikilinks, and templated
weblinks could be combined. The default syntax would continue using
[[-wikilinks everywhere, and the markdown syntax will us []()-links everywhere;
both will allow similar URL and DESCR fields including schemes and images,
despite the fact that markdown only supports some of these. {{-wikiinclude
links and ![]() templated image links could be similarly combined. Extra
attention would be required to make thumbnail links work assuming wiki-include
links use the same | separator.
Original comment by stu.andrews on 25 Mar 2012 at 10:36
GoogleCodeExporter
commented
8 years ago I really do not see a reason to try to "create a link" with a character that
would cause issues in the filesystem. I prefer to live in the simple world
where filename and the wiki name are the same (save the extension). And
frankly, even if there were people who really want to name wikipages "Sign<"
and "Sign>", I find it hard to believe they would see no issue with the fact
that they all link to the same file (just as "Sign*" and a bunch of others).
Wikipedia, with all its complexities, simply considers " " and "_" equivalent,
and quite appropriately discusses other issues as *restrictions* on naming
(instead of doing some much wider (and user configurable?) substitution of
Vimwiki, and furthermore proclaiming "\" and "/" freely interchangeable in
links).
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28technical_restricti
ons%29
Wikimedia is also the one that uses [URL name] for external links (otherwise it
is quite consistent with its use of "|" as separators, at least in links and
many templates). Markdown has no such syntax, AFAIK. Markdown, on the other
hand, uses the links for which are typically of the []() form (where it would
be really stretching it to think of "](" as "the separator"). And all its
dialects support the "reference style" links, with the full definition
deferred, which really requires a very different handling if it was to be
supported by Vimwiki, and not changing a character or two in some template or
regular expression.
Regarding the syntax option, it is an interesting idea, but at present any
"support" for other syntaxes is a complete joke (the syntax files for
"wikimedia" and "markdown" seem to have little to do with those wiki syntaxes).
Regarding the arrangement of splitting the syntax file into two parts (one with
regexes and one with general handling), this is good only if it permits you to
do more with less code. The disadvantage is that the code is hard to understand
(even now, after the link stuff has been moved over inside, the code is almost
inscrutable). I do not see that it would have any "code reduction" benefits.
Currently, each vimwiki_somesyntax file is around 100 lines (it is more or less
just a single file copied three times with a change or two here and there),
plus the monstrous 800 line main syntax file. This does not look good: far more
accurate (but certainly not perfect) syntax files at
https://github.com/chikamichi/mediawiki.vim/blob/master/syntax/mediawiki.vim
and https://github.com/hallison/vim-markdown/blob/master/syntax/markdown.vim
are less than 400 lines together, a large part of it is due to various html
elements allowed in wikimedia. And all this basically just to support the
default syntax (with many thousand lines of fairly high-level script code, just
to allow a single output format, with heaps of unresolved issues). Compare that
with txt2tags http://txt2tags.org/, where 7000 lines of Python (not loading any
sophisticated libraries) can export to over a dozen of dissimilar formats.
The point of MultiWikiModel was not so much to provide "extensions", it was to
simplify things in the first place, without limiting the power and flexibility.
Unfortunately, the link parts did not really get simpler by now, it just works
a little better now and there is much better testing and documentation
available. But the convoluted nature of many code paths is still there,
together with an incredible amount of "options", all of which just stands in
the way of correcting major deficiencies.
The tables are a good example, completely elementary in terms of power, lacking
of any nontrivial parsing of rows, and contributing to the large size of the
syntax file. The main feature seems to be the automatic alignment, which could
be done with the same "quality" by several(?) far more generally useful
plugins, and which is completely useless with anything but the smallest and
most regular of tables. Yet this "feature" seems to be the one that determines
how everything is implemented. I will look at the table code tomorrow if I have
time, since I do not want the poor row parsing to be the reason for instituting
some unnecessarily complex link syntax. But this whole attitude of insisting
that some marginal feature must be supported, while anything else may get
arbitrarily disfunctional or unpredictable or complex, is the main reason for
having so much complexity in the code with relatively little to show for it.
The fastest way to get it to the point where other syntaxes can be supported
(in some useful way) is to figure out how to do things reliably and correctly
with a simple syntax and simple code, and then trying to to augment a suitable
subset of another syntax with things needed or useful by vimwiki. Right now, it
is the simplification that is needed most. Compatibility is long gone, since
CamelCase got changed and then turned off. Some sort of conversion script is
going to be needed for links anyway, I assume, and that is not too difficult.Original comment by tpospi...@gmail.com on 28 Mar 2012 at 1:53
GoogleCodeExporter
commented
8 years ago Tomas, I can see your point on "bad_symbols". Let's remove them.
As far as I remember there were no comparable table plugins on vim.org before
vimwiki. If there are several plugins, that are better than builtin one we
should definitly think about removing it. But I am 99% sure there is no plugin
that uses | as column separator and aware of [[...|...]] links.
And as always it is hard to disagree on most parts of your text.
At first "features" didn't determine how everithing is implemented. Later
decisions made them so. Mostly.
But anyway, I get quite a lot of emails regarding those marginal features
showing people uses them. And I just try to preserve them if possible. If you
think dropping them we could get major improvements and simplification in the
long term -- let's do it.
Original comment by habamax on 28 Mar 2012 at 4:23
GoogleCodeExporter
commented
8 years ago
I can work without markdown []()-links ... "to get it to the point where other
syntaxes can be supported". ;-)
Three requests moving forward in this effort:
1) Can we work in a mode where we keep the simplest 'syntax' file
customizations? Specifically, I would like to keep customizable markers for:
strong, emphasis, bold italics, code, headers, list bullets, list numbers, and
preformatted text. I am also interested in keeping the |-table separator, but
this need not be customizable ...
2) Can we avoid code that uses raw-character syntax markers, and instead try to
use predefined constants e.g. g:vimwiki_rxHdr, g:vimwiki_rxWikiLinkSeparator?
3) Can we address the treatment of orphan pages within the MultiWikiModel?
Specifically, I would like a minimal set of (customizable) settings to be
applied whenever I open an orphan page ... just to be able to edit the page
within vimwiki, but without worrying too much about html output, interwiki
links, and such.
Thanks!
Original comment by stu.andrews on 28 Mar 2012 at 5:33
GoogleCodeExporter
commented
8 years ago Tables are now [[link|desc]] aware, default syntax uses | separators.
2) we can and probably should. :)Original comment by habamax on 5 Apr 2012 at 3:12
GoogleCodeExporter
commented
8 years ago Stuart, could you remove [http://link desc] type of links? I have just tried
but had no luck -- deleted too much stuff.Original comment by habamax on 5 Apr 2012 at 4:17
GoogleCodeExporter
commented
8 years ago There is a very comprehensive Align plugin, for instance, but it will not do
any complicated parsing to make it work correctly for vimwiki tables
(respecting all the inline syntax).
Those "badsymbols" really were a little strange idea, but the actual code seems
more complicated by the attempts to allow any mixes of / and \ as path
separators. What is sorely needed is some sort of review of all the current
options, since many of those were added with not much regard of how difficult
would it be to really support them, not to mention in combination with others.
The testing would need several different profiles to allow for checks on at
least a few more important combinations.
To support wikimedia, it maybe needed(?) to keep their " " = "_" equivalence
(for wiki filenames only, not directories?). But it does not seems to be the
most important thing to consider.
For wikimedia syntax, you will definitely need [http://link desc] type, just
like Markdown cannot be without []()-links. But I would certainly suggest
simplifying the default syntax for links: currently six(!) syntactically
different kinds of links are supported, which is a huge overkill, and I find
the code very difficult to navigate and modify. Just [[ ]] and {{ }} is enough,
with the simplest "|" separator, and for convenience "plain" links, maybe only
with http: and https: (other ones are almost irrelevant/not recognized by the
general public anyway). Plus CamelCase for those who insist, for compatibility
reasons.
Original comment by tpospi...@gmail.com on 5 Apr 2012 at 8:34
GoogleCodeExporter
commented
8 years ago Supporting different syntaxes: I would want to see that, I am just saying that
the current way of doing that will not work if the "support" is to be anything
but a vague claim.
If an actual syntax different from the "default" (whatever this one is going to
turn out to be) is to be supported, a much larger part of syntax would have to
be moved to the syntax specific part (and eventually, just the "highlight" part
plus a few minor things would be shared). To some (perhaps great) extent, this
is going to be true for the support code as well. The current approach is more
or less good just for basic highlighting, but is related to the target syntax
only by a long stretch of imagination.
If anyone considers the "Header" syntax a success of the current model, I must
point out that even in this (very elementary) case, the "unification" came at a
cost of a vast simplification. The actual Wikimedia allows comments at the end
of the header line (this is a tiny discrepancy), but in most dialects(?) of
Markdown, a header can have (any number of) header chars at the end, and also
two-line "underlined" headers for the two top-levels (and this is a very large
difference!). The idea that syntax-specific file sets up a few simple strings
and the "main" syntax file will take care of the rest is completely unworkable
for any seriously meant support. Even the "simple" inline styles will have
different escape and containment rules in various syntaxes. (For block
environments, it is the same story: only small parts of the needed
state-tracking will be shareable, should anyone consider any format-conversion
support).
I would say that to think of the other syntaxes, one would should do the same
as for the default syntax: try to first come up with some model of behaviour: a
subset of the target syntax and its processing rules (or a close approximation
that could be implemented in Vim, with the highlighting being in sync with the
rules as much as possible), augmented by things missing in the target
model/syntax but meaningful in Vimwiki (i.e. dealing with the local filesystem,
diary etc.)
For Wikimedia, one would probably need first a careful selection of HTML tags,
attributes and {{templates}} that are going to be supported.
For Markdown, one has to first try to look around to find which markdown
extension would be a suitable "target" syntax. Specify embedding rules for
inline markup. Scoping rules for blocks (especially list items).
Just like for the default syntax: collecting some nontrivial example files is
really needed in the beginning, in order to come up with suitable syntax rules.
Having access to a good HTML generator for target syntax would be required too,
since documentation is usually not saying much about the finer points of the
model.
Of course, all this is a lot of work, and I would not want to spend a lot of
time on that while the default syntax is still very underspecified and has a
lot of problems. But introducing a lot of "configurable" characters into the
code is not helping right now, when the code needs a lot of refactoring and
reduction, especially to separate out and syntax-specific regular expressions
and the HTML strings.
In each syntax, there must be only a sensible amount of options supported that
influence the semantics of input, and no user-configurable syntax (aside from
some very minor purely cosmetic issues that have no effect on parsing and can
be tolerated). Otherwise, the code to support all that quickly gets absurdly
complex and difficult to maintain, and any chances to have a solid and reliable
system go down very quickly.
Original comment by tpospi...@gmail.com on 5 Apr 2012 at 9:01
GoogleCodeExporter
commented
8 years ago [deleted comment][deleted comment]@maxim: I can help clean-out the templated linksOriginal comment by stu.andrews on 6 Apr 2012 at 2:42
GoogleCodeExporter
commented
8 years ago Tomas, Stuart
I am not sure where we end rergarding links.
For each syntax we should define 'followable' links which is used to navigate
local wiki files:
* 'default' would have (and has) [[...|...]], {{...|...}}, CamelCase
* 'wikimedia' let us say the same as 'default'.
* 'markdown' [...](...)
Besides that each syntax could have their own extensions on links that are not
processed by vimwiki:
* 'wikimedia': [http://link.com linkname]
* 'markdown': ...
Does it make sense?
Original comment by habamax on 6 Apr 2012 at 4:29
GoogleCodeExporter
commented
8 years ago Tomas, Maxim:
I agree with your second point, that each syntax can define its own extensions.
This is why I implemented "templated weblinks", and the following templates:
* 'default': [http://link.com linkname]
* 'wikimedia': [http://link.com linkname]
* 'markdown' [...](...)
However, in my view, the [[wikilink]] 'followable' links are quite common, and
are supported in many syntaxes.
For example, Gollum (https://github.com/github/gollum) is an effort to
implement wikis on Github, supporting and compiling different syntaxes.
Importantly, Gollum supports [[wikilinks]] regardless of chosen syntax. The
discuss absolute vs. relative, reference vs. transclusion, etc. and so there
is strong overlap with our efforts.
Another example is the TrunkNotes app on iOS is a markdown variant that support
[[wikilink]] 'followable' links to navigate local wiki files. Files that I
author in Vimwiki and/or TrunkNotes are interoperable in this regard.
Moreover, [[Wikilinks]] are closely related to Markdown's reference style
links, and if needed, they can be easily converted. Indeed, when I compile to
html on my laptop with the Discount compiler, I perform this transformation in
a simple preprocessing step.
In my view, these are good reasons to re-consider keeping the links we have,
perhaps with some cleanup.
- S.
Original comment by stu.andrews on 6 Apr 2012 at 3:11
GoogleCodeExporter
commented
8 years ago Regarding the orphan pages, I can see that they probably are very useful for
some people (as "readme" and such files for various projects or directories).
But there are two big problems:
1. If multiple syntaxes are allowed(even for these orphan pages), how is the
syntax going to be determined for these files?
Note that for various other reasons, it would be ideal if various syntaxes were required to use distinct file extensions (Problem 1 would then go away). But enforcing it is not so easy if you want people to carry on the way they are used to (some document formats/wikis even use .txt, .wiki is probably common too). This problem basically stems from the fact that the same person rarely uses several wiki syntaxes (or they use each inside the appropriate content managment system only).
2. Should linking to these orphans be supported (with the normal wiki/interwiki
syntax)? Again, this is difficult if orphans can be of several different
syntaxes.
A possible approaches
a) no allowing wiki-style links whose target is an orphan
b) allowing links to orphans only from the wikis using the same syntax (using the orphan: scheme?). For consistency, it would seem natural to use relative path, but in this situation, it may be that the absolute path would be the most useful (since ../../../readme does not tell you much about which project it concerns), so this still creates some complications in the code and wiki model. I guess the absolute paths are the more reasonable option, but it is pretty clear that people who only use one syntax/one wiki (=nearly everybody) will see this as a strange irregularity.
c) more schemes orphan1:,...,... I am not going to go here, more complications are not needed now when the vimwiki's "other" syntaxes are sort of imaginary at the moment.
Some small issues: where to put the converted files? I thought the only natural
place would be the same directory. But vimwiki currently seems to generate an
extra html directory (what happens if you have no write priviledges for the
parent directory?). I find this approach questionable, although it sort of
avoids some problems with overwriting a project HTML file of the same name (a
problem which is easily addressed by prompting the user).Original comment by tpospi...@gmail.com on 6 Apr 2012 at 3:23
GoogleCodeExporter
commented
8 years ago I know that one of the reasons for the templates was to allow/account for
various syntaxes. But I am not sure it is going to be flexible enough to allow
fixing lots of small details that always crop up in parsing and highlighting,
not to mention possible compatibility issues with external parsers.
And I certainly want to simplify the default syntax (even if it means that
previously created wikis may need to be adjusted), so that it is possible to
work on improving reliability and later capability. Adding even more ways of
doing the same is the opposite. Either use [[.]] for wiki links only, and [..]
and {{..}} for all other links, files and images (but even here, I do not like
the "space" separator in one and other separators in other places), or use only
[[..]] and {{..}} with suitable schemes.
Markdown is used as a documentation format, I have not seen any major dialects
ever mention how to make "internal" links. Therefore it is a little odd to pick
it as one of the alternative syntaxes, and if you want to use it for a
(many-file) wiki, one would have to decide how to augment the syntax/rules to
allow some sort of wiki linking (making a new dialect right from the start).
Either adding [[..]], as Stuart says, or trying to use some wiki "schemes". I
have a feeling that for interoperability concerns, some extra syntax (like
[[..]]) may actually be better (Markdown dialects will likely not process it
and leave it alone, while with [this](WikiLink) all sorts of things could
happen).
Otherwise, for some concrete dialect of Markdown whose syntax could be aimed
for in Vimwiki, I would definitely try to pick some of the more sophisticated
extensions that aim at producing decent quality documents. Throwaway "wiki
syntaxes" used by big coding websites aim at not much more than being a
slightly better plain text, and you will end up deviating from them more and
more if you try to address issues they ignore (or create). Original comment by tpospi...@gmail.com on 6 Apr 2012 at 4:24
GoogleCodeExporter
commented
8 years ago Stuart, Let us keep 'templated' links.
Default syntax should not have any while mediawiki and markdown should have
their own.
Specific 'templated' link syntax should be in appropriate syntax file.
Original comment by habamax on 6 Apr 2012 at 6:50
GoogleCodeExporter
commented
8 years ago Just to be clear about my usage of Vimwiki, and in no way intended as a
criticism of other contrasting views, I wanted to mention the following. I use
Vimwiki primarily as a tool for recording, organizing, and retrieving
information. Compiling pages into html is an added bonus, but is not often
necessary for individual use. A powerful feature of Vimwiki that I use to my
advantage, is that it understands a basic subset of Markdown (a well-defined
standard) and has been used to author a functional and satisfactory wiki that
is compatible with third-party software and websites; two dialects of Markdown
that use `[[..]]`-links (without schemes or subdirs) to denote internal wiki
links are those used in Trunk Notes and Gollum. Also, for my purposes, a
syntax "being only slightly better than plain text" is a feature, not a
drawback.
Still, I understand that there exist a broader set of goals for Vimwiki's
development and would like to support however I can. I think that `[[..]]` and
`{{..}}` links, in conjunction with schemes, are great choices for Vimwiki's
revised wiki syntax going forward. Templated web- and image-links are defined
via a separate set of regular expressions and should not interfere with further
development (i.e. improving reliability and later capability) of Vimwiki's
links. I will to work to disable templated links *in the default syntax* as
Maxim suggests, and to keep the code simple and disjoint.
Regarding orphan wikis:
I have orphan wikis simply because I do not want to maintain a long list of
per-wiki configurations (g:vimwiki_list) in my .vimrc file. It's not very
portable, and requires that I switch context and restart Vimwiki to create a
new wiki.
I would like to see a system whereby per-wiki configuration is located in a
file at the root of each wiki. (Perhaps this was mentioned in the details of
MultiWikiModel, so I apologize if I am re-imagining this idea). Whenever a
recognized file is opened, Vimwiki would search upwards in the directory tree
looking for the configuration. Vimwiki could suggest a default configuration
to be added to the current directory if one is not found. To enable interwiki
links (as outlined in MultiWikiModel), all that Vimwiki needs is a way to
discover and register wikis. One solution has already been suggested by Tomas:
add links from a central location to the individual wikis. Something like this:
VimwikiWikiRegistry/
Wiki1 --> /Path/to/wiki1
Wiki2 --> /Path/to/wiki2
FunStuff --> /Path/to/another/wiki/somewhere
Docs --> /Path/to/the/documentation/i/reference/all/the/time
Wikilinks *within each wiki* would be functional with or without registering
the wiki, however wikis could only be referenced from other wikis via interwiki
links if they are registered (symbolically linked in VimwikiWikiRegistry). If
a configuration file can be written to the wiki root, then I don't think we
will have trouble figuring out an appropriate html output directory (perhaps by
asking the user to update their config file).
Does this make sense? I think this would alleviate the difficulty of adding
new wikis, so that support for orphan wikis would not be needed.
Thanks,
-S.
Original comment by stu.andrews on 9 Apr 2012 at 3:25
GoogleCodeExporter
commented
8 years ago @stuart
Wikies are registered by the current model (g:vimwiki_list), aren't they? One
can just add 'name' to a wiki dictionary and use it. Or do you mean we can
populate it from somewhere else?
I don't get if with the MultiWikiModel we need a separate list of
available(registered) wikies somewhere or list of directories(symlinks) in
vimwiki_dir would be enough.
Original comment by habamax on 10 Apr 2012 at 4:31
GoogleCodeExporter
commented
8 years ago @habamax: Yes, I think we should populate g:vimwiki_list when wikis are
discovered by reading their localized configuration files. Yes, it is
sufficient to use the list of directories (symlinks) proposed in
MultiWikiModel. If we adopt localized configuration files, then it would be
trivial for the user (or Vimwiki) to write a configuration file in an orphan
wiki, thereby making the wiki immediately discoverable by Vimwiki. Subsequent
addition of a symlink to g:vimwiki_dir is all that would be required to enable
interwiki links.
Some more justification, in case the above answer isn't clear ...
Registering a wiki using the current model (g:vimwiki_list) involves a lot of
work, and disrupts ones workflow. In order to register or modify a wiki, one
needs to navigate to their .vimrc file, find the section where g:vimwiki_list
is defined, make additions or changes, and then save and restart vim. If there
are many isolated wikis which the user wants to register, the list
g:vimwiki_list will become difficult to navigate and maintain.
Now, consider a situation where you have vimwiki installed on several different
systems, and you synchronize some (but not all) of your wikis between systems,
and that the root paths of your wikis change. This means your .vimrc file is
easily not portable.
The alternative that I am considering would keep the configuration for each
wiki in the root directory of each wiki itself (this approach is common for
localized configurations, e.g. Mercurial & Git version control tools will
search for a local config file, before looking elsewhere). This solution is
consistent with Tomas's proposal in MultiWikiModel to "register" wikis under a
common location identified by g:vimwiki_dir.
Vimwiki would still use g:vimwiki_list, but it would build the list as it
discovers each local configuration. For example, wikis symlinked from the
centralized directory (g:vimwiki_dir="/Path/to/VimwikiWikiRegistry/") would be
discovered at startup, simply by reading each config file from the symlinked
directories. Other wikis could be discovered when a file (with any common wiki
extension) is opened. Vimwiki would search upwards in the directory tree
looking for the appropriate configuration file.
Tomas described a similar setup, using g:vimwiki_dir and g:vimwiki_html_dir.
MultiWikiModel requires a centralized directory for the html output of all
wikis in order to implement interwiki links in a useful manner. Also, the
names of the symlinks in g:vimwiki_dir serve the purpose of defining wiki
"names" to be used in interwiki schemes.
Original comment by stu.andrews on 10 Apr 2012 at 8:50
GoogleCodeExporter
commented
8 years ago Thx, Stuart!
This sounds like a very good idea.Original comment by habamax on 11 Apr 2012 at 4:00
GoogleCodeExporter
commented
8 years ago Tomas did an amazing job providing his vision in MultiWikiModel, I think we
should try to implement it.Original comment by habamax on 11 Apr 2012 at 4:03
GoogleCodeExporter
commented
8 years ago @22 I (and it would seems most people) like Vimwiki for its ease of creating
some content (not for its fairly basic HTML generating capabilities). However,
I see the main usefulness of wiki syntax in providing a system for creating
_structured text_ that is easy to write for a human, and easy to be processed
(by "easy", I mean much easier than docbook or HTML). But it still has to
encode the document structure in one way or another, obeying specific rules
(and not to be just an informal convention for writing simple text, like a
generic Markdown). Without well-behaved converter to a more precisely specified
format (such as HTML), one cannot really claim that the markup actually encodes
some document structure.
It would be a pity if thousands of line of code went into merely highlighting
some "markers" and "following links", with no solid structure behind it. The
great advantage of working inside Vim is that people actually do not have to
know some of the more fiddly rules (especially concerning inline markup), since
the syntax highlighting can be kept in very good sync with the actual
processing rules in most cases. This is a great practical advantage other
systems usually do not have, and offsets some of the drawbacks, like the lower
processing speed.
@22 orphans: The main issue with the simultaneous support of "orphans" and
"multiple syntaxes" (with not necessarily distinct extensions) is how to
determine which file syntax applies to a specific orphan. This is the main
problem that would need to be addressed. Suggesting to go on a wild goose chase
for some configuration file somewhere that might help with that determination
is not a solution to this problem. One has to try to use the "normal" Vim way
(i.e. a simple procedure of a few lines that could be used in some
autocommand). No database or internet queries or scans of the filesystem or
some sort of thorough analysis of the content of the file. Prompting the user
(who insists on using an ambiguous configuration) is one simple solution. Most
other options are of rather marginal value, and one could just accept that for
orphans, the default/global setting (for _that_ kind of syntax) will apply, or
user is going to be prompted if really needed. For the converted output, I see
nothing better or simpler than simply use the file's own directory.
"Orphan files" should not be confused with the regular wiki files, and not
everything applies to them. They are just isolated files using the same syntax
(i.e. fancier "readme" files), but not a part of a wiki (= a coherent system of
interlinked files), there should not be much need for any special
configuration. [Unless the file's "syntax" depends heavily on various
parameters that must be read from some configuration. Which is one of many
reasons why syntax should not depend on any "configurable" parameters.]
@22 configuration in general. You are right that it is worth considering a
separate "configuration" files for Vimwiki. But not at this point, and
certainly not randomly distributed over the whole filesystem. Files outside of
.vimrc are not really needed for the current functionality (or configuration),
but would be useful/necessary for more advanced wiki functionality: to hold
"database" of wikifiles/headings/mutual links (to support reasonably efficient
backreferences, fragment links, "maxhi" etc.) For such caches, each wiki's
"root" directory would be the natural location. Right now, Vimwiki is an editor
plugin, one cannot draw meaningful analogies with Mercurial or Git.
I do hope no one will even think about coding something akin to advanced
features now, that would be a disaster. What is needed now is to simplify and
reduce current configuration options, remove/amalgamate
useless/harmful/unneeded options and, in case anyone is serious about "other
syntaxes", start writing down (I do not mean coding) which options might make
sense (and have some legitimate use) for which syntax. Most of the legitimate
per-wiki options would likely become per-syntax options, as well as some of the
(currently) global ones.
@23 MultiWikiModel allows people to work with Vimwiki's present setup, without
moving their wikis, not forcing people to have their wikis in dedicated
directories For example: the (typical) vimwiki/ located in user's home
directory: the home directory would be the main 'path'; therefore one has to
declare which subdirs are going to be considered regular wikis (and not simply
scan for all subdirs). It feels redundant, but one is not configuring wikis
every day. Besides, having a declared order on wikis may be a good idea anyway,
as mentioned in MultiWikiModel.
But the main point is not just adding names or to unify all wiki linking in
HTML. It is an attempt to simplify the configuration, by removing the need for
(nearly all) per-wiki options involving paths (and style/template filenames
just as well).
Some time ago, when I first configured Vimwiki to use several wikis (in order
to do some tests), I could not get a special CSS file recognized, and I gave up
after half a dozen trials. There were so many things that might have gone
"wrong" (path is relative to what?, separator has to be "/" or "\" on windows?,
is it required at the end of the path, or not allowed there? etc.), it would
require too much patience or knowledge of some internal Vimwiki functions to
track down. As Stewart writes, if you have to configure several things for
several wikis in .vimrc, it can get even harder. But I am saying that this
usability problem should not be moved to some other file(s), but instead be
reduced by _not_ having _everything_ independently configurable (and relying on
the fact that people looking for a very different setup could often use a
filesystem link to have the physical file/directory where they want it).
But if vimwiki's configuration options keep growing I have to agree with
Stewart, it would be better to have them somewhere else, eventually. Although
now most options appear to be hardly unnecessary, their number may have to grow
significantly if more input and output formats were to be supported in some
inter-operable way.
But de-centralizing those options that are needed for every run of Vimwiki?
That would have a very bad impact on performance (downright disastrous in case
of "autodiscovery" of numerous wikis). Also, since most(?) natural options
would be per-syntax (same-syntax wikis likely differ just in their location in
the filesystem for non-schizophrenic users), the natural place for storing the
configuration would not be each wiki's directory, so you are more or less back
to the centralized model.
At present, we have to take the ".vimrc" configuration as far as we can, it is
still the best choice. MultiWikiModel is a way of getting practically all paths
out of the .vimrc. The way options are setup would need serious restructuring
to be meaningful for other syntaxes, because just like the syntax and much of
the support code, it is currently setup for a single syntax (and all other
syntaxes, as long as they are the same as the default one).
Original comment by tpospi...@gmail.com on 11 Apr 2012 at 6:58
GoogleCodeExporter
commented
8 years ago @24 Having wiki's named (instead of numbered, MultiWikiModel) means you can
reference them correctly even if some of them are not available. This means
wimwiki_list can be larger than what is presently available. (Having stable
keyboard shortcuts for getting to the index is not going to work if the
non-available ones were removed from the list and then numbered sequentially,
but that is not an issue, their sequence is declared afterall).
It seems that I and Maxim have a hard time understanding why you seem to need
to create/use so many "wikis" all the time. What is it that makes them all
different? Is something not working if you, say, add '/' as the path of your
(last?) wiki and configure what it is that you require for that "wiki"?
While I think that many basic things work with multiple wikis, I would not be
surprized if many issues cropped up (besides performance) if a large number of
wikis were being used. My impression was that allowing several wikis was meant
to be for a small number of them (and having already two "diaries" seems almost
one too many), and people with extensive wikis would best try to use the tree
hierarchy to organize the files into reasonably sized directories. I would
certainly not want encourage people to create more "wikis" automatically
anytime they open a file somewhere. If you are looking for a way to store some
information on files that you recently worked with, there is viminfo-file and
vim session-file for demanding users (certainly the latter one allows
significant flexibility).
@24 Having wiki's named (instead of numbered, MultiWikiModel) means you can
reference them correctly even if some of them are not available. This means
wimwiki_list can be larger than what is presently available. (Having stable
keyboard shortcuts for getting to the index is not going to work if the
non-available ones were removed from the list and then numbered sequentially,
but that is not an issue, their sequence is declared afterall).
It seems that I and perhaps Maxim have a hard time understanding why you seem
to need to create/use so many "wikis" all the time. What is it that makes them
all different? Is something not working if you, say, add '/' as the path of
your (last?) wiki and configure what it is that you require for that "wiki"?
While I think that many basic things work with multiple wikis, I would not be
surprised if many issues cropped up (besides performance) if a large number of
wikis were being used. My impression was that allowing several wikis was meant
to be for a small number of them (and having already two "diaries" seems almost
one too many), and people with extensive wikis would best try to use the tree
hierarchy to organize the files into reasonably sized directories. I would
certainly not want encourage people to create more "wikis" automatically
anytime they open a file somewhere. If you are looking for a way to store some
information on files that you recently worked with, there is viminfo-file and
vim session-file for demanding users (certainly the latter one allows
significant flexibility).
What you suggest for configuration discovery sound good, but is more suited for
certain types of applications, such as version control systems. I think that it
would open a lot of problems for Vimwiki, with the benefits only the
increased/easier configurability (and "increased" may not necessarily be
beneficial at this point). One problem is the performance, the second is more
of an ecology concern: one should try to avoid littering the filesystem with
numerous files (which tends to happen if something is done "automatically").
That is why I was recently somewhat surprised that when generating an html for
an orphan file, Vimwiki actually created an extra directory to hold it. Many
vim users use dozens of plugins, all sharing a little bit of space in .vimrc. I
do not think that Vimwiki grew to the size and importance yet to need or
deserve more resources.Original comment by tpospi...@gmail.com on 11 Apr 2012 at 7:23
GoogleCodeExporter
commented
8 years ago @tomas: I envision Vimwiki being active for isolated readme files or reference
manuals authored by programmers other than myself with arbitrary syntaxes and
file extensions. For isolated files, it does not make sense to call them wikis
but I would still want to open them with Vimwiki.
If, as you suggest, all I need to do is configure a single wiki with path "/"
... then, well ... "Bob's your uncle". Otherwise, read on ...
The entire discussion is a bit premature because Vimwiki does not currently
support many different syntaxes. However:
* Yes, determining syntax is (currently) the main issue.
* Yes, an autocommand might work (at least until more syntaxes are added).
* Yes, prompting the user could work, but will get annoying especially if multiple configurations have to be made.
* Yes, less configuration makes editing one's .vimrc easier, but you still have to switch context, edit, and restart vim. If I have to do this for every readme file that I edit, I will ... !! On the other hand, I have no problem with miscellaneous configuration files on my filesystem; the OS, hg, git, and rsync are immediate examples that come to mind.
* But no, autodiscovery is not a "wild goose chase". It is a simple linear search. Moreover, Vimwiki would first try the usual method of scanning the current g:vimwiki_list. If that fails, the search for a configuration file need only be performed once per wiki per session. Also, autodiscovery does not imply that a lot of wikis would be used simultaneously; in reality, only a small number would ever be active at one time. In contrast, g:vimwiki_list would be very long if I added each independent readme file as an isolated wiki.
I've enjoyed having this detailed discussion. Now, let's get something done,
shall we.
Original comment by stu.andrews on 12 Apr 2012 at 4:42
GoogleCodeExporter
commented
8 years ago I sort of suspected that various project readme files could be an explanation
of your interest in "numerous unrelated" files, but it was rather squarely
contraindicated by your suggestion to deal with the problem by making local
configuration files (as I find it rather contrived that you could not modify a
file's extension or insert a modeline, but there would be no problem with
adding an entire "configuration" file to the project).
I also suspected that the having a wiki with path "/" is not going to solve all
the problems for you, but it is not quite preposterous in general (of course,
it would have to come after the "regular wikis", and be for a fixed syntax, and
for someone who does not expect vimwiki to generate the HTML for all the files).
The "autodiscovery" in itself is a definite procedure, but what about the
actual problem? When one fails to discover anything, one falls back to ... and
then ... and then ... ?
It is nevertheless more clear now why you have a struggle with .vimrc
configuration, and indeed it is very unpleasant. However, I think that there
*lightweight* remedies or partial solutions to your troubles, as opposed to
your more complete solution (well, solution-repeater, which only works after
someone solved the problem completely at first).
I am still not completely certain of your workflow, as you sometimes seem to
portray the situation as if all kinds of "wiki" files were coming and leaving
all the time. In case it was at least a little non-transient, the following may
help: autocommands (i.e. BufRead) can actually be defined for a path/file
pattern (:he autocmd-patterns), so that they apply only in a certain directory
(and/or for certain filenames). This would be the key to a persistent solution,
requiring only one modification per project of .vimrc (or some other
auto-sourced file).
A non-persistent way is described below (one has to do something each time the
irregular file is opened, but there is no need to touch .vimrc or any similar
file).
But first a few things useful for comparison.
* "Configuration" files for git or hg were put in place at someone's very
explicit wish, and are expected to pertain to dozens or hundreds of related
files. There are not semi-automatically generated by editor plugins, browser
extensions or any other programs people installed for a completely different
reason. If anything, a VC-ed repository could perhaps be likened to a wiki (=
set of related files), not to a "readme" file.
* A much better analogy to the problem you seem to be against is the problem of
determining the encoding of a (non-binary) file (except that the encoding
problem is of interest to millions of people). Ideally, such meta-info would be
retrieved by the OS, but in practice, one has to resort to simple automatic
guessing (large programs such as browsers can afford to try to improve the
chances of correct guess at the expense of a lot of code), and when that fails,
giving the user a chance to override. No one generates a "config" file to make
(the first step of) the chase faster the second time (and giving a headache to
those who try to improve OS's ability to guess the types of files by throwing
in an extra file type).
* With vim, the guessing is pretty basic. One has to configure their vimrc so
that the simple auto-guessing works most of the time for the files that
particular person encounters most often, and for all the other encodings, one
has to do extra work. Clicking on the file is definitely not going to do it,
but there are faster ways than editing your .vimrc and trying again.
* Many filetype plugins face similar problems: the filetype is too generic, and
some important specific settings cannot be obtained automatically via simple
filename or file-contents checks. Again, no one pollutes the filesystem with
files (that would provide the correct information had they been somehow
correctly "configured" and magically kept in sync with the state of the
corresponding file), instead the plugin offers some configuration variables
that users can set to override the automatic decision. Sometimes the variable
has to be set in .vimrc, but it does not have to be this way. The gentler way
is: from the already opened buffer (which was perhaps misclassified), :let
b:filetype_flavour=banana and then :set ft=fruit (or reload with :e ). If
the filetype "fruit" is coded to skip the "autodetection" of flavour in case
the relevant variable is already set, you now end up with the correctly
classified flavour (and syntax highlighting etc.), with just a bit of manual
work and no modification of .vimrc.
* Vimwiki's main mandate is helping people create and manage their personal
wiki. It was not meant to be an autodetection plugin for any kind of wiki-like
syntax, let alone a nebulous and irregular family of textual files various
projects may contain. Perhaps writing such a plugin would be useful to some
people, but I do not quite see which part of Vimwiki would actually be of any
use for that. Also, this rather intricate problem is of little practical use to
a typical vimwiki user, who is likely using vimwiki for creating the content.
In any case, my advice to any such plugin-writer would be to avoid widely
spreading "config" files over an entire filesystem (unless the plugin is solely
for the author's use, in which case any liberties can be taken with the common
practice).
If vimwiki is going to support several input formats, it must set some
externally obvious buffer-local variable to indicate the type of the file
anyway (even if one did not consider any orphan-related problems). Maxim had
set up Vimwiki quite nicely, but it was for a single syntax (or a minor
variation or two, none of which would ever escape its vimwiki cage). If these
variations were actually reworked to be somewhat compatible with some
established wiki syntaxes, one would have to set a "flavour" variable as a
minimum courtesy for other plugins to have a fighting chance to identify the
buffer type. Since the user can choose any file extension for any syntax,
"vimwiki" filetype could be hijacking actual Wikimedia files, for example.Original comment by tpospi...@gmail.com on 13 Apr 2012 at 8:22
GoogleCodeExporter
commented
8 years ago @tpospich8: please see r7881533842fb for a lightweight (partial?) solution to
the orphan wiki conundrumOriginal comment by stu.andrews on 17 Apr 2012 at 10:20
GoogleCodeExporter
commented
8 years ago The original issue is fixed.Original comment by habamax on 5 May 2012 at 8:05
Original issue reported on code.google.com by
firecat4...@gmail.comon 22 Mar 2012 at 9:50