[futurebasic] Re: [FB] Re: Line-wrapping in the Editor

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2010 : Group Archive : Group : All Groups

From: Max Taylor <maxclass@...>
Date: Wed, 20 Jan 2010 08:31:33 -0800
On Jan 20, 2010, at 7:19 AM, Stu Cram wrote:

> On 20-Jan-10, at 9:00 AM, Edwards, Waverly wrote:
> 
>> Overloading of the [+] sign would have an effect on the language.

<snip> Additional Overloading commetns

> I think there also could be
>  string1 += string2
> to concatenate string2 after string1.
> 
> I agree with Wave's comment - use something else for line continuation that has no other meaning in the language. ¬ by itself at the end of a line seems to meet that for now.

Me too.

I may have deleted it but I think I remember the original reason for this Subject had to do with the possible problem with using different fonts in different languages. Personally I have not basic problem with the "option-l"
key sequence.

I don't know what its ascii equivalent or key equivalent is that it might, in some circumstances, cause a problem but there is also another combination that I have not seen anyone discuss.

That is what has in the past been called a "soft carriage return".

It is generated with "shift+return" or "control+return". Checking it out in "Pages" with "show invisibles turned on" it has its own uniquely displayed visual glyph which looks just like the "option-l" except that it has an arrow head on the downward pointing portion.

It produces the same visual effect as a "carriage return" but I think it has a "unique" ascii character (possible) associated with it because it displays differently on the screen.

It might be worth checking it out as a possible alternative to the "option-l" combination if it turns out to be a little more universal in its scope. Apple has it in its applications and I think they think globally overall when implementing certain characters within their software.

It may be possible to use it also (or along side of) the "option-l" and possible substitute the same type of visual indicator within FB when it is used..

I did try it in FB and it does produce a carriage return effect (without any visual indication) but it brings up an error on compile. Seems that whatever code it generates could also be overlooked by the compiler just as the "option-l" is and possibly be more universally accepted world wide.

Just some more thoughts.

Max Taylor
The MaxClass Guy