[erlang-questions] Reading (and ignoring) escape-sequences

[Mazen Harake]

I think you misunderstood a little of what my problem was; let me try to 
describe the problem in another way.

Take the following assumptions:

1) You have a menu in the terminal, this menu "pops up" prompting for an 
optional selection
2) You can perform one of the following two actions:
     a) Exit: Press Esc (\027) to exit the menu and don't make a selection
     b) Move: Press UpArrow (\027[A) or DownArrow (\027B) to move 
between selections
3) The program reads character by character

In order to distinguish between action a and b you have to be able to 
(very quickly) peek at the next character in buffer to know if there is 
a "[" after the "\e". If there isn't then you _assume_ that the user 
pressed Esc only. This is because it is assumed that a user can not 
press another key fast enough. Had it been a special key then you would 
have found a "[" character waiting there after the "\e" because all the 
related keys would have been copied to the buffer before the first 
getch() even returns.

To relate this to what you wrote; Erlang does have timeouts but this is 
not relevant because what is really needed is the ability to peek into 
the second character without blocking for input. An even better solution 
would be if this was done at a lower level so that perhaps (like 
ncurses) in erlang you would get e.g. 40x as the character for UpArrow 
(or whatever, it would probably be defined as macros anyway).

I'm curious; how would you handle the mentioned scenario in your editor?

Anyway it was a surprise to me that these sort of things weren't handled 
in a better way overall and even if Erlang wasn't really made to handle 
these kind of things I would hope that it would have better support in 
the future because it is absolutely gold to be able to write tools like 
e.g. table view and the debugger without the need for gs (or wx) without 
the nasty scrolling all the time (e.g. like top).

/Mazen



Let's assume that we tried doing this in Erlang, then there would be 
Well it is interesting when you say: If the sequence is "\027[A"

On 24/03/2010 00:29, Richard O'Keefe wrote:
>
> On Mar 23, 2010, at 10:13 PM, Mazen Harake wrote:
>
>> Yeah I've already started digging into that.
>>
>> The problem is more fundamental then I thought and in the end it 
>> turns out that all libraries (including ncurses) depend on the the 
>> fact that a human can not type in the escape sequence as fast as it 
>> is received by a computer. This makes it _extreamly_ hard (I would 
>> say impossible) to do this from pure Erlang; it has to be done from 
>> inside the driver.
>
> There seems to be no fundamental reason why the Erlang _language_
> would be unsuitable for the task, it does have time-outs, after all.
>
> My own emacs-like screen editor handles this by not _caring_
> whether the ESC was generated by some other key or by the user
> pressing the ESC key.  If the sequence "\027[A" comes in, I just
> don't care whether the user pressed one key (Up arrow) or three
> (ESC, [, A).  (In emacs terms, Meta-[ has its own keymap.)
>
> For me, processing fancy-key sequences got a _lot_ easier when I
> decided to support the ECMA sequences only.  These days, when
> practically all terminals are actually terminal emulators, and
> they emulate the ECMA/ANSI interface more or less well, it's not
> too hard.  In the old days, we _desperately_ needed termcap/
> termlib, because you might have a computer with twenty terminals,
> no two of them using the same codes.
>
> Perhaps the place to start, then, is just how many kinds of terminal
> you want to support.  On my system,
>     toe | wc
> lists 1562 different terminal descriptions.  (There aren't that
> many ways to encode the fancy keys, but there _are_ lots.)  If you
> want to support any fraction of those terminals, you have no
> realistic option but to use termcap/termlib.  You could process
> that using Erlang, but why bother?  You might as well use the method
> ncurses uses, by using ncurses in an outboard program.
>
> If you only want to support ECMA/ANSI escape sequences, the best way
> is to redesign your protocol so that you don't care any more than I
> do whether a sequence was typed by hand or the result of a single
> keypress.  ECMA/ANSI escapes generally have the form
>     ESC [ {parameter;...;parameter} letter
> so simply ensuring that nobody ever has any other reason to send
> ESC [ should get you a long way.
>

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com