Re: [hackers][vis][PATCH] Handle quote matching in its own function

From: Marc André Tanner <mat_AT_brain-dump.org>
Date: Mon, 15 Feb 2016 17:50:12 +0100

On Mon, Feb 15, 2016 at 04:01:48PM +0100, Silvan Jegen wrote:
> Unlike other paired characters neither of the quote types allow for the
> search for the closing occurrence to be optimised because there is no
> directionality implied. This means theoretically we always have to start
> from the beginning of a file to check whether all the quotes until the
> occurrence of the one in question have been properly closed before we
> can say which one is the closing occurrence of the quote.
>
> This is the justification for introducing this new function that
> duplicates some code. Instead of searching from the beginning of a
> file we start our search for the corresponding quote character at
> an arbitrarily chosen offset of 500 bytes before the occurrence in
> question.
> ---
> Consider this to be a bug report for a pet peeve of mine. When you
> position the cursor at line 797 of vis.c in vis on the quote after
> __DATE__ the quote highlighting will be wrong. The text motion for
> "select inner quote" is wrong as well but I think it makes more sense
> there to select the text between the quotes instead of selecting nothing
> only because the quotes are not actually corresponding to each other.
>
> This patch fixes the highlighting case but it may be overkill for such
> marginal issue.

Yes it is. The highlighting feature is just a convenience which should
work most of the time. As you noted making this work correctly for all
cases would need integration with a lexer. Simply counting a couple
of quotes like it is currently done will only work for the common case.

Things which are not handled correctly include:

 - escaped quotes as in "some \"string\""

 - quotes can also appear on their own, an example from your patch
   (case '"':). For single quotes this is frequently the case with
   english comments.

What would be more interesting is to add a way to define motions and
text objects in Lua. Integration with the LPeg based lexers should
then be relatively easy ...

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Received on Mon Feb 15 2016 - 17:50:12 CET

This archive was generated by hypermail 2.3.0 : Mon Feb 15 2016 - 18:00:15 CET