On Wed, Sep 2, 2020 at 5:47 AM tom ehlert wrote:
>
> UNIX System V certainly was connected to serial terminals (Televideo,
> VT100, ...)
>
> and it had the VI visual editor with definitively cursor movement
> across the screen, even when the terminal had no cursor keys.
I was a system administrat
On 9/2/2020 2:29 AM, tom ehlert wrote:
UNIX System V certainly was connected to serial terminals (Televideo,
VT100, ...)
and it had the VI visual editor with definitively cursor movement
across the screen, even when the terminal had no cursor keys.
cursor movement is not tied to memory-mapped d
> And as there aren't many tools where ZB's idea would make
> sense in his opinion, it seems a bit like brewing up a tempest in a
> teacup... ;-)
+1
> And another reason why this might not be in general a good idea is if we
> take compatibility with old(er) DOS software/environments serious, on
On 8/31/2020 7:16 PM, Jon Brase wrote:
> Not that convincing rationale considering rather modest overhead
necessary.
Recall that FreeDOS isn't just about having a FOSS alternative to
MS-DOS for modern machines (where you're really better off just using
Linux and DOSBox), or for your early-90s
> I'm not sure, but probably a program can distinguish whether it's in
> "interactive mode" or used for batch processing? It seems like this should be
> possible, but I don't think it is. I've tried doing something similar
> (though not quite the same), where I tried to automatically detect whet
On Tue, Sep 1, 2020 at 1:35 AM Jon Brase wrote:
>
> > Not that convincing rationale considering rather modest overhead necessary.
>
> Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for
> modern machines (where you're really better off just using Linux and DOSBox),
> or
On Mon, Aug 31, 2020 at 09:16:54PM -0500, Jon Brase wrote:
> Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS
> for modern machines (where you're really better off just using Linux and
> DOSBox), or for your early-90s 486 retrogaming machine, it's also meant
> to be an alte
On 01/09/2020 04:16, Jon Brase wrote:
it's also meant to be an alternative to MS-DOS for the very oldest PC hardware,
all the way back to the original IBM 5150. The core software might therefore be
expected to work in very little RAM. As I recall, the minimum configuration for
the 5150 had onl
> Not that convincing rationale considering rather modest overhead necessary.
Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for
modern machines (where you're really better off just using Linux and DOSBox),
or for your early-90s 486 retrogaming machine, it's also m
On Mon, Aug 31, 2020 at 8:43 PM ZB wrote:
> On Mon, Aug 31, 2020 at 05:07:14PM -0400, dmccunney wrote:
>
> > One of the most popular was Chris Dunford's CED. The following from
> > the CED docs is relevant:
>
> Thanks, I'll try to examine it. Still my suggestion is to make all these
> tools of Fr
On Mon, Aug 31, 2020 at 05:07:14PM -0400, dmccunney wrote:
> One of the most popular was Chris Dunford's CED. The following from
> the CED docs is relevant:
Thanks, I'll try to examine it. Still my suggestion is to make all these
tools of FreeDOS, that offer command line - better. There's really
On Mon, Aug 31, 2020 at 3:47 PM ZB wrote:
<...>
Recall that in the old days, DOS *COMMAND.COM* did not have command
line recall and edito\ing. To get it, you installed a TSR that added
it. There were a number of them.
One of the most popular was Chris Dunford's CED. The following from
the C
On Mon, Aug 31, 2020 at 12:40:34PM -0700, Ralf Quint wrote:
> If you are trying to keep 20 lines in the "history" and even assuming you
> limit the length of an entry line to 40 characters, that's already 800
> bytes, just for the buffer space...
...IN RAM, not in program code. :)
> But in any c
On 8/31/2020 11:28 AM, ZB wrote:
On Mon, Aug 31, 2020 at 11:10:56AM -0700, Ralf Quint wrote:
On 8/31/2020 10:44 AM, ZB wrote:
...
2. It could keep "history" for last, say. twenty-thirty command-line entries
(available as usual with Up/Down keys).
...
A second issue is that a lot of thos
One more I'm less interested in, but maybe it would be useful for the others?
I mean assuming we have full control over cursor movement as already
described - the "Ins" key could be a switch between default "insert" and
alternative "overwrite" mode (if not too complicated to implement)
--
regards
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote:
> Mercury also suggests Ctrl-Arrow for word-wise cursor movements.
Alternatively we could use PgUp/PgDn for this, which aren't used (and
probably won't be used for anything) by debug. This could have advantage
of "Control" not being invol
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote:
> It can harm if you do batch processing. And WHY do you perform "r"
> at the start? I always only look at "r" AFTER doing things which
> will have sent interesting data to the registers, NOT before.
Just realized it's an old habit :D if
On Mon, Aug 31, 2020 at 11:10:56AM -0700, Ralf Quint wrote:
> On 8/31/2020 10:44 AM, ZB wrote:
> > 1. I believe it would be handy if it could immediately after its start
> >perform 'r' (show registers' contents). Usually we're going to have
> >a look at that first when using "debug". Even
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote:
> Hi ZB,
>
> > 1. I believe it would be handy if it could immediately after its start
> > perform 'r' (show registers' contents). Usually we're going to have
> > a look at that first when using "debug". Even if we aren't - having
> >
Hi ZB,
> 1. I believe it would be handy if it could immediately after its start
> perform 'r' (show registers' contents). Usually we're going to have
> a look at that first when using "debug". Even if we aren't - having
> these two lines on the screen immediately after start won't do any h
On 8/31/2020 10:44 AM, ZB wrote:
1. I believe it would be handy if it could immediately after its start
perform 'r' (show registers' contents). Usually we're going to have
a look at that first when using "debug". Even if we aren't - having
these two lines on the screen immediately after
4. Ctrl + Arrow should skip a word at a time, as in most modern text editors.
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Monday, August 31, 2020 1:44 PM, ZB wrote:
> 1. I believe it would be handy if it could immediately after its start
> perform 'r' (show regi
1. I believe it would be handy if it could immediately after its start
perform 'r' (show registers' contents). Usually we're going to have
a look at that first when using "debug". Even if we aren't - having
these two lines on the screen immediately after start won't do any harm.
2. It could
23 matches
Mail list logo
