Some items from the K95 survey
Thanks to those who took the time to fill in the K95 survey:
If you haven't filled it in yet, please do; it's important to the future of
Kermit Project and to the thousands of people and companies and
organizations that use it and depend on it.
Some people had complaints that have easy answers, but they didn't leave
a mailing address for response, so I'll list them here. Here's one:
In VT320 mode, receiving some characters (typically seen while reading
mail with a text mail client program and encountering foreign language
spam) that either locks up the terminal emulation or switches to some
funny alternate character set consisting mostly of boxes, which can only
be cleared by using the "reset terminal" item on the "Actions" menu.
Someday I will have to sit down and figure out what character(s) do this
and how to filter them out.
No need for that, just look at the second item in the Bugs section of
the Kermit 95 FAQ:
and for greater detail look here:
The short answer is that, thanks to Microsoft, you have change your terminal
character set from Latin-1 (ISO 8859-1) or DEC Multinational, which you are
using now, and which are structurally standards-compliant, and which allow
VMS to send 8-bit control characters, to CP1252, the Microsoft code page in
which all of those emails are written that hang your terminal session.
Kermit is doing nothing wrong, its VT320 emulation is correct. If you used
a real VT terminal (220, 320, 420, or 520) instead of Kermit, the same
thing would happen, but, unlike with Kermit, you would not be able to do a
thing about it. In other words, you can't have 8-bit C1 control characters
(used, as far as I know, only by VMS) and Microsoft "smart quotes" at the
same time. If you configure K95 to use CP1252, you have to tell VMS to SET
TERM /NOEIGHT or whatever the syntax is.
I have a DEC/HP LK461-A2 keyboard on my PC. This is a PS2 keyboard
identical to the keyboard on a real VT320/VT420/VT520 terminal. The key
mappings aren't the same as when using a real VT... I think it is because
Kermit thinks it is a PC keyboard and trys to map the keys based on their
PC keyboard physical locations, which is wrong for this keyboard. I'm
sure I can fix this with a suitable custom key mapping, but laziness
Yes, the keyboard can be mapped any way you want. 99.9999% of all K95 users
have a PC keyboard, so the DEFAULT mapping is for them. But Kermit is
nothing if not customizable. I could make an LK keymap for you, but maybe
somebody else out there already has done that and will send it in.
Getting the terminal window size correctly.
I'm not aware of problems with this. As I mentioned here recently, I think,
the main reason for this complaint is that K95 has two choices for what to
do when you resize its window: change the screen dimensions or change the
font size. One of those has to be the default, and no default will please
everybody. The thing to keep in mind is that if there is some behavior you
don't like, there's probably a way to change it. If you can't find it, ask:
Hard to troubleshoot.
That's what we're here for. K95 has tons of troubleshooting tools and we
don't mind being asked about them. If you have a problem, ask.
The scripting language is very strange and difficult to work with.
Improve the scripting language and fix some of the bugs in it.
OK, it's strange, what can I say. It's an accretion of 25 years of history
and the contributions of different people. Anyway, name a scripting
language that isn't strange! :-) One reason that Kermit's language is
strange is that, even when we come realize that some facet of it could be
done better in a different way, we resist the temptation to ever change it
in any way that would break existing scripts. It's stable, and scripts are
portable across a wide range of platforms and connection methods. As for
bugs, let us know, and feel free to suggest any improvements. There's a
good chance that what you are looking for is already there.
Other complaints are, of course, on the mark:
. No new releases in 4 years, the awkwardness of getting patches, etc.
That's what I want to fix. I need your help. Help me make the
*business case* that our management requires.
. The scattered nature of the documentation. Fixing this is one of the
goals of the current exercise. One respondent asked for a searchable
built-in help system -- this has been on my list for a while, I'll
what I can do.
. Difficulty of managing SSH keys. Right, this needs work.
. A blind user complained there is no machine-readable script manual.
True, but that's because there isn't a script manual, period, except for
the final chapters of "Using C-Kermit", 2nd edition, which is, by the
way, available as a PDF file, in case that helps. But this is another
situation I want to address. It should be noted, by the way, that in
the past all of our published manuals were sent to Readings for the
Blind to be made available in machine-readable format.
Keep 'em coming!