Confusing textwrap parameters, and request for RE help
DL Neil
PythonList at DancesWithMice.info
Wed Mar 25 05:29:35 EDT 2020
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
More information about the Python-list
mailing list