[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [newbie] terminal handling facilities
- From: Klaus Ripke <paul-lua@...>
- Date: Thu, 29 Sep 2005 13:28:01 +0200
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.