So what about to remove VTermInputDriver from the image? And add it in future with working handler. -- Pavel On Thu, Dec 13, 2012 at 5:24 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
haha, so these are commits from the pre-full-name aera. Anyway, dfgs was a student in bern ;), but since I put the code in the system I should be the owner ;).
VTerm*Driver abstract over the terminal, and yes they are crucial for any decent terminal support. - provide colors for terminal - provide cursor navigation - provide terminal capability access
due to lack of NativeBoost in the main image, so far I could not use tcap, but that will change.
So far I did not port the input handler (but there is a fully fledged smalltalk-based readline implementation ready). Once that is in the image there should be no more undefined calls.
And using #perform: is a very bad habit in my opinion. It breaks all tools, since you make everything implicit (and quite slow as well)..
On 2012-12-11, at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
... and please, please, please, use real names, not initials when committing packages!
Esteban
On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
I would like to ask who has the initials "dfgs". And I have a question for him/her. The VTermInputDriver initialization methods generate a lot of unimplemented calls because they expect a handler object with protocol that is not defined in the image. Do we need the VTerm classes at all? Can you provide an abstract handler class? Or what about to switch this calls to perform:/perform:with: form.
Cheers, -- Pavel