search

qqzsxyz / vimwiki

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

Highlight_existing_links() fails when wiki has filename containing "&", e.g. [[Test&File]] #316

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 

The error ...

 > line    9:
 > E63: invalid use of \_
 >
 > E475: Invalid argument: VimwikiLinkT `{{\%(2009-01-23\|2009-10-18\|2010-05-04\/ ... 
- etc.

Original issue reported on code.google.com by stu.andrews on 21 May 2012 at 4:41

GoogleCodeExporter commented 8 years ago 
It is regression bug, I believe. We should escape special symbols.

Original comment by habamax on 21 May 2012 at 6:06

GoogleCodeExporter commented 8 years ago

Original comment by habamax on 21 May 2012 at 4:12

GoogleCodeExporter commented 8 years ago 
rdc8f8e741194 fixes the highlighting of files with & , e.g. [[Test&File]]

Which characters are valid & invalid in filenames?

Here's my suggestion concerning the special characters that have previously 
received attn.  E.g. in vimwiki#base#file_pattern()

- valid '~&.' 
- invalid '*'
- undecided '$'

Original comment by stu.andrews on 21 May 2012 at 4:47

GoogleCodeExporter commented 8 years ago

Original comment by stu.andrews on 21 May 2012 at 4:54

GoogleCodeExporter commented 8 years ago 
Probably this link could be taken into account:

http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(technical_restriction
s)

Original comment by habamax on 21 May 2012 at 5:53

GoogleCodeExporter commented 8 years ago 
I will test filenames against different symbols on linux and windows.

Original comment by habamax on 21 May 2012 at 5:53

GoogleCodeExporter commented 8 years ago 
btw,

valid symbols is those we should escape in filenames?

Original comment by habamax on 21 May 2012 at 5:58

GoogleCodeExporter commented 8 years ago 
"Valid" = "accepted" = "handled" using whichever method is required for a given 
operation (escaped, ...)

Original comment by stu.andrews on 21 May 2012 at 9:14

GoogleCodeExporter commented 8 years ago 
I mean, symbols could be valid for filenames but not for regexps and vice versa.

Original comment by habamax on 22 May 2012 at 4:42

GoogleCodeExporter commented 8 years ago 
I guess those 5 symbols are enough to be escaped for file patterns.

Should we restrict what symbols to use in filenames? I am not so sure.

Original comment by habamax on 22 May 2012 at 5:10

GoogleCodeExporter commented 8 years ago 
Like I suggested earlier, our policy could be to aim (i.e. within Vimwiki) to 
support *all* special characters, and force the user to choose names that are 
compatible with any external restrictions that they encounter (e.g. filesystem, 
wiki conventions, other syntaxes, ...).

So, in our code, we would escape all characters (and only those) that have 
special meanings in those regexps ... regardless of whether or not it made 
sense for a filename or not.   Certain operations, like creating or renaming a 
file, could be designed to fail gracefully if the filesystem complained ...

Do you think this approach is feasible?

Original comment by stu.andrews on 22 May 2012 at 7:09

GoogleCodeExporter commented 8 years ago 
Yes, I agree. This approach is the best we can have here I believe.

Original comment by habamax on 22 May 2012 at 7:44

GoogleCodeExporter commented 8 years ago 
a reminder

http://code.google.com/p/vimwiki/source/detail?r=81bdf76b7ef0d5c130dda4ce1fe0344
1b3e8ae21

Original comment by habamax on 25 May 2012 at 3:32

GoogleCodeExporter commented 8 years ago 
\V doesn't quite work at the moment.

links with description are highlighted as nonexistent.

Original comment by habamax on 25 May 2012 at 3:50

GoogleCodeExporter commented 8 years ago 
I have added \m (magic) to the end of 'files' pattern.

Original comment by habamax on 25 May 2012 at 4:14

GoogleCodeExporter commented 8 years ago 
I have added a description to each of the issue316 links, and with 
rb0d22a771b96, all of them are highlighted as existent and correctly show their 
descriptions ... EXCEPT FOR:

1. [[issue316_\_i|hello]] which appears as plain text
2. "issue316_[_h|hello" appears as an existing link, incorrectly treating the 
description as part of the url
3. "issue316_]_j|hello" is the same as 2.

Original comment by stu.andrews on 25 May 2012 at 5:41

GoogleCodeExporter commented 8 years ago 
1. that is because of \. I think it is ok.

I have 2 and 3 as plain text... :)

I had it before \V so the problem is in smth else.

Original comment by habamax on 26 May 2012 at 10:06

GoogleCodeExporter commented 8 years ago 
Fixed with r507d4aed9e0c.

I have to check it with windows.

Original comment by habamax on 29 May 2012 at 4:45

GoogleCodeExporter commented 8 years ago

Original comment by habamax on 1 Jun 2012 at 11:09