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 th
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
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
To: How to use LiveCode
Sent: Sat, Mar 17, 2012 12:35 pm
Subject: Re: Failing to understand the oddities of the
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
This seems wrong to me. Regardless of how the engine interprets a chunk
expression, a command of the form put into should
result in containing 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
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,
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
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
If it resolves to an insertion point, then it's doing exactly what you would
expect. It's putting something into that insertion point.
Bob
On Mar 18, 2012, at 9:32 PM, Geoff Canyon wrote:
> So from a consistency standpoint, you are certainly correct; putting
> something into a negative range
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 Lan
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 diffe
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 t
On Mon, Mar 19, 2012 at 12:54 PM, J. Landman Gay
wrote:
> 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 wo
On Mar 20, 2012, at 1:52 AM, Geoff Canyon wrote:
> On Mon, Mar 19, 2012 at 12:54 PM, J. Landman Gay
> wrote:
>
>> 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 po
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
>> wrote:
>>
> ...
> Jacque's point still holds, though -- the implementation of this form using
> lines instead of chars is *
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 ch
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
>>> wrote:
>>>
>> ...
>> Jacque's point still holds, though -- th
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 le
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
I'd like to chime in here again on a couple of things.
First, I'm sticking by my assertion that a range with an end point less
than a start point is not a logical structure in a general sense. I'm well
aware the the selectedChunk uses that mechanism to indicate the position of
the insertion point
And I might add, you may or may not get a trailing CR in a filter result
depending on whether or not the whole chunk ended in a CR, regardless of
whether or not the filter results CONTAIN the last line with the trailing CR.
I think the overriding principle now is that once a command or function
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
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 "mor
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.comc
24 matches
Mail list logo
