You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm actually using the Python textile library, and filed a ticket on this there (textile/python-textile#16) but they (rightly) take the PHP version as the standard to follow. So I come before you with this humble feature request.
If you self-link a URL like
"$":https://github.com/textile/php-textile
the https:// scheme gets dropped from the linked string:
When I read the first example, I feel like my eye initially "scans" the link as text, and passes the content on to my brain to read. But the content doesn't read as text, so my brain has to stop and go over it again more carefully.
Whereas the second one scans immediately as a URL, and my eye just skips immediately to the next block of text, and there's much less of an interruption in the reading process.
This is a fairly minor issue for an individual link, but as you might guess from the example one of our use cases is documentation of web services, in which case we have lots of (long) URLs mixed in with text, and having them visually blend together becomes a bigger problem.
The text was updated successfully, but these errors were encountered:
Thanks for taking the time to post here; appreciated. IIRC, ths originally started as a request to suppress the email scheme in self-linked email addresses. The discussion originally took place when I was part of the Textpattern community and I cannot now remember if it was hammered out in the forum or on IRC. The closest forum discussion I can find is here but I don't have IRC logs going back that long. It seems that several Textpattern users voted for the omission of the scheme from the link text - and I was one of them.
I can certainly understand, though, that this is not a universally appealing decision.However, as the feature has been in php-textile since February 2012, I'm not willing to just to commit a change that re-instates the inclusion of the scheme.
I'm open to discussion on a way forward on this and a couple of options come to mind;
Add the ability to configure the list of excluded schemes
Add a new notation that includes the entire link as the link-text (perhaps "$+" instead of "$")
I'd be in favour of a new notation. It's clearly something that individual authors will have a preference for - and may even wish to use both styles within the same document for difference use cases.
Most importantly, I'd be against a change in behaviour that would cause a change in output when reprocessing a document with a newer build of php-textile.
Sorry for the very slow reply. I actually like the configuration-based approach, my feeling is that this is something that would be set as a system-wide preference. (I think the self-link-scheme-visibility branch is exactly what I'd be looking for.)
I'm actually using the Python textile library, and filed a ticket on this there (textile/python-textile#16) but they (rightly) take the PHP version as the standard to follow. So I come before you with this humble feature request.
If you self-link a URL like
the https:// scheme gets dropped from the linked string:
github.com/textile/php-textile
This seems less than ideal to me -- I think seeing the scheme really helps the reader "recognize" the string as a URL.
This gets to be more of an issue when you get into very long URLs (which is where the self-linking really comes in handy). Compare:
vs
When I read the first example, I feel like my eye initially "scans" the link as text, and passes the content on to my brain to read. But the content doesn't read as text, so my brain has to stop and go over it again more carefully.
Whereas the second one scans immediately as a URL, and my eye just skips immediately to the next block of text, and there's much less of an interruption in the reading process.
This is a fairly minor issue for an individual link, but as you might guess from the example one of our use cases is documentation of web services, in which case we have lots of (long) URLs mixed in with text, and having them visually blend together becomes a bigger problem.
The text was updated successfully, but these errors were encountered: