bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'

[Eli Zaretskii <eliz@gnu.org>]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: philipk@posteo.net,  67600@debbugs.gnu.org
> Date: Tue, 12 Dec 2023 18:53:25 +0530
> 
> >>     (file-remote-p "/ssh:userwith/@host:/") ;; => nil
> >>     (file-remote-p "/ssh:userwith@host/:/") ;; => nil
> >>     (file-remote-p "/ssh:userwith@host:/") ;; => /ssh:userwith@host:
> >
> > Why are you talking about slashes in user and host names?  There are
> > slashes in remote file names outside of those two.  Are you saying
> > that slashes in thing-at-point-email-regexp will only ever match if
> > they are in the user or host names?  That's not what I see:
> >
> >   (string-match "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?" 
> >     "/ssh:userwith@host:/what/ever/it/can/be")
> >       => 0
> 
> I see what you mean now.  But the problem is that even without the
> slashes in the regexp, the filename you gave matches:
> 
>    (string-match "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?" 
>      "/ssh:userwith@host:/what/ever/it/can/be") ;; => 1
> 
> the matched string is ssh:userwith@host.  So the old regexp will still
> return false positives when the point is on userwith@host I think.
> 
> With the slashes, the matched string is /ssh:userwith@host.  If we drop
> the slash from the first character class i.e.,
> 
>    (string-match "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?" 
>      "/ssh:userwith@host:/what/ever/it/can/be") ;; => 1

Yes, but now it matches without the leading slash, i.e. not entirely.
But see bug#67688.  My bother is that this change could perhaps
increase the probability of such mis-guesses.  Not sure it matters,
I'm just asking.