In reply to Stefan Seefeld <[EMAIL PROTECTED]>
>>
>> I thought about that too, but unfortunately I don't have the time
>> to work out all the details. For example, some terminals save
>> scrolled lines, some don't (so where do you store screen
>> information).
>
>I don't understand. In what way is scrolling related to the terminal
>emulator, i.e. the parser filtering out control sequences ?
the problem is that some keys are also control sequences (CR, LF, TAB,
F1, etc). if you press Shift+PgUp in a linux console, what happens is
that lines that were scrolled before become visible again. this isn't
expected in a true vt100 emulator (it didn't have this capability).
now where do you put the Shift+PgUp functionality (where do the extra
lines go, etc)? it can be done, but it gets a little weird. and i can
surely make up new key sequences that do weird things and that would
put some weight in the terminal design.
>> Most of them implement a huge common subset of commands, and so on.
>> So let's do the following: let me finish this one (I'm really
>> enjoying working in cmtt10!) and post it on sourceforge, then other
>> people can pick it up and "generalize it". After all, I already did
>> the hard work here!!! I guess there should be a lot of people
>> interested in such a thing, after all the Linux console is going to
>> some undefined place really slowly (main reason why I wrote this
>> thing), and the Berlin project could make good use of it. As an
>> aside, do you people really see the need for a completely generic
>> terminal? What are the reasons for a `linux' terminal emulator not
>> being enough, for example?
>
>ok, I'm speaking for me, and probably for berlin: berlin isn't linux
>specific in any way. I don't see any need to be locked into one
>particular environment.
i know. my exaple can be restated as `vt220' terminal emulator, for
example.
>Also, different terminal emulators (read: control sequence parsers)
>are unrelated to each other, they are a good candidate for a modular
>design (i.e. you may want to swap out one emulator object against
>another one if the client changes the terminal type).
on 100% of the emulators there is a huge sharing of common control
sequences. this tells me that, even though the modular design is
something right from a pure programming point of view, it is somewhat
unecessary. right now i am running my emulator with a small subset of
ansi implemented, and i already can do everything i did with any other
emulator.
>I would never try to put everything into the same code. Most codes
>mean similar things anyway (cursor positioning, font / color setting,
>etc.), so all that changes is the interpreter which filters out the
>commands. That shouldn't be too hard to get right.
it isn't. my problem is that i don't really see a huge necessity for
it. it seems one of those cases where a perfect program design is
actually much more than what's needed in practice. i may be wrong.
>Most terminal programs I'v looked into are awefully messy, mostly
>because they don't separate the graphics from the tty and the parser
>properly. This cries for a good object oriented design !
actually, this cries for a good code design, and that's about it. the
emulator i'm writing has everything pretty much separated --- not in
the final C file itself, but in the CWEB source code. that's one of
CWEB's beauties, the fact that you don't have to obey any order
whatsoever (take a look, for example, at dviv.dvi to see what i mean).
the amount of extra coding needed for a generic terminal, as opposed
to an ansi or vtxxx emulator, is not negligible by any measure, and
the gains are not clear yet to me.
>(have a look into the berlin code, we do have a terminal widget.
>What's missing is the emulator, i.e. a pluggable parser which reads
>out the control sequences. Right now we simply ignore them, i.e. all
>we can run are programs in canonical mode)
that's pretty good. once i finish my thesis i'll spend some time
designing a new terminal which is impossible to be emulated by it ;)
cheers,
--
Cesar Augusto Rorato Crusius __o __o __o __o __o
Stanford University _`\<, _`\<, _`\<, _`\<, _`\<,
e-mail:[EMAIL PROTECTED] (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_)
www.stanford.edu/~crusius
o _ _ _
__o __o __o __o /\_ _ \\o (_)\__/o (_)
_`\<, _`\<, _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/
(_)/(_) (_)/(_) (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
He who sacrifices functionality for ease of use
Loses both and deserves neither
