World: r3wp

And worse .. it's intermittent!

I see that too, but I thought it had something to do with Synergy, 
because I see it in other apps too.

It works here, with and without synergy (if we mean the same program, 
the tcp/ip km switch to use the same mouse and keyboard for two computers).
WinXP

Yes, I've noticed something has changed there. (Probably should check 
the AltME changes log for a different behaviour.)

(Mm.. not much written in the changelog.)

I'm finding the AltME under LInux seems to sync much better than 
AltME under Windows. By checking the web public discussions at rebol.net, 
I found that  some topics hadn't synced. I dotted but no effect. 
So I switched to Linux  where AltME synced everything.

It may be that it was just a different installation that did it ..

Why is file share disabled in this world?

I would like to share a slideshow.

I think it had something to do with that the world was created before 
filesharing was available

No, just was not turned on here.

Any plan to turn file sharing on?

is it rebol on os x or altme, pasting code into altme doesn't keep 
newlines and tabs, if it is an altme issue then a fix would be very 
welcome 8)

Louis:  This is not my world, you would have to ask Carl.

Will, pasted from what?  That is the key.  Please look at the contents 
of your paste in a hex editor, and tell me if it has CR, LF, LF + 
CR,. or CR + LF.

Reichart, ok. Thanks for answering. By the way, I really like AltME.

Thanks.   It is funny, where the lines of responsibility lay.

Tried cr lf crlf, not sure if the clipboard get modified automagically, 
but can't paste with newline. Maybe some other os x user can check. 
No problem with tabs..

I have a Mac, but today I'm away from it.

The source does matter, try writting a couple of lines with TextEdit, 
and also try copying and pasting from a website.

Tried a variety of combination 8)

So you are saying that all source lose line info?

Yes, maybe someone can test

I will test Monday.

I can confirm that this is the case, and it is very annoying.

Problem can be easily demonstrated by copying the following three 
lines from TexEdit (Notepad like default text editor on Mac):

One
Two
Three

Interestingly enough, if I copy and paste the above "line" back into 
TextEdit then they appear as three seperate lines again.

>> view layout [t: area]
(escape)
>> t/text
== "this is^Ma^Mtest"

Pasted from TextEdit

so it seems that VID doesn't handle that correctly. If I type the 
text in including ^M manually, I get the same result (line breaks 
are ignored)

>> t/text: rejoin ["this is" newline "a" newline "test"]   
== "this is^/a^/test"
>> show t

That works

For the record:
>> newline
== #"^/"
>> crlf
== "^M^/"

>> t/text
== "this is^/a^/test"

This is from Notepad in WindowsXP.

MS IM on Mac has same issue.

at least for cut & paste. Not so for manual

Henrik, thank you for the research.    So, VID has it too?  And to 
confirm, you get different results on Windows and Mac?

Only the last test above was done in Windows XP. The others were 
done in OSX.


When I paste from TextEdit in MacOSX into a VID textarea, ^M is pasted, 
and it doesn't work right. When I paste from Notepad in Windows into 
a VID textarea, ^/ is pasted and it works correctly. So the results 
are different, yes.


When I copy and paste from a VID textarea to TextEdit, it looks alright, 
but this might be due to how TextEdit handles different line ending 
chars the same. I can't see the line endings in TextEdit. When I 
save the TextEdit file to disk in Windows Latin 1 format and read 
it in REBOL, the line endings are correct.


When I copy and paste between two VID text areas in OSX, it looks 
alright.


OSX Rebol/View has also another bug in which, when using cursor up 
or down in a text area, the cursor also moves one char to the left.

when doing a 'read clipboard:// in OSX, I still get the ^M. so it 
might not be VID after all.

Interesting, this is why I want to run lots of simple conclusive 
tests.  I don't want AltME to have separate routines for separate 
computers, I also don't want to both Carl unless we have our facts 
in order.

I don't think this is an AltME problem, but a rebol/clipboard general 
problem. But I think that Mac Roman text formatting does use a different 
line ending and that comes through with the clipboard into rebol.

I think the problem is that read without /binary is supposed to do 
transparent line ending conversion, but doesn't when reading clipboard 
data.

AltME updated to 1.2.9 with no problem.

What is new?

Apparently not much... http://www.altme.com/new.html

:>)  I was hoping that this new version could read my brain waves 
so I wouldn't have to type.

another issue is how text encoding is done. I just had a conversation 
in Danish with Geomol. While Danish letters look right on a mac it 
will look different in Windows and vice versa.

¾¿Œ <--- on a mac

æøå <--- in winXP

that's because of different code-pages on Mac/Win

I'm finding longer delays or retries necessary when connecting to 
AltME recently (since last major update ?)

I just did some speed tests.  Seems about the same.  Even though 
it should be unrealted, do you still have your message count set 
to 100?

Of note, AltME seems to be the same speed, and Qtask should be about 
20% faster, and will continue getting faster.

Ah no, I mean, first time connection to AltME worldserver.  While 
it is running it seems fine.