Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #58153 > unrolled thread
| Started by | lawrencedo99@gmail.com |
|---|---|
| First post | 2016-06-09 20:37 -0700 |
| Last post | 2016-07-02 20:05 +0000 |
| Articles | 20 on this page of 178 — 28 participants |
Back to article view | Back to comp.os.vms
VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-09 20:37 -0700
Re: VMS Features I Wish Linux Had "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-10 08:17 -0500
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-10 17:04 +0200
Re: VMS Features I Wish Linux Had osuvman50@gmail.com - 2016-06-10 08:34 -0700
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-10 12:12 -0400
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-10 20:28 +0200
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-10 18:32 +0000
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-10 20:44 +0200
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 15:35 -0400
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-11 09:07 +0200
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-11 10:52 -0400
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-11 16:59 +0200
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-12 11:12 +0200
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-12 12:32 +0200
Re: VMS Features I Wish Linux Had johnwallace4@yahoo.co.uk - 2016-06-12 04:50 -0700
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-12 14:12 +0200
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-12 14:47 +0200
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-12 17:14 +0200
Re: VMS Features I Wish Linux Had Hans Vlems <hvlems@freenet.de> - 2016-06-12 09:40 -0700
Re: VMS Features I Wish Linux Had "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-12 16:06 -0400
Re: VMS Features I Wish Linux Had abrsvc <dansabrservices@yahoo.com> - 2016-06-12 13:19 -0700
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 16:32 -0400
Re: VMS Features I Wish Linux Had helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 20:19 +0000
Re: VMS Features I Wish Linux Had Hans Vlems <hvlems@freenet.de> - 2016-06-12 14:20 -0700
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-12 21:03 +0200
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-12 21:11 +0200
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-12 21:16 +0200
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-12 21:27 +0200
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-13 14:00 -0400
Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-13 21:35 +0200
Re: VMS Features I Wish Linux Had kludge@panix.com (Scott Dorsey) - 2016-06-14 11:28 -0400
Re: VMS Features I Wish Linux Had Bill Gunshannon <bill.gunshannon@gmail.com> - 2016-06-16 10:31 -0400
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-16 14:47 +0000
Re: VMS Features I Wish Linux Had Bill Gunshannon <bill.gunshannon@gmail.com> - 2016-06-16 12:19 -0400
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-16 16:44 +0000
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-16 18:23 +0000
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-16 21:26 +0000
VMS and Sweden, was: Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-14 19:33 +0000
Re: VMS and Sweden, was: Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-14 23:36 +0200
Re: VMS and Sweden, was: Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-16 18:18 +0000
Microsoft buys LinkedIn, Was: Re: VMS and Sweden Paul Sture <nospam@sture.ch> - 2016-06-19 12:39 +0200
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-19 13:51 +0000
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden Paul Sture <nospam@sture.ch> - 2016-06-19 19:43 +0200
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden Bill Gunshannon <bill.gunshannon@gmail.com> - 2016-06-19 15:53 -0400
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden lawrencedo99@gmail.com - 2016-06-19 22:44 -0700
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden Bill Gunshannon <bill.gunshannon@gmail.com> - 2016-06-20 13:21 -0400
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden lawrencedo99@gmail.com - 2016-06-21 07:02 -0700
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden VAXman- @SendSpamHere.ORG - 2016-06-20 11:25 +0000
Re: Microsoft buys LinkedIn, Was: Re: VMS and Sweden Paul Sture <nospam@sture.ch> - 2016-06-19 22:02 +0200
Re: VMS Features I Wish Linux Had koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 16:53 -0400
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-12 13:34 -0700
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-13 13:54 -0400
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-12 13:32 -0700
Re: VMS Features I Wish Linux Had Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 13:07 +0000
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-13 14:06 -0400
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-13 13:48 -0400
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-13 13:41 -0700
Re: VMS Features I Wish Linux Had John Reagan <xyzzy1959@gmail.com> - 2016-06-13 13:47 -0700
Re: VMS Features I Wish Linux Had Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 22:34 +0000
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-13 20:22 -0400
Re: VMS Features I Wish Linux Had Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-14 04:26 +0000
Re: VMS Features I Wish Linux Had "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-14 18:59 -0500
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-14 21:11 -0400
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-15 02:32 -0700
Re: VMS Features I Wish Linux Had Henry Crun <mike@rechtman.com> - 2016-06-12 16:54 +0300
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-12 15:52 +0000
Re: VMS Features I Wish Linux Had Henry Crun <mike@rechtman.com> - 2016-06-12 20:42 +0300
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-12 19:35 +0000
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-13 14:10 -0400
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-13 13:43 -0400
Filename completion, was: Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-10 18:29 +0000
Re: Filename completion, was: Re: VMS Features I Wish Linux Had Paul Sture <nospam@sture.ch> - 2016-06-10 22:14 +0200
Re: Filename completion, was: Re: VMS Features I Wish Linux Had Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-11 00:06 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-10 20:05 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-11 09:12 +0200
Re: VMS Features I Wish Linux Had Joukj <joukj@hrem.nano.tudelft.nl> - 2016-06-13 09:37 +0200
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-13 09:56 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-13 10:53 +0000
Re: VMS Features I Wish Linux Had Bill Gunshannon <bill.gunshannon@gmail.com> - 2016-06-11 09:33 -0400
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-11 10:53 -0400
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-11 15:27 +0000
Re: VMS Features I Wish Linux Had moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-12 03:15 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-12 11:19 +0200
Re: VMS Features I Wish Linux Had helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 18:55 +0000
Re: VMS Features I Wish Linux Had koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 08:59 -0400
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-13 15:55 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-13 19:36 +0000
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-13 13:46 -0700
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-13 21:20 +0000
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-13 17:27 -0700
Re: VMS Features I Wish Linux Had johnwallace4@yahoo.co.uk - 2016-06-13 23:55 -0700
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-14 00:12 -0700
Re: VMS Features I Wish Linux Had koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-14 09:36 -0400
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 10:32 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 11:24 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 10:42 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 20:12 +0200
Re: VMS Features I Wish Linux Had koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-14 09:32 -0400
Re: Parsers (was Re: VMS Features I Wish Linux Had) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-14 10:58 -0400
Re: Parsers (was Re: VMS Features I Wish Linux Had) VAXman- @SendSpamHere.ORG - 2016-06-14 15:25 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 11:22 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 10:35 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 20:16 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 20:37 +0000
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-14 18:27 -0400
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 11:24 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-15 11:57 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 14:39 +0200
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-15 08:58 -0400
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 15:30 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-15 14:35 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 19:29 +0200
Re: VMS Features I Wish Linux Had Chris Scheers <chris@applied-synergy.com> - 2016-06-15 13:26 -0500
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-16 11:18 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-16 09:57 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-16 13:58 +0200
Re: VMS Features I Wish Linux Had Chris Scheers <chris@applied-synergy.com> - 2016-06-16 15:20 -0500
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:17 +0200
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 11:21 +0200
Re: VMS Features I Wish Linux Had Paul Sture <nospam@sture.ch> - 2016-06-19 12:59 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-15 11:53 +0000
Re: VMS Features I Wish Linux Had koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 16:51 -0400
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 11:28 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 10:47 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 20:17 +0200
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 20:55 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 11:31 +0200
Re: VMS Features I Wish Linux Had David Froble <davef@tsoft-inc.com> - 2016-06-14 18:29 -0400
Re: VMS Features I Wish Linux Had johnwallace4@yahoo.co.uk - 2016-06-14 04:14 -0700
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-14 11:25 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 20:21 +0200
Re: VMS Features I Wish Linux Had koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-14 09:44 -0400
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-14 20:22 +0200
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-14 19:23 +0000
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 11:34 +0200
Re: VMS Features I Wish Linux Had johnwallace4@yahoo.co.uk - 2016-06-15 03:17 -0700
Re: VMS Features I Wish Linux Had Johnny Billquist <bqt@softjar.se> - 2016-06-15 13:04 +0200
Re: VMS Features I Wish Linux Had Paul Sture <nospam@sture.ch> - 2016-06-19 05:34 +0200
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-18 21:45 -0700
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-16 18:31 +0000
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-15 02:36 -0700
Re: VMS Features I Wish Linux Had Hans Vlems <hvlems@freenet.de> - 2016-06-15 11:53 -0700
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-06-15 19:10 +0000
Terminals, was: Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-16 18:45 +0000
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-16 18:33 +0000
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-30 02:15 -0700
Re: VMS Features I Wish Linux Had Steven Schweda <sms.antinode@gmail.com> - 2016-06-30 03:58 -0700
Re: VMS Features I Wish Linux Had hb <end.of@inter.net> - 2016-06-30 14:25 +0200
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-30 11:29 -0400
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-06-30 15:29 -0700
Re: VMS Features I Wish Linux Had "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-30 20:59 -0400
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-07-01 11:21 -0400
Re: VMS Features I Wish Linux Had "Kerry Main" <kemain.nospam@gmail.com> - 2016-07-01 12:41 -0400
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-07-01 14:39 -0400
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-01 15:13 -0700
Re: VMS Features I Wish Linux Had "Kerry Main" <kemain.nospam@gmail.com> - 2016-07-01 21:31 -0400
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-07-02 16:33 -0400
Re: VMS Features I Wish Linux Had "Kerry Main" <kemain.nospam@gmail.com> - 2016-07-02 16:57 -0400
Re: VMS Features I Wish Linux Had Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-07-02 17:34 -0400
Re: VMS Features I Wish Linux Had helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-07-03 06:40 +0000
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-03 00:09 -0700
Re: VMS Features I Wish Linux Had "Kerry Main" <kemain.nospam@gmail.com> - 2016-07-03 08:12 -0400
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-07-03 12:35 +0000
Re: VMS Features I Wish Linux Had Paul Sture <nospam@sture.ch> - 2016-07-03 10:50 +0200
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-03 11:05 +0000
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-07-03 12:29 +0000
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-03 11:44 +0000
Re: VMS Features I Wish Linux Had johnwallace4@yahoo.co.uk - 2016-07-03 06:59 -0700
Re: VMS Features I Wish Linux Had Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-03 15:58 +0000
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-03 14:38 -0700
Re: VMS Features I Wish Linux Had "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-07-03 17:53 -0500
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-03 16:19 -0700
Re: VMS Features I Wish Linux Had "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-07-03 21:03 -0500
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-03 21:11 -0700
Re: VMS Features I Wish Linux Had johnwallace4@yahoo.co.uk - 2016-07-04 05:48 -0700
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-04 16:55 -0700
Re: VMS Features I Wish Linux Had lawrencedo99@gmail.com - 2016-07-03 14:33 -0700
Re: VMS Features I Wish Linux Had VAXman- @SendSpamHere.ORG - 2016-07-02 20:05 +0000
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-15 11:53 +0000 |
| Message-ID | <00B0AA63.7138A5C4@SendSpamHere.ORG> |
| In reply to | #58374 |
In article <njq0bp$ndo$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes: >VAXman- @SendSpamHere.ORG wrote: >> In article <njphlo$sa6$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-14 12:35, VAXman-@SendSpamHere.ORG wrote: >>>> In article <njoicg$lv7$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-13 21:36, VAXman-@SendSpamHere.ORG wrote: >>>>>> In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>>> On 2016-06-13 14:59, Bob Koehler wrote: >>>>>>>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>>>>>>> One issue with the VMS terminal line editing is because it is handled in >>>>>>>>> the driver, it does not have access to the filesystem to allow it to do >>>>>>>>> filename completion. >>>>>>>> Which belongs in the CLI, not the terminal driver. The CLI should be >>>>>>>> doing it's own command line editing,instead of leaning on the limited >>>>>>>> editing in the driver. >>>>>>> I don't agree. I want command line editing, no matter if I'm at the CLI, >>>>>>> or in some user application. And I do not consider it to be a good >>>>>>> system design that every program should include their own version of >>>>>>> commmand line editing. >>>>>> In VMS, what do you think processes command lines? Assuming you're using >>>>>> the VMS CLI callback in yor program(s). If it's just stupid unix-line -X >>>>>> switches, etc., then you're on your own. >>>>> Uh... What if I do a read in my program...? How would CLI editing come >>>>> into play there? Are you suggesting that all terminal I/O should be done >>>>> by callbacks to the CLI instead of issuing a QIO? >>>> Explain? A 'read' of what? ...from where? >>> A read of a string, from a terminal, to a program. >>> >>> In BASIC: >>> >>> LINPUT FOO$ >>> >>> In MACRO-11: >>> >>> QIOW$S #IO.RLB,#TILUN,#TIEFN,,#IOSB,,<#BUF,#BUFSIZ> >>> >>> In C: >>> >>> fgets(buffer, bufsiz, stdin); >>> >>> In FORTRAN-77: >>> >>> READ(5,10) STR >>> 10 FORMAT(1A80) >>> >>> >>> It should not be that hard to get. ;-) >> >> And those things don't work? Sure they do but where is there any implication >> that you should be able to edit the input in those? >> > >Well, I had this simple program laying around, and used it as an example. > >10 Input "Temp F"; t > GoTo 99 Unless t <> 0. > > c = ( t - 32 ) * 5 / 9 > Print c > > GoTo 10 > >99 End > >Ready > >run >TEMP 14-JUN-2016 18:24 > >Temp F? 123 >DFE90A::DFE 18:24:13 BASIC CPU=00:00:01.28 PF=2638 IO=789 MEM=1140 >Temp F? 423 > 217.222 > >Note, I typed 123, then a ^T to get on a new line to leave the 123 there, then 3 >left arrows and a 4. The data ended up being 423. Is that what's being asked? ??? After CTRL-T, assuming it wasn't disabled, your prompt should have been: Temp F? 123 You then moved the cursor backward and replace 1 with 4. That's some of it. Now, enter enough characters to fill the line and cause a carriage return. Now try backspacing. ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-13 16:51 -0400 |
| Message-ID | <SOvsKFZy$cGX@eisner.encompasserve.org> |
| In reply to | #58305 |
In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > On 2016-06-13 14:59, Bob Koehler wrote: >> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>> >>> One issue with the VMS terminal line editing is because it is handled in >>> the driver, it does not have access to the filesystem to allow it to do >>> filename completion. >> >> Which belongs in the CLI, not the terminal driver. The CLI should be >> doing it's own command line editing,instead of leaning on the limited >> editing in the driver. > > I don't agree. I want command line editing, no matter if I'm at the CLI, > or in some user application. And I do not consider it to be a good > system design that every program should include their own version of > commmand line editing. Putting editing into the CLI does not mean it has to be removed from the terminal driver. But the terminal driver is a limited context and should only be used for limited purposes. I've got UNIX shells that will let me make use of most of the power of vi (oxymoron), or emacs. I see no reason why all that should be in a driver. But I also don't want a driver that provides only the functions of a card punch.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-14 11:28 +0200 |
| Message-ID | <njoior$lv7$4@Iltempo.Update.UU.SE> |
| In reply to | #58328 |
On 2016-06-13 22:51, Bob Koehler wrote: > In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-13 14:59, Bob Koehler wrote: >>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>> >>>> One issue with the VMS terminal line editing is because it is handled in >>>> the driver, it does not have access to the filesystem to allow it to do >>>> filename completion. >>> >>> Which belongs in the CLI, not the terminal driver. The CLI should be >>> doing it's own command line editing,instead of leaning on the limited >>> editing in the driver. >> >> I don't agree. I want command line editing, no matter if I'm at the CLI, >> or in some user application. And I do not consider it to be a good >> system design that every program should include their own version of >> commmand line editing. > > Putting editing into the CLI does not mean it has to be removed from > the terminal driver. But the terminal driver is a limited context > and should only be used for limited purposes. True. One does not exclude the other. But I fail to see the benefit of having both. > I've got UNIX shells that will let me make use of most of the power > of vi (oxymoron), or emacs. I see no reason why all that should be > in a driver. But I also don't want a driver that provides only the > functions of a card punch. I want that vi or emacs capability always, no matter what program or context I am in, and not just at the CLI or shell. Which is the reason I think it belongs in the driver. This functionality, in my mind, is not tied to a specific application or environment. It's a functionality that I want basically all the time, everywhere. Based on that, it's not hard to see where it should go. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-14 10:47 +0000 |
| Message-ID | <00B0A991.08C9F17D@SendSpamHere.ORG> |
| In reply to | #58345 |
In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-13 22:51, Bob Koehler wrote: >> In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-13 14:59, Bob Koehler wrote: >>>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>>> >>>>> One issue with the VMS terminal line editing is because it is handled in >>>>> the driver, it does not have access to the filesystem to allow it to do >>>>> filename completion. >>>> >>>> Which belongs in the CLI, not the terminal driver. The CLI should be >>>> doing it's own command line editing,instead of leaning on the limited >>>> editing in the driver. >>> >>> I don't agree. I want command line editing, no matter if I'm at the CLI, >>> or in some user application. And I do not consider it to be a good >>> system design that every program should include their own version of >>> commmand line editing. >> >> Putting editing into the CLI does not mean it has to be removed from >> the terminal driver. But the terminal driver is a limited context >> and should only be used for limited purposes. > >True. One does not exclude the other. But I fail to see the benefit of >having both. > >> I've got UNIX shells that will let me make use of most of the power >> of vi (oxymoron), or emacs. I see no reason why all that should be >> in a driver. But I also don't want a driver that provides only the >> functions of a card punch. > >I want that vi or emacs capability always, no matter what program or >context I am in, and not just at the CLI or shell. Which is the reason I >think it belongs in the driver. This functionality, in my mind, is not >tied to a specific application or environment. It's a functionality that >I want basically all the time, everywhere. Based on that, it's not hard >to see where it should go. So, vi and or emacs aren't that special; it's the unix terminal driver that's to be given all the credits. ...wait for it... ...wait for it... Hopefully, the light comes on. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-14 20:17 +0200 |
| Message-ID | <njphnc$sa6$2@Iltempo.Update.UU.SE> |
| In reply to | #58349 |
On 2016-06-14 12:47, VAXman-@SendSpamHere.ORG wrote: > In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-13 22:51, Bob Koehler wrote: >>> In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-13 14:59, Bob Koehler wrote: >>>>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>>>> >>>>>> One issue with the VMS terminal line editing is because it is handled in >>>>>> the driver, it does not have access to the filesystem to allow it to do >>>>>> filename completion. >>>>> >>>>> Which belongs in the CLI, not the terminal driver. The CLI should be >>>>> doing it's own command line editing,instead of leaning on the limited >>>>> editing in the driver. >>>> >>>> I don't agree. I want command line editing, no matter if I'm at the CLI, >>>> or in some user application. And I do not consider it to be a good >>>> system design that every program should include their own version of >>>> commmand line editing. >>> >>> Putting editing into the CLI does not mean it has to be removed from >>> the terminal driver. But the terminal driver is a limited context >>> and should only be used for limited purposes. >> >> True. One does not exclude the other. But I fail to see the benefit of >> having both. >> >>> I've got UNIX shells that will let me make use of most of the power >>> of vi (oxymoron), or emacs. I see no reason why all that should be >>> in a driver. But I also don't want a driver that provides only the >>> functions of a card punch. >> >> I want that vi or emacs capability always, no matter what program or >> context I am in, and not just at the CLI or shell. Which is the reason I >> think it belongs in the driver. This functionality, in my mind, is not >> tied to a specific application or environment. It's a functionality that >> I want basically all the time, everywhere. Based on that, it's not hard >> to see where it should go. > > So, vi and or emacs aren't that special; it's the unix terminal driver that's > to be given all the credits. ...wait for it... ...wait for it... Hopefully, > the light comes on. I'm getting the feeling that either you do not understand anything at all, or you are trying to be funny and totally failing. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-14 20:55 +0000 |
| Message-ID | <00B0A9E6.12C2CF5B@SendSpamHere.ORG> |
| In reply to | #58365 |
In article <njphnc$sa6$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-14 12:47, VAXman-@SendSpamHere.ORG wrote: >> In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-13 22:51, Bob Koehler wrote: >>>> In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-13 14:59, Bob Koehler wrote: >>>>>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>>>>> >>>>>>> One issue with the VMS terminal line editing is because it is handled in >>>>>>> the driver, it does not have access to the filesystem to allow it to do >>>>>>> filename completion. >>>>>> >>>>>> Which belongs in the CLI, not the terminal driver. The CLI should be >>>>>> doing it's own command line editing,instead of leaning on the limited >>>>>> editing in the driver. >>>>> >>>>> I don't agree. I want command line editing, no matter if I'm at the CLI, >>>>> or in some user application. And I do not consider it to be a good >>>>> system design that every program should include their own version of >>>>> commmand line editing. >>>> >>>> Putting editing into the CLI does not mean it has to be removed from >>>> the terminal driver. But the terminal driver is a limited context >>>> and should only be used for limited purposes. >>> >>> True. One does not exclude the other. But I fail to see the benefit of >>> having both. >>> >>>> I've got UNIX shells that will let me make use of most of the power >>>> of vi (oxymoron), or emacs. I see no reason why all that should be >>>> in a driver. But I also don't want a driver that provides only the >>>> functions of a card punch. >>> >>> I want that vi or emacs capability always, no matter what program or >>> context I am in, and not just at the CLI or shell. Which is the reason I >>> think it belongs in the driver. This functionality, in my mind, is not >>> tied to a specific application or environment. It's a functionality that >>> I want basically all the time, everywhere. Based on that, it's not hard >>> to see where it should go. >> >> So, vi and or emacs aren't that special; it's the unix terminal driver that's >> to be given all the credits. ...wait for it... ...wait for it... Hopefully, >> the light comes on. > >I'm getting the feeling that either you do not understand anything at >all, or you are trying to be funny and totally failing. It is you that are not being serious. You'd said you wanted 'vi' or 'emacs' capability always. I'll wager a good bet that those features are NOT part of the basic input of unix/linux. Why do you believe that the terminal driver should have recall, search, find-and-replace, insert, delete, etc. which are functions in 'vi', 'emacs' and most every editor; yet, most of those functions are not implemented by/in the terminal driver. If you want elaborate input editing, don't use the basic terminal driver I/O; use other I/O routines -- for example, SMG. If it was ALL up to the terminal driver and it buffered a pool of your input, how can you know if the recalled input is applicable to your command line or your current application or some previously executed application? Oh, let me see, the terminal driver should expunge any data from the previous application at application rundown? OK, I can see that. Then, the terminal driver would need to maintain mode state of the input so that a new application can not touch the command line(s), or do you like to open up potential security holes in the name of simplicity simply because you don't want to take the time to program your application's input? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 11:31 +0200 |
| Message-ID | <njr79i$khb$1@Iltempo.Update.UU.SE> |
| In reply to | #58375 |
On 2016-06-14 22:55, VAXman-@SendSpamHere.ORG wrote: > In article <njphnc$sa6$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-14 12:47, VAXman-@SendSpamHere.ORG wrote: >>> In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-13 22:51, Bob Koehler wrote: >>>>> In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> On 2016-06-13 14:59, Bob Koehler wrote: >>>>>>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>>>>>> >>>>>>>> One issue with the VMS terminal line editing is because it is handled in >>>>>>>> the driver, it does not have access to the filesystem to allow it to do >>>>>>>> filename completion. >>>>>>> >>>>>>> Which belongs in the CLI, not the terminal driver. The CLI should be >>>>>>> doing it's own command line editing,instead of leaning on the limited >>>>>>> editing in the driver. >>>>>> >>>>>> I don't agree. I want command line editing, no matter if I'm at the CLI, >>>>>> or in some user application. And I do not consider it to be a good >>>>>> system design that every program should include their own version of >>>>>> commmand line editing. >>>>> >>>>> Putting editing into the CLI does not mean it has to be removed from >>>>> the terminal driver. But the terminal driver is a limited context >>>>> and should only be used for limited purposes. >>>> >>>> True. One does not exclude the other. But I fail to see the benefit of >>>> having both. >>>> >>>>> I've got UNIX shells that will let me make use of most of the power >>>>> of vi (oxymoron), or emacs. I see no reason why all that should be >>>>> in a driver. But I also don't want a driver that provides only the >>>>> functions of a card punch. >>>> >>>> I want that vi or emacs capability always, no matter what program or >>>> context I am in, and not just at the CLI or shell. Which is the reason I >>>> think it belongs in the driver. This functionality, in my mind, is not >>>> tied to a specific application or environment. It's a functionality that >>>> I want basically all the time, everywhere. Based on that, it's not hard >>>> to see where it should go. >>> >>> So, vi and or emacs aren't that special; it's the unix terminal driver that's >>> to be given all the credits. ...wait for it... ...wait for it... Hopefully, >>> the light comes on. >> >> I'm getting the feeling that either you do not understand anything at >> all, or you are trying to be funny and totally failing. > > It is you that are not being serious. You'd said you wanted 'vi' or 'emacs' > capability always. I'll wager a good bet that those features are NOT part of > the basic input of unix/linux. Why do you believe that the terminal driver > should have recall, search, find-and-replace, insert, delete, etc. which are > functions in 'vi', 'emacs' and most every editor; yet, most of those functions > are not implemented by/in the terminal driver. Ok. So you did not understand. The "vi" or "emacs" in line editing is not the full editor, and have never been. It is still line editing. But yes, things like recalling and editing previous lines, as well as the current line are things that I like to have. And you are right, Unix/Linux do not have that, which is one of the things I am complaining about. The solution of having to include it in every program is horrible. Not only does it mean that it might be working differently in every program, but it also means that one program might not have it at all. So it's all very inconsistent, and ugly. I think the terminal driver *is* the right place for this. But no, I am not calling for a full blown screen editor, and never have been. > If you want elaborate input editing, don't use the basic terminal driver I/O; > use other I/O routines -- for example, SMG. If it was ALL up to the terminal > driver and it buffered a pool of your input, how can you know if the recalled > input is applicable to your command line or your current application or some > previously executed application? Oh, let me see, the terminal driver should > expunge any data from the previous application at application rundown? OK, I > can see that. Then, the terminal driver would need to maintain mode state of > the input so that a new application can not touch the command line(s), or do > you like to open up potential security holes in the name of simplicity simply > because you don't want to take the time to program your application's input? What data a user enters is the users choice. If he get that from recalling a previous line and entering it, or types it all in by hand makes no difference. I suspect you still think that the terminal driver should handle things like rubout and ^U/^X. Why do you think those should be in there, but not the ability to delete anything else than the last character entered? Johnny
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-14 18:29 -0400 |
| Message-ID | <njq0gl$ndo$2@dont-email.me> |
| In reply to | #58365 |
Johnny Billquist wrote: > I'm getting the feeling that either you do not understand anything at > all, or you are trying to be funny and totally failing. Wait, I thought Brian's comment on lawyers and hell was rather funny ....
[toc] | [prev] | [next] | [standalone]
| From | johnwallace4@yahoo.co.uk |
|---|---|
| Date | 2016-06-14 04:14 -0700 |
| Message-ID | <b367314f-9a9f-4881-8c9b-c3e24029b261@googlegroups.com> |
| In reply to | #58345 |
On Tuesday, 14 June 2016 10:29:00 UTC+1, Johnny Billquist wrote: > On 2016-06-13 22:51, Bob Koehler wrote: > > In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > >> On 2016-06-13 14:59, Bob Koehler wrote: > >>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: > >>>> > >>>> One issue with the VMS terminal line editing is because it is handled in > >>>> the driver, it does not have access to the filesystem to allow it to do > >>>> filename completion. > >>> > >>> Which belongs in the CLI, not the terminal driver. The CLI should be > >>> doing it's own command line editing,instead of leaning on the limited > >>> editing in the driver. > >> > >> I don't agree. I want command line editing, no matter if I'm at the CLI, > >> or in some user application. And I do not consider it to be a good > >> system design that every program should include their own version of > >> commmand line editing. > > > > Putting editing into the CLI does not mean it has to be removed from > > the terminal driver. But the terminal driver is a limited context > > and should only be used for limited purposes. > > True. One does not exclude the other. But I fail to see the benefit of > having both. > > > I've got UNIX shells that will let me make use of most of the power > > of vi (oxymoron), or emacs. I see no reason why all that should be > > in a driver. But I also don't want a driver that provides only the > > functions of a card punch. > > I want that vi or emacs capability always, no matter what program or > context I am in, and not just at the CLI or shell. Which is the reason I > think it belongs in the driver. This functionality, in my mind, is not > tied to a specific application or environment. It's a functionality that > I want basically all the time, everywhere. Based on that, it's not hard > to see where it should go. > > Johnny It may not be hard to see where it should go on RSX. VMS is not RSX (and UNIX is not VMS). For this kind of line-editing thing, VMS has SMG, which also works for line-oriented (as well as screen-oriented) applications. So for command line handling with multi line recall, definable keys, and other such delights, VMS programmers might want to look at SMG or something based on SMG. Or they might not. Depends what the goals and constraints are.
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-14 11:25 +0000 |
| Message-ID | <00B0A996.75E73ECD@SendSpamHere.ORG> |
| In reply to | #58350 |
In article <b367314f-9a9f-4881-8c9b-c3e24029b261@googlegroups.com>, johnwallace4@yahoo.co.uk writes: >On Tuesday, 14 June 2016 10:29:00 UTC+1, Johnny Billquist wrote: >> On 2016-06-13 22:51, Bob Koehler wrote: >> > In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> >> On 2016-06-13 14:59, Bob Koehler wrote: >> >>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >> >>>> >> >>>> One issue with the VMS terminal line editing is because it is handled in >> >>>> the driver, it does not have access to the filesystem to allow it to do >> >>>> filename completion. >> >>> >> >>> Which belongs in the CLI, not the terminal driver. The CLI should be >> >>> doing it's own command line editing,instead of leaning on the limited >> >>> editing in the driver. >> >> >> >> I don't agree. I want command line editing, no matter if I'm at the CLI, >> >> or in some user application. And I do not consider it to be a good >> >> system design that every program should include their own version of >> >> commmand line editing. >> > >> > Putting editing into the CLI does not mean it has to be removed from >> > the terminal driver. But the terminal driver is a limited context >> > and should only be used for limited purposes. >> >> True. One does not exclude the other. But I fail to see the benefit of >> having both. >> >> > I've got UNIX shells that will let me make use of most of the power >> > of vi (oxymoron), or emacs. I see no reason why all that should be >> > in a driver. But I also don't want a driver that provides only the >> > functions of a card punch. >> >> I want that vi or emacs capability always, no matter what program or >> context I am in, and not just at the CLI or shell. Which is the reason I >> think it belongs in the driver. This functionality, in my mind, is not >> tied to a specific application or environment. It's a functionality that >> I want basically all the time, everywhere. Based on that, it's not hard >> to see where it should go. >> >> Johnny > >It may not be hard to see where it should go on RSX. > >VMS is not RSX (and UNIX is not VMS). > >For this kind of line-editing thing, VMS has SMG, which also >works for line-oriented (as well as screen-oriented) applications. > >So for command line handling with multi line recall, definable keys, >and other such delights, VMS programmers might want to look at >SMG or something based on SMG. Or they might not. Depends what >the goals and constraints are. Nope, you're wrong! All of it belongs in the terminal driver! Incoming! Run for cover! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-14 20:21 +0200 |
| Message-ID | <njphui$ss1$1@Iltempo.Update.UU.SE> |
| In reply to | #58350 |
On 2016-06-14 13:14, johnwallace4@yahoo.co.uk wrote: > On Tuesday, 14 June 2016 10:29:00 UTC+1, Johnny Billquist wrote: >> On 2016-06-13 22:51, Bob Koehler wrote: >>> In article <njmdvo$vo0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-13 14:59, Bob Koehler wrote: >>>>> In article <njeel9$fq3$1@dont-email.me>, "John E. Malmberg" <wb8tyw@qsl.net_work> writes: >>>>>> >>>>>> One issue with the VMS terminal line editing is because it is handled in >>>>>> the driver, it does not have access to the filesystem to allow it to do >>>>>> filename completion. >>>>> >>>>> Which belongs in the CLI, not the terminal driver. The CLI should be >>>>> doing it's own command line editing,instead of leaning on the limited >>>>> editing in the driver. >>>> >>>> I don't agree. I want command line editing, no matter if I'm at the CLI, >>>> or in some user application. And I do not consider it to be a good >>>> system design that every program should include their own version of >>>> commmand line editing. >>> >>> Putting editing into the CLI does not mean it has to be removed from >>> the terminal driver. But the terminal driver is a limited context >>> and should only be used for limited purposes. >> >> True. One does not exclude the other. But I fail to see the benefit of >> having both. >> >>> I've got UNIX shells that will let me make use of most of the power >>> of vi (oxymoron), or emacs. I see no reason why all that should be >>> in a driver. But I also don't want a driver that provides only the >>> functions of a card punch. >> >> I want that vi or emacs capability always, no matter what program or >> context I am in, and not just at the CLI or shell. Which is the reason I >> think it belongs in the driver. This functionality, in my mind, is not >> tied to a specific application or environment. It's a functionality that >> I want basically all the time, everywhere. Based on that, it's not hard >> to see where it should go. >> >> Johnny > > It may not be hard to see where it should go on RSX. Well, if anything, I would expect people to argue just the opposite. With a very limited memory space, and a terminal driver that is already complex beyond belief, RSX could be a real nightmare. And to be honest - would I have to actually put the code directly into the terminal driver, it would never have happened. However, since the terminal driver have the capability of calling out to code outside of the driver, but in the driver context, it became much more doable. > VMS is not RSX (and UNIX is not VMS). Definitely not. VMS can bloat in way totally impossible in RSX. > For this kind of line-editing thing, VMS has SMG, which also > works for line-oriented (as well as screen-oriented) applications. > > So for command line handling with multi line recall, definable keys, > and other such delights, VMS programmers might want to look at > SMG or something based on SMG. Or they might not. Depends what > the goals and constraints are. Essentially the Unix solution, in other words. Each program should link in a library for doing this, and it depends on each program which library they happen to link in, and with which options, and the end result will be different everywhere. I'm not particularly impressed. Johnny
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-14 09:44 -0400 |
| Message-ID | <cBNZ36WrxynT@eisner.encompasserve.org> |
| In reply to | #58345 |
In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > > I want that vi or emacs capability always, no matter what program or > context I am in, and not just at the CLI or shell. Which is the reason I > think it belongs in the driver. This functionality, in my mind, is not > tied to a specific application or environment. It's a functionality that > I want basically all the time, everywhere. Based on that, it's not hard > to see where it should go. In the driver basically means at elevated IPL. I don't want someone running emacs at elevated IPL on my systems. That's why we need both the in-the-driver limited capabilities and the in-the-program capabilities. And DCL should take more adantage of the latter.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-14 20:22 +0200 |
| Message-ID | <njpi0c$ss1$2@Iltempo.Update.UU.SE> |
| In reply to | #58355 |
On 2016-06-14 15:44, Bob Koehler wrote: > In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> >> I want that vi or emacs capability always, no matter what program or >> context I am in, and not just at the CLI or shell. Which is the reason I >> think it belongs in the driver. This functionality, in my mind, is not >> tied to a specific application or environment. It's a functionality that >> I want basically all the time, everywhere. Based on that, it's not hard >> to see where it should go. > > In the driver basically means at elevated IPL. I don't want someone > running emacs at elevated IPL on my systems. That's why we need both > the in-the-driver limited capabilities and the in-the-program > capabilities. And DCL should take more adantage of the latter. Noone have suggested running Emacs in the driver. Jeez... Johnny
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-14 19:23 +0000 |
| Message-ID | <njplja$cjc$1@dont-email.me> |
| In reply to | #58367 |
On 2016-06-14, Johnny Billquist <bqt@softjar.se> wrote: > On 2016-06-14 15:44, Bob Koehler wrote: >> In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> >>> I want that vi or emacs capability always, no matter what program or >>> context I am in, and not just at the CLI or shell. Which is the reason I >>> think it belongs in the driver. This functionality, in my mind, is not >>> tied to a specific application or environment. It's a functionality that >>> I want basically all the time, everywhere. Based on that, it's not hard >>> to see where it should go. >> >> In the driver basically means at elevated IPL. I don't want someone >> running emacs at elevated IPL on my systems. That's why we need both >> the in-the-driver limited capabilities and the in-the-program >> capabilities. And DCL should take more adantage of the latter. > > Noone have suggested running Emacs in the driver. Jeez... > The best solution appears to be to keep the editing of the current line in the terminal driver (which would allow repainting of the line if there's any output while the user is typing) and to keep management of the command history within the application itself. I wouldn't want to see large chunks of command history kept in non-paged memory in the kernel; I don't think that's where it belongs. OTOH having an OS which implements basic line editing services means you don't have to implement that in every application. Of course, that argument would be more convincing if the terminal driver of the OS in question allowed editing of lines which wrapped multiple physical lines. :-) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 11:34 +0200 |
| Message-ID | <njr7f7$khb$2@Iltempo.Update.UU.SE> |
| In reply to | #58370 |
On 2016-06-14 21:23, Simon Clubley wrote: > On 2016-06-14, Johnny Billquist <bqt@softjar.se> wrote: >> On 2016-06-14 15:44, Bob Koehler wrote: >>> In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> >>>> I want that vi or emacs capability always, no matter what program or >>>> context I am in, and not just at the CLI or shell. Which is the reason I >>>> think it belongs in the driver. This functionality, in my mind, is not >>>> tied to a specific application or environment. It's a functionality that >>>> I want basically all the time, everywhere. Based on that, it's not hard >>>> to see where it should go. >>> >>> In the driver basically means at elevated IPL. I don't want someone >>> running emacs at elevated IPL on my systems. That's why we need both >>> the in-the-driver limited capabilities and the in-the-program >>> capabilities. And DCL should take more adantage of the latter. >> >> Noone have suggested running Emacs in the driver. Jeez... >> > > The best solution appears to be to keep the editing of the current line > in the terminal driver (which would allow repainting of the line if > there's any output while the user is typing) and to keep management of > the command history within the application itself. Well, you could argue that the application should be responsible for the repainting as well... > I wouldn't want to see large chunks of command history kept in non-paged > memory in the kernel; I don't think that's where it belongs. OTOH having > an OS which implements basic line editing services means you don't have > to implement that in every application. Well, the saved history needs to go somewhere. Exactly where is a technical question. But you are repeating my point about having the (hopefully) same code replicated in each program being a bad design. > Of course, that argument would be more convincing if the terminal driver > of the OS in question allowed editing of lines which wrapped multiple > physical lines. :-) Agreed. But that is once more a technical issue. It does not change the question of wether it should be there or not. But I agree that it should be done better. Johnny
[toc] | [prev] | [next] | [standalone]
| From | johnwallace4@yahoo.co.uk |
|---|---|
| Date | 2016-06-15 03:17 -0700 |
| Message-ID | <9a7fd492-6b7b-495c-8c24-84610dfd5d7d@googlegroups.com> |
| In reply to | #58399 |
On Wednesday, 15 June 2016 10:34:33 UTC+1, Johnny Billquist wrote: > On 2016-06-14 21:23, Simon Clubley wrote: > > On 2016-06-14, Johnny Billquist <bqt@softjar.se> wrote: > >> On 2016-06-14 15:44, Bob Koehler wrote: > >>> In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > >>>> > >>>> I want that vi or emacs capability always, no matter what program or > >>>> context I am in, and not just at the CLI or shell. Which is the reason I > >>>> think it belongs in the driver. This functionality, in my mind, is not > >>>> tied to a specific application or environment. It's a functionality that > >>>> I want basically all the time, everywhere. Based on that, it's not hard > >>>> to see where it should go. > >>> > >>> In the driver basically means at elevated IPL. I don't want someone > >>> running emacs at elevated IPL on my systems. That's why we need both > >>> the in-the-driver limited capabilities and the in-the-program > >>> capabilities. And DCL should take more adantage of the latter. > >> > >> Noone have suggested running Emacs in the driver. Jeez... > >> > > > > The best solution appears to be to keep the editing of the current line > > in the terminal driver (which would allow repainting of the line if > > there's any output while the user is typing) and to keep management of > > the command history within the application itself. > > Well, you could argue that the application should be responsible for the > repainting as well... > > > I wouldn't want to see large chunks of command history kept in non-paged > > memory in the kernel; I don't think that's where it belongs. OTOH having > > an OS which implements basic line editing services means you don't have > > to implement that in every application. > > Well, the saved history needs to go somewhere. Exactly where is a > technical question. But you are repeating my point about having the > (hopefully) same code replicated in each program being a bad design. > > > Of course, that argument would be more convincing if the terminal driver > > of the OS in question allowed editing of lines which wrapped multiple > > physical lines. :-) > > Agreed. But that is once more a technical issue. It does not change the > question of wether it should be there or not. But I agree that it should > be done better. > > Johnny continuing the rathole... Why does non-privileged hardware-independent commonly required stuff that's not in the driver need to be replicated individually in every program? Isn't that what libraries are for, be they vendor provided or whatever? Where the saved history lives is an interesting question. You presumably wouldn't want application B to be able to (by default) see data entered to application A?
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 13:04 +0200 |
| Message-ID | <njrcnr$is$1@Iltempo.Update.UU.SE> |
| In reply to | #58403 |
On 2016-06-15 12:17, johnwallace4@yahoo.co.uk wrote: > On Wednesday, 15 June 2016 10:34:33 UTC+1, Johnny Billquist wrote: >> On 2016-06-14 21:23, Simon Clubley wrote: >>> On 2016-06-14, Johnny Billquist <bqt@softjar.se> wrote: >>>> On 2016-06-14 15:44, Bob Koehler wrote: >>>>> In article <njoior$lv7$4@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> >>>>>> I want that vi or emacs capability always, no matter what program or >>>>>> context I am in, and not just at the CLI or shell. Which is the reason I >>>>>> think it belongs in the driver. This functionality, in my mind, is not >>>>>> tied to a specific application or environment. It's a functionality that >>>>>> I want basically all the time, everywhere. Based on that, it's not hard >>>>>> to see where it should go. >>>>> >>>>> In the driver basically means at elevated IPL. I don't want someone >>>>> running emacs at elevated IPL on my systems. That's why we need both >>>>> the in-the-driver limited capabilities and the in-the-program >>>>> capabilities. And DCL should take more adantage of the latter. >>>> >>>> Noone have suggested running Emacs in the driver. Jeez... >>>> >>> >>> The best solution appears to be to keep the editing of the current line >>> in the terminal driver (which would allow repainting of the line if >>> there's any output while the user is typing) and to keep management of >>> the command history within the application itself. >> >> Well, you could argue that the application should be responsible for the >> repainting as well... >> >>> I wouldn't want to see large chunks of command history kept in non-paged >>> memory in the kernel; I don't think that's where it belongs. OTOH having >>> an OS which implements basic line editing services means you don't have >>> to implement that in every application. >> >> Well, the saved history needs to go somewhere. Exactly where is a >> technical question. But you are repeating my point about having the >> (hopefully) same code replicated in each program being a bad design. >> >>> Of course, that argument would be more convincing if the terminal driver >>> of the OS in question allowed editing of lines which wrapped multiple >>> physical lines. :-) >> >> Agreed. But that is once more a technical issue. It does not change the >> question of wether it should be there or not. But I agree that it should >> be done better. >> >> Johnny > > continuing the rathole... > > Why does non-privileged hardware-independent commonly required > stuff that's not in the driver need to be replicated individually > in every program? Isn't that what libraries are for, be they > vendor provided or whatever? Well, this then boils down to which library, and which version of that library are you linking to, and is that a shared library, or is it linked into every program that use it? In an ideal world, all programs would then be linking to the same library, at the same version (I would assume), and this library would be shared, so that only one copy existed, and so on. But ideal worlds so seldom show up in real life... > Where the saved history lives is an interesting question. You > presumably wouldn't want application B to be able to (by default) > see data entered to application A? I can see that some people would prefer that. Personally, I do not feel strongly about it, and am perfectly happy with input used in one program show up in another if you recall old input. It might sometimes be useful, and otherwise I can just move on to the next input. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2016-06-19 05:34 +0200 |
| Message-ID | <kfgh3d-88d.ln1@news.chingola.ch> |
| In reply to | #58403 |
On 2016-06-15, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote: > On Wednesday, 15 June 2016 10:34:33 UTC+1, Johnny Billquist wrote: <snip> >> >> Well, the saved history needs to go somewhere. Exactly where is a >> technical question. But you are repeating my point about having the >> (hopefully) same code replicated in each program being a bad design. >> <snip> > continuing the rathole... > > > Where the saved history lives is an interesting question. You > presumably wouldn't want application B to be able to (by default) > see data entered to application A? The Terminal program in OS X has recently[1] acquired separate bash history files for separate sessions. These live in the directory ~/.bash_sessions. I'll admit I haven't explored this feature in depth yet, but when running Terminal with multiple sessions open, close then restart it (usually only done here for a logout/login or reboot), then each session has its previous context for current directory and history restored. (The scrollback buffer for each session in also restored, but that's probably part of the general OS X support for restoring application context from the previous session.) [1] I _think_ this feature arrived with the latest major version of OS X, last autumn. -- There are two hard things in computer science, and they are cache invalidation, naming, and off-by-one errors.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-18 21:45 -0700 |
| Message-ID | <e7c6308d-b086-43eb-91c7-b40e2dcf2503@googlegroups.com> |
| In reply to | #58575 |
On Sunday, June 19, 2016 at 3:56:17 PM UTC+12, Paul Sture wrote: > These live in the directory ~/.bash_sessions. Death to dotfile clutter! Why doesn’t Apple follow the XDG Base Directory Spec <http://standards.freedesktop.org/basedir-spec/latest/>? Even some Linux apps have discovered it.
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-16 18:31 +0000 |
| Message-ID | <njur9q$q8l$5@dont-email.me> |
| In reply to | #58399 |
On 2016-06-15, Johnny Billquist <bqt@softjar.se> wrote: > On 2016-06-14 21:23, Simon Clubley wrote: >> >> The best solution appears to be to keep the editing of the current line >> in the terminal driver (which would allow repainting of the line if >> there's any output while the user is typing) and to keep management of >> the command history within the application itself. > > Well, you could argue that the application should be responsible for the > repainting as well... > Depends; I'm thinking about things like broadcast messages from various random sources which are not under the control of the application. If it's a SMG style character cell windowed application then the application has to do it. If it's a scrolling TTY type application then a read with prompt gives the terminal driver enough information to do it itself. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.os.vms
csiph-web