Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrectly detects text as URL #39

Open
HaleTom opened this issue Feb 11, 2022 · 4 comments
Open

Incorrectly detects text as URL #39

HaleTom opened this issue Feb 11, 2022 · 4 comments

Comments

@HaleTom
Copy link

HaleTom commented Feb 11, 2022

I'm pasting my public key signature:

SHA256:+LMe8hqm106I3FUuQrqBBSLPffRHf8GgnL+fPunc7ek 2022-02-11 obsidian-main repo

What gets inserted:

[](<SHA256:+LMe8hqm106I3FUuQrqBBSLPffRHf8GgnL+fPunc7ek 2022-02-11 obsidian-main repo>)

I'm curious as to why the < and > are in there.

My config:
image

@GollyTicker
Copy link

GollyTicker commented May 7, 2022

Related to this. Why is the default fallback reg-exp this one?

[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)

I find it problematic in that the following text is detected as a URL when clearly it only contains an URL as part of some text:

some before text
https://example.com/hello-world
some after text

This is inconvinient, as it prevents me from simply pasting larger bodies of text containing URLs. Pasting it becomes this:

[](<some before text
https://example.com/hello-world
some after text>)

Notice the extra [](<...>) around the content. This unfortunately makes this plugin a bit less useful and beaks the flow.

However, if I use this reg-exp instead - which essentially just adds a ^ at front and $ at the back - ensuring that the entire body must be a URL,

^[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)$

then the above copy-statement simply works. (Edit: Fixed ^)

What speaks against using this new reg-exp? I think it's very common, that users of this plugin will copy larger bodies with contained URLs - and in this case I think the standard behavior should be, that it is not detected as an URL.

What do you think?

@Cito
Copy link
Contributor

Cito commented May 8, 2022

@HaleTom To answer the original question: The < and > are Markdown syntax to specify auto links.

@GollyTicker Makes sense. However, it should be a ^ instead of a # at the beginning of the regex.

@GollyTicker
Copy link

Thanks for the correction. Could we adapt this reg exp in the plugin to change the default behavior?

Adding test cases would also be nice, as I see that there are not testcases currently.

I could offer help, if you want.

@AhmadFCheema
Copy link

The Regex here for catching links is very buggy. Both the primary method to catch URIs and the Fallback Regular expression are problematic. Text with a colon : often gets matched. Other false-positives are: font-style: red, foo: bar, foo:bar, foo123: bar, etc.

One circumvention of these bugs is to, for the setting Behavior on pasting URL when nothing is selected, select Do nothing. While this won't fix the bugged matching of URIs and take away one nice feature, it will resolve the vast majority of bugged everyday pasting of common text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants