Re: Failing to understand the oddities of the line chunk
On Mar 20, 2012, at 11:52 AM, Bob Sneidar wrote: So let it be done! But let's go with consistency in ALL things. Tough to do, as long as we're using English -- though you might have thought through this already (cough, cough):-) -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On Mar 20, 2012, at 1:52 AM, Geoff Canyon wrote: On Mon, Mar 19, 2012 at 12:54 PM, J. Landman Gay jac...@hyperactivesw.comwrote: I think it should behave the same way character selections do. A negative range has been a valid construct since HyperCard and is, actually, the only way to set the insertion point by script. It's a necessary feature. This seems to work, and is far clearer: *select* before char 8 of fld 1 after works as well, as do word and line references. Right, but if you have an insertion point in a field (no text selected), then the selectedChunk will contain something like char 13 to 12 of field 2 This is designed so that the selectedChunk is always in the form char startchar to endchar of fld fldNbr That's just the way it works. After dealing with chunks for a while it does make sense, and it's consistent. Jacque's point still holds, though -- the implementation of this form using lines instead of chars is *not* consistent. try this: put one,two,three into t replace comma with cr in t put t into tt put WHAT!!!??? into line 3 to 2 of tt put t cr cr tt which gives you: one two three WHAT!!!???one two three The WHAT should appear at the start of line 3, or possibly should replace the cr at the end of line 2, depending on how you look at it. I agree with you that this syntax should be blocked by the IDE at compile time if it's not going to be implemented properly at runtime. I'd call it a bug. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
I understand that this is what the engine returns when the selection is empty, and I'm prepared to accept it as a necessary method for the engine to describe an empty insertion point, but just because the engine reports char 13 to 12 doesn't mean the engine should accept setting the selection to char 47 to 26, or to word 9 to 3, or line 7 to 4. The engine returns one exact format, and allowing it to accept that one exact format should be all it does. There's no reason other than bad history to do so. On Tue, Mar 20, 2012 at 8:40 AM, Peter M. Brigham, MD pmb...@gmail.comwrote: Right, but if you have an insertion point in a field (no text selected), then the selectedChunk will contain something like char 13 to 12 of field 2 This is designed so that the selectedChunk is always in the form char startchar to endchar of fld fldNbr ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On Mar 20, 2012, at 10:00 AM, Klaus on-rev wrote: Hi Peter, Am 20.03.2012 um 14:40 schrieb Peter M. Brigham, MD: On Mar 20, 2012, at 1:52 AM, Geoff Canyon wrote: On Mon, Mar 19, 2012 at 12:54 PM, J. Landman Gay jac...@hyperactivesw.comwrote: ... Jacque's point still holds, though -- the implementation of this form using lines instead of chars is *not* consistent. try this: put one,two,three into t replace comma with cr in t put t into tt ##put WHAT!!!??? into line 3 to 2 of tt ## Wrong ORDER of line range! put Waht!!!??? into line 2 to 3 of tt ## Will give the desired result: That's my point. The compiler should reject put WHAT!!!??? into line 3 to 2 of tt if it's not going to implement it in a way that is consistent with put WHAT!!!??? into char 3 to 2 of tt -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
Folks- Maybe I've missed this, but has a bug been filed? I can't think of a use case where the current behavior is preferred, and I can't see how changing it to something more consistent and er... correct... would break any existing code. I think this is something the rev team should fix, or at least look into. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
If I may be so bold, remember the discussion about the filter command returning different results depending on whether or not the chunk ended in a CR or not? Some argued that that was how it ought to behave. Are we now saying that consistency is the order of the day? So let it be written! So let it be done! But let's go with consistency in ALL things. Bob On Mar 20, 2012, at 6:40 AM, Peter M. Brigham, MD wrote: Right, but if you have an insertion point in a field (no text selected), then the selectedChunk will contain something like char 13 to 12 of field 2 This is designed so that the selectedChunk is always in the form char startchar to endchar of fld fldNbr That's just the way it works. After dealing with chunks for a while it does make sense, and it's consistent. Jacque's point still holds, though -- the implementation of this form using lines instead of chars is *not* consistent. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
I think it's unlikely anything about this behavior will change no matter what bug report is filed. There's the backward compatibility issue you raised (although I personally think that is usually a cop out) but you could also argue that what happens is by design. I'm thinking your hope for a more right answer is probably in vain at this point! Pete On Tue, Mar 20, 2012 at 10:53 AM, Alex Tweedly a...@tweedly.net wrote: On 20/03/2012 17:17, Pete wrote: So I wouldn't vote for a bug report that asked for lines to behave like characters in this respect. I would vote for a bug report that asked for this situation to be caught as an error (although I think it would have to be a run time error not compile time since the start and end points could be variables or expressions). Lost in this discussion is the reason why someone wanted to do this in the first place. Alex, I think it was you that started this whole thread - did you have a specific reason for wanting to specify a line range with an end point before the start or was it just an observation? No, no specific reason to want to do it - it kind of happened by accident :-) And it wasn't so much an observation as a question - can someone give me a rationale for this behaviour so I can deal with it better ? What I *wanted* to do was replace line 'x' of someContainer (and everything after it) by my new data, so I did the (temptingly logical - but WRONG) thing of put newData into line x to -1 of someContainer NB that is simply wrong, because line -1 means the last line that is there - not to the end after what I specified :-) as it happened, the container had x-1 lines in it at the time (including a trailing line delimiter, just to confuse things), so that became equivalent to put newData into line x to x-1 of someContainer I knew that what was happening seemed wrong - but couldn't figure out how or why. Jacque's explanation showed me what I should do - but still left that niggling feeling of something being a bit odd. I can get what I wanted in a couple of safe ways a.delete line x to -1 of t!! inverted range - but AFAIK it does the right thing with it in all cases put newData into line 2 of t b.put newData into line 2 to kInfinity of t -- where kInfinity is some arbitrarily large constant I'm not sure what I would vote for now, hence I haven't yet put in a bug report. Personally, I'd probably like a run-time error, but I suspect that the need for backwards compatability would prevent that being feasible. -- Alex, still hoping for someone to come up with a more right answer :-) __**_ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode -- Pete Molly's Revenge http://www.mollysrevenge.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On 3/19/12 11:47 AM, Bob Sneidar wrote: If it resolves to an insertion point, then it's doing exactly what you would expect. It's putting something into that insertion point. That was my first reaction too, but on closer inspection it's putting the text into the wrong line. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
I can't help but feel that LC should flag a run time error in this situation. it's not logical for a range to have an end point less than its start point. Any other action requires an arbitrary decision on what the user wants to happen and, as evident from this thread, different users expect different things. Pete On Mon, Mar 19, 2012 at 10:29 AM, J. Landman Gay jac...@hyperactivesw.comwrote: On 3/19/12 11:47 AM, Bob Sneidar wrote: If it resolves to an insertion point, then it's doing exactly what you would expect. It's putting something into that insertion point. That was my first reaction too, but on closer inspection it's putting the text into the wrong line. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com __**_ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode -- Pete Molly's Revenge http://www.mollysrevenge.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On 3/19/12 12:42 PM, Pete wrote: I can't help but feel that LC should flag a run time error in this situation. it's not logical for a range to have an end point less than its start point. Any other action requires an arbitrary decision on what the user wants to happen and, as evident from this thread, different users expect different things. I think it should behave the same way character selections do. A negative range has been a valid construct since HyperCard and is, actually, the only way to set the insertion point by script. It's a necessary feature. When applied to lines instead of characters, the current implementation isn't following the same rules. My choice would be to make it consistent with the established behavior for character ranges. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On Mon, Mar 19, 2012 at 12:54 PM, J. Landman Gay jac...@hyperactivesw.comwrote: I think it should behave the same way character selections do. A negative range has been a valid construct since HyperCard and is, actually, the only way to set the insertion point by script. It's a necessary feature. This seems to work, and is far clearer: *select* before char 8 of fld 1 after works as well, as do word and line references. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
You're right (IMHO) - the original reason I struggled to understand this was not the trailing delimiter issue, but rather the incorrect handling of 'inverted' ranges in a chunk expression. There are a variety of possible valid interpretations of a inverted range (my opinion is that these are, in order): 1. normalize the order (as you suggested) (i.e. put xxx into line 3 to 2 ... would be equivalent to put xxx into line 2 to 3 ...) 2. take the from part of the chunk range expression, and stop there (i.e. put xxx into line 3 to 2 ... would be equivalent to put xxx into line 2 ...) 3. cause an error !!?? What it does now is (I think) equivalent to put xxx before line 3 of Which is consistent to viewing put xxx into (chunk) of (container) as being equivalent to put xxx before line tFROM of container repeat with i = tFROM to tTO of container delete line i of (the original) container end repeat So I can just about see that there is some consistency in the current method - but it is highly unintuitive and hard to predict. -- Alex. On 17/03/2012 20:31, Geoff Canyon wrote: This seems wrong to me. Regardless of how the engine interprets a chunk expression, a command of the form putsomething intosome chunk should result insome chunk containingsomething So the fact that you are putting b into something should result in that thing being b, where here the result is ba further, there's the fact that after the command, the chunk is still empty. So: put a cr into t;put b into line 2 to -1 of t;put line 2 to -1 of t is empty puts true. I did a quick check to take the negative line number out of this. If you have a field with contents: a b c then put line 2 to 1 of fld 1 puts empty, and put x into line 2 to 1 of fld 1 results in line 1 of the field being xa again, this feels wrong. line 2 to 1 of something should be an error. I can see the value of having it return empty when you are getting it, but putting something into it results in bad behavior. Another way of addressing this would be to say that chunk expressions always understand and follow proper order. So line 2 to 1 would be the same as line 1 to 2 Under that scenario, put x into line 2 to 1 of fld 1 would result in the field containing: x c and the original problem: put a CR into t; put b into line 2 to -1 of t; put t would put b which seems like a much more reasonable (and predictable) outcome. gc On Sat, Mar 17, 2012 at 11:33 AM, J. Landman Gay jac...@hyperactivesw.comwrote: On 3/17/12 8:16 AM, Alex Tweedly wrote: This code put a CR into t; put b into line 2 of t; put t produces (as I would expect) a b BUT put a CR into t; put b into line 2 to -1 of t; put t produces ba Why should adding the to -1 change this to put the new data before what was there before ? It's because of how the engine ignores trailing delimiters. The variable t contains only one line, so line 2 to -1 evaluates to line 2 to 1. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com __**_ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On 3/18/12 6:52 PM, Alex Tweedly wrote: You're right (IMHO) - the original reason I struggled to understand this was not the trailing delimiter issue, but rather the incorrect handling of 'inverted' ranges in a chunk expression. There are a variety of possible valid interpretations of a inverted range (my opinion is that these are, in order): An inverted range in character chunking equates to an insertion point. I.e., char 2 to 1 of a line is an insertion point after char 1. Testing for range inversion is one way to know whether a selection has any content. The behavior with lines looks like the engine is attempting that but it isn't acting the same. put a cr into t;put b into line 2 to -1 of t equates to put 'b' into line 2 to 1. If inverted ranges should yield an insertion point, then the insertion should go after after line 1. So it isn't acting quite the same way but it looks like it's supposed to. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
So from a consistency standpoint, you are certainly correct; putting something into a negative range should behave the same whether the chunk involved is characters, items, words, or lines. But I'd still argue that the use of into instead of before or after demands that the target resolve to a valid range, which should be replaced by the command. Trying to interpret it another way requires making an arbitrary decision about using the starting or ending part of the expression, and whether to put the string before or after that chunk -- arbitrary decisions that have obviously been made in different ways for lines and chars. On Sun, Mar 18, 2012 at 9:00 PM, J. Landman Gay jac...@hyperactivesw.comwrote: An inverted range in character chunking equates to an insertion point. I.e., char 2 to 1 of a line is an insertion point after char 1. Testing for range inversion is one way to know whether a selection has any content. The behavior with lines looks like the engine is attempting that but it isn't acting the same. put a cr into t;put b into line 2 to -1 of t equates to put 'b' into line 2 to 1. If inverted ranges should yield an insertion point, then the insertion should go after after line 1. So it isn't acting quite the same way but it looks like it's supposed to. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Failing to understand the oddities of the line chunk
This code put a CR into t; put b into line 2 of t; put t produces (as I would expect) a b BUT put a CR into t; put b into line 2 to -1 of t; put t produces ba Why should adding the to -1 change this to put the new data before what was there before ? I can see that there is no line 2, so saying line 2 to -1 does need to be interpreted. But if you specify a line number higher than exists, normally the string will be padded with enough CRs to make it work, e.g. put a CR into t; put b into line 3 of t; put t produces a b but put a CR into t; put b into line 3 to -1 of t; put t again produces ba -- Alex. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
On 3/17/12 8:16 AM, Alex Tweedly wrote: This code put a CR into t; put b into line 2 of t; put t produces (as I would expect) a b BUT put a CR into t; put b into line 2 to -1 of t; put t produces ba Why should adding the to -1 change this to put the new data before what was there before ? It's because of how the engine ignores trailing delimiters. The variable t contains only one line, so line 2 to -1 evaluates to line 2 to 1. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
What Jacque said. answer the number of items of 1,2, --give 2 Same with line delimiters. Craig Newman -Original Message- From: J. Landman Gay jac...@hyperactivesw.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Sat, Mar 17, 2012 12:35 pm Subject: Re: Failing to understand the oddities of the line chunk On 3/17/12 8:16 AM, Alex Tweedly wrote: This code put a CR into t; put b into line 2 of t; put t produces (as I would expect) a b BUT put a CR into t; put b into line 2 to -1 of t; put t produces ba Why should adding the to -1 change this to put the new data before what was there before ? It's because of how the engine ignores trailing delimiters. The variable t contains only one line, so line 2 to -1 evaluates to line 2 to 1. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Failing to understand the oddities of the line chunk
Thanks Jacque. I kept seeing it as line 2 to the end and so expected it to go there. I now see it; so I can simply do constant infinity=99 put a CR into t; put b into line 2 to infinity of t and I get the right (i.e. desired :-) answer. Thanks !! -- Alex On 17/03/2012 16:33, J. Landman Gay wrote: On 3/17/12 8:16 AM, Alex Tweedly wrote: This code put a CR into t; put b into line 2 of t; put t produces (as I would expect) a b BUT put a CR into t; put b into line 2 to -1 of t; put t produces ba Why should adding the to -1 change this to put the new data before what was there before ? It's because of how the engine ignores trailing delimiters. The variable t contains only one line, so line 2 to -1 evaluates to line 2 to 1. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
