I believe this has the same underlying problems as bugs 1582 and 34.  I have
noticed that Ctrl-Ins, Ctrl-Del, and Shift-Del, are unreliable for cutting and
pasting because sometimes the editor treats them as special (cut/paste/etc) and
sometimes inserts a literal (that is the arrow for Esc, partial block for
Shift-Del, etc) ascii code.  Are there different input modes that aren't
switching correctly?

Hi, no, there is only one input mode. However, as much keys as possible
are treated as literals. There is currently a problem with AltGr handling,
maybe this is related to your problem as well.

You can try to use TE instead of EDIT - both are part of FreeDOS :-).
If you have enough space and RAM, try SETEDIT - setedit.sourceforge.net
(32bit application, LOTS of features, can edit HUGE files).

Extra details: Alt-Backspace (undo) and formerly also
Ctrl-Ins, Ctrl-Del, and Shift-Del (copy/paste stuff,
now using other shortcuts) have the very SPECIAL
property that they are only available through the
"read port 0x60 if keyboard IRQ happens" interrupt
handler. This handler may sometimes get things wrong,
and I would really suggest to REMOVE this handler
completely. It depends on hardware and is only used
for keystrokes which would not put anything into the
keyboard buffer when using a NORMAL keyboard driver
(e.g. MKEYB / XKEYB / KEYB).

So the best would probably be to remove the special
keyboard handler completely. You would have to put
UNDO on another hotkey (and Shift/Ctrl-Ins/Del, too,
but that has already happened in 0.6 anyway) and
change waitforkeyboard(). The gain would be better
compatibility and probably less crashes.

Assigning to FreeDOS_1.0 milestone. -jh

Upgrading the severity from 'normal' to 'major'.  If it's on the "1.0 to-do
list", then it should be more important than a 'normal' severity.  -jh

*** Bug 1494 has been marked as a duplicate of this bug. ***

This is a duplicate of bug 1494, so I am removing bug 1494.

bug 1494 tells:
> the change to ctrl-c / ctrl-v or whatever is nice for those
> accustomied to it, but edit should still support the original
> keybindings as well.

Extra comment: shift/ctrl - ins/del (and alt-backspace) cannot
be detected by BIOS keyboard calls (except MAYBE through int 15.4f).

However, the direct hardware irq tapping in older EDIT versions
did not work well, so I would prefer to support ONLY hotkeys which
BIOS can detect. Maybe an option /WIRETAP_PORT60 to re-enable the
old shift/ctrl ins/del keys for those who insist on using them
anyway would be an idea? Alternatively, an option /HOOK_INT154f
is probably already enough. Suggestions on how to use int 15.4f
to detect those keys are welcome.

I have modified the keyboard handling in EDIT 0.6b/c/d, to use
only reliable BIOS functions now (older versions tried to read
the keyboard port directly). HOWEVER, this means that you can
only use keys which are recognized by the BIOS in those versions.
Shift-Ins / Shift-Del are okay in 0.6d, but Ctrl-Ins had to be
replaced by both-Shifts-Ins. Further, Shift-Backspace (no hotkey
anyway) seems to crash EDIT 0.6d and Alt-Backspace is not
available there (so you must use Ctrl-Z for "UNDO block delete").

Summary: EDIT 0.6d is very stable now, Shift-Del solved, but you
cannot use Ctrl-Ins in 0.6d (Ctrl-Del was not an hotkey anyway???).
Rather, you have to use both-Shifts-Ins for now.
An int 15.4f handler may solve this in a later version.

Thanks to Arkady reminding me that I had a bug in AT (102+ key)
keyboard handling, I can now call this bug "WORKSFORME" in version
0.7 of EDIT :-).

If you have an AT keyboard (not an 84 key XT / 8086 one, that is),
you can now use Ctrl-Ins and Alt-BackSpace as aliases for Ctrl-C
(copy) and Ctrl-Z (undo).

Shift-Ins / Ctrl-V (paste) and Shift-Del / Ctrl-X (cut) still work,
too, so all requested keys work now (Ctrl-Del has no special
function, I guess asking for that was a bug in the bug report).

If you do have an PC XT / 84 key keyboard, you 1. have to use
Ctrl-C and Ctrl-Z (cannot use Ctrl-Ins and Alt-BackSpace) but
2. there may be other EDIT bugs which only show up on PC XT.
Nobody has those 20+ years old PCs anymore, so this is hard to test.

EDIT 0.7 works better in 40 column modes now (if you have any use
for that feature?) but not really good. The main improvement is
that you can now put 2 windows side by side in one 80 columns EDIT
session without messing up the design too much. Use the mouse to
drag windows to other size or position.

Please change bug status from WORKSFORME to CLOSED if you agree
that EDIT 0.7 fixes the issues described in this bug report. Thanks.

I would like to mention that personally I have had no trouble with Edit 0.7 and 
this is under FreeDOS and under Windows 98's gui (in otherwords launching edit 
and running through a dos-box-window).  I think we could say that this bug is 
fixed.  I'm not going to close it though because I'm never a far outlier 
(except on this machine, I've got 512 entries in my root directory for Windows 
drive.  Something seriously wrong there.)