On 18/02/2008, Claudio M. Alessi [EMAIL PROTECTED] wrote:
Okay, i reply to myself.
The following is an improved version of the previous patch
which use is_modifier() rather then the preprocessor #if
and check for the next character after the ESC key. This
allow to send immediately the ESC
On Tue, Feb 19, 2008 at 03:25:04PM +0200, Daniel Bainton wrote:
IMO it would make sense to s/ESC/META/ the patch though, as it isn't just the
esc key that is affected.
You are probably right, i just used ESC because it's what
the ascii(7) man page show. Using META is even better and
i'm pretty
On Tue, Feb 19, 2008 at 02:56:02PM +0100, Claudio M. Alessi wrote:
On Tue, Feb 19, 2008 at 03:25:04PM +0200, Daniel Bainton wrote:
IMO it would make sense to s/ESC/META/ the patch though, as it isn't just
the
esc key that is affected.
Which keys are affected? I think they all generate an
On Tue, Feb 19, 2008 at 06:51:11PM +0100, Marc Andre Tanner wrote:
Could you please try the attached patch and report whether this solves
the problem? Also the delay you saw can be adjusted with the environment
variable ESCDELAY, see the dvtm-status script for an example.
Of course it does,
Okay, i reply to myself.
The following is an improved version of the previous patch
which use is_modifier() rather then the preprocessor #if
and check for the next character after the ESC key. This
allow to send immediately the ESC key when typed (without
have to wait for another key to be
Hi,
i was frustrated to not be able to use my usual
alt+n keys combination in WeeChat, ELinks, bash,
and so forth. This due to a problem related to the
way dvtm handles the input which forced me to type
another key before the alt+n have any effect.
I decided to try to solve the problem by
