* Re: [9fans] unicode input for OSX-native drawterm [not found] <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> @ 2007-10-30 1:20 ` underspecified 2007-10-30 1:39 ` underspecified 0 siblings, 1 reply; 9+ messages in thread From: underspecified @ 2007-10-30 1:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: inferno-list, acme-sac [-- Attachment #1: Type: text/plain, Size: 965 bytes --] *sigh* I don't need to complain, but this is *exactly* what I have been working on in Acme SAC for the last month. We *really* need some way of getting the drawterm/emu/acme-sac OS X code in sync... --underspecified On 10/30/07, andrey mirtchovski <mirtchovski@gmail.com> wrote: > > this is the last piece of the puzzle that i was missing from the OSX > drawterm: the ability to input text when i'm using a different > keyboard layout than the english one (that's bulgarian for me). > > this file will pick up the unicode key from the input event and send > it directly to plan9 without attempting to pass it as a char (which is > what the old code did). > > since my screen.c has accumulated quite a few patches missing from the > CVS repository i'm attaching the whole thing. maintainers of acme-sac > and inferno can add the changes: they're in the kEventRawKeyDown event > handler and the convert_key routine and are quite obvious. > > [-- Attachment #2: Type: text/html, Size: 1269 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-10-30 1:20 ` [9fans] unicode input for OSX-native drawterm underspecified @ 2007-10-30 1:39 ` underspecified 2007-10-30 8:07 ` Francisco J Ballesteros 0 siblings, 1 reply; 9+ messages in thread From: underspecified @ 2007-10-30 1:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: inferno-list, acme-sac [-- Attachment #1: Type: text/plain, Size: 2702 bytes --] I apologize for being grumpy in my last post. While we are talking about Unicode input in OS X, I feel I should put in my 2 cents' worth. In Carbon, input events (from the keyboard, IMEs, character maps, etc.) generate Unicode text input events. If the Unicode events are not handled by your app, then raw keyboard events are generated. What our apps really need is to handle Unicode text events. That will make it possible for Bulgarian keyboards, Japanese IMEs, and math symbols from the special chars table to work in drawterm, emu, what-have-you-not. I've already implemented handlers for Unicode input events in Acme SAC for OS X. Grabbing the Unicode chars from kEventRawKeyDown might work for Bulgarian, but it doesn't scale. The problem with doing everything in Unicode is that we need to redo all of our special character checks and conversion to use Unicode values instead of MacCharCodes. I've been working on Unicode-based special character handling as well, but the code is still a bit buggy. With the release of Leopard, it looks like Apple is finally phasing out Carbon. It has been brought up a couple of times on various lists, but the future of p9/inferno apps on OS X is ideally a Cocoa rewrite. This would actually take care of a lot of the annoying aspects of internationalized text input for us. I wish I had the time and Objective C knowledge to undertake such a project. Anyway, could I propose an osx-ip9 Google group or mailing list, so that all of us Mac hackers working on different apps can keep current on what others are working on? --underspecified On 10/30/07, underspecified <underspecified@gmail.com> wrote: > > *sigh* I don't need to complain, but this is *exactly* what I have been > working on in Acme SAC for the last month. > We *really* need some way of getting the drawterm/emu/acme-sac OS X code > in sync... > > --underspecified > > On 10/30/07, andrey mirtchovski <mirtchovski@gmail.com> wrote: > > > > this is the last piece of the puzzle that i was missing from the OSX > > drawterm: the ability to input text when i'm using a different > > keyboard layout than the english one (that's bulgarian for me). > > > > this file will pick up the unicode key from the input event and send > > it directly to plan9 without attempting to pass it as a char (which is > > what the old code did). > > > > since my screen.c has accumulated quite a few patches missing from the > > CVS repository i'm attaching the whole thing. maintainers of acme-sac > > and inferno can add the changes: they're in the kEventRawKeyDown event > > handler and the convert_key routine and are quite obvious. > > > > > [-- Attachment #2: Type: text/html, Size: 3454 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-10-30 1:39 ` underspecified @ 2007-10-30 8:07 ` Francisco J Ballesteros 2007-10-30 8:42 ` Noah Evans 0 siblings, 1 reply; 9+ messages in thread From: Francisco J Ballesteros @ 2007-10-30 8:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs THere's no much traffic on the list. using the inferno and/or 9fans lists to report what's being done to port emu/drawterm to macs would be nice. I guess I'll have to learn cocoa if I want to be able to adjust our inferno in the futue. On 10/30/07, underspecified <underspecified@gmail.com> wrote: > I apologize for being grumpy in my last post. > > While we are talking about Unicode input in OS X, I feel I should put in my > 2 cents' worth. > In Carbon, input events (from the keyboard, IMEs, character maps, etc.) > generate Unicode text input events. > If the Unicode events are not handled by your app, then raw keyboard events > are generated. > What our apps really need is to handle Unicode text events. That will make > it possible for Bulgarian keyboards, > Japanese IMEs, and math symbols from the special chars table to work in > drawterm, emu, what-have-you-not. > I've already implemented handlers for Unicode input events in Acme SAC for > OS X. > > Grabbing the Unicode chars from kEventRawKeyDown might work for Bulgarian, > but it doesn't scale. > The problem with doing everything in Unicode is that we need to redo all of > our special character checks and > conversion to use Unicode values instead of MacCharCodes. I've been working > on Unicode-based special > character handling as well, but the code is still a bit buggy. > > With the release of Leopard, it looks like Apple is finally phasing out > Carbon. It has been brought up a couple > of times on various lists, but the future of p9/inferno apps on OS X is > ideally a Cocoa rewrite. This would actually > take care of a lot of the annoying aspects of internationalized text input > for us. I wish I had the time and Objective > C knowledge to undertake such a project. > > Anyway, could I propose an osx-ip9 Google group or mailing list, so that all > of us Mac hackers working on different > apps can keep current on what others are working on? > > --underspecified > > > On 10/30/07, underspecified <underspecified@gmail.com> wrote: > > *sigh* I don't need to complain, but this is *exactly* what I have been > working on in Acme SAC for the last month. > > We *really* need some way of getting the drawterm/emu/acme-sac OS X code > in sync... > > > > --underspecified > > > > > > > > On 10/30/07, andrey mirtchovski < mirtchovski@gmail.com> wrote: > > > this is the last piece of the puzzle that i was missing from the OSX > > > drawterm: the ability to input text when i'm using a different > > > keyboard layout than the english one (that's bulgarian for me). > > > > > > this file will pick up the unicode key from the input event and send > > > it directly to plan9 without attempting to pass it as a char (which is > > > what the old code did). > > > > > > since my screen.c has accumulated quite a few patches missing from the > > > CVS repository i'm attaching the whole thing. maintainers of acme-sac > > > and inferno can add the changes: they're in the kEventRawKeyDown event > > > handler and the convert_key routine and are quite obvious. > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-10-30 8:07 ` Francisco J Ballesteros @ 2007-10-30 8:42 ` Noah Evans 2007-11-03 15:14 ` Paul Lalonde 0 siblings, 1 reply; 9+ messages in thread From: Noah Evans @ 2007-10-30 8:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I messed around with cocoa and emu for a couple of hours a while back. I can give a few pointers for anyone starting from stratch(or implement it if there's a cocoa expert willing to help me). The primary problem was setting up the runtime manually(os x cocoa applications do a lot of the work for you behind the scenes, win.c's way of doing things doesn't work that way so you have to do it yourself). I'm really enjoying how many people are working on OS X these days. Acme-sac for OSX especially. Noah On 10/30/07, Francisco J Ballesteros <nemo@lsub.org> wrote: > THere's no much traffic on the list. using the inferno and/or 9fans lists > to report what's being done to port emu/drawterm to macs would be nice. > > I guess I'll have to learn cocoa if I want to be able to adjust our inferno in > the futue. > > On 10/30/07, underspecified <underspecified@gmail.com> wrote: > > I apologize for being grumpy in my last post. > > > > While we are talking about Unicode input in OS X, I feel I should put in my > > 2 cents' worth. > > In Carbon, input events (from the keyboard, IMEs, character maps, etc.) > > generate Unicode text input events. > > If the Unicode events are not handled by your app, then raw keyboard events > > are generated. > > What our apps really need is to handle Unicode text events. That will make > > it possible for Bulgarian keyboards, > > Japanese IMEs, and math symbols from the special chars table to work in > > drawterm, emu, what-have-you-not. > > I've already implemented handlers for Unicode input events in Acme SAC for > > OS X. > > > > Grabbing the Unicode chars from kEventRawKeyDown might work for Bulgarian, > > but it doesn't scale. > > The problem with doing everything in Unicode is that we need to redo all of > > our special character checks and > > conversion to use Unicode values instead of MacCharCodes. I've been working > > on Unicode-based special > > character handling as well, but the code is still a bit buggy. > > > > With the release of Leopard, it looks like Apple is finally phasing out > > Carbon. It has been brought up a couple > > of times on various lists, but the future of p9/inferno apps on OS X is > > ideally a Cocoa rewrite. This would actually > > take care of a lot of the annoying aspects of internationalized text input > > for us. I wish I had the time and Objective > > C knowledge to undertake such a project. > > > > Anyway, could I propose an osx-ip9 Google group or mailing list, so that all > > of us Mac hackers working on different > > apps can keep current on what others are working on? > > > > --underspecified > > > > > > On 10/30/07, underspecified <underspecified@gmail.com> wrote: > > > *sigh* I don't need to complain, but this is *exactly* what I have been > > working on in Acme SAC for the last month. > > > We *really* need some way of getting the drawterm/emu/acme-sac OS X code > > in sync... > > > > > > --underspecified > > > > > > > > > > > > On 10/30/07, andrey mirtchovski < mirtchovski@gmail.com> wrote: > > > > this is the last piece of the puzzle that i was missing from the OSX > > > > drawterm: the ability to input text when i'm using a different > > > > keyboard layout than the english one (that's bulgarian for me). > > > > > > > > this file will pick up the unicode key from the input event and send > > > > it directly to plan9 without attempting to pass it as a char (which is > > > > what the old code did). > > > > > > > > since my screen.c has accumulated quite a few patches missing from the > > > > CVS repository i'm attaching the whole thing. maintainers of acme-sac > > > > and inferno can add the changes: they're in the kEventRawKeyDown event > > > > handler and the convert_key routine and are quite obvious. > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-10-30 8:42 ` Noah Evans @ 2007-11-03 15:14 ` Paul Lalonde 2007-11-03 15:23 ` David Leimbach 0 siblings, 1 reply; 9+ messages in thread From: Paul Lalonde @ 2007-11-03 15:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Sorry to come in late, I've been on the road all week) One thing about doing this Cocoa port --- I've been reflecting on this since Leopard was announced as dropping Carbon --- is that we should probably take the opportunity to build the front-end, simple as it is, using the recommended gui tool chain. It doesn't uglify the distribution build process, and lets us address (by doing nothing more) most of the bugs I put in when I did the Carbon port. Our needs are simple: we just post one image, appropriately resized, in one window. The code interface requires an objective-C to C++ wrapper to hand back that image for writing and its converse, mouse event & keyboard communication (trivial) and probably a short function to handle the resize event. It should be substantially simpler than the twisted little maze of Carbon calls. Paul On 30-Oct-07, at 1:42 AM, Noah Evans wrote: > I messed around with cocoa and emu for a couple of hours a while back. > I can give a few pointers for anyone starting from stratch(or > implement it if there's a cocoa expert willing to help me). The > primary problem was setting up the runtime manually(os x cocoa > applications do a lot of the work for you behind the scenes, win.c's > way of doing things doesn't work that way so you have to do it > yourself). > > I'm really enjoying how many people are working on OS X these days. > Acme-sac for OSX especially. > > Noah > > On 10/30/07, Francisco J Ballesteros <nemo@lsub.org> wrote: >> THere's no much traffic on the list. using the inferno and/or >> 9fans lists >> to report what's being done to port emu/drawterm to macs would be >> nice. >> >> I guess I'll have to learn cocoa if I want to be able to adjust >> our inferno in >> the futue. >> >> On 10/30/07, underspecified <underspecified@gmail.com> wrote: >>> I apologize for being grumpy in my last post. >>> >>> While we are talking about Unicode input in OS X, I feel I should >>> put in my >>> 2 cents' worth. >>> In Carbon, input events (from the keyboard, IMEs, character maps, >>> etc.) >>> generate Unicode text input events. >>> If the Unicode events are not handled by your app, then raw >>> keyboard events >>> are generated. >>> What our apps really need is to handle Unicode text events. That >>> will make >>> it possible for Bulgarian keyboards, >>> Japanese IMEs, and math symbols from the special chars table to >>> work in >>> drawterm, emu, what-have-you-not. >>> I've already implemented handlers for Unicode input events in >>> Acme SAC for >>> OS X. >>> >>> Grabbing the Unicode chars from kEventRawKeyDown might work for >>> Bulgarian, >>> but it doesn't scale. >>> The problem with doing everything in Unicode is that we need to >>> redo all of >>> our special character checks and >>> conversion to use Unicode values instead of MacCharCodes. I've >>> been working >>> on Unicode-based special >>> character handling as well, but the code is still a bit buggy. >>> >>> With the release of Leopard, it looks like Apple is finally >>> phasing out >>> Carbon. It has been brought up a couple >>> of times on various lists, but the future of p9/inferno apps on >>> OS X is >>> ideally a Cocoa rewrite. This would actually >>> take care of a lot of the annoying aspects of internationalized >>> text input >>> for us. I wish I had the time and Objective >>> C knowledge to undertake such a project. >>> >>> Anyway, could I propose an osx-ip9 Google group or mailing list, >>> so that all >>> of us Mac hackers working on different >>> apps can keep current on what others are working on? >>> >>> --underspecified >>> >>> >>> On 10/30/07, underspecified <underspecified@gmail.com> wrote: >>>> *sigh* I don't need to complain, but this is *exactly* what I >>>> have been >>> working on in Acme SAC for the last month. >>>> We *really* need some way of getting the drawterm/emu/acme-sac >>>> OS X code >>> in sync... >>>> >>>> --underspecified >>>> >>>> >>>> >>>> On 10/30/07, andrey mirtchovski < mirtchovski@gmail.com> wrote: >>>>> this is the last piece of the puzzle that i was missing from >>>>> the OSX >>>>> drawterm: the ability to input text when i'm using a different >>>>> keyboard layout than the english one (that's bulgarian for me). >>>>> >>>>> this file will pick up the unicode key from the input event and >>>>> send >>>>> it directly to plan9 without attempting to pass it as a char >>>>> (which is >>>>> what the old code did). >>>>> >>>>> since my screen.c has accumulated quite a few patches missing >>>>> from the >>>>> CVS repository i'm attaching the whole thing. maintainers of >>>>> acme-sac >>>>> and inferno can add the changes: they're in the >>>>> kEventRawKeyDown event >>>>> handler and the convert_key routine and are quite obvious. >>>>> >>>>> >>>> >>>> >>> >>> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHLJBUpJeHo/Fbu1wRAn/6AJ4uu10HJpAYIIjHcyMiVgqy8Y8UigCgkV2p 5lwQVdlSwstuN9W+feB/SzQ= =FwxW -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-11-03 15:14 ` Paul Lalonde @ 2007-11-03 15:23 ` David Leimbach 2007-11-03 18:50 ` Tom Lieber 0 siblings, 1 reply; 9+ messages in thread From: David Leimbach @ 2007-11-03 15:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Carbon is still in Leopard. Just built the latest native drawterm using it like 5 minutes ago. On Nov 3, 2007 8:14 AM, Paul Lalonde <plalonde@telus.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (Sorry to come in late, I've been on the road all week) > > One thing about doing this Cocoa port --- I've been reflecting on > this since Leopard was announced as dropping Carbon --- is that we > should probably take the opportunity to build the front-end, simple > as it is, using the recommended gui tool chain. It doesn't uglify > the distribution build process, and lets us address (by doing nothing > more) most of the bugs I put in when I did the Carbon port. Our > needs are simple: we just post one image, appropriately resized, in > one window. The code interface requires an objective-C to C++ > wrapper to hand back that image for writing and its converse, mouse > event & keyboard communication (trivial) and probably a short > function to handle the resize event. It should be substantially > simpler than the twisted little maze of Carbon calls. > > Paul > > > On 30-Oct-07, at 1:42 AM, Noah Evans wrote: > > > I messed around with cocoa and emu for a couple of hours a while back. > > I can give a few pointers for anyone starting from stratch(or > > implement it if there's a cocoa expert willing to help me). The > > primary problem was setting up the runtime manually(os x cocoa > > applications do a lot of the work for you behind the scenes, win.c's > > way of doing things doesn't work that way so you have to do it > > yourself). > > > > I'm really enjoying how many people are working on OS X these days. > > Acme-sac for OSX especially. > > > > Noah > > > > On 10/30/07, Francisco J Ballesteros <nemo@lsub.org> wrote: > >> THere's no much traffic on the list. using the inferno and/or > >> 9fans lists > >> to report what's being done to port emu/drawterm to macs would be > >> nice. > >> > >> I guess I'll have to learn cocoa if I want to be able to adjust > >> our inferno in > >> the futue. > >> > >> On 10/30/07, underspecified <underspecified@gmail.com> wrote: > >>> I apologize for being grumpy in my last post. > >>> > >>> While we are talking about Unicode input in OS X, I feel I should > >>> put in my > >>> 2 cents' worth. > >>> In Carbon, input events (from the keyboard, IMEs, character maps, > >>> etc.) > >>> generate Unicode text input events. > >>> If the Unicode events are not handled by your app, then raw > >>> keyboard events > >>> are generated. > >>> What our apps really need is to handle Unicode text events. That > >>> will make > >>> it possible for Bulgarian keyboards, > >>> Japanese IMEs, and math symbols from the special chars table to > >>> work in > >>> drawterm, emu, what-have-you-not. > >>> I've already implemented handlers for Unicode input events in > >>> Acme SAC for > >>> OS X. > >>> > >>> Grabbing the Unicode chars from kEventRawKeyDown might work for > >>> Bulgarian, > >>> but it doesn't scale. > >>> The problem with doing everything in Unicode is that we need to > >>> redo all of > >>> our special character checks and > >>> conversion to use Unicode values instead of MacCharCodes. I've > >>> been working > >>> on Unicode-based special > >>> character handling as well, but the code is still a bit buggy. > >>> > >>> With the release of Leopard, it looks like Apple is finally > >>> phasing out > >>> Carbon. It has been brought up a couple > >>> of times on various lists, but the future of p9/inferno apps on > >>> OS X is > >>> ideally a Cocoa rewrite. This would actually > >>> take care of a lot of the annoying aspects of internationalized > >>> text input > >>> for us. I wish I had the time and Objective > >>> C knowledge to undertake such a project. > >>> > >>> Anyway, could I propose an osx-ip9 Google group or mailing list, > >>> so that all > >>> of us Mac hackers working on different > >>> apps can keep current on what others are working on? > >>> > >>> --underspecified > >>> > >>> > >>> On 10/30/07, underspecified <underspecified@gmail.com> wrote: > >>>> *sigh* I don't need to complain, but this is *exactly* what I > >>>> have been > >>> working on in Acme SAC for the last month. > >>>> We *really* need some way of getting the drawterm/emu/acme-sac > >>>> OS X code > >>> in sync... > >>>> > >>>> --underspecified > >>>> > >>>> > >>>> > >>>> On 10/30/07, andrey mirtchovski < mirtchovski@gmail.com> wrote: > >>>>> this is the last piece of the puzzle that i was missing from > >>>>> the OSX > >>>>> drawterm: the ability to input text when i'm using a different > >>>>> keyboard layout than the english one (that's bulgarian for me). > >>>>> > >>>>> this file will pick up the unicode key from the input event and > >>>>> send > >>>>> it directly to plan9 without attempting to pass it as a char > >>>>> (which is > >>>>> what the old code did). > >>>>> > >>>>> since my screen.c has accumulated quite a few patches missing > >>>>> from the > >>>>> CVS repository i'm attaching the whole thing. maintainers of > >>>>> acme-sac > >>>>> and inferno can add the changes: they're in the > >>>>> kEventRawKeyDown event > >>>>> handler and the convert_key routine and are quite obvious. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFHLJBUpJeHo/Fbu1wRAn/6AJ4uu10HJpAYIIjHcyMiVgqy8Y8UigCgkV2p > 5lwQVdlSwstuN9W+feB/SzQ= > =FwxW > -----END PGP SIGNATURE----- > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-11-03 15:23 ` David Leimbach @ 2007-11-03 18:50 ` Tom Lieber 2007-11-04 7:24 ` Jeff Sickel 0 siblings, 1 reply; 9+ messages in thread From: Tom Lieber @ 2007-11-03 18:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 11/3/07, David Leimbach <leimy2k@gmail.com> wrote: > Carbon is still in Leopard. Just built the latest native drawterm > using it like 5 minutes ago. Yes, it's just that its days have been numbered by Apple. -- Tom Lieber http://AllTom.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-11-03 18:50 ` Tom Lieber @ 2007-11-04 7:24 ` Jeff Sickel 2007-11-04 10:54 ` Charles Forsyth 0 siblings, 1 reply; 9+ messages in thread From: Jeff Sickel @ 2007-11-04 7:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Nov 3, 2007, at 1:50 PM, Tom Lieber wrote: > On 11/3/07, David Leimbach <leimy2k@gmail.com> wrote: >> Carbon is still in Leopard. Just built the latest native drawterm >> using it like 5 minutes ago. > > Yes, it's just that its days have been numbered by Apple. and like old OS 9, it's dead.. no longer being supported or going anywhere. That said, we're lucky that the current drawterm code in Carbon behaves properly: Apple does not support any GUI code or event loops from Cocoa or Carbon in anything other than the main thread--and the current Carbon port is a direct reflection of the X11 ports, which let child threads create their own event loops to handle drawing: a direct conflict w/ the current supported architecture for Carbon or Cocoa. I'd like to see a Cocoa front end that is launched as a separate process. Sure you take a bit of a hit on the pass-thru, but you can then let the Cocoa event loop do it's odd things on top of Mach and let drawterm and other code use the Plan 9 model. jas ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] unicode input for OSX-native drawterm 2007-11-04 7:24 ` Jeff Sickel @ 2007-11-04 10:54 ` Charles Forsyth 0 siblings, 0 replies; 9+ messages in thread From: Charles Forsyth @ 2007-11-04 10:54 UTC (permalink / raw) To: 9fans > Apple does not support any GUI code or event loops > from Cocoa or Carbon in anything other than the main thread--and the some people just never learn. i think they should stick to consumer gadgets. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-11-04 10:54 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> 2007-10-30 1:20 ` [9fans] unicode input for OSX-native drawterm underspecified 2007-10-30 1:39 ` underspecified 2007-10-30 8:07 ` Francisco J Ballesteros 2007-10-30 8:42 ` Noah Evans 2007-11-03 15:14 ` Paul Lalonde 2007-11-03 15:23 ` David Leimbach 2007-11-03 18:50 ` Tom Lieber 2007-11-04 7:24 ` Jeff Sickel 2007-11-04 10:54 ` Charles Forsyth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).