Re: Making tab-complete.c easier to maintain

Hello, thank you for many valuable opinions.

I am convinced that bare regular expressions cannot be applied
here:)

At Mon, 16 Nov 2015 18:59:06 +1300, Thomas Munro <thomas.munro@enterprisedb.com> wrote in
<CAEepm=26AR3drcAUW+paLvJmXS6WV36kk6e72GWS4rAykOueOg@mail.gmail.com>
> It's an interesting idea to use regular expressions, but it's a shame to
> move the patterns so far away from the actions they trigger.

Yes, I agree. RE is powerful tool but too complicated. Some
intermediate expression would be needed but it also adds
different kind of complexity.

At Mon, 16 Nov 2015 23:09:52 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqR+uQj=QvXDbookA5OmbmCR6So2fJxCLbh6gJ6OvacDLA@mail.gmail.com>
> This makes the situation messier. At least with Thomas' patch one can
> immediately know the list of words that are being matched for a given
> code path while with this patch we need to have a look to the regex
> where they are list. And this would get more and more complicated with
> new commands added.

Hmm, so I named the enum items to reflect its pattern but even
though I also think it is one of the problem of using regular
expressions.

At Mon, 16 Nov 2015 12:16:07 -0300, Alvaro Herrera <alvherre@2ndquadrant.com> wrote in
<20151116151606.GW614468@alvherre.pgsql>
> I don't think this is an improvement.  It seems to me that a lot more
> work is required to maintain these regular expressions, which while
> straightforward are not entirely trivial (harder to read).
> 
> If we could come up with a reasonable format that is pre-processed to a
> regexp, that might be better.  I think Thomas' proposed patch is closer
> to that than Horiguchi-san's.

I aimed that matching mechanism can handle optional elements in
syntexes more robustly. But as all you are saying, bare regular
expression is too complex here.



regares,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center