[LyX/master] Allow an 'other' type for hyperlinks. Format change.

[Jürgen Spitzmüller]

Am Montag, dem 26.12.2022 um 11:45 -0500 schrieb Richard Kimberly Heck:
> What I was thinking here was that "Other" would more or less act like
> 'literal', in the sense that it would just output whatever's there.

Yes. Would it make more sense to rename this to "Custom"? After all,
it's completely fine to enter mailto, web or any other valid or invalid
URI there. Also relative URIs, btw, which has been not possible before,
AFAICS.

> The special handling of "http" with the Web one confused me; I missed
> that it would also handle "ftp://". 

And https://, ftps://, ldap://, git:// and any scheme, as long as an
"authority" part is indicated by double slash (it only checks for "://"
in the string).

> But now I wonder whether we should change "Web" to "HTTP" or
> something like that, and let everything 'literal' be 
> handled by "Other". Then we could say something like:
> 
>      Web: Adds "http://" if not given (but also allows other
> 'authorities')

or "other schemes, if an authority is specified".

>      EMail: Adds "mailto:" if not given.
>      File: Adds "file://" if not given.
>      Other: Outputs as is.
> 
> Then I'd write a lyx2lyx script that would convert non-http targets
> to other.
> 
> Alternatively, I'm starting to wonder how useful these 'types' really
> are. Does it really save people a lot of effort not to have to write 
> "mailto" or "http"? Or is that just more confusing?

I think it was thought to help people who are not familiar with the URI
syntax at all (who don't know that email addresses need to be prefixed
by mailto: and file addresses by file:). And probably do not even know
what http means (except that it is somehow involved in internet
addresses).

In my opinion a more sensible UI would feature a combo box with a range
of common schemes (http, https, ftp, ftps, mailto, file, tel, doi, git,
ldap, ...), represented in the combo by more accessible descriptions,
(e.g., "Web Hypertext (http)", "Web Hypertext, Secured (https)", ...),
and "Custom". 

We could also not only check if the current scheme is already prefixed,
but also if _a different_ one is (think of the http://tel: case you
just addressed). We have QURL at disposal which could help us here with
parsing the components and a basic validation, and we could add
LineEdit validators for all URIs except Custom.

But maybe that's post-2.4 stuff and we just release 2.4 with what we
have now, which is already an improvement.

Jürgen


> 
> Riki
> 
> 

-- 
Jürgen