Selection of words with leading '.' broken since "support nested parentheses" change

[clayne]

Problem:

If one tries to select a word from a line like:

clayne@a4-sfx:~ $ find -maxdepth 1 -type f -name '.bash*'
./.bashrc
./.bash_history
./.bash_profile

The selection will ignore the leading . leaving only /.bashrc in the selection buffer. This is new (and surprising) behavior. In efforts of figuring out what the problem was, I bisected between 3.0.0 and HEAD and found:

656d58bc5625eacf3eeb95d541a64c580d703f83 is the first bad commit
commit 656d58bc5625eacf3eeb95d541a64c580d703f83
Author: mintty <mintty@users.noreply.github.com>
Date:   Mon Feb 13 00:00:00 2023 +0100

    hover and open URL: support nested parentheses (#1196)

 src/termmouse.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 55 insertions(+), 4 deletions(-)
bisect found first bad commit

From this version:

clayne@a4-sfx:~/git/mintty (master=) $ git tag --contains 656d58bc5625eacf3eeb95d541a64c580d703f83
3.6.4

Repro of bisect environment:

The bisect script I used as /tmp/mintty-bisect:

#!/bin/bash

set -e
set -o pipefail

cd ~/git/mintty \
       	&& make clean \
       	&& make -j16 exe \
       	&& bin/cygwin64/mintty -h always bash -c 'echo ./foo.bar' \
       	|| exit 125

echo 'Press enter for GOOD and any other character for BAD' 1>&2
IFS='' read -rn1 tmp && [[ -z "$tmp" ]]

And this command to kick it off:

cd ~/git/mintty \
       	&& git bisect reset \
       	&& git bisect start HEAD 3.0.0 \
       	&& git bisect run /tmp/mintty-bisect

Note: some builds will naturally fail depending on how recent the gcc version is on the host (-Werror).

[BrianInglis]

WJFFM - Works Just Fine For Me:

$ mintty -v
mintty 3.6.4 (x86_64-pc-cygwin)
© 2023 Thomas Wolff, Andy Koppe
License GPLv3+: GNU GPL version 3 or later
There is no warranty, to the extent permitted by law.
$ find -maxdepth 1 -name '.bash*'
./.bashrc
./.bash_aliases
./.bash_completion
./.bash_env
./.bash_functions
./.bash_history
./.bash_logout
./.bash_profile
$ echo ./.bash_env

Only if you don't get your mouse cursor into the left margin, will it skip the leading . dot.
Are you using a small or non-mono font and/or small window?
It might be safer if it did not select the / slash as the first character when it is directly prefixed by anything, back to protocol scheme ...:/\+ or blank, or included other prefix and / slash.
Is this some compromise between URL and path selection?

[mintty]

Hotfix:

diff --git a/src/termmouse.c b/src/termmouse.c
index dca3ca18..b32fcc3e 100644
--- a/src/termmouse.c
+++ b/src/termmouse.c
@@ -59,7 +59,7 @@ static char scheme = 0;
       else if (c == '/') {
         scheme = '/';
       }
-      else if (scheme)
+      else if (scheme && c != '.')  // #1208
         break;
       else
         scheme = 0;

[clayne]

@BrianInglis It doesn't actually work correctly. The following is a trivial repro:

$ echo "./.bashrc"
./.bashrc

Double click on the bashrc part and it will stop on the / leaving /.bashrc in the selection buffer.

@mintty I submitted a PR to fix the state machine in a more fundamental way as it is not properly accounting for the required // part of the URI spec (other chars preceding / could also break it, e.g. _/foo) and technically the spec allows [.+-] within the scheme portion: #1209

[lazka]

Another thing I noticed is that "~/foo/bar" no longer get selected fully.

[spsilk]

I'm also experiencing this issue on mintty 3.6.4.

3.6.2 seems fine.

Before realizing this issue was already discussed in this thread, I had asked about it on unix.stackexchange. I thought at the time I had just mucked up some setting dictating how text selection is broken.

That post is here: https://unix.stackexchange.com/questions/752370/double-click-in-cygwin-not-selecting-dot-at-beginning-of-paths/

In that post, I included a bunch of screenshots showing examples of "incorrect" (or at least different from 3.6.2) text selection. In case that clarifies the discussion above.

@BrianInglis I also noticed I can replicate mintty 3.6.2's selection if I double click right on the leading dot. But this is certainly different from mintty 3.6.2 behaviour.

Thanks.

[mintty]

This is fixed already in the mintty repository, for 3.6.5.

[clayne]

This is fixed already in the mintty repository, for 3.6.5.

Any chance we can get a release? :-)

[mintty]

Half a dozen issues remaining.

[mintty]

Release 3.6.5.