On 25/03/20 11:57 AM, Chris Angelico wrote:
On Wed, Mar 25, 2020 at 9:37 AM DL Neil via Python-list
<python-list@python.org> wrote:
As you observe, the problem with terminal emulators is the extent of
their emulation and the degree of adoption of their 'extended features'!
My concern grows because of the need (I assume) for the URL to be
'clickable', not merely 'complete' and 'unadorned' (no added hyphen
rendering it useless).
A complete URL is clickable. If I print out the string
"https://example.com/"; then it can be right-clicked and copied, or
sent to a browser, or whatever. (Technically I don't need it to be
"clickable", but the terminal emulator has to recognize it as a link.)
FTR I'm using XFCE and xfce4-terminal, although I think everything
applies to most of the popular terminal emulators.
The problem is that a long URL will wrap. So my options are:
1) Let it wrap, violating the indentation
2) Break it, which stops it from being clickable
3) Get help from the terminal emulator
Despite the almost-irresistible urge to prove that I'm a class-y guy
[albeit with a warped sense of humor], I'm warming to the 'partition'
suggestion:
- the output from textwrap.wrap() is a list of strings,
- we are talking about fixed-length lines denominated in characters,
- locating a[ll] URI (from a sub-set of schemes, eg "http", "https",
...) is a well-worn path.
I'm not bothered too much by specific schemes. If a word matches the
regex ^[a-z]+:// then I'll call it a URL.
Thus (simplified to assume the presence of exactly one URI!!!):
- textwrap the first partition
- len( URI )
- it becomes trivial to ascertain if the URL might append the last line
(of the first 'wrapped' partition)
- failing that, the URI must start a new line (by defn)
- if it is 'too long', ie would be wrapped by textwrap, treat it separately,
- conversely, prepend the URI to the third partition,
- text-wrap the third partition,
- assemble the tweet-display.
Hmm. So, basically, manual reimplementation of parts of textwrap. I'll
hold that thought for later... if it's possible to just change the
regex and keep the code unchanged, I'll prefer that, but this is a
possibility. Thanks.
Thought I'd better buy-in some groceries before the country goes into
lock-down at midnight, but this problem was amusing me whilst awaiting
my turn to get into the store, to the check-out,...
1 what features does the terminal offer when a user 'clicks'?
Is it only applicable to URLs and linked to the web-browser within
"Preferred Applications"? Are you able to 'grab' that click from the
app? eg MOUSEDOWN*.
2 ultimately, you're on-a-hiding-to-nothing (apologies to
non-English-English speakers: means 'no hope'!) given that URLs are
defined by, but not length-limited by, RFC. Any 'limits' are applied by
implementation/web-browser publishers. Currently in-use editions may
vary widely, ie from 2K~64K. Any and all of which would blow terminal
line-lengths right out-of-the-water.
(that was the thought nagging at the back of my mind earlier - but we've
been talking about 'the terminal', ie outside of the limitations of a
web-browser environment, so it was insufficiently assertive)
The usual work-around (which I thought was initially/largely motivated
by the Tweet's 140-character limit) was to use a URL-shortener - gaining
brevity at the expense of double-handling. In reality, as time has
gone-by, various ones expressed concerns about (institutionalised)
bit-rot and raise security issues ('what am I actually clicking on?').
There was actually a W3C "Working Group Note" that has been released
into the public domain (a small surprise to me), detailing "Curie"-s.
Sadly, as-yet I don't think any (major) web-browser offers an
implementation. (mea culpa?) I seriously doubt that Gnome Terminal has
implemented same/similar!
However, may we return to my earlier question: could the app trap a
'click'? In which case, the app could store the actual-URI and provide
its own Curie-like URL-shortening service, by substituting some
(shorter!) 'click-here' text into the presentation. On the
return-journey, in capturing the click, the app could substitute
back-again before passing the full-length URI to the web-browser.
QED?
(smirk - Murphy meets "The best laid plans of mice and men...")
(apologies, I don't use Gnome - it didn't/doesn't offer the
multi-display control/flexibility I require)
* I've been looking at edX's "Creative Coding" online course. It is
aimed at artists and animators learning to code, and thus aims to make
the computer draw (instead of counting dollars-and-cents, per the usual
course-format). Sadly it is JavaScript-based (the p5.js library). Why do
things the easy way? Nah! Instead, I've been investigating a 'corner' of
Python with which I have had no contact to date. The Pygame library
offers a drawing "canvas", hence it gaining my attention. Plus, without
the complication of a full-fat GUI, (I think) it will present text AND
allow keyboard and mouse-key trapping - all from the comfort and glory
of a terminal-based Python program...
Have you ever poked into this dark corner of the pip-y-verse?
Would you like a PoC (I'll call it 'coursework')? (tomorrow)
Web.Refs:
https://www.w3.org/TR/2010/NOTE-curie-20101216/
https://www.pygame.org/docs (site under maintenance at this moment)
https://www.edx.org/course/creative-coding
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
