Confusing textwrap parameters, and request for RE help

[DL Neil]

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 at 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