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(dot)munro(at)enterprisedb(dot)com> wrote in <CAEepm=26AR3drcAUW+paLvJmXS6WV36kk6e72GWS4rAykOueOg(at)mail(dot)gmail(dot)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(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqR+uQj=QvXDbookA5OmbmCR6So2fJxCLbh6gJ6OvacDLA(at)mail(dot)gmail(dot)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(at)2ndquadrant(dot)com> wrote in <20151116151606(dot)GW614468(at)alvherre(dot)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