Matching the [ character

[justin-neilon]

Hi there,
This may be a silly question but how would you match a term on the [ or ] characters?
As an example, I'd like to tag or match the below text (in []) as a comment:

this is text.[this is a comment]

the idea being that I'd tag it with the below, but this will be interpreted as a group:

nlp(text).match("[*]").text()

Is there a way to escape "special" characters?

[spencermountain]

Hey Justin, this is a really good idea. It's not currently possible, but I'd be happy to add support for this somehow in v14.
These characters would be considered whitespace, and are separated in the 'pre' and 'post' properties of term data - so we would need some additional query or syntax to reach for these. It's a good idea, as the current internal method for this is gross.
In the meantime, you can inspect .json() results with a for-loop and a regex. It won't be pretty. I can help you come up with a solution if you'd like
Cheers

[Drache93]

Probably a stupid question, but I assume the input text already had the square brackets, and you're trying to find them? Or are you meaning regex style groups?

Otherwise selecting bits of text is available with the .groups() method. You tell it which parts of your results are a group in matching, and you can access by index or by name.

https://observablehq.com/@spencermountain/compromise-accessors

nlp(text).match("[*]").group("0").text()

[justin-neilon]

unfortunately I'm looking for existing square brackets (I'm experimenting with making an Inform7 parser, to give you some context)

[Drache93]

Ah bad luck.

I was curious about cheating, and passing in your value as the match :D since the square brackets are already there. Probably with some escaping over certain values it should work. But no luck.

const text = "this is text.[this is a comment]";
const res = nlp(text).match(text).groups(); // result in no groups {}

I tried escaping the .

Matching only on "[this is a comment]" for testing, also didn't work. But matching on [this] worked fine. Without the .groups() same results, matching doesn't seem to like it.

Matching works on this, this is then breaks on this is a (returns empty).

@spencermountain Something weirder or am I missing something?

[spencermountain]

Hey @Drache93 - yeah, this will not be possible right now. we have a handful of @methods like @hasComma - and we could add @hasClosingSquareBracket and everything, but that blows.
I think it's a syntax issue - if anyone has a good idea for what this could look like, let me know.

@Drache93 - i've done a huge amount of work on the dev branch. It's 60% faster than our improvements earlier in the year, and also cleans up a lot of the this stuff you're describing. I can't wait to show you.

[spencermountain]

I think it's likely that some matches will get too complicated for a text query, and should be articulated in JSON. This is getting standardized in v14 - I will add support for pre/post punctuation queries.

anyway, just brainstorming -

// automagically interprets punctuation
nlp('walked (fast)').has('walked ( ')

// at-method with sorta-params
nlp('walked [fast]').has('walked @pre([)')

//unclosed angle-bracket to mark pre/post punctuation lookup
nlp('walked (fast)').has('walked <(')

[spencermountain]

solution for v14 (unreleased):

  let  regs = [{ word: 'may' }, { pre: '[' }]
  let m = nlp('may, [2019] foo').match(regs)
  m.text()
  // 'may, [2019]'

looking like december.

[Drache93]

60%!! Wow, that's really impressive. Look forward to it. The code base has clearly had some serious refactoring!

That looks really good. Makes more sense that your brainstorming. But personally I'm still not sure it's totally clear as an array.
An array passed into .match() would suggest to me either and AND or OR (not sure which :D ). Like match on any of these things (so my brain is leaning towards OR). Just checked, and that's how .lookup() works. So maybe confuses things if you use same syntax?
Last thought if I may! If the match is on may and the pre is [ that would say to me that we expect [may. Not may [. Does that make sense?

Considering .match() is a pretty core function, no harm in it taking an object of parameters as second argument. Currently 2nd arg is just a shortcut for .group().

I might be over thinking it, but hopefully food for thought.