How to soft-wrap long text with no spaces? [SOLVED]

[bn]

Thanks Stan,

resizeStack is a very tricky handler if you want to get only one message after resizing is done.
In former times resizeStack was even trickier until Mark Waddingham revised it. I was easy to crash LC when doing weird stuff in resizeStack.
The laws of LC do not all apply in resizeStack. E.g., all the "send in time stuff" from inside resizeStack are apparently only sent after resizeStack finishes.
That is why I had to cancel the pending message except for one to get only 1 significant message in this special use case of resizeStack.

I have updated the sample stack here

https://forums.livecode.com/viewtopic.p ... 69#p217069

So no genius but humbly adapting to what is going on...

Kind regards
Bernd

PS I love "semantic reasons"

[bn]

Hi Stam,

here is a version of handler "wrapField" that uses "measureText". It seems to work a little faster and seems to be correct although the formatting is slightly different. I was just interested in how it compares.

Code: Select all

command wrapField2 pText
   local  tLineNum, tLineWidth, tFieldTextWidth, tCollectText, tNewText, t, t1
   put the width of me - (the leftMargin of me + the rightMargin of me) - (2 * the borderWidth of me) into tFieldTextWidth
   lock screen
   put the milliseconds into t
   repeat for each char tChar in pText
      put tChar after tCollectText
      put measureText(tCollectText,me) into tLineWidth
      if tLineWidth >= tFieldTextWidth then
         put char 1 to - 2 of tCollectText & return after tNewText
         delete char 1 to -2 of tCollectText
      end if 
   end repeat
   put tCollectText after tNewText
   
   set the text of me to tNewText
   
   put the milliseconds - t into t1
   put t1 && the length of tNewText into msg
end wrapField2

Kind regards
Bernd

[stam]

Bernd, you are a legend!

Like many other helpful things in LC, if you don't know they exist, you don't know they exist and it's nearly impossible to stumble upon them; and measureText is yet another function i hadn't heard of... learn something new everyday and some days twice a day!
Almost makes me wish the IDE would open with a 'Function of the day' or some such lol... Almost.

Yes, your handler is slightly faster but still slow (as expected) on longer texts and best served by deferring the wrap until after resizing - again thank you for helping with that...
Your handler also fixes an issue i discovered with my handler, where setting the uText to a long text that contains carriage returns would only re-wrap the 1st paragraph (i missed this initially because i forgot to set dontWrap to true and it was just wrapping text normally). Your way fixes this, so it's working pretty perfectly now!

I attach the final stack in case anyone else wants to test - two buttons set the uText of the field "multiLine" to a short (~1000 chars) or long (~5000 chars) string and present the wrapped text while storing the source text in the custom property uText of the field. Resizing the stack resizes the field and triggers a re-wrap, which is live for shorter texts (length < 1024) and deferred for longer texts. All the code is in a behaviour script for the field and card script for the resizing.

[FourthWorld]

Another option to consider:

If your users have an important need to view the full file path, readability of the path is enhanced when the line break occurs on "/", leaving each leaf intact so the user can quickly grasp the folder name. This is the same readability principle that prompts most text display to wrap at word boundaries.

Bernd's algo could be modified to use items instead of chars, with "/" as to the itemdel.

Even more readable (and radically faster) would be to replace "/" with " / " to let LC's natural soft wrap do the work.

[stam]

Another option to consider:

If your users have an important need to view the full file path, readability of the path is enhanced when the line break occurs on "/", leaving each leaf intact so the user can quickly grasp the folder name. This is the same readability principle that prompts most text display to wrap at word boundaries.

Bernd's algo could be modified to use items instead of chars, with "/" as to the itemdel.

Even more readable (and radically faster) would be to replace "/" with " / " to let LC's natural soft wrap do the work.

Great idea Richard - i'll implement that for my project i think.
I really should have thought of replacing "/" with "/ " so it wraps on the space... duh!

Nevertheless, this will probably find a use as a general character-wrapping method and it it works really well as it is - i'll pop stack onto sample stacks at some point, with a way to import the behaviour and resizing scripts to a different stack.

The background to all of this came about because i've been considering the new PolyList for a project and each item contains a couple of file paths - but with polyList you cannot edit the text directly as in a datagrid and the natural shape of it is narrower. So i added my skPopover for display and editing of the paths, but to accommodate the longer paths the popover would have to be ridiculously wide and short, better to have multi-line fields in it.

For my purposes, lining up the slashes would definitely make it easier to read and edit (of course i now have to figure out how to edit a hard-wrapped field but store it as single line, but i think the function formattedText will probably help with that).

Thank you everyone for your help!
Stam

[richmond62]

To edit a hard wrapped field & store it as a single line you might have to remove the delimiters again.

I wonder if text that has been hard wrapped by having " / " inserted into it will not, also, have had carriage returns inserted into it by the IDE which will have to be removed along with an delimiters you inserted?

[stam]

I think formattedText is designed to unwrap hard wrapped text as the stack I attached does - but not sure it will do, as I think it replaces CR with a space and 2 CRs with one CR. I’d need to test it though, not quite sure how it works.

However if I do wrap by replacing slash with slash & space & CR then I’ll just replace the latter with a slash to reconstitute the file path… should be straightforward (he says…)

[stam]

Further to this, using "/ " wasn't the answer - it just creates a huge list of single words which is actually more difficult to read as a filepath than a hard-wrapped filepath.

Surprisingly simple in my specific use-case to directly edit the hard-wrapped text, store a non-hard-wrapped version of the edit while re-wrapping the field, as i have no requirement to preserve CR: just remove all CR and set the uText of the field to this to present a hard-wrapped version while storing an accurate filepath - i put this in the behaviour script inside an closeField handler, which is called when exiting the field and the text has changed.

The formattedText function was not helpful - i think i misunderstood it's utility and if i've understood correctly this is helpful for changing a 'normally' wrapped field to a hard wrapped field (inserting CRs) and vice versa, not helpful at all in this context...

Thanks once again everyone for helping with what should have been a simple thing!

============
EDIT: For my own uses, I've made this into a palette (can be used as plugin), which will add 2 behaviour substacks to any topStack (1 for the wrapping behaviour and one for a card behaviour to implement the resizing functions), and shared it on sample stacks if anyone may have use of this:
https://livecodeshare.runrev.com/stack/ ... ppingField

Once copied into the topStack just assign the wrapping behaviour stack to the behaviour of any fields that need it and the resizing behaviour to the behaviour of the card. Worked well for me, but let me know if any issues...

S.

[FourthWorld]

Further to this, using "/ " wasn't the answer - it just creates a huge list of single words which is actually more difficult to read as a filepath than a hard-wrapped filepath.

Although a vertical list in which each line is one leaf of the path is what Apple's designers chose for the most commonly-used method of interacting with the file system, their GetFille dialog, that's not what I had in mind.

Attached is an example of the padding result I was imagining, with one example as described above for enhanced readability, and the other with the extra padding removed to keep the path as close as practical to the original string. Both methods use LC's built-in softwrap to do the heavy lifting with the efficiency we expect from compiled C++, the latter taking an extra step to use the formattedText as a source for then removing the padding.

Personally, when a path is long enough I don't find any representation particularly helpful, which is part of why Apple and other OS vendors have been steadily abstracting the file system away from the need for users to interact with it directly.

Just the same, here's the card script from the example:

Code: Select all

-- Goal: Allow the user to easily read every leaf of a file path given
-- LC's contraint of not imposing line wraps on non-word boundaries.
--
-- This example has three fields of equal size, where:
--
-- Field 1 contains the source, a full path to a file comprised of 906 characters,
-- which is longer than allowed on Windows but in par with the path length limit 
-- for macOS.
--
-- Field 2 shows two-liner for padding display to use LC's built-in softwrap.
--
-- Field 3 shows a longer handler that lets LC's built-in softwrap to the
-- heavy lifting, while using the formatted text to allow removal of the padding
-- to more closely preserve the original path string.


on resizeStack x,y
   put y div 3 into tShim
   set the rect of fld 1 to 0,0,x,tShim
   set the rect of fld 2 to 0,tShim,x,tShim*2
   set the rect of fld 3 to 0,tShim*2,x,y
   InsertWithWrapPadded the text of fld 1, the long id of fld 2
   InsertWithWrapFormatted the text of fld 1, the long id of fld 3
end resizeStack

on InsertWithWrapPadded pText, pDestField
   replace "/" with " / " in pText
   set the text of pDestField to pText
end InsertWithWrapPadded


on InsertWithWrapFormatted pText, pDestField
   lock screen
   replace "/" with "/ " in pText
   set the text of pDestField to pText
   get the formattedText of pDestField
   replace "/ " with "/" in it
   set the text of pDestField to it
   unlock screen
end InsertWithWrapFormatted
 

Path Wrapping.zip

(1.34 KiB) Downloaded 69 times

[stam]

Attached is an example of the padding result I was imagining, with one example as described above for enhanced readability, and the other with the extra padding removed to keep the path as close as practical to the original string. Both methods use LC's built-in softwrap to do the heavy lifting with the efficiency we expect from compiled C++, the latter taking an extra step to use the formattedText as a source for then removing the padding.

Thanks Richard that's really quite cool and showcases a brilliant use for formattedText - thank you.
Storing that in the code-bank!

[FourthWorld]

Our way of conceptualizing file systems is becoming as rare as knowing how to solder chips onto motherboards:

https://www.theverge.com/22684730/stude ... tion-gen-z

[stam]

Our way of conceptualizing file systems is becoming as rare as knowing how to solder chips onto motherboards:

https://www.theverge.com/22684730/stude ... tion-gen-z

On the face of it seems like an interesting article.
But I am deeply sceptical.

Pretending that people not being able to find directories is a new thing that only started 4 years ago is daft.
We can all regale tales of how 'stupid' users couldn't do 'basic' tasks spanning back decades, not years. This is no different.

Sure - many people now use mobile devices where interactions with file systems are different because of sandboxing - but the article is talking about university students who by definition have a pc or laptop - and the chance of most of these not understanding basic concepts about folders is, well, ludicrous.

I regularly teach medical undergraduate students and have done so for many years; the current lot are definitely 'gen z' with all the connotations that entails.
However, I can assure you that the 'inability to use folders' is not something I've ever witnessed, even in this lot. Not even remotely. Quite the opposite! Sure, they probably don't know the how the innards of a unix system is set up, managing folders and leveraging the file system presented to them by the OS of their choice is never an issue.

I call bullish*t.
Or more accurately, I call clickbait...

my $0.02 anyway...

[FourthWorld]

I regularly teach medical undergraduate students ...

Have you considered the possibility that such a demographic may not necessarily reflect the cognitive habits, self-discipline, learning attitudes, or even baseline IQ distribution of the general consumer population?

The article may overstate the case, but it seems reasonable there's a case here just the same.

Steve Jobs spent a chunk of the last years of his life focused on what he felt was liberating people from having to think in the strict taxonomical confines effective manual file management requires. It would not be surprising if his efforts were not entirely ineffectual.

And he's far from alone. What is the cloud?

[stam]

I regularly teach medical undergraduate students ...

Have you considered the possibility that such a demographic may not necessarily reflect the cognitive habits, self-discipline, learning attitudes, or even baseline IQ distribution of the general consumer population?

The article may overstate the case, but it seems reasonable there's a case here just the same.

Steve Jobs spent a chunk of the last years of his life focused on what he felt was liberating people from having to think in the strict taxonomical confines effective manual file management requires. It would not be surprising if his efforts were not entirely ineffectual.

And he's far from alone. What is the cloud?

Richard, the article did not comment on the 'general consumer population'.
It very specifically derived its 'data' from university students and professors teaching said students. Astrophysics students for example. These are not your 'general consumer population'.

The gist is 'look at these kids, they can't even find files and folders, they victims of a different computer paradigm because that's all these youngsters know'.

I'm not sure where you see the 'reasonable case', perhaps you have specific experiences that I don't - but a) the 'older' population as just as computer illiterate now as they were 20 years ago in my experience and b) I teach the very same segment of students this article proposes to be it's source of data and not never seen anything like it - quite the contrary, I find these youngsters much more computer savvy and increasingly so with the years.

Unless of course there's something special about American students? who knows...

S.

[richmond62]

By not thinking in terms of

strict taxonomical confines

my wife can never find files on her Xubuntu laptop.

As I am a lot more 'an*l' than she is and tend to be 'strictly taxonomically confined': so LiveCode files go in folders with an '_LC' suffix,
and so on, I can find the blasted things later.

Needless to say, unlike my wife, I can never find the fish-slice, a pair of socks or my book on Bengali scripts of the 19th century
(to name but a few); while she, thank goodness, can usually locate those things pretty quickly.

So, Steve Jobs may have freed people from lots of things; one of which is how to find one's files in a seven-eight level file system
without using the incredibly annoying Find File thing on macOS, or the even worse Catfish on Xubuntu.

But, this is a common tendency: most teenagers I teach cannot add 2 2-figure numbers together without a calculator.

I always tell them, "When I go to the jungle my slide-rule goes with me."