[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29343: 27.0.50; Match data doesn't contain elements for non-matched
bug#29343: 27.0.50; Match data doesn't contain elements for non-matched subgroups
Fri, 19 Apr 2019 20:42:23 +0200
Am Fr., 19. Apr. 2019 um 20:29 Uhr schrieb Noam Postavsky <address@hidden>:
> Philipp Stephani <address@hidden> writes:
> > Am Sa., 17. März 2018 um 01:37 Uhr schrieb Noam Postavsky <address@hidden>:
> >> Philipp Stephani <address@hidden> writes:
> >> > $ emacs -Q -batch -eval '(progn (string-match
> >> > "^\\(a\\)?\\(b\\)\\(c\\)?$" "b") (print (match-data)))'
> >> > (0 1 nil nil 0 1)
> >> >
> >> > Note that neither the `a` nor the `c` group matched, but there are
> >> > entries for `a` in `match-data`, but not for `c`. This makes working
> >> > with the match data unnecessarily hard because its length depends on
> >> > whether certain optional groups have matched or not. I haven't seen any
> >> > discussion about this behavior in either the manual or the docstring. I
> >> > think the match data in this case should be (0 1 nil nil 0 1 nil nil).
> >> You can get that result by passing a list of the expected length as the
> >> REUSE argument to match-data:
> > True, but that also requires knowing the expected length. In the most
> > general case this should work for unknown regular expressions.
> I don't understand how the general case you describe could occur. If
> you don't know the expected length, that means you don't what groups are
> in the regexp, so you can only rely on group 0 existing, i.e., you only
> care about the first two elements in the match-data.
The context here is https://github.com/magnars/s.el/pull/117. Normally
you'd expect something like Python's Match.group
(https://docs.python.org/3/library/re.html#re.Match.group), i.e. a
group match per defined group, even if the group didn't match. That
Emacs doesn't behave this way is surprising and should at least be