Possible problem with vat going backwards

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible problem with vat going backwards

Dave Roberts
Bram,

(Vim 7 from this morning's CVS sources - WinXP)

I probably need to stop using slashdot.org to test HTML editing code
against but here's a snippet that shows a possible problem.

<TD>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" ALIGN="LEFT" width="100">
<TR><TD ><FONT SIZE="2">
&nbsp;<A HREF="//apache.slashdot.org/">Apache</A></FONT></TD></TR>
</TABLE>
</TD>

If you put the cursor on either 'TABLE' or '/TABLE' and use '%' to match
(unless starting with -u NONE so matchit isn't loaded) it works correctly.

If you put the curson on the 'TABLE' and use 'vat' it works correctly.

If you put the curson on '/TABLE' and use 'vat' it highlights everything.

The problem is the '<TD >' (space before the >) on the third line. If
you remove that space it works.

As I said, it may be that slashdot is just doing it wrong and there are
LOTS of those in a single source page from them.

Thanks,

- Dave
Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

A.J.Mechelynck
----- Original Message -----
From: "Dave Roberts" <[hidden email]>
To: "Vim-Dev" <[hidden email]>
Sent: Thursday, July 21, 2005 4:38 PM
Subject: Possible problem with vat going backwards


> Bram,
>
> (Vim 7 from this morning's CVS sources - WinXP)
>
> I probably need to stop using slashdot.org to test HTML editing code
> against but here's a snippet that shows a possible problem.
>
> <TD>
> <TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" ALIGN="LEFT"
> width="100">
> <TR><TD ><FONT SIZE="2">
> &nbsp;<A HREF="//apache.slashdot.org/">Apache</A></FONT></TD></TR>
> </TABLE>
> </TD>
>
> If you put the cursor on either 'TABLE' or '/TABLE' and use '%' to match
> (unless starting with -u NONE so matchit isn't loaded) it works correctly.
>
> If you put the curson on the 'TABLE' and use 'vat' it works correctly.
>
> If you put the curson on '/TABLE' and use 'vat' it highlights everything.
>
> The problem is the '<TD >' (space before the >) on the third line. If you
> remove that space it works.
>
> As I said, it may be that slashdot is just doing it wrong and there are
> LOTS of those in a single source page from them.
>
> Thanks,
>
> - Dave

That space is not a syntax error. There could have been something like <TD
WIDTH=25% ALIGN=RIGHT DIR=RTL> instead.

Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

Bram Moolenaar
In reply to this post by Dave Roberts

Dave Roberts wrote:

> (Vim 7 from this morning's CVS sources - WinXP)
>
> I probably need to stop using slashdot.org to test HTML editing code
> against but here's a snippet that shows a possible problem.
>
> <TD>
> <TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" ALIGN="LEFT" width="100">
> <TR><TD ><FONT SIZE="2">
> &nbsp;<A HREF="//apache.slashdot.org/">Apache</A></FONT></TD></TR>
> </TABLE>
> </TD>
>
> If you put the cursor on either 'TABLE' or '/TABLE' and use '%' to match
> (unless starting with -u NONE so matchit isn't loaded) it works correctly.
>
> If you put the curson on the 'TABLE' and use 'vat' it works correctly.
>
> If you put the curson on '/TABLE' and use 'vat' it highlights everything.
>
> The problem is the '<TD >' (space before the >) on the third line. If
> you remove that space it works.
>
> As I said, it may be that slashdot is just doing it wrong and there are
> LOTS of those in a single source page from them.

I see the problem.  The <TD > isn't recognized.  This change will fix
it:

*** search.c~ Thu Jul 21 20:20:34 2005
--- search.c Thu Jul 21 22:47:22 2005
***************
*** 3713,3719 ****
       */
      for (n = 0; n < count; ++n)
      {
! if (do_searchpair((char_u *)"<[^ \t>/!]\\+\\%(\\_s\\_[^>]\\{-}[^/]>\\|$\\|>\\)",
     (char_u *)"",
     (char_u *)"</[^>]*>", BACKWARD, (char_u *)"", 0) <= 0)
  {
--- 3713,3719 ----
       */
      for (n = 0; n < count; ++n)
      {
! if (do_searchpair((char_u *)"<[^ \t>/!]\\+\\%(\\_s\\_[^>]\\{-}[^/]>\\|$\\|\\_s\\=>\\)",
     (char_u *)"",
     (char_u *)"</[^>]*>", BACKWARD, (char_u *)"", 0) <= 0)
  {

--
Q: How do you tell the difference between a female cat and a male cat?
A: You ask it a question and if HE answers, it's a male but, if SHE
   answers, it's a female.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

Dave Roberts


Bram Moolenaar wrote:

>Dave Roberts wrote:
>
>  
>
>>(Vim 7 from this morning's CVS sources - WinXP)
>>
>>I probably need to stop using slashdot.org to test HTML editing code
>>against but here's a snippet that shows a possible problem.
>>
>><TD>
>><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" ALIGN="LEFT" width="100">
>><TR><TD ><FONT SIZE="2">
>>&nbsp;<A HREF="//apache.slashdot.org/">Apache</A></FONT></TD></TR>
>></TABLE>
>></TD>
>>
>>If you put the cursor on either 'TABLE' or '/TABLE' and use '%' to match
>>(unless starting with -u NONE so matchit isn't loaded) it works correctly.
>>
>>If you put the curson on the 'TABLE' and use 'vat' it works correctly.
>>
>>If you put the curson on '/TABLE' and use 'vat' it highlights everything.
>>
>>The problem is the '<TD >' (space before the >) on the third line. If
>>you remove that space it works.
>>
>>As I said, it may be that slashdot is just doing it wrong and there are
>>LOTS of those in a single source page from them.
>>    
>>
>
>I see the problem.  The <TD > isn't recognized.  This change will fix
>it:
>
>*** search.c~ Thu Jul 21 20:20:34 2005
>--- search.c Thu Jul 21 22:47:22 2005
>***************
>*** 3713,3719 ****
>       */
>      for (n = 0; n < count; ++n)
>      {
>! if (do_searchpair((char_u *)"<[^ \t>/!]\\+\\%(\\_s\\_[^>]\\{-}[^/]>\\|$\\|>\\)",
>      (char_u *)"",
>      (char_u *)"</[^>]*>", BACKWARD, (char_u *)"", 0) <= 0)
>   {
>--- 3713,3719 ----
>       */
>      for (n = 0; n < count; ++n)
>      {
>! if (do_searchpair((char_u *)"<[^ \t>/!]\\+\\%(\\_s\\_[^>]\\{-}[^/]>\\|$\\|\\_s\\=>\\)",
>      (char_u *)"",
>      (char_u *)"</[^>]*>", BACKWARD, (char_u *)"", 0) <= 0)
>   {
>
>  
>

Seems to have done the trick...

Thanks,

- Dave
Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

Bram Moolenaar
In reply to this post by Dave Roberts

Nicolas Schodet wrote:

> * Bram Moolenaar <[hidden email]> [050721 22:51]:
> > [...]
> > ! if (do_searchpair((char_u *)"<[^ \t>/!]\\+\\%(\\_s\\_[^>]\\{-}[^/]>\\|$\\|\\_s\\=>\\)",
> >      (char_u *)"",
> >      (char_u *)"</[^>]*>", BACKWARD, (char_u *)"", 0) <= 0)
>
> This looks like searchpair() vim function...

Right, it's using the same code.

> Is there a way to implement text objects in vim script language? This
> could be a better idea than include this in vim source code.

You can use ":omap" and ":vmap" for this.

Even though it's now implemented in C this can still be slow.  Mainly
when editing HTML, at every <BR> it tries to find the matching </BR>,
fails and continues looking backwards for the next tag.  Doing this in
Vim script would be slower.

--
My girlfriend told me I should be more affectionate.
So I got TWO girlfriends.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

A.J.Mechelynck
----- Original Message -----
From: "Bram Moolenaar" <[hidden email]>
To: "Nicolas Schodet" <[hidden email]>
Cc: "Vim-Dev" <[hidden email]>
Sent: Friday, July 22, 2005 11:22 AM
Subject: Re: Possible problem with vat going backwards
[...]
> Even though it's now implemented in C this can still be slow.  Mainly
> when editing HTML, at every <BR> it tries to find the matching </BR>,
> fails and continues looking backwards for the next tag.  Doing this in
> Vim script would be slower.

Then maybe it would still be useful to have a user-settable list of unpaired
tags -- either a buffer-local option, or reuse the b:unaryTagsStack variable
already used for that purpose by the closetag.vim plugin (vim-online tip
#13).

Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

A.J.Mechelynck
----- Original Message -----
From: "Tony Mechelynck" <[hidden email]>
To: "Nicolas Schodet" <[hidden email]>; "Bram Moolenaar"
<[hidden email]>
Cc: "Vim-Dev" <[hidden email]>
Sent: Friday, July 22, 2005 11:30 AM
Subject: Re: Possible problem with vat going backwards


> ----- Original Message -----
> From: "Bram Moolenaar" <[hidden email]>
> To: "Nicolas Schodet" <[hidden email]>
> Cc: "Vim-Dev" <[hidden email]>
> Sent: Friday, July 22, 2005 11:22 AM
> Subject: Re: Possible problem with vat going backwards
> [...]
>> Even though it's now implemented in C this can still be slow.  Mainly
>> when editing HTML, at every <BR> it tries to find the matching </BR>,
>> fails and continues looking backwards for the next tag.  Doing this in
>> Vim script would be slower.
>
> Then maybe it would still be useful to have a user-settable list of
> unpaired tags -- either a buffer-local option, or reuse the
> b:unaryTagsStack variable already used for that purpose by the
> closetag.vim plugin (vim-online tip

Oops... _script_ #13.

> #13).
>
> Best regards,
> Tony.


Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

Bram Moolenaar
In reply to this post by A.J.Mechelynck

Tony Mechelynck wrote:

> [...]
> > Even though it's now implemented in C this can still be slow.
> > Mainly when editing HTML, at every <BR> it tries to find the
> > matching </BR>, fails and continues looking backwards for the next
> > tag.  Doing this in Vim script would be slower.
>
> Then maybe it would still be useful to have a user-settable list of
> unpaired tags -- either a buffer-local option, or reuse the
> b:unaryTagsStack variable already used for that purpose by the
> closetag.vim plugin (vim-online tip #13).

The list would need to be set by the ftplugin, since it's different for
each filetype.  It could be a list of tags that are always alone, such
as <br>, so that the search for the matching one can be skipped.  

We could use a regexp pattern for this to keep it simple.

--
ARTHUR: Charge!
   [They all charge with swords drawn towards the RABBIT.  A tremendous twenty
   second fight with Peckinpahish shots and borrowing heavily also on the
   Kung Fu and karate-type films ensues, in which some four KNIGHTS are
   comprehensively killed.]
ARTHUR: Run away!  Run away!
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Possible problem with vat going backwards

A.J.Mechelynck
----- Original Message -----
From: "Bram Moolenaar" <[hidden email]>
To: "Tony Mechelynck" <[hidden email]>
Cc: "Nicolas Schodet" <[hidden email]>; "Vim-Dev" <[hidden email]>
Sent: Friday, July 22, 2005 1:26 PM
Subject: Re: Possible problem with vat going backwards


>
> Tony Mechelynck wrote:
>
>> [...]
>> > Even though it's now implemented in C this can still be slow.
>> > Mainly when editing HTML, at every <BR> it tries to find the
>> > matching </BR>, fails and continues looking backwards for the next
>> > tag.  Doing this in Vim script would be slower.
>>
>> Then maybe it would still be useful to have a user-settable list of
>> unpaired tags -- either a buffer-local option, or reuse the
>> b:unaryTagsStack variable already used for that purpose by the
>> closetag.vim plugin (vim-online tip #13).
>
> The list would need to be set by the ftplugin, since it's different for
> each filetype.  It could be a list of tags that are always alone, such
> as <br>, so that the search for the matching one can be skipped.
>
> We could use a regexp pattern for this to keep it simple.

It can even differ for each programming style, since it can be empty for
XHTML where every unpaired opening tag must end in />; and even in
"classical" HTML, p,li,td etc. could be present or not depending on whether
or not </p> </li> </td> etc. are systematically used in the file considered.
The Closetag plugin uses a space-separated list (not as a List but as a
String since it works with Vim 6) but if you think a regexp pattern would
make it simpler (and faster), why not? -- OTOH, a space-separated list would
make communication easier between this new feature and that existing (and, I
think, widely used) add-on script. The script already has different defaults
for HTML ("Area Base Br DD DT HR Img Input LI Link Meta P Param") and XML
(the empty string). I use XHTML-like coding style except in one directory
tree containing older files where <BR> tags are written <BR> not <BR />, so
I already use the following lines in ~/vimfiles/ftplugin/html.vim:

" Auto-close HTML tags (XHTML style) with Ctrl-_
if expand("%:p:h") =~? '\<chroniq\>'
    let b:unaryTagsStack = 'BR'
else
    let b:unaryTagsStack = ""
endif
runtime! macros/closetag.vim


Best regards,
Tony.