Perché Vim regex non consente più di 9 gruppi di acquisizione?

Da :h E65possiamo vedere che Vim non consente più di 9 gruppi di acquisizione in un comando di sostituzione.

Ad esempio il seguente comando funzionerà:

s/\v(a)(b)(c)(d)(e)(f)(g)(h)(i)/\9\8\7\6\5\4\3\2\1

Ma questo con un altro gruppo di acquisizione fallirà:

s/\v(a)(b)(c)(d)(e)(f)(g)(h)(i)(j)/\10\9\8\7\6\5\4\3\2\1

La mia domanda non riguarda il motivo per cui fallisce (è un limite rigido di Vim), ma perché Vim ha questo limite?

Inoltre, sono consapevole che una regex di vita reale con più di 9 gruppi di acquisizione sarebbe probabilmente piuttosto mostruosa da leggere e da mantenere, ma sono ancora curiosa.

regular-expression

— statox
fonte

Magari non riguardava solo Vim: stackoverflow.com/a/10993346/2558252

— nobe4

@ nobe4: interessante! Quindi forse le persone che hanno creato questi strumenti hanno ritenuto che più di 9 gruppi fossero inutili ...

— statox

Suppongo che questo limite provenga da vi, che ha ereditato il limite da ed / sed. Alcuni anni fa ho realizzato una patch per supportare fino a 99 gruppi, ma non era inclusa

— Christian Brabandt,

@ChristianBrabandt Un'aggiunta più utile sarebbe quella di implementare flag numerici come in sed: s/.../.../3sostituirebbe solo la terza occorrenza del modello. Questa è probabilmente la caratteristica che mi manca di più in Vim.

— Sato Katsura,

Supportare acquisizioni con nome sarebbe un altro modo per alleviare questo problema. Detto questo, la maggior parte delle volte che ho visto ovunque vicino a 9 gruppi di cattura è stato quando le persone non sapevano di poter usare gruppi non di acquisizione - \%().

— Jamessan,

La ragione ovvia è che i gruppi con due o più cifre sono ambigui: dovrebbero \12essere presi come gruppo 12 o come gruppo 1 seguito dalla stringa 2?

Vi sono altri motivi legati all'efficienza (tempo di corrispondenza esponenziale e simili). Questi sono stati uno spettacolo quando è edstato scritto. Da allora sono stati scoperti algoritmi migliori.

— Sato Katsura
fonte

Questa è una buona possibilità, hai qualche riferimento / lettura in merito?

— nobe4,

@ nobe4 Per la parte relativa all'ambiguità: no, ma l'IMO è ovvio. Per quanto riguarda l'efficienza, dovresti leggere le prime implementazioni di regexps. All'epoca era un problema ben noto. Non ho citazioni esatte, ma non dovrebbero essere difficili da trovare.

— Sato Katsura,

In effetti sembra totalmente plausibile.

— statox

Sì, quasi sicuramente il parser è stato scritto per cercare una singola cifra dopo una barra rovesciata e non è mai cambiato. Questo era abbastanza comune, molto tempo fa. Altre lingue hanno escogitato modi per aggirare questo problema (ad esempio, prendendo in considerazione \11un riferimento a una cattura solo se ce ne sono almeno 11, il che è incoerente ma di solito va bene; e cose come \g{11}per i riferimenti secondari e le ${11}sostituzioni), ma vim non ha mai introdotto uno di quelli.

— Hobbs,