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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
