Bug in syntax/mail.vim
Richard Hartmann
to reproduce:
vim -u NONE -U NONE
:set syntax
:set ft=mail
i " this newline is for readability
http://vim.org/(test)
The closing bracket will not be highlighted.
Richard
Ben Schmidt
> Hi all,
>
> to reproduce:
>
> vim -u NONE -U NONE
> :set syntax
Presuming you mean :syntax enable.
> :set ft=mail
> i " this newline is for readability
> http://vim.org/(test)
>
> The closing bracket will not be highlighted.
I suspect it is deliberate. URLs rarely contain parentheses, but are often written
inside them in sentences, e.g.
There is interesting information on the web (for example, at http://vim.org/).
Cheers,
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Richard Hartmann
> I suspect it is deliberate. URLs rarely contain parentheses, but are often written
> inside them in sentences, e.g.
>
> There is interesting information on the web (for example, at http://vim.org/).
That is true. In case there is an opening bracket in the URL, I do think
highlighting the closing bracket as well would make sense, though.
Richard
Ben Schmidt
Yeah. I think it would make sense, too, but it's horrible to code nicely and reliably.
Gautam Iyer
> > to reproduce:
> >
> > vim -u NONE -U NONE
> > :set syntax
>
> Presuming you mean :syntax enable.
>
> > :set ft=mail
> > i " this newline is for readability
> > http://vim.org/(test)
> >
> > The closing bracket will not be highlighted.
>
> I suspect it is deliberate. URLs rarely contain parentheses, but are
> often written inside them in sentences, e.g.
>
> There is interesting information on the web (for example, at
> http://vim.org/).
Yes, it is deliberate (I wrote it a long time ago, for exactly the
purpose you point out above). If you notice, even a period at the end of
a URL will not be highlighted as in www.vim.org.
If you like you can modify the current URL regexp so that it that
matches URLs which includes the ")" at the end provided the URL contains
a "(". Send it to me, and I'll include it :).
GI
--
'Code Orange' -- Eat dessert first.
Tony Mechelynck
The parentheses should have been percent-escaped, i.e., replaced by a percent
sign and their hex value (00-FF) as in
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
225. You sign up for free subscriptions for all the computer magazines
James Vega
> The parentheses should have been percent-escaped, i.e., replaced by a percent
> sign and their hex value (00-FF) as in
>
> http://www.vim.org/%28test%29
While it's true that the URL RFC dictates that such characters should be
hex-escaped, most user interfaces accept the non-escaped version so
people don't have to remember character codes for everything. This does
make it more difficult to perform proper highlighting/selection of a URL
but it's a give and take for user simplicity vs. developer hardship.
This is also why angle brackets are specified for use as URL delimiters
in text, since it vastly simplifies parsing.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Matt Wozniski
> On Thu, Jan 10, 2008 at 08:28:14PM +0100, Tony Mechelynck wrote:
> > The parentheses should have been percent-escaped, i.e., replaced by a percent
> > sign and their hex value (00-FF) as in
> >
> > http://www.vim.org/%28test%29
>
> While it's true that the URL RFC dictates that such characters should be
> hex-escaped, most user interfaces accept the non-escaped version so
> people don't have to remember character codes for everything. This does
> make it more difficult to perform proper highlighting/selection of a URL
> but it's a give and take for user simplicity vs. developer hardship.
> This is also why angle brackets are specified for use as URL delimiters
> in text, since it vastly simplifies parsing.
Actually, RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) says at
3.2.3 (URI Comparison) that parentheses, being in the reserved set,
are not required to evaluate as equal to the %XX forms. So, a
standards conforming web server could send you to a different page
depending on whether you use http://vim.org/%28test%29 or
http://vim.org/(test) ... Though that may or may not be relevant to
the conversation at hand.
~Matt
James Vega
>
> On Jan 10, 2008 2:39 PM, James Vega <jame...@jamessan.com> wrote:
> > On Thu, Jan 10, 2008 at 08:28:14PM +0100, Tony Mechelynck wrote:
> > > The parentheses should have been percent-escaped, i.e., replaced by a percent
> > > sign and their hex value (00-FF) as in
> > >
> > > http://www.vim.org/%28test%29
> >
> > While it's true that the URL RFC dictates that such characters should be
> > hex-escaped, most user interfaces accept the non-escaped version so
> > people don't have to remember character codes for everything. This does
> > make it more difficult to perform proper highlighting/selection of a URL
> > but it's a give and take for user simplicity vs. developer hardship.
> > This is also why angle brackets are specified for use as URL delimiters
> > in text, since it vastly simplifies parsing.
>
> Actually, RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) says at
> 3.2.3 (URI Comparison) that parentheses, being in the reserved set,
> are not required to evaluate as equal to the %XX forms.
I was thinking of RFC 1738 (Uniform Resource Locators) but it also
mentions that parentheses are reserved characters and can be escaped
unless they're being used for a reserved purpose.
Ben Schmidt
> mentions that parentheses are reserved characters and can be escaped
> unless they're being used for a reserved purpose.
And whether they have a reserved purpose is dictated by the URL scheme, isn't it,
not the browser/software. So a web browser shouldn't serve different pages, as
brackets don't have a reserved purpose in http URIs.
Mike Williams
> On Thu, Jan 10, 2008 at 08:28:14PM +0100, Tony Mechelynck wrote:
>> The parentheses should have been percent-escaped, i.e., replaced by a percent
>> sign and their hex value (00-FF) as in
>>
>> http://www.vim.org/%28test%29
>
> While it's true that the URL RFC dictates that such characters should be
> hex-escaped,
Chapter and verse please, for education purposes. My reading of 3986
(which updates 1738) allows ( and ) to appear in URLs with no
requirement to percent encode. Percent encoding of any URL characters
that do no otherwise require them should only happen when those
characters are used to indicate components within the URL. Obviously
this could be any character, including alphanums!
> most user interfaces accept the non-escaped version so
> people don't have to remember character codes for everything. This does
> make it more difficult to perform proper highlighting/selection of a URL
> but it's a give and take for user simplicity vs. developer hardship.
> This is also why angle brackets are specified for use as URL delimiters
> in text, since it vastly simplifies parsing.
Mike
--
Youth would be an ideal state if it came a little later in life.