[9fans] Mac OS X Drawterm Oddity

[9fans] Mac OS X Drawterm Oddity

[Gregory Pavelcak]

Hope this isn't old news but ...

On my native Mac OS X drawterm, when I snarf a 
, subsequent pastes
seem to insert a newline.

On osx-x11 drawterm, 
 gets pasted.

Just discovered it when I tried to cut-and-paste 
 into a sed
command.

Oh, and Merry Christmas and Happy New Year!

Greg

Re: [9fans] Mac OS X Drawterm Oddity

[Gregory Pavelcak]

Let's try again, although you may have guessed.

On my native Mac OS X drawterm, when I snarf a <CR>, subsequent pastes
seem to insert a newline.

On osx-x11 drawterm, <CR> gets pasted.

Re: [9fans] Mac OS X Drawterm Oddity

[andrey mirtchovski]

here's the offending code in clipread (gui-osx/screen.c):

                while (*s) {
                    if (*s == '\r') *s = '\n';
                    s++;
                }

i don't know the reason this is in there, but if you remove this and
recompile you can test whether anything breaks for us :)

On Dec 28, 2007 12:45 PM, Gregory Pavelcak <g.pavelcak@comcast.net> wrote:
> Let's try again, although you may have guessed.
>
> On my native Mac OS X drawterm, when I snarf a <CR>, subsequent pastes
> seem to insert a newline.
>
> On osx-x11 drawterm, <CR> gets pasted.
>
>

Re: [9fans] Mac OS X Drawterm Oddity

[Gregory Pavelcak]

OK, did it. I'm getting the correct snarf/paste results now and
no apparent ill effects in the whole 15 seconds I've been running
the new drawterm, but I'll let you know if anything comes up.

Thanks.

Greg

Re: [9fans] Mac OS X Drawterm Oddity

[Russ Cox]

> On my native Mac OS X drawterm, when I snarf a <CR>, subsequent pastes
> seem to insert a newline.
> 
> On osx-x11 drawterm, <CR> gets pasted.

Which one do you think is the bug?  They both sound correct to me.

I suspect that since OS X uses plain \r as the
end of line sequence, if you snarf multiple lines
in some native application then you'll get something
like hello\rworld.  Pasting that into Plan 9 *should*
produce hello\nworld, since \n is the Plan 9
end of line sequence.

In X11, it is assumed (perhaps incorrectly) that the
X11 server is already doing that translation.

Similarly, in Windows, the snarf buffer rewrites \r\n
into plain \n.

In all cases the goal is to make it so that if you copy
multiple lines out of a native application and paste
them into Plan 9, you get multiple lines separated
only by \n.  It is definitely possible that the code is
not managing to do this, but your report doesn't
make that clear.

Russ

Re: [9fans] Mac OS X Drawterm Oddity

[Gregory Pavelcak]

Now I'm confused. I was talking about snarfing the visible
(well OK, newlines are visible, but I mean the one with a
little 'C' at 11 o'clock and a little 'R' at 5 o'clock)
unicode character 000d, but the first email message
I sent out went out with the little CR character and came back to
me with newlines. Just the sort of thing I did not want to have
happen. It's simple,  I just think that what I paste should look
just like what I just cut. How else should it look?

Greg

Re: [9fans] Mac OS X Drawterm Oddity

[Pietro Gagliardi]

That's not a newline, that's a carriage return. Two different things.  
OS X automatically converts the two formats - which are used by  
different computer operating systems - and some editors allow you to  
do it manually. Windows uses a carriage return followed by a newline.

 From nemo's guide, if you give a Plan 9 a Windows file, it would  
look like
	a(cr)
	b
But if you give Windows a Plan 9 file, it would look like an a with a  
b on top. OS X doesn't care.

On Dec 31, 2007, at 12:53 PM, Gregory Pavelcak wrote:

> Now I'm confused. I was talking about snarfing the visible
> (well OK, newlines are visible, but I mean the one with a
> little 'C' at 11 o'clock and a little 'R' at 5 o'clock)
> unicode character 000d, but the first email message
> I sent out went out with the little CR character and came back to
> me with newlines. Just the sort of thing I did not want to have
> happen. It's simple,  I just think that what I paste should look
> just like what I just cut. How else should it look?
>
> Greg

Re: [9fans] Mac OS X Drawterm Oddity

[Gregory Pavelcak]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Let this be a commandment: As you cut, so shall you paste.
There are very simple identity conditions for strings. Let's
use 'em.

Greg

[-- Attachment #2: Type: message/rfc822, Size: 5215 bytes --]

From: Pietro Gagliardi <pietro10@mac.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Mac OS X Drawterm Oddity
Date: Mon, 31 Dec 2007 12:57:31 -0500
Message-ID: <F4D6555D-6088-49D7-8F67-3F3880971248@mac.com>

That's not a newline, that's a carriage return. Two different things.  
OS X automatically converts the two formats - which are used by  
different computer operating systems - and some editors allow you to  
do it manually. Windows uses a carriage return followed by a newline.

 From nemo's guide, if you give a Plan 9 a Windows file, it would  
look like
	a(cr)
	b
But if you give Windows a Plan 9 file, it would look like an a with a  
b on top. OS X doesn't care.

On Dec 31, 2007, at 12:53 PM, Gregory Pavelcak wrote:

> Now I'm confused. I was talking about snarfing the visible
> (well OK, newlines are visible, but I mean the one with a
> little 'C' at 11 o'clock and a little 'R' at 5 o'clock)
> unicode character 000d, but the first email message
> I sent out went out with the little CR character and came back to
> me with newlines. Just the sort of thing I did not want to have
> happen. It's simple,  I just think that what I paste should look
> just like what I just cut. How else should it look?
>
> Greg

 

Re: [9fans] Mac OS X Drawterm Oddity

[Gary Wright]

On Dec 31, 2007, at 7:30 AM, Russ Cox wrote:

>> On my native Mac OS X drawterm, when I snarf a <CR>, subsequent  
>> pastes
>> seem to insert a newline.
>>
>> On osx-x11 drawterm, <CR> gets pasted.
>
> Which one do you think is the bug?  They both sound correct to me.
>
> I suspect that since OS X uses plain \r as the
> end of line sequence,

Mac OS 9 and earlier used \r as the end of line sequence but
Mac OS X uses \n.

Gary Wright