search: trim trailing whitespace

[ThomasAdam]

When amforma is given a string to search, if that string contains a
valid protocol (gemini://), and that string contains trailing
whitespace, then the string is treated as a search term.

Although perhaps slightly more uncommon, if the input string was as a
result of copy/paste then it's possible the string could contain
trailing spaces, which is not what was intended, but rather should be
removed so that it's treated either as a valid gemini:// link or a
search term.

Some efforts around this appeared in #138

Note that with respect to #138, I wonder if there's still more work to be
done? Currently, the following strings are considered valid search terms:

abc
gemini://xteddy.org

At the moment, the check for this happens both in the form of a regexp, and
some other conditionals in display/display.go. I think longer-term this
should be cleaned up, namely:

• Better define how search terms are recognised -- do we have a prefix for
  that, or do we just treat the absense of a protocol marker (foo://) as a
  legitimate seach term? Either way, we should be ignoring any whitespace
  coming before something which contains a protocol, as in:

  gemini://xteddy.org

  ... should not be treated as a search term.

• I am not sure regexing out the conditions for what is a valid protocol or a
  search term is necessarily the correct thing to do either. Perhaps we could
  go down the quoting route, whereby if someone did this:

  "I want this"

  ... as a search term, we treat the trailing space as noise and remove it,
  and then send along I want this as one term, without the quotes. But
  there's no standard in knowing how GUS or geminispace.info will
  interpret that appropriately.

[makew0rld]

Thanks for the fix and bringing this up!

Just a heads up your xteddy example is confusing, because the leading spaces you wrote got removed by GitHub's markdown renderer. Ironic.

Anyway I think the issue of accidentally pasting in links with extra spaces at the end or beginning is good thing to fix. I don't there needs to be anything more complicated then just adding a call to strings.TrimSpace though. So if you could switch out your line for that one that'd be great.

Better define how search terms are recognised

Is it not decently defined in #138 and in the code?

Perhaps we could go down the quoting route

Could you explain more what you meant? Did you mean to write " i want this" in your example? But even if you did, I don't think this is really necessary. I don't really see a use case where being able to include whitespace at the end or start is useful.

[ThomasAdam]

Thanks for the fix and bringing this up!

Just a heads up your xteddy example is confusing, because the leading spaces you wrote got removed by GitHub's markdown renderer. Ironic.

Ah, so it is! Ironic indeed. But you still understood my point; the whitespace should still be trimmed.

Anyway I think the issue of accidentally pasting in links with extra spaces at the end or beginning is good thing to fix. I don't there needs to be anything more complicated then just adding a call to strings.TrimSpace though. So if you could switch out your line for that one that'd be great.

Done.

Better define how search terms are recognised

Is it not decently defined in #138 and in the code?

It is, although I was referring more to the point that we have:

• hasSpaceisURL to check if what's being entered has a space and doesn't contain a URL
• Then the logic for checking against that regexp also has extra checks as well:

if (strings.Contains(query, " ") && !hasSpaceisURL.MatchString(query)) ||
    (!strings.HasPrefix(query, "//") && !strings.Contains(query, "://") &&
    !strings.Contains(query, ".")) && !strings.HasPrefix(query, "about:") {

I guess the point I'm making is that this could probably be cleaned up, but it works for now.

Could you explain more what you meant? Did you mean to write " i want this" in your example? But even if you did, I don't think this is really necessary. I don't really see a use case where being able to include whitespace at the end or start is useful.

Bloody markdown! ;) Yes, I was curious to know whether the whitespace sensitivity at the start/end of a phrase would be important for string matching in GUS or geminispace -- but I suspect it really isn't important at all at the moment. We can ignore this.

[makew0rld]

Thanks! Merged.

the logic for checking against that regexp also has extra checks as well

Ah I see. You could try to combine that into one regex, but I wonder if that just might make it harder to read rather than cleaner.