Re: [newbie] terminal handling facilities

[Klaus Ripke <paul-lua@...>]

On Thu, Sep 29, 2005 at 06:07:33AM -0400, Glenn Maynard wrote:
> We're discussing the Lua terminal application that would fail to handle
> window changes, not these others.
fine, so it will be a great application if it's going to run in 9 screens.
but right now the question was whether it will be started at all.

> It has been standard practice for terminal applications; as far as
> I know, nobody is writing them today in Lua.
which is a pitty.
Sure, some luacurses would attract more developers and help them
create more powerful applications than doing some half-hearted
job by hand but it's not there right now.

> > Why not teach screen to turn SIGWINCH into some in-band input
> > for certain apps? It's dealing with it anyway.
> > As modern unicode xterms tend to pipe IO through luit,
> > that would be another possibility to hook in.
> 
> Before making up alternatives, you need to explain what's wrong with the
> existing mechanism.  SIGWINCH works just fine.  You're offering solutions
> without saying what the problem is.
guess I did, but maybe I have not been explicit enough. Sorry.

> It seems to me that the "problem" is "Lua doesn't have a way to hook
> SIGWINCH".  The obvious solution is "add a way to hook SIGWINCH", but
> you're suggesting things like "introduce a whole new interface to replace
> SIGWINCH", and I have no idea why.

to summarize the SIGWINCH issues:
- I did suggest the possibility to use a small portion of builtin
 C code to handle the ioctl and sigwinch.
- I mentioned the alternative to do the same in an external wrapper
 to avoid the need of a C library or special lua binary altogether
 (which in turn eases shipping by avoiding the need for recompilation
 to match your LUA_NUMBER etc.).
- reading a character from input is not a whole new interface for Lua
 while a signal handler is and in some implementations might even
 require to restart an interrupted syscall
 (which is no problem if dealt with by a wrapper).
- SIGWINCH has its limitations as apps miss a size change while
 executing e.g. some editor or pager in a new process group,
 so one wants some key bound to the same effect anyway.
- as a terminal signal is delivered to the foreground group only,
 some people argue that an escape sequence would have been a better
 interface in the first place, so programs like ssh would not need
 to care (which is exactly the "whole new interface" issue).
- personally I do not use any system lacking signals but I've been
 told such systems exist and lamentably are even in widespread use.

for the ncurses problems:
- there is no luacurses available AFAIK
- it probably would be there if it where trivial.
 Having studied and occasionally patched the code of apps like
 mutt or elinks, I doubt it is.
- if ncurses would not have its drawbacks, mutt probably would
 not care to offer the use of slang-curses as an alternative
 (which has other problems, though).
- ncurses on windows is definitely a pita.
 One might have to resort to pdcurses or something like that.
 Again, I don't care but others might.


To state this one more time: having a portable luacurses including
SIGWINCH handling where applicable would be great.
Yet IMHO there are issues enough to not rudely rule out the
consideration of other options.


best
Klaus