Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom Tromey <tom@tromey.com>]

Tom> -	"$hex\\s+<foo"
Tom> +	[string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]

>> Personally I find this a lot less readable than just writing out the
>> regular expression.

Tom> I find this style much less readable:
Tom> ...
Tom> set re "$hex\\s+<(\\.)?foo"
Tom> ...

Tom> That is, I don't understand why you would join logically separate
Tom> parts of the regexp together and force readers of the regexp to go
Tom> through the process of separating them out again.

The specific reason I do find this more readable is that reading a
regular expression is a skill I already have, whereas decoding:

 [string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]

requires picking through each part and trying to understand what the
point is.

Tom> It's also error prone, especially where the dot is concerned:
Tom> - if you forget the second backslash on the s, you get a mismatch and
Tom>   it's easily spotted.
Tom> - if you forget the second backslash on the dot, you still get a match,
Tom>   but it'll match any character, say the a in "0x00c0ffee <afoo>".
Tom> I've seen many examples of this mistake in the testsuite sources.

This is not a mistake per se, I think.  Like, it isn't an instance of
someone being confused as to what to write and picking the wrong one.  I
think it is rather laziness about the quoting combined with the
recognition that it is hardly likely to matter.

Not that I'm supporting laziness in all cases, but a lot of times it
really just isn't important.

Like, in this case, if one wrote "<.?foo" would this really ever trigger
erroneously?  In your example above, where does "afoo" come from?  It
seems to me that a situation like that can be solved by picking more
distinct symbol names, something we've already had to do plenty of times
when it turns out that some C library happens to define the same symbol
name as a test case.

Another thought here is that regexps interact badly with Tcl double
quotes.  But they aren't as bad when using braces.  So maybe that's
another approach.

Just to ground this discussion a bit, I don't really care about this
particular test.  You can land this patch if you want.  I'm not likely
to ever look at it again.  However this is more about the future
direction of the test suite in general.  I would be against a more
global replacement of relatively straightforward (to me) regular
expressions with concatenations of function calls, not to mention
requiring this very wordy approach in patches.

Today I wrote a Tcl implementation of the "quotemeta" thing from the
AdaCore internal test suite.  We discussed it once before.  I'll attach
it to that bug.  It does help quite a bit (IMO) but unfortunately not
with the particular problem in this thread.

Tom