Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #29906 > unrolled thread
| Started by | "BartC" <bc@freeuk.com> |
|---|---|
| First post | 2013-01-10 20:58 +0000 |
| Last post | 2013-01-14 22:11 -0800 |
| Articles | 20 on this page of 139 — 33 participants |
Back to article view | Back to comp.lang.c
Command line arguments "BartC" <bc@freeuk.com> - 2013-01-10 20:58 +0000
Re: Command line arguments pu <uselpa.list@gmail.com> - 2013-01-10 22:02 +0100
Re: Command line arguments pu <uselpa.list@gmail.com> - 2013-01-11 14:43 +0100
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 19:10 +0000
Re: Command line arguments Willem <willem@turtle.stack.nl> - 2013-01-10 21:02 +0000
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-10 21:34 +0000
Re: Command line arguments Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-01-10 22:02 +0000
Re: Command line arguments Greg Martin <greg@softsprocket.com> - 2013-01-10 14:13 -0800
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-10 22:32 +0000
Re: Command line arguments Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-10 17:49 -0500
Re: Command line arguments BruceS <bruces42@hotmail.com> - 2013-01-10 16:05 -0700
Re: Command line arguments Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-10 18:15 -0500
Re: Command line arguments JohnF <john@please.see.sig.for.email.com> - 2013-01-11 06:54 +0000
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 02:26 -0500
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 09:02 +0000
Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-11 11:17 -0700
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 13:20 -0500
Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-11 13:13 -0700
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 19:22 +0000
Re: Command line arguments Fred K <fred.l.kleinschmidt@gmail.com> - 2013-01-11 14:42 -0800
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 01:22 +0000
Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 01:39 +0000
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 03:16 +0000
Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-12 09:49 -0800
Re: Command line arguments JohnF <john@please.see.sig.for.email.com> - 2013-01-12 04:14 +0000
Re: Command line arguments Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-13 20:19 +0200
Re: Command line arguments JohnF <john@please.see.sig.for.email.com> - 2013-01-14 04:56 +0000
Re: Command line arguments Ken Brody <kenbrody@spamcop.net> - 2013-01-22 15:32 -0500
Re: Command line arguments Ken Brody <kenbrody@spamcop.net> - 2013-01-22 15:25 -0500
Re: Command line arguments Fred K <fred.l.kleinschmidt@gmail.com> - 2013-01-10 14:49 -0800
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 00:11 +0000
Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-10 21:16 -0500
Re: Command line arguments Les Cargill <lcargill99@comcast.com> - 2013-01-11 21:25 -0600
Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-10 21:05 -0500
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-10 21:15 -0500
Re: Command line arguments 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-11 01:36 -0800
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 19:33 +0000
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 14:57 -0500
Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-11 14:26 -0600
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 20:49 +0000
Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-11 18:15 -0600
Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 01:11 +0000
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 01:38 +0000
Re: Command line arguments Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-12 14:57 -0800
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-12 18:08 -0500
Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-13 00:42 +0000
Re: Command line arguments Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-13 12:31 -0800
Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-13 04:54 -0600
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-13 12:37 +0000
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 15:54 -0500
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 21:16 +0000
Re: Command line arguments Greg Martin <greg@softsprocket.com> - 2013-01-11 13:17 -0800
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 22:48 +0000
Re: Command line arguments gazelle@shell.xmission.com (Kenny McCormack) - 2013-01-11 22:53 +0000
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-11 23:46 +0000
Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-11 18:12 -0600
Re: Command line arguments Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-11 19:59 -0500
Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 01:32 +0000
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 02:47 +0000
Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 03:23 +0000
Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-11 22:28 -0700
Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-11 18:54 -0800
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 03:42 +0000
Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-11 23:18 -0500
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 12:06 +0000
Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-12 11:43 -0500
Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-12 10:27 -0700
Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-12 10:22 -0800
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 20:26 +0000
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 20:53 +0000
Re: Command line arguments Geoff <geoff@invalid.invalid> - 2013-01-12 16:58 -0800
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-13 01:51 +0000
Re: Command line arguments Geoff <geoff@invalid.invalid> - 2013-01-13 00:27 -0800
Re: Command line arguments Sjouke Burry <s@b> - 2013-01-14 06:00 +0000
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-14 21:44 +0000
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-12 16:10 -0500
Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 21:25 +0000
Re: Command line arguments pacman@kosh.dhis.org (Alan Curry) - 2013-01-12 22:10 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-13 01:30 +0000
Re: (OT keyboard input) Keith Thompson <kst-u@mib.org> - 2013-01-12 20:47 -0800
Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-13 08:46 +0000
Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-13 03:56 -0600
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-13 12:10 +0000
Re: (OT keyboard input) Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-13 11:21 -0500
Re: (OT keyboard input) 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-13 09:43 -0800
Re: (OT keyboard input) "osmium" <r124c4u102@comcast.net> - 2013-01-13 12:09 -0600
Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-13 20:34 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-13 21:58 +0000
Re: (OT keyboard input) Dr Nick <nospam-4@temporary-address.org.uk> - 2013-01-13 22:26 +0000
Re: (OT keyboard input) Greg Martin <greg@softsprocket.com> - 2013-01-13 14:51 -0800
Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-13 23:47 +0000
Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-14 01:34 +0000
Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-13 23:53 -0500
Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-14 00:26 -0600
Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-14 07:36 -0500
Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-14 13:40 -0600
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 14:23 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 13:36 +0000
Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-14 09:25 -0500
Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-14 21:09 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 22:06 +0000
Re: (OT keyboard input) Nobody <nobody@nowhere.com> - 2013-01-15 08:16 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-15 11:50 +0000
Re: (OT keyboard input) Keith Thompson <kst-u@mib.org> - 2013-01-15 07:53 -0800
Re: (OT keyboard input) Nobody <nobody@nowhere.com> - 2013-01-15 20:26 +0000
Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-15 21:08 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-15 22:19 +0000
Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-15 20:37 -0500
Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-16 02:24 -0600
Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-16 04:28 +0000
Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-16 06:44 -0500
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-16 13:57 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-16 14:32 +0000
Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-17 00:35 +0000
Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-15 23:51 +0000
Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-14 21:15 +0000
Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 21:59 +0000
Re: (OT keyboard input) Greg Martin <greg@softsprocket.com> - 2013-01-13 10:04 -0800
Re: (OT keyboard input) Roberto Waltman <usenet@rwaltman.com> - 2013-01-13 20:09 -0500
Re: Command line arguments Geoff <geoff@invalid.invalid> - 2013-01-10 23:47 -0800
Re: Command line arguments Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-13 20:03 +0200
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-10 22:30 +0000
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-10 18:12 -0500
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-10 18:15 -0500
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 00:16 +0000
Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-10 15:46 -0800
Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-10 17:58 -0700
Re: Command line arguments Johann Klammer <klammerj@NOSPAM.a1.net> - 2013-01-11 09:26 +0100
Re: Command line arguments Les Cargill <lcargill99@comcast.com> - 2013-01-11 21:23 -0600
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 03:45 +0000
Re: Command line arguments Philip Lantz <prl@canterey.us> - 2013-01-11 20:52 -0800
Re: Command line arguments Les Cargill <lcargill99@comcast.com> - 2013-01-11 23:21 -0600
Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-12 09:52 -0800
Re: Command line arguments James Dow Allen <jdallen2000@yahoo.com> - 2013-01-13 01:22 -0800
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-13 11:11 -0500
Re: Command line arguments Azazel <azazel@remove.azazel.net> - 2013-01-14 09:26 -0600
Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-14 17:08 -0500
Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-14 23:13 +0000
Re: Command line arguments 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-14 22:11 -0800
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2013-01-13 08:46 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <kcts9c$j4v$1@speranza.aioe.org> |
| In reply to | #30046 |
In article <J8oIs.8135$eE2.750@fx29.fr7>, BartC <bc@freeuk.com> wrote: > > >"Alan Curry" <pacman@kosh.dhis.org> wrote in message >> >> I assure you, the Linux console and xterm are more accurate emulations of >> the >> VT100 than anything you ever saw in Windows (unless you had a Windows >> xterm) > >This is where you lose me. I'm not interested in emulation of any sort of >terminal. I just want to read keys from my keyboard; how difficult can it >be? > I assume as a newcomer to the platform you're trying to write programs the simplest way possible. That means using stdio, and that means you're accessing an ASCII-based character stream. Not raw key events. >I understand that with standard line input via C's getchar() and so on, the >OS or the library will take care of basic line-editing; that's fine. So far so good. > >But moving just one step beyond that, in order to implement a console-based >editor for example, seems to have been made extraordinarily difficult for >some reason! I can never quite understand what DOS and Windows programmers mean when they use the word "console". In unix, the console is just a regular terminal, which happens to be the destination for kernel messages. And it can be any kind of terminal - it might be attached to a serial port or it might be a remote node on the network. > >> The terminal interface is based on streams of characters, corresponding to >> stdin and stdout/stderr. The format of these streams is usually ASCII or a >> superset of ASCII like ISO8859-x or UTF-8. Where in any of those character >> sets do you find "shift+ctrl combos"? > >The keyboard handling I want needs two kinds of key presses. Printable keys, >and control keys. They don't need to share the same code-space. I don't >expect it to work with stdin as I said above, and I don't see the need to >have to encode everything as a serial stream of ASCII codes either. "Everything as a serial stream of ASCII codes" is a good candidate for short statement of the unix philosophy... Really, it's just backward compatibility. The unix culture started with hardware terminals that sent ASCII over a serial line to a host computer, and tons of programs were developed to use that interface. Later when keyboards and monitors directly connected to the unix host became common, we didn't want to throw all of our existing code away, so we retained the old "ASCII terminal" paradigm by including an emulator in the kernel. That's why the default Linux console is a VT100 emulator running on top of the PC keyboard and video hardware, with your stdin and stdout connected to the emulated serial line. Of course there were people with dreams of fancier user interfaces, and they built the X Window System. And on top of that they built KDE and GNOME and other fancy stuff. Those are the two major user interface possibilities for unix programs: ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of the road" interface that looks like a plain text terminal but provides detailed information about key events. Not one that's widely used at least. > >> When your input scheme isn't ASCII or UTF-8, you need a more ambitious >> library than curses. Like SDL, or an X11 widget library (Xt+Xaw/Xm, tk, >> wxWidgets, gtk, etc.) or raw Xlib. > >Help! It sounds so complicated that I may have to forget the whole thing, >and just make my editors etc work with the minimum set of keys that are >certain to be available. (However, the SDL looks intriguing..) Did you know there are approximately 17 zillion text editors already? Can you really hate *all* of them enough to justify adding another? The minimum set of keys that are certain to be available on all terminals is the printable ASCII set. Actually, probably less than that. Somebody out there might still have a functioning uppercase-only terminal. -- Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-01-13 03:56 -0600 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <qfv4f810bb7jpl2lejbebg3334h88mrl1c@4ax.com> |
| In reply to | #30058 |
On Sun, 13 Jan 2013 08:46:37 +0000 (UTC), pacman@kosh.dhis.org (Alan Curry) wrote: >In article <J8oIs.8135$eE2.750@fx29.fr7>, BartC <bc@freeuk.com> wrote: >> >> >>"Alan Curry" <pacman@kosh.dhis.org> wrote in message >>> >>> I assure you, the Linux console and xterm are more accurate emulations of >>> the >>> VT100 than anything you ever saw in Windows (unless you had a Windows >>> xterm) >> >>This is where you lose me. I'm not interested in emulation of any sort of >>terminal. I just want to read keys from my keyboard; how difficult can it >>be? >> > >I assume as a newcomer to the platform you're trying to write programs the >simplest way possible. That means using stdio, and that means you're >accessing an ASCII-based character stream. Not raw key events. He wants to be able to pick up things like key-up/key down events, detect various combinations of shift, alt, ctrl, whatever being pressed with the keys, etc. >>I understand that with standard line input via C's getchar() and so on, the >>OS or the library will take care of basic line-editing; that's fine. > >So far so good. > >> >>But moving just one step beyond that, in order to implement a console-based >>editor for example, seems to have been made extraordinarily difficult for >>some reason! > >I can never quite understand what DOS and Windows programmers mean when they >use the word "console". In unix, the console is just a regular terminal, >which happens to be the destination for kernel messages. And it can be any >kind of terminal - it might be attached to a serial port or it might be a >remote node on the network. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).aspx The high level functions provide a somewhat stream-oriented interface, the lower level functions provide much more control, as well as access to a variety of events happening to your console window (size changes, notifications from the OS about various things, mouse events...). >>> The terminal interface is based on streams of characters, corresponding to >>> stdin and stdout/stderr. The format of these streams is usually ASCII or a >>> superset of ASCII like ISO8859-x or UTF-8. Where in any of those character >>> sets do you find "shift+ctrl combos"? >> >>The keyboard handling I want needs two kinds of key presses. Printable keys, >>and control keys. They don't need to share the same code-space. I don't >>expect it to work with stdin as I said above, and I don't see the need to >>have to encode everything as a serial stream of ASCII codes either. > >"Everything as a serial stream of ASCII codes" is a good candidate for short >statement of the unix philosophy... > >Really, it's just backward compatibility. The unix culture started with >hardware terminals that sent ASCII over a serial line to a host computer, and >tons of programs were developed to use that interface. > >Later when keyboards and monitors directly connected to the unix host became >common, we didn't want to throw all of our existing code away, so we retained >the old "ASCII terminal" paradigm by including an emulator in the kernel. >That's why the default Linux console is a VT100 emulator running on top of >the PC keyboard and video hardware, with your stdin and stdout connected to >the emulated serial line. > >Of course there were people with dreams of fancier user interfaces, and they >built the X Window System. And on top of that they built KDE and GNOME and >other fancy stuff. > >Those are the two major user interface possibilities for unix programs: >ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of the >road" interface that looks like a plain text terminal but provides detailed >information about key events. Not one that's widely used at least. But there is for Windows. He's used those facilities, and he'd like to port his application to *nix. Maybe his application does something logical when you tap the alt key three times while holding ctrl-shift-backspace and wiggling the mouse. I'd probably be a poor customer for that application, since I don't think I'm coordinated enough to use that UI. >>> When your input scheme isn't ASCII or UTF-8, you need a more ambitious >>> library than curses. Like SDL, or an X11 widget library (Xt+Xaw/Xm, tk, >>> wxWidgets, gtk, etc.) or raw Xlib. >> >>Help! It sounds so complicated that I may have to forget the whole thing, >>and just make my editors etc work with the minimum set of keys that are >>certain to be available. (However, the SDL looks intriguing..) > >Did you know there are approximately 17 zillion text editors already? Can you >really hate *all* of them enough to justify adding another? > >The minimum set of keys that are certain to be available on all terminals is >the printable ASCII set. Actually, probably less than that. Somebody out >there might still have a functioning uppercase-only terminal. Why does "you can't do that, because it couldn't be done on a VT-100" seem a less than satisfying answer? But this is *nix, and that is the philosophy. It's no more or less silly than S/370's continuing fondness of 3270s*. And if you want to develop for either of those platforms, you'll have to adapt. I've seen (semi-)documented interfaces to console hardware, but it's always been vendor specific. Perhaps BartC's best option (given the little I understand about his application) is to create his own "text console" window with some toolkit on top of X. It's really not that difficult to do. A bidirectional pipe to a "console server" application, his app writes screen update commands in one end, the server writes keystroke (and whatnot) events in the other. That can even work in Windows (although the "console server" will be quite different). *Although obviously the *nix folks will point out that those are *not* the same, as 3270s are inherently evil, since they don't work well with *nix.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2013-01-13 12:10 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <cxxIs.8669$K84.1572@fx09.fr7> |
| In reply to | #30060 |
"Robert Wessel" <robertwessel2@yahoo.com> wrote in message news:qfv4f810bb7jpl2lejbebg3334h88mrl1c@4ax.com... > On Sun, 13 Jan 2013 08:46:37 +0000 (UTC), pacman@kosh.dhis.org (Alan > Curry) wrote: >>Those are the two major user interface possibilities for unix programs: >>ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of >>the >>road" interface that looks like a plain text terminal but provides >>detailed >>information about key events. Not one that's widely used at least. > > > But there is for Windows. He's used those facilities, and he'd like > to port his application to *nix. Yes, exactly. I'd even gone as far as going through PDcurses under Windows (a version of ncurses), so that it'd would work painlessly under Linux - as I thought. > Maybe his application does something > logical when you tap the alt key three times while holding > ctrl-shift-backspace and wiggling the mouse. I'd probably be a poor > customer for that application, since I don't think I'm coordinated > enough to use that UI. I want to use Ctrl+Home, for example, to get to the top of a document. PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks text from here to the top of the file). But Ncurses under Linux doesn't recognise *any* shift combinations for keys like Home! So a Linux library ported to Windows, works better than it did under Linux! >>Did you know there are approximately 17 zillion text editors already? Can >>you >>really hate *all* of them enough to justify adding another? (And there are also zillions of cars on the roads; why not just take a taxi instead of buying your own?!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lpitcher@teksavvy.com> |
|---|---|
| Date | 2013-01-13 11:21 -0500 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <uaBIs.46895$sm1.44448@newsfe22.iad> |
| In reply to | #30062 |
Now, far afield from C, we come to On Sunday 13 January 2013 07:10, in comp.lang.c, bc@freeuk.com wrote: [snip] > I want to use Ctrl+Home, for example, to get to the top of a document. > > PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks > text from here to the top of the file). > > But Ncurses under Linux doesn't recognise *any* shift combinations for > keys like Home! Often, an X "GUI desktop" will reserve some shift combinations for itself. In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home" function. Be mindful of the environment. Curses can only receive keysequences that the OS (or it's proxys, like X and it's window managers) pass to it. Try running your curses-based program in a raw terminal, not under X control. > So a Linux library ported to Windows, works better than it did under > Linux! Not really. Windows does less than Linux does. And PDCurses is /not/ curses; it is a Curses subset, written for Microsoft DOS applications. Hence, it works within the confines (limits and abilities) of a DOS environment, and /not/ within the limits and abilities of a Unixish environment. FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key. [snip] -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2013-01-13 09:43 -0800 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <59173887-8325-4143-8d29-39e69a4a57f8@googlegroups.com> |
| In reply to | #30065 |
Lew Pitcher於 2013年1月14日星期一UTC+8上午12時21分44秒寫道： > Now, far afield from C, we come to > > > > On Sunday 13 January 2013 07:10, in comp.lang.c, bc@freeuk.com wrote: > > [snip] > > > I want to use Ctrl+Home, for example, to get to the top of a document. > > > > > > PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks > > > text from here to the top of the file). > > > > > > But Ncurses under Linux doesn't recognise *any* shift combinations for > > > keys like Home! > > > > Often, an X "GUI desktop" will reserve some shift combinations for itself. > > In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home" > > function. > > > > Be mindful of the environment. Curses can only receive keysequences that the > > OS (or it's proxys, like X and it's window managers) pass to it. Try > > running your curses-based program in a raw terminal, not under X control. > > > > > > > So a Linux library ported to Windows, works better than it did under > > > Linux! > > > > Not really. Windows does less than Linux does. And PDCurses is /not/ curses; > > it is a Curses subset, written for Microsoft DOS applications. Hence, it > > works within the confines (limits and abilities) of a DOS environment, > > and /not/ within the limits and abilities of a Unixish environment. > > > > FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key. > > > > > > [snip] > > -- > > Lew Pitcher > > "In Skills, We Trust" Acctually DOS 3.X to DOS4.X only supported non-re-entrant IRT and a simple command invoker that worked in the real memory under 640K but could be shelled in a primitive way still within the memory limit. Anyway, I got my 1024X768X256 color multi-sync color monitor from Matsushita's Panasoic logo and VGA card to experiment on the DOS part in 1991-1992 for a budget about USD 1000 at that time. Anyway I was managed to do quite a few interesting things at that time without resorting to an infant linux system to show 256 color images.
[toc] | [prev] | [next] | [standalone]
| From | "osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2013-01-13 12:09 -0600 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <algbjbFej5cU1@mid.individual.net> |
| In reply to | #30066 |
88888 Dihedral wrote: > Lew Pitcher? 2013?1?14????UTC+8??12?21?44???: >> Now, far afield from C, we come to >> >> >> >> On Sunday 13 January 2013 07:10, in comp.lang.c, bc@freeuk.com wrote: >> >> [snip] >> >>> I want to use Ctrl+Home, for example, to get to the top of a >>> document. >> >>> >> >>> PDcurses returns that under Windows (but not Shift+Ctrl+Home, which >>> marks >> >>> text from here to the top of the file). >> >>> >> >>> But Ncurses under Linux doesn't recognise *any* shift combinations >>> for >> >>> keys like Home! >> >> >> >> Often, an X "GUI desktop" will reserve some shift combinations for >> itself. >> >> In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home" >> >> function. >> >> >> >> Be mindful of the environment. Curses can only receive keysequences >> that the >> >> OS (or it's proxys, like X and it's window managers) pass to it. Try >> >> running your curses-based program in a raw terminal, not under X >> control. >> >> >> >> >> >>> So a Linux library ported to Windows, works better than it did under >> >>> Linux! >> >> >> >> Not really. Windows does less than Linux does. And PDCurses is /not/ >> curses; >> >> it is a Curses subset, written for Microsoft DOS applications. >> Hence, it >> >> works within the confines (limits and abilities) of a DOS >> environment, >> >> and /not/ within the limits and abilities of a Unixish environment. >> >> >> >> FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key. >> >> >> >> >> >> [snip] >> >> -- >> >> Lew Pitcher >> >> "In Skills, We Trust" > > Acctually DOS 3.X to DOS4.X only supported > non-re-entrant IRT and a simple command invoker > that worked in the real memory under 640K but > could be shelled in a primitive way still within > the memory limit. > > Anyway, I got my 1024X768X256 color multi-sync > color monitor from Matsushita's Panasoic logo > and VGA card to experiment on the DOS part in > 1991-1992 for a budget about USD 1000 at that time. > > Anyway I was managed to do quite a few > interesting things at that time without resorting > to an infant linux system to show 256 color images. Your Komodo dragon, the world's largest living lizard, is found... in the lesser Sunda Chain of the Indonesian Archipelago...
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2013-01-13 20:34 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <kcv5o5$u13$1@speranza.aioe.org> |
| In reply to | #30062 |
In article <cxxIs.8669$K84.1572@fx09.fr7>, BartC <bc@freeuk.com> wrote: >"Robert Wessel" <robertwessel2@yahoo.com> wrote in message >news:qfv4f810bb7jpl2lejbebg3334h88mrl1c@4ax.com... >> On Sun, 13 Jan 2013 08:46:37 +0000 (UTC), pacman@kosh.dhis.org (Alan >> Curry) wrote: > >>>Those are the two major user interface possibilities for unix programs: >>>ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of >>>the >>>road" interface that looks like a plain text terminal but provides >>>detailed >>>information about key events. Not one that's widely used at least. >> >> >> But there is for Windows. He's used those facilities, and he'd like >> to port his application to *nix. > >Yes, exactly. I'd even gone as far as going through PDcurses under Windows >(a version of ncurses), so that it'd would work painlessly under Linux - as >I thought. Does any of that stuff work when you telnet or ssh into the Windows box? The great thing about curses-based applications under unix is that the answer to that question is "they work exactly the same". Because programs that don't work remotely are kind of ridiculous in the Internet era. Anyway, it seems you were fooled by the name "PDcurses". It's not a port of curses or ncurses. It's an independent clone, and not meant to be an exact one. The HISTORY file has this to say about the first version (when it was called "PCcurses"): There are some parts left out between ncurses and PCcurses. One is the support for multiple terminals - not very interesting on a PC anyway. Because we KNOW what terminal we have, there is no need for a termcap or terminfo library. PCcurses also has some things that neither curses nor ncurses have. Compared to the original UNIX curses, PCcurses has lots of extras. Fancy key combinations would be part of the "lots of extras". I see that PDcurses is on sourceforge now (no updates lately, but maybe it doesn't need any) and allegedly runs on Linux, with an X11 backend and an SDL backend. Give that a try? > >So a Linux library ported to Windows, works better than it did under Linux! If you prioritize things like "recognize Ctrl+Home" over things like "support multiple terminals" and "work over the network". Those priorities just seem backwards to any right-thinking unix programmer. -- Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2013-01-13 21:58 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <V6GIs.2274$2i7.1926@fx27.fr7> |
| In reply to | #30076 |
"Alan Curry" <pacman@kosh.dhis.org> wrote in message news:kcv5o5$u13$1@speranza.aioe.org... > In article <cxxIs.8669$K84.1572@fx09.fr7>, BartC <bc@freeuk.com> wrote: >>Yes, exactly. I'd even gone as far as going through PDcurses under Windows >>(a version of ncurses), so that it'd would work painlessly under Linux - >>as >>I thought. > Does any of that stuff work when you telnet or ssh into the Windows box? It's possible I'm not using the right library for what I want to, which is, IMO, extremely basic input and output for a non-graphic display mode, that is (in a small way) cross-platform. That is: o Being able to write text at (row, column) on a screen or console window, preferably in a choice of primary colours. (Both sets of curses seem just about capable of that) o Being able to know what keys have been pressed on my keyboard, including the various shifts that all computer keyboards have had for decades. I don't consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get to the beginning of a file? I bet it involves a shift, ctrl or alt key!) o And being able to do so without the intermediate library taking over my machine and/or my program (like SDL, which disables stdout and stderr!) > If you prioritize things like "recognize Ctrl+Home" over things like > "support > multiple terminals" and "work over the network". Those priorities just > seem > backwards to any right-thinking unix programmer. Imagine a computer without a network attached, but with a keyboard and basic character display. You would surely expect those peripherals to work, without having half their capabilities unavailable because the protocols for controlling them via a network can't accommodate them. It seems that with Unix, I have to pretend that even the simplest peripheral I want to access is at the end of a link, via an interface not updated since the 1970s! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <nospam-4@temporary-address.org.uk> |
|---|---|
| Date | 2013-01-13 22:26 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <876230yb11.fsf@temporary-address.org.uk> |
| In reply to | #30082 |
"BartC" <bc@freeuk.com> writes: > Imagine a computer without a network attached, but with a keyboard and > basic character display. You would surely expect those peripherals to > work, without having half their capabilities unavailable because the > protocols for controlling them via a network can't accommodate them. > > It seems that with Unix, I have to pretend that even the simplest > peripheral I want to access is at the end of a link, via an interface > not updated since the 1970s! No, it' possible. It's just very messy. But if you are already using pdcurses, is it this one: http://sourceforge.net/project/shownotes.php?release_id=497965 ? Because this says: "Modifier keys are now returned on key up in X11, as in Win32. And in general, modifier key reporting is more consistent across platforms." "Modifier keys" is the magic terminology you need to look for. It's quite clearly possible - because otherwise the program I'm writing this in wouldn't work (it famously makes a lot of use of modifier keys). But that doesn't mean it's easy! It's just one of these things. You're expressing the same sort of incredulity I'd express on saying "you mean I can't have 8 virtual desktops and switch between them with a single key press, chain 10 little filter programs together or boot in very few seconds indeed". Some things do some things well and others - which sound just as easy - very badly. Others do others.
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg@softsprocket.com> |
|---|---|
| Date | 2013-01-13 14:51 -0800 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <ETGIs.80220$pV4.55244@newsfe21.iad> |
| In reply to | #30082 |
On 13-01-13 01:58 PM, BartC wrote: > "Alan Curry" <pacman@kosh.dhis.org> wrote in message > news:kcv5o5$u13$1@speranza.aioe.org... >> In article <cxxIs.8669$K84.1572@fx09.fr7>, BartC <bc@freeuk.com> wrote: > >>> Yes, exactly. I'd even gone as far as going through PDcurses under >>> Windows >>> (a version of ncurses), so that it'd would work painlessly under Linux - >>> as >>> I thought. > >> Does any of that stuff work when you telnet or ssh into the Windows box? > > It's possible I'm not using the right library for what I want to, which is, > IMO, extremely basic input and output for a non-graphic display mode, that > is (in a small way) cross-platform. That is: > > o Being able to write text at (row, column) on a screen or console window, > preferably in a choice of primary colours. (Both sets of curses seem just > about capable of that) > > o Being able to know what keys have been pressed on my keyboard, including > the various shifts that all computer keyboards have had for decades. I > don't > consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get > to the beginning of a file? I bet it involves a shift, ctrl or alt key!) > > o And being able to do so without the intermediate library taking over my > machine and/or my program (like SDL, which disables stdout and stderr!) > >> If you prioritize things like "recognize Ctrl+Home" over things like >> "support >> multiple terminals" and "work over the network". Those priorities just >> seem >> backwards to any right-thinking unix programmer. > > Imagine a computer without a network attached, but with a keyboard and > basic > character display. You would surely expect those peripherals to work, > without having half their capabilities unavailable because the protocols > for > controlling them via a network can't accommodate them. > > It seems that with Unix, I have to pretend that even the simplest > peripheral > I want to access is at the end of a link, via an interface not updated > since > the 1970s! > Again, I'll point you to GTK+. I don't know how much has been ported to cygwin but it has libvte for terminal emulation. http://developer.gnome.org/vte/0.26/
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-01-13 23:47 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <0.612e19a5cf46b19a9a73.20130113234752GMT.871udohcgn.fsf@bsb.me.uk> |
| In reply to | #30082 |
"BartC" <bc@freeuk.com> writes: > "Alan Curry" <pacman@kosh.dhis.org> wrote in message > news:kcv5o5$u13$1@speranza.aioe.org... >> In article <cxxIs.8669$K84.1572@fx09.fr7>, BartC <bc@freeuk.com> wrote: > >>>Yes, exactly. I'd even gone as far as going through PDcurses under Windows >>>(a version of ncurses), so that it'd would work painlessly under Linux - >>>as >>>I thought. > >> Does any of that stuff work when you telnet or ssh into the Windows box? > > It's possible I'm not using the right library for what I want to, which is, > IMO, extremely basic input and output for a non-graphic display mode, that > is (in a small way) cross-platform. That is: > > o Being able to write text at (row, column) on a screen or console window, > preferably in a choice of primary colours. (Both sets of curses seem just > about capable of that) Not if the display is monochrome. Now I know you know this, but the point is a general one. A library like curses hides this form you. Some displays allow fine-grained control of the brightness of individual characters and soon some 3D display may well allow a z-position. When a feature becomes common place, libraries like ncurses will offer support for them, but since the purpose of ncurses is portability it is inherently conservative about such things. > o Being able to know what keys have been pressed on my keyboard, including > the various shifts that all computer keyboards have had for decades. I don't > consider Ctrl+Home to be that esoteric. It may not be esoteric, but it is not universal. If you want a program to work using common terminal types you have to accept that Ctrl+Home can't be used. There are ways to get round this: (a) Use your own X window. XLib lets you know a huge amount about what keys are being pressed and exactly when. My editor, being X aware, lets me bind Ctrl+Alt+Super+Home (to pick an extreme example) but when I run the editor in a terminal emulation I have to accept that this won't work because the terminal being emulated has no way to say "Ctrl+Alt+Super+ Home was pressed and released". (b) Go a little bit beyond what ncurses gives you and accept a loss of flexibility. You can write a small function to read and return and extended set of key combinations but you must then tell your users that the software needs to run in, say, an xterm window. (I choose xterm because it generate unique escape sequences for all sorts of combinations like Ctrl+Home, Shift+Ctrl+Home and so on.) > (What key combo do *you* use to get > to the beginning of a file? I bet it involves a shift, ctrl or alt > key!) (Home three times: the first goes to start of line, the second to the top of the page and the third to start of the file. Multi key presses like this are so fast that it's probably quicker the Ctrl+Home.) > o And being able to do so without the intermediate library taking over my > machine and/or my program (like SDL, which disables stdout and stderr!) > >> If you prioritize things like "recognize Ctrl+Home" over things like >> "support >> multiple terminals" and "work over the network". Those priorities just >> seem >> backwards to any right-thinking unix programmer. > > Imagine a computer without a network attached, but with a keyboard and basic > character display. You would surely expect those peripherals to work, > without having half their capabilities unavailable because the protocols for > controlling them via a network can't accommodate them. I'd expect them to work (and of course they do) but you can't insist that the work the way you want them to or that you are used to. My hard drive works, but user programs can only access it via an very complex and high-level abstraction provided by the OS. You are kicking against the abstraction that *nix systems use for non-graphical terminals. All you can do is take a deep breath and move on. > It seems that with Unix, I have to pretend that even the simplest peripheral > I want to access is at the end of a link, via an interface not updated since > the 1970s! Obviously it has been updated, but the model is from the 1970s. It works surprisingly well and has enough advantages that it's not going to go away anytime soon. It's not uncommon to see old terminals still plugged in to servers for monitoring purposes and so on. It wouldn't be hard to provide a general method to do what you want. All that would be need is some patches to a good terminal emulator like xterm so that it reports (as escape sequences) raw key presses and releases. An extended curses library could then provide access to this virtual hardware at all sorts of levels, from actual events like "left control down" to "Ctrl+Home pressed and released". But I suspect this would not take off because the benefits are small compared to work required, and programs that have any sort of portability limitation can be viewed with suspicion. For example, with no patching at all, you could bundle your editor with xterm (because it does report Ctrl+Home) but the fact that it won't run in my preferred terminal program would put me off. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2013-01-14 01:34 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <kcvnav$5m5$1@speranza.aioe.org> |
| In reply to | #30082 |
In article <V6GIs.2274$2i7.1926@fx27.fr7>, BartC <bc@freeuk.com> wrote: >"Alan Curry" <pacman@kosh.dhis.org> wrote in message >news:kcv5o5$u13$1@speranza.aioe.org... > >> Does any of that stuff work when you telnet or ssh into the Windows box? > >It's possible I'm not using the right library for what I want to, which is, >IMO, extremely basic input and output for a non-graphic display mode, that >is (in a small way) cross-platform. That is: > >o Being able to write text at (row, column) on a screen or console window, >preferably in a choice of primary colours. (Both sets of curses seem just >about capable of that) Cursor positioning and character attributes: yes, those are core features of curses from the beginning, since they were supported by all terminals. (Originally the attributes were just bold/underline/inverse/blink, then colors showed up.) > >o Being able to know what keys have been pressed on my keyboard, including >the various shifts that all computer keyboards have had for decades. I don't >consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get >to the beginning of a file? I bet it involves a shift, ctrl or alt key!) In the editor "vim", the command for "move to beginning of file" is gg. No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), which does involve a shift key to generate the G, but the editor doesn't *know* that you used the shift key. Typing "1g" with caps-lock on would do the same thing. The editor can't tell the difference. It only knows that it received an uppercase G (ASCII code 71). Have you ever used a unix text editor before deciding you needed to make a new one? > >o And being able to do so without the intermediate library taking over my >machine and/or my program (like SDL, which disables stdout and stderr!) The one time I tried to run an SDL program it locked up my console pretty thorougly. I'm not a fan... > >Imagine a computer without a network attached, but with a keyboard and basic >character display. You would surely expect those peripherals to work, >without having half their capabilities unavailable because the protocols for >controlling them via a network can't accommodate them. Imagine also that you've designed a multi-user operating system, and that you can't take seriously a computer with no network and only a single keyboard and screen attached. Would you take the time to design an API to allow convenient access to all of the hardware capabilities, then hope that enough programs get written or rewritten with the new API to make it worthwhile? Or just make it emulate a serial terminal so you can run the thousands of programs you've already got? Unix vendors during the critical transition period chose the easy option (the second one). They never created any API for DOS-like text-mode applications that assume direct access to a local keyboard and monitor. And it's too late now. The ASCII + ECMA-48 terminal paradigm has its disadvantages but it's available everywhere, good enough most of the time, the old users are used to it, and the new users faint instantly at the sight of text mode so they won't appreciate any improvements to it. > >It seems that with Unix, I have to pretend that even the simplest peripheral >I want to access is at the end of a link, via an interface not updated since >the 1970s! Yes, you've got it! That or go full GUI. Or keep trying to find something in between those two options, and suffer from the flakiness of the lesser-used libraries. -- Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-01-13 23:53 -0500 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <kd0313$atm$1@dont-email.me> |
| In reply to | #30097 |
On 01/13/2013 08:34 PM, Alan Curry wrote: > In article <V6GIs.2274$2i7.1926@fx27.fr7>, BartC <bc@freeuk.com> wrote: ... >> o Being able to know what keys have been pressed on my keyboard, including >> the various shifts that all computer keyboards have had for decades. I don't >> consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get >> to the beginning of a file? I bet it involves a shift, ctrl or alt key!) > > In the editor "vim", the command for "move to beginning of file" is gg. > No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), > which does involve a shift key to generate the G, but the editor doesn't > *know* that you used the shift key. Typing "1g" with caps-lock on would > do the same thing. The editor can't tell the difference. It only knows > that it received an uppercase G (ASCII code 71). > > Have you ever used a unix text editor before deciding you needed to make > a new one? Bart appears to be a follower of the NIH (Not Invented Here) principle. He wants to reinvent everything himself; nothing designed by anyone else is good enough to be used without modification. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-01-14 00:26 -0600 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <o497f8hlmmeh30qvi0nr3bdo2p66vvfhms@4ax.com> |
| In reply to | #30106 |
On Sun, 13 Jan 2013 23:53:54 -0500, James Kuyper <jameskuyper@verizon.net> wrote: >On 01/13/2013 08:34 PM, Alan Curry wrote: >> In article <V6GIs.2274$2i7.1926@fx27.fr7>, BartC <bc@freeuk.com> wrote: >... >>> o Being able to know what keys have been pressed on my keyboard, including >>> the various shifts that all computer keyboards have had for decades. I don't >>> consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get >>> to the beginning of a file? I bet it involves a shift, ctrl or alt key!) >> >> In the editor "vim", the command for "move to beginning of file" is gg. >> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), >> which does involve a shift key to generate the G, but the editor doesn't >> *know* that you used the shift key. Typing "1g" with caps-lock on would >> do the same thing. The editor can't tell the difference. It only knows >> that it received an uppercase G (ASCII code 71). >> >> Have you ever used a unix text editor before deciding you needed to make >> a new one? > >Bart appears to be a follower of the NIH (Not Invented Here) principle. >He wants to reinvent everything himself; nothing designed by anyone else >is good enough to be used without modification. You're complaining about Bart's motivations after someone brought up vi as an example of how to do something?!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-01-14 07:36 -0500 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <kd0u4c$8iu$1@dont-email.me> |
| In reply to | #30110 |
On 01/14/2013 01:26 AM, Robert Wessel wrote: > On Sun, 13 Jan 2013 23:53:54 -0500, James Kuyper > <jameskuyper@verizon.net> wrote: > >> On 01/13/2013 08:34 PM, Alan Curry wrote: ... >>> In the editor "vim", the command for "move to beginning of file" is gg. >>> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), >>> which does involve a shift key to generate the G, but the editor doesn't >>> *know* that you used the shift key. Typing "1g" with caps-lock on would >>> do the same thing. The editor can't tell the difference. It only knows >>> that it received an uppercase G (ASCII code 71). >>> >>> Have you ever used a unix text editor before deciding you needed to make >>> a new one? >> >> Bart appears to be a follower of the NIH (Not Invented Here) principle. >> He wants to reinvent everything himself; nothing designed by anyone else >> is good enough to be used without modification. > > > You're complaining about Bart's motivations after someone brought up > vi as an example of how to do something?! Well, yes, but there's no direct connection between those events. I also went to sleep "after someone brought up vi as an example of how to do something" - but that doesn't mean Alan's message put me to sleep. What you're describing happened only in the first paragraph of Alan's that I quoted. It's the second one that actually triggered my response, not the first. That's why I quoted the second one, and why I placed my response immediately after it. I quoted the first paragraph only to put the second one in it's appropriate context. Also, my comments were triggered not just by this particular thread, but also by many other threads in which Bart has decided to go off on his own and create new tools, because of his dissatisfaction with some of the features of tools designed by other people, features he considers bugs. I don't object to him spending his time reinventing things; it's his time to spend as he wants. Spending it that way means he has less time to spend inventing completely new things, and it also means that when he does invent new things, they often depend upon his reinvented tools, in ways that would inhibit their adoption by other people - but it's his decision to make about how important those issues are. It just gets a bit annoying when he complains so much about the fact that things other people designed work differently from the way he expected them to. A bit more experience with such systems, if collected with an open mind, could greatly improve his own design repertoire. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-01-14 13:40 -0600 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <ehn8f89u9bjmasmbsq6kdtakvvh47ogbpe@4ax.com> |
| In reply to | #30122 |
On Mon, 14 Jan 2013 07:36:27 -0500, James Kuyper <jameskuyper@verizon.net> wrote: >On 01/14/2013 01:26 AM, Robert Wessel wrote: >> On Sun, 13 Jan 2013 23:53:54 -0500, James Kuyper >> <jameskuyper@verizon.net> wrote: >> >>> On 01/13/2013 08:34 PM, Alan Curry wrote: >... >>>> In the editor "vim", the command for "move to beginning of file" is gg. >>>> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), >>>> which does involve a shift key to generate the G, but the editor doesn't >>>> *know* that you used the shift key. Typing "1g" with caps-lock on would >>>> do the same thing. The editor can't tell the difference. It only knows >>>> that it received an uppercase G (ASCII code 71). >>>> >>>> Have you ever used a unix text editor before deciding you needed to make >>>> a new one? >>> >>> Bart appears to be a follower of the NIH (Not Invented Here) principle. >>> He wants to reinvent everything himself; nothing designed by anyone else >>> is good enough to be used without modification. >> >> >> You're complaining about Bart's motivations after someone brought up >> vi as an example of how to do something?! > >Well, yes, but there's no direct connection between those events. I also >went to sleep "after someone brought up vi as an example of how to do >something" - but that doesn't mean Alan's message put me to sleep. > >What you're describing happened only in the first paragraph of Alan's >that I quoted. It's the second one that actually triggered my response, >not the first. That's why I quoted the second one, and why I placed my >response immediately after it. I quoted the first paragraph only to put >the second one in it's appropriate context. > >Also, my comments were triggered not just by this particular thread, but >also by many other threads in which Bart has decided to go off on his >own and create new tools, because of his dissatisfaction with some of >the features of tools designed by other people, features he considers >bugs. I don't object to him spending his time reinventing things; it's >his time to spend as he wants. Spending it that way means he has less >time to spend inventing completely new things, and it also means that >when he does invent new things, they often depend upon his reinvented >tools, in ways that would inhibit their adoption by other people - but >it's his decision to make about how important those issues are. > >It just gets a bit annoying when he complains so much about the fact >that things other people designed work differently from the way he >expected them to. A bit more experience with such systems, if collected >with an open mind, could greatly improve his own design repertoire. Sorry, was mostly trying to be humorous, should have included a smiley.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2013-01-14 14:23 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <nyUIs.2$Zf6.0@fx16.fr7> |
| In reply to | #30106 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:kd0313$atm$1@dont-email.me... > On 01/13/2013 08:34 PM, Alan Curry wrote: >> Have you ever used a unix text editor before deciding you needed to make >> a new one? > > Bart appears to be a follower of the NIH (Not Invented Here) principle. > He wants to reinvent everything himself; nothing designed by anyone else > is good enough to be used without modification. (It's habit. I used to design and build my own hardware too (in the form of microprocessor and graphics boards). Since these didn't come with software, that had to be created as well, from scratch (literally, at one time, starting from binary machine code). That included languages, editors, libraries, compilers, and as well as everything associated with graphic displays. I don't do hardware any more, but it gives me a different perspective on things, such as being able to tell when things are far bigger and more complex than necessary.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2013-01-14 13:36 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <lUTIs.1$bV2.0@fx14.fr7> |
| In reply to | #30097 |
"Alan Curry" <pacman@kosh.dhis.org> wrote in message news:kcvnav$5m5$1@speranza.aioe.org... > In article <V6GIs.2274$2i7.1926@fx27.fr7>, BartC <bc@freeuk.com> wrote: >>o Being able to write text at (row, column) on a screen or console window, >>preferably in a choice of primary colours. (Both sets of curses seem just >>about capable of that) > In the editor "vim", the command for "move to beginning of file" is gg. > No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), > which does involve a shift key to generate the G, but the editor doesn't > *know* that you used the shift key. Typing "1g" with caps-lock on would > do the same thing. The editor can't tell the difference. It only knows > that it received an uppercase G (ASCII code 71). (So how do you insert 1G or 1g into the file itself?) > Have you ever used a unix text editor before deciding you needed to make > a new one? Yes, I've played with them. They reminded me of those line-editors I used to use on teletypes. > The ASCII + ECMA-48 terminal paradigm has its > disadvantages but it's available everywhere, good enough most of the > time, the old users are used to it, and the new users faint instantly at > the sight of text mode so they won't appreciate any improvements to it. I've looked up ECMA-48, and I think now I can dispense with Curses (for linux; while on Windows I use what I had before). I can directly send escape codes to stdout to give me cursor positioning, and bold (I haven't tested colour yet, but that is not critical). And, with the help of downloaded versions of kbhit() and getch() which modify how getchar() works, I can directly get keyboard entry, even if some keys are escape sequences. There are still missing modifiers, but I can live with that too. (kbhit() is essential when writing an editor, to flush out any pending keystrokes, which otherwise cause problems when the screen can't keep up). Now what I want to know is, what on earth is curses, ncurses or PDcurses actually for?! Anyway, thanks. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-01-14 09:25 -0500 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <kd14ho$elm$1@dont-email.me> |
| In reply to | #30124 |
On 01/14/2013 08:36 AM, BartC wrote: > "Alan Curry" <pacman@kosh.dhis.org> wrote in message > news:kcvnav$5m5$1@speranza.aioe.org... ... >> In the editor "vim", the command for "move to beginning of file" is gg. >> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1), >> which does involve a shift key to generate the G, but the editor doesn't >> *know* that you used the shift key. Typing "1g" with caps-lock on would >> do the same thing. The editor can't tell the difference. It only knows >> that it received an uppercase G (ASCII code 71). > > (So how do you insert 1G or 1g into the file itself?) By first switching from command mode to edit mode. Several commands put vi into edit mode, including 'i' == insert, 'a' = append, and 'o' = open new line. You escape from edit mode back to command mode by hitting the escape key. More modern editors typically use a menu to do the same things that vi does through commands, and therefore don't need separate command and edit modes. I would never recommend vi for new users, the learning curve is too steep. However, having already ascended that curve, I find vi easier to use than those more modern editors. >> Have you ever used a unix text editor before deciding you needed to make >> a new one? > > Yes, I've played with them. They reminded me of those line-editors I used to > use on teletypes. That's not surprising, vi is much more than a line editor, but it was developed from an older line editor named ex, and still supports the entire ex command set. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-01-14 21:09 +0000 |
| Subject | Re: (OT keyboard input) |
| Message-ID | <0.58f391898698b4e15678.20130114210926GMT.87sj63eak9.fsf@bsb.me.uk> |
| In reply to | #30124 |
"BartC" <bc@freeuk.com> writes: <snip> > I've looked up ECMA-48, and I think now I can dispense with Curses > (for linux; while on Windows I use what I had before). > > I can directly send escape codes to stdout to give me cursor > positioning, and bold (I haven't tested colour yet, but that is not > critical). > > And, with the help of downloaded versions of kbhit() and getch() which > modify how getchar() works, I can directly get keyboard entry, even if > some keys are escape sequences. What does "directly get" mean? The right way to get keyboard input is by reading the characters that come from the terminal emulator (or the real terminal in the unlikely event you have one connected) via the tty device or a pseudo tty device. You've previously talked about direct access to the keyboard in a way that suggests you don't like this model, but any code that tries to bypass all this is unlikely to play well with other programs. Can you link to the kbhit and getch code? Most of the ones that come up in a search don't do much at all. curses allows you to do non-blocking reads and, after calling the keypad function, the curses input functions do pretty much what getch does. > There are still missing modifiers, but > I can live with that too. (kbhit() is essential when writing an > editor, to flush out any pending keystrokes, which otherwise cause > problems when the screen can't keep up). Do you really want an editor that drops keystrokes? > Now what I want to know is, what on earth is curses, ncurses or > PDcurses actually for?! To do what you've decided to do but in a more portable way. I suggested extending the input function so that it can return more keycodes (provided you accept that not all terminals can generate them all) but a quick test reveals that it already does this. I.e. in an xterm which can generate all these combinations, wgetch will return distinct codes for Home, Shift+Home, Ctrl+Home, Alt+Home, Ctrl+Alt+Home and so on for others that I did not test. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web