* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
@ 2023-12-03 12:52 Philip Kaludercic
2023-12-03 13:14 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Philip Kaludercic @ 2023-12-03 12:52 UTC (permalink / raw)
To: 67600
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Tags: patch
I noticed this recently when trying to extract a link to an mailing list
of mine hosted on SourceHut.
In GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw scroll bars) of 2023-11-25 built on icterid
Repository revision: 78eb99c72c6834a9161fc4e3f3cef3fc6bdffefd
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --with-imagemagick --with-x-toolkit=lucid
--with-native-compilation=aot --with-tree-sitter 'CFLAGS=-O2
-march=native -mtune=native -pipe''
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-dashes-to-thing-at-point-email-regexp.patch --]
[-- Type: text/patch, Size: 998 bytes --]
From 1caf9c71b7b0ad4a31a9318932b242f7a46183f5 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 3 Dec 2023 13:49:07 +0100
Subject: [PATCH] Add dashes to 'thing-at-point-email-regexp'
* lisp/thingatpt.el (thing-at-point-email-regexp): Allow for
a (thing-at-point 'email) query to match addresses with dashes, as
used by Sourcehut.
---
lisp/thingatpt.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/thingatpt.el b/lisp/thingatpt.el
index 88efbf73beb..80dc5ee60b7 100644
--- a/lisp/thingatpt.el
+++ b/lisp/thingatpt.el
@@ -652,7 +652,7 @@ thing-at-point-looking-at
;; Email addresses
(defvar thing-at-point-email-regexp
- "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
+ "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
"A regular expression probably matching an email address.
This does not match the real name portion, only the address, optionally
with angle brackets.")
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 23 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-03 12:52 bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp' Philip Kaludercic
@ 2023-12-03 13:14 ` Eli Zaretskii
2023-12-12 7:21 ` Philip Kaludercic
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-03 13:14 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 67600
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Sun, 03 Dec 2023 12:52:04 +0000
>
> I noticed this recently when trying to extract a link to an mailing list
> of mine hosted on SourceHut.
Looks like you are adding slashes, not dashes?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-03 13:14 ` Eli Zaretskii
@ 2023-12-12 7:21 ` Philip Kaludercic
2023-12-12 12:06 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Philip Kaludercic @ 2023-12-12 7:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67600
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 03 Dec 2023 12:52:04 +0000
>>
>> I noticed this recently when trying to extract a link to an mailing list
>> of mine hosted on SourceHut.
>
> Looks like you are adding slashes, not dashes?
Of course, my bad:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-slashes-to-thing-at-point-email-regexp.patch --]
[-- Type: text/x-diff, Size: 1000 bytes --]
From ee60512a4fa5fc33e1439c680505127828708d12 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 3 Dec 2023 13:49:07 +0100
Subject: [PATCH] Add slashes to 'thing-at-point-email-regexp'
* lisp/thingatpt.el (thing-at-point-email-regexp): Allow for
a (thing-at-point 'email) query to match addresses with slashes, as
used by Sourcehut.
---
lisp/thingatpt.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/thingatpt.el b/lisp/thingatpt.el
index 88efbf73beb..80dc5ee60b7 100644
--- a/lisp/thingatpt.el
+++ b/lisp/thingatpt.el
@@ -652,7 +652,7 @@ thing-at-point-looking-at
;; Email addresses
(defvar thing-at-point-email-regexp
- "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
+ "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
"A regular expression probably matching an email address.
This does not match the real name portion, only the address, optionally
with angle brackets.")
--
2.39.2
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 7:21 ` Philip Kaludercic
@ 2023-12-12 12:06 ` Eli Zaretskii
2023-12-12 12:21 ` Visuwesh
2023-12-16 10:41 ` Philip Kaludercic
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-12 12:06 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 67600
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: 67600@debbugs.gnu.org
> Date: Tue, 12 Dec 2023 07:21:18 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Date: Sun, 03 Dec 2023 12:52:04 +0000
> >>
> >> I noticed this recently when trying to extract a link to an mailing list
> >> of mine hosted on SourceHut.
> >
> > Looks like you are adding slashes, not dashes?
>
> Of course, my bad:
Thanks.
My bother here is that this could cause false positives whereby
thing-at-point would recognize file names with slashes as email
addresses. Because otherwise I don't understand why the slash was
omitted in the first place. Can we somehow make sure this won't
happen?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 12:06 ` Eli Zaretskii
@ 2023-12-12 12:21 ` Visuwesh
2023-12-12 12:27 ` Eli Zaretskii
2023-12-16 10:41 ` Philip Kaludercic
1 sibling, 1 reply; 16+ messages in thread
From: Visuwesh @ 2023-12-12 12:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Philip Kaludercic, 67600
[Tuesday December 12, 2023] Eli Zaretskii wrote:
> Thanks.
>
> My bother here is that this could cause false positives whereby
> thing-at-point would recognize file names with slashes as email
> addresses. Because otherwise I don't understand why the slash was
> omitted in the first place. Can we somehow make sure this won't
> happen?
I am running Emacs with the same change before Philip created this bug
report and so far I haven't had false positives for email addresses
because files with a @ in its name is rare. In practise, I think this
patch is harmless in that regard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 12:21 ` Visuwesh
@ 2023-12-12 12:27 ` Eli Zaretskii
2023-12-12 12:41 ` Visuwesh
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-12 12:27 UTC (permalink / raw)
To: Visuwesh; +Cc: philipk, 67600
> From: Visuwesh <visuweshm@gmail.com>
> Cc: Philip Kaludercic <philipk@posteo.net>, 67600@debbugs.gnu.org
> Date: Tue, 12 Dec 2023 17:51:32 +0530
>
> [Tuesday December 12, 2023] Eli Zaretskii wrote:
>
> > Thanks.
> >
> > My bother here is that this could cause false positives whereby
> > thing-at-point would recognize file names with slashes as email
> > addresses. Because otherwise I don't understand why the slash was
> > omitted in the first place. Can we somehow make sure this won't
> > happen?
>
> I am running Emacs with the same change before Philip created this bug
> report and so far I haven't had false positives for email addresses
> because files with a @ in its name is rare. In practise, I think this
> patch is harmless in that regard.
Remote files that have user@host in their names do have that
character.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 12:27 ` Eli Zaretskii
@ 2023-12-12 12:41 ` Visuwesh
2023-12-12 13:08 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2023-12-12 12:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: philipk, 67600
[Tuesday December 12, 2023] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: Philip Kaludercic <philipk@posteo.net>, 67600@debbugs.gnu.org
>> Date: Tue, 12 Dec 2023 17:51:32 +0530
>>
>> [Tuesday December 12, 2023] Eli Zaretskii wrote:
>>
>> > Thanks.
>> >
>> > My bother here is that this could cause false positives whereby
>> > thing-at-point would recognize file names with slashes as email
>> > addresses. Because otherwise I don't understand why the slash was
>> > omitted in the first place. Can we somehow make sure this won't
>> > happen?
>>
>> I am running Emacs with the same change before Philip created this bug
>> report and so far I haven't had false positives for email addresses
>> because files with a @ in its name is rare. In practise, I think this
>> patch is harmless in that regard.
>
> Remote files that have user@host in their names do have that
> character.
AFAIU, user cannot have slashes in them as per the POSIX standards [1]
and likewise with hostname so remote files should not pose a problem.
Of course this assumes that you're only looking at methods like ssh,
doas, sudo, etc. It seems like tramp disallows slashes in user and host
anyway, try:
(file-remote-p "/ssh:userwith/@host:/") ;; => nil
(file-remote-p "/ssh:userwith@host/:/") ;; => nil
(file-remote-p "/ssh:userwith@host:/") ;; => /ssh:userwith@host:
1. https://serverfault.com/a/578264
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 12:41 ` Visuwesh
@ 2023-12-12 13:08 ` Eli Zaretskii
2023-12-12 13:23 ` Visuwesh
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-12 13:08 UTC (permalink / raw)
To: Visuwesh; +Cc: philipk, 67600
> From: Visuwesh <visuweshm@gmail.com>
> Cc: philipk@posteo.net, 67600@debbugs.gnu.org
> Date: Tue, 12 Dec 2023 18:11:47 +0530
>
> [Tuesday December 12, 2023] Eli Zaretskii wrote:
>
> >> I am running Emacs with the same change before Philip created this bug
> >> report and so far I haven't had false positives for email addresses
> >> because files with a @ in its name is rare. In practise, I think this
> >> patch is harmless in that regard.
> >
> > Remote files that have user@host in their names do have that
> > character.
>
> AFAIU, user cannot have slashes in them as per the POSIX standards [1]
> and likewise with hostname so remote files should not pose a problem.
> Of course this assumes that you're only looking at methods like ssh,
> doas, sudo, etc. It seems like tramp disallows slashes in user and host
> anyway, try:
>
> (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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 13:08 ` Eli Zaretskii
@ 2023-12-12 13:23 ` Visuwesh
2023-12-12 13:35 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2023-12-12 13:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: philipk, 67600
[Tuesday December 12, 2023] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: philipk@posteo.net, 67600@debbugs.gnu.org
>> Date: Tue, 12 Dec 2023 18:11:47 +0530
>>
>> [Tuesday December 12, 2023] Eli Zaretskii wrote:
>>
>> >> I am running Emacs with the same change before Philip created this bug
>> >> report and so far I haven't had false positives for email addresses
>> >> because files with a @ in its name is rare. In practise, I think this
>> >> patch is harmless in that regard.
>> >
>> > Remote files that have user@host in their names do have that
>> > character.
>>
>> AFAIU, user cannot have slashes in them as per the POSIX standards [1]
>> and likewise with hostname so remote files should not pose a problem.
>> Of course this assumes that you're only looking at methods like ssh,
>> doas, sudo, etc. It seems like tramp disallows slashes in user and host
>> anyway, try:
>>
>> (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
then the matched string is again ssh:userwith@host. And this regexp
still matches the sr.ht list email addresses (this is the regexp I use
in my Emacs checkout).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 13:23 ` Visuwesh
@ 2023-12-12 13:35 ` Eli Zaretskii
2023-12-12 14:25 ` Visuwesh
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-12 13:35 UTC (permalink / raw)
To: Visuwesh; +Cc: philipk, 67600
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 13:35 ` Eli Zaretskii
@ 2023-12-12 14:25 ` Visuwesh
0 siblings, 0 replies; 16+ messages in thread
From: Visuwesh @ 2023-12-12 14:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: philipk, 67600
[Tuesday December 12, 2023] Eli Zaretskii wrote:
>> 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.
Thanks for the pointer but changing the email address regexp will have
no effect on the return value of (thing-at-point 'filename), and this is
what ffap does (along with other heuristics), and others will do when
they want to get the filename at point.
But IME, the filename thing-at-point matches are really limited compared
to the additional heuristics that ffap employs to match filename but
they still aren't perfect: filenames with spaces in them are only picked
up by ffap only when the point is over the "first word".
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-12 12:06 ` Eli Zaretskii
2023-12-12 12:21 ` Visuwesh
@ 2023-12-16 10:41 ` Philip Kaludercic
2023-12-16 13:38 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Philip Kaludercic @ 2023-12-16 10:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67600
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: 67600@debbugs.gnu.org
>> Date: Tue, 12 Dec 2023 07:21:18 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Date: Sun, 03 Dec 2023 12:52:04 +0000
>> >>
>> >> I noticed this recently when trying to extract a link to an mailing list
>> >> of mine hosted on SourceHut.
>> >
>> > Looks like you are adding slashes, not dashes?
>>
>> Of course, my bad:
>
> Thanks.
>
> My bother here is that this could cause false positives whereby
> thing-at-point would recognize file names with slashes as email
> addresses. Because otherwise I don't understand why the slash was
> omitted in the first place. Can we somehow make sure this won't
> happen?
One idea might be to just add slashes to the user name part of the
address, which would suffice to solve the issue I was having.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-16 10:41 ` Philip Kaludercic
@ 2023-12-16 13:38 ` Eli Zaretskii
2023-12-16 14:50 ` Philip Kaludercic
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-16 13:38 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 67600
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: 67600@debbugs.gnu.org
> Date: Sat, 16 Dec 2023 10:41:32 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: 67600@debbugs.gnu.org
> >> Date: Tue, 12 Dec 2023 07:21:18 +0000
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Philip Kaludercic <philipk@posteo.net>
> >> >> Date: Sun, 03 Dec 2023 12:52:04 +0000
> >> >>
> >> >> I noticed this recently when trying to extract a link to an mailing list
> >> >> of mine hosted on SourceHut.
> >> >
> >> > Looks like you are adding slashes, not dashes?
> >>
> >> Of course, my bad:
> >
> > Thanks.
> >
> > My bother here is that this could cause false positives whereby
> > thing-at-point would recognize file names with slashes as email
> > addresses. Because otherwise I don't understand why the slash was
> > omitted in the first place. Can we somehow make sure this won't
> > happen?
>
> One idea might be to just add slashes to the user name part of the
> address, which would suffice to solve the issue I was having.
Can you show a patch, so we could make sure we are on the same page?
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-16 13:38 ` Eli Zaretskii
@ 2023-12-16 14:50 ` Philip Kaludercic
2023-12-16 14:59 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Philip Kaludercic @ 2023-12-16 14:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67600
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: 67600@debbugs.gnu.org
>> Date: Sat, 16 Dec 2023 10:41:32 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: 67600@debbugs.gnu.org
>> >> Date: Tue, 12 Dec 2023 07:21:18 +0000
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> >> Date: Sun, 03 Dec 2023 12:52:04 +0000
>> >> >>
>> >> >> I noticed this recently when trying to extract a link to an mailing list
>> >> >> of mine hosted on SourceHut.
>> >> >
>> >> > Looks like you are adding slashes, not dashes?
>> >>
>> >> Of course, my bad:
>> >
>> > Thanks.
>> >
>> > My bother here is that this could cause false positives whereby
>> > thing-at-point would recognize file names with slashes as email
>> > addresses. Because otherwise I don't understand why the slash was
>> > omitted in the first place. Can we somehow make sure this won't
>> > happen?
>>
>> One idea might be to just add slashes to the user name part of the
>> address, which would suffice to solve the issue I was having.
>
> Can you show a patch, so we could make sure we are on the same page?
Never mind, I misremembered my own patch, this is already what I am
proposing.
- "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
+ "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
I had falsely assumed that my suggestion was to apply this change
- "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9/]+[-.a-zA-Z0-9/]*>?"
+ "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9/]+[-.a-zA-Z0-9/]*>?"
Which would risk more false positives.
--
Philip Kaludercic
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-16 14:50 ` Philip Kaludercic
@ 2023-12-16 14:59 ` Eli Zaretskii
2023-12-17 12:11 ` Philip Kaludercic
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-12-16 14:59 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 67600
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: 67600@debbugs.gnu.org
> Date: Sat, 16 Dec 2023 14:50:27 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Can you show a patch, so we could make sure we are on the same page?
>
> Never mind, I misremembered my own patch, this is already what I am
> proposing.
>
> - "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
> + "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
>
> I had falsely assumed that my suggestion was to apply this change
>
> - "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9/]+[-.a-zA-Z0-9/]*>?"
> + "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9/]+[-.a-zA-Z0-9/]*>?"
>
> Which would risk more false positives.
Thanks.
If you think the patch is safe enough, feel free to install. If there
are problems with it, I guess we will hear about them sooner or later.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp'
2023-12-16 14:59 ` Eli Zaretskii
@ 2023-12-17 12:11 ` Philip Kaludercic
0 siblings, 0 replies; 16+ messages in thread
From: Philip Kaludercic @ 2023-12-17 12:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67600-done
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: 67600@debbugs.gnu.org
>> Date: Sat, 16 Dec 2023 14:50:27 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Can you show a patch, so we could make sure we are on the same page?
>>
>> Never mind, I misremembered my own patch, this is already what I am
>> proposing.
>>
>> - "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
>> + "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9]+[-.a-zA-Z0-9]*>?"
>>
>> I had falsely assumed that my suggestion was to apply this change
>>
>> - "<?[-+_~a-zA-Z0-9][-+_.~:a-zA-Z0-9]*@[-a-zA-Z0-9/]+[-.a-zA-Z0-9/]*>?"
>> + "<?[-+_~a-zA-Z0-9/][-+_.~:a-zA-Z0-9/]*@[-a-zA-Z0-9/]+[-.a-zA-Z0-9/]*>?"
>>
>> Which would risk more false positives.
>
> Thanks.
>
> If you think the patch is safe enough, feel free to install. If there
> are problems with it, I guess we will hear about them sooner or later.
OK thanks, done.
--
Philip Kaludercic
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-12-17 12:11 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-03 12:52 bug#67600: [PATCH] Add dashes to 'thing-at-point-email-regexp' Philip Kaludercic
2023-12-03 13:14 ` Eli Zaretskii
2023-12-12 7:21 ` Philip Kaludercic
2023-12-12 12:06 ` Eli Zaretskii
2023-12-12 12:21 ` Visuwesh
2023-12-12 12:27 ` Eli Zaretskii
2023-12-12 12:41 ` Visuwesh
2023-12-12 13:08 ` Eli Zaretskii
2023-12-12 13:23 ` Visuwesh
2023-12-12 13:35 ` Eli Zaretskii
2023-12-12 14:25 ` Visuwesh
2023-12-16 10:41 ` Philip Kaludercic
2023-12-16 13:38 ` Eli Zaretskii
2023-12-16 14:50 ` Philip Kaludercic
2023-12-16 14:59 ` Eli Zaretskii
2023-12-17 12:11 ` Philip Kaludercic
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.