[9fans] Mac OS X Drawterm Oddity - Plan9

This is a discussion on [9fans] Mac OS X Drawterm Oddity - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [9fans] Mac OS X Drawterm Oddity

  1. [9fans] Mac OS X Drawterm Oddity

    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

  2. Re: [9fans] Mac OS X Drawterm Oddity

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

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

    On osx-x11 drawterm, gets pasted.


  3. Re: [9fans] Mac OS X Drawterm Oddity

    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 wrote:
    > Let's try again, although you may have guessed.
    >
    > On my native Mac OS X drawterm, when I snarf a , subsequent pastes
    > seem to insert a newline.
    >
    > On osx-x11 drawterm, gets pasted.
    >
    >


  4. Re: [9fans] Mac OS X Drawterm Oddity

    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

  5. Re: [9fans] Mac OS X Drawterm Oddity

    > On my native Mac OS X drawterm, when I snarf a , subsequent pastes
    > seem to insert a newline.
    >
    > On osx-x11 drawterm, 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


  6. Re: [9fans] Mac OS X Drawterm Oddity

    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

  7. Re: [9fans] Mac OS X Drawterm Oddity

    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



  8. Re: [9fans] Mac OS X Drawterm Oddity

    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

  9. Re: [9fans] Mac OS X Drawterm Oddity


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

    >> On my native Mac OS X drawterm, when I snarf a , subsequent
    >> pastes
    >> seem to insert a newline.
    >>
    >> On osx-x11 drawterm, 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

+ Reply to Thread