I didn't know commas were letters

[stam]

“Beginner” in this specific instance refers to knowing how to ask a question that will give you the answer you want.

It is not related to how knowledgeable you are, but it is a general developer trait; a key skill is to know how to ask the right question.

The sheer number of posts you’ve made n this forum would suggest you should know better. It’s not about how much you know than I do or vice versa. It’s a basic skill.

Why should I bother answering your question when you then just turn around and state something like yeah but that won’t brew my coffee to my liking (meaning something completely irrelevant to the question asked), instead of actually thanking people taking an interest in your problem and then developing the discussion to the direction you need?

Like I stated before, conversing with you is an exercise in futility and I’ll desist now. Best of luck.

[richmond62]

a key skill is to know how to ask the right question.

Well, as Ludwig Wittgenstein pointed out, not many people seem to know how to ask questions.

[dunbarx]

Richmond.

I too find it hard to follow many of your threads. And I know you are a serious person.

Anyway, since you and I are both old-fashioned, at least as concerns this language, it is a shame that the filter command does not deal with words. If it did, you could simply:

Code: Select all

filter words of yourText without "|*"

WildCards are regex "light".

Craig

[stam]

Yes, but that’s is not what Richmond wants apparently, even after his explicit explanations what he wanted:

Yes, it will, but it will not allow you to perform further operations on those words.

Using regex with matchChunk gets the offset of a pattern match.
I had written a function that returns the start and end char number of a match, as well as the matched string for all occurrences of a pattern within a string and posted in my regex primer.

This is a workaround for the lack of global matches in PCRE regex, which is the flavour of regex available in LiveCode. You can find the function here:
https://github.com/stam66/regexPrimerFo ... workaround

[tetsuo29]

When your item delimiter is a space, and your loop gets to "cheese|pickle," that is a word.

When you put "cheese|pickle," into DIX and then set the item delimiter to "|" then, item 1 of DIX is "cheese" and item 2 of DIX is "pickle,".

You're choosing to just put item 1 of DIX into DUX so DUX just is "cheese".

This ("cheese") is the only part of DIX that you are placing into field 2.

How is the comma supposed to be passed to field 2? It's not part of anything that you are preserving and passing.

Were you expecting the comma to be treated as its own word? Like you were thinking that when the loop got to "cheese|pickle," that that word would only be "cheese|pickle" and that the comma would get picked up as a word on the next iteration of your loop?

Test my theory and see what item 2 of DIX is when "cheese|pickle," is encountered.

If item 2 of DIX has trailing characters that need to be preserved then you will want to find a way to identify them and concatenate them onto DUX when adding more text to field 2.

[richmond62]

I am NOT expecting the comma to be treated either as a word or part of a word, I am expecting it to be treated as punctuation: obviously the term word is unable to distinguish that.

[tetsuo29]

I am NOT expecting the comma to be treated either as a word or part of a word, I am expecting it to be treated as punctuation: obviously the term word is unable to distinguish that.

If it's not a word or a part of a word how is it supposed to magically be transported into field 2? Nothing goes to field 2 without an instruction to put it there, right? Your code only moves words or items to field 2 or did I miss something?

[FourthWorld]

I am NOT expecting the comma to be treated either as a word or part of a word, I am expecting it to be treated as punctuation: obviously the term word is unable to distinguish that.

HyperCard got a lot of things right. Its novel redefinition of "word" isn't among them.

I have no reason to mislead you in suggesting trueWord when you want to parse true words. Try it where using "word" doesn't do what you want and see if the outcome improves.

[dunbarx]

@Richmond.

Did you understand what Richard was suggesting to you?

The number of words in

Code: Select all

aa bb , cc, dd

is 5 whereas number of trueWords is 4.

Won't "trueWords" allow you to parse out commas in your text? It "undoes" the old HC definition of what a word is, in terms of what you consider "punctuation".

@ Richard. I dunno, I do not see the issue with

Code: Select all

 aa, bb, cc

being three words, that is, space is the word delimiter, period. I did always dislike the fact that HC decided that text within parentheses defined words in its own way,

Code: Select all

"aa, bb , cc"

being one word. I thought that was utterly unnecessary and worse, confusing.

Craig

[dunbarx]

Richmond.

I am NOT expecting the comma to be treated either as a word or part of a word, I am expecting it to be treated as punctuation: obviously the term word is unable to distinguish that.

So you are saying that LC needs to distinguish "punctuation" (the comma in particular?) in some new and different way, that is, not just a character. I mean, I think, it would be a new chunk type.

OK, but why? Where does this cause any additional effort or unwanted confusion? Where would that new state of affairs be useful, or streamline what we already have?

And why stop at the comma? How about the colon or semicolon? But again, where does this either slow us down or confuse us? Think it the other way, can you give an example how it might be of real value?

Craig

[FourthWorld]

@ Richard. I dunno, I do not see the issue with

Code: Select all

 aa, bb, cc

being three words, that is, space is the word delimiter, period.

Something that offers a space delimiter is useful, and "word" has a feature the standard item delimiter doesn't, in not counting multiple delimiters as delimiting empty chunks.

Useful, but not how we use "word" in any context outside of xTalk.

In natural language words are considered distinct from punctuation.

The redefinition of "word" by the HyperCard team then goes further to define multiple words within double quotes as a single word, which is also useful yet also not how "word" is defined in any natural language.

Learnability is aided by using novel terms to describe novel concepts.

Richmond is not new to xTalk, but as a linguist and a common speaker it isn't surprising that the unusual definition of "word" in xTalk remains a source of confusion.

I suppose spaceDelimitedNoveltySometimesUsefulForCertainParsingTasks might have been a bit much. But if I had been in the room when the behavior of "word" was defined I might have argued as strongly for using a novel term to describe a novel concept almost as strongly as I would have advised against the "sometimes rule" of allowing some function calls to be made with property syntax.

But many human artifacts are accidents of history, and that this is one more is certainly not the worst cognitive challenge our species has faced.

And with the relatively recent addition of "trueWord", at last we have a chunk type that works in LC as words work in the rest of the world.

[dunbarx]

Richard.

Ah, pointing out the "specialNess" of the word delimiter, space, is timely. I haven't thought about this in decades. It is special in just the way you said, a string of spaces of arbitrary length is a countable string of chars, but only one delimiter. I assume that construct is deeply buried in the engine, which is why a brand new chunk, the "trueWord" was required to amend that issue.

Richmond?

Craig

[FourthWorld]

Ah, pointing out the "specialNess" of the word delimiter, space, is timely. I haven't thought about this in decades. It is special in just the way you said, a string of spaces of arbitrary length is a countable string of chars, but only one delimiter. I assume that construct is deeply buried in the engine, which is why a brand new chunk, the "trueWord" was required to amend that issue.

The trueWord chunk type also supports that useful feature of words, tho in a way more conformant with normal definitions of "word".

Where trueWord differs is counting only actual words. It doesn't include punctuation as part of a word, and it doesn't treat multiple words between double quotes as a single word.

[richmond62]

My 'problem' with trueWord is that if I throw 'cheese|smelly' at it it splits that up into 2 words when for my needs I need to treat it as a 2 item thing with '|' as the itemDelimiter.

[dunbarx]

Richmond.

That is the way "trueWords" works. But I do not understand what you said:

... when for my needs I need to treat it as a 2 item thing with '|' as the itemDelimiter.

What about simply:

Code: Select all

set the itemDel to "|"
answer item 1 of "cheese|smelly" & return & item 2 of "cheese|smelly"

You are out of the word world and into the item world. That should obviate all issues, since the itemDel rules.

Craig