vscode: Global regex search with "Not matching character" doesn't match newline

I just use \n{0} a the end of all my searches… been working fine so far…

This heuristic of using \n is my alternative to actually having a button or checkbox to enable multiline mode.

IMO it’s much better to have slower search than to potentially cause bugs (among other things), e.g. when someone refactors code and the search doesn’t match all it should, in which case you better hope your CI catches it.

Nothing worse than a regex engine that doesn’t comply to spec in such a glaring way as redefining \s to exclude \n, which is pretty unintuitive. I’d at least show a warning message when the regex contains \s.

Also, having an option to opt-in for \s to include \n seems reasonable to me.

All I can do is what I think is right for the majority of users and hope that the rest can google their way to a solution. Because of the perf impact and possibility for unexpected behavior I think multiline search should always be an explicit opt in. My guess is that we would add a button for this some day but it will take careful UX thinking because we have too many options crammed into a small space already.

I explicitly asked it to match any char that was not a ] To the best of my knowledge \n and \r are not ] so therefore should have been matched. There is no visible indication anywhere that multiline is turned on or off. It is just some magic that goes on behind the scenes. Only way to get consistent results would be to add \n{0} to every regex I do.

You may feel that \s should match only spaces and tabs but can you guarantee that every single user of VSCode would (1) know that that is indeed what is going on, and (2) know how to bypass the limitation if they needed to?

It seems like you are just saying that “if a regex can match \n then the multiline flag should be turned on”. Isn’t this the same as having the multiline flag turned on all the time?

Anyway to me the whole point is that the majority of regexes are not intended to match multiple lines, it’s quite common to include \s when you really are looking for spaces and tabs within a line. And including \s should not blow up your search results by matching a bunch of \r and \n when you did not explicitly ask for it.

This heuristic of using \n is my alternative to actually having a button or checkbox to enable multiline mode.

Then 👍 Big thumbs up that [^s] should indeed turn that mode on… Ok… I am up to date and agreeing. Good job everyone… take a 5 minute break and enjoy your evening.

Wanted to create a new issue that \s does not match newlines, but found this.

@roblourens Yeah, currently multiline mode is only turned on when a literal newline is in the regex, for perf.

How about better newline-regex detection? Something like this:

const { assert } = require("chai");

// Just came up with this, thus requires more tests. Doesn't match some edge cases.
// Requires a variable-length negative-lookbehind support, which is supported by latest ES
const IS_MULTILINE = /(?<!(?<!\\)\[[^\]]*)(?<!\\)\\[ns]|(?<!\\)\[\^(.(?<!(?<!\\)\\[ns]))*(?<!\\)\]|(?<!\\)\[(?!\^)[^\]]*(?<!\\)\\[ns]/;

assert.notOk(IS_MULTILINE.test(/[^\n]/));
assert.notOk(IS_MULTILINE.test(/[^\s]/));
assert.notOk(IS_MULTILINE.test(/\[^a]/));
assert.notOk(IS_MULTILINE.test(/[\\s]/));

assert.ok(IS_MULTILINE.test(/[^\\s]/));
assert.ok(IS_MULTILINE.test(/[^\\n]/));
assert.ok(IS_MULTILINE.test(/[^s]/));
assert.ok(IS_MULTILINE.test(/[\s]/));
assert.ok(IS_MULTILINE.test(/\[\s/));
assert.ok(IS_MULTILINE.test(/[^\s]\s\]/));
assert.ok(IS_MULTILINE.test(/\[\s\]/));