Colleagues, I'm trying to improve editline library in order to it would fit my needs and fix some bugs. First of all I'd like to fix the way it handles signals. Now the signal handler at it's end restores the old handler and send interrupt recived to the whole process group. Well, I do not like the last step but some third-party software might rely upon that [strange] behaviour so I would like to have a way to turn it off. But the first step, the restoration of the old hadler, is just wrong for signal SIGWINCH. The result is that application cannot track down the changes of the window size automatically more than one time per line (with the standard handler). That is definitely A Bad Thing. I would say that SIGWINCH needs just different handler. I'd like to hear you opinions how editline should behave. Actually I would like to change the library but do it smoothly and I do not going to break the existing applications. Also in future I want to see in the editline library: 1) a timeout for the input, 2) callbacks for the events (periodic events, arriving new data on the file descriptor from the given set), 3) an interface to obtain editline's idea of terminal state. Ridiculos, but current interface allows to CHANGE it, to PRINT it to the user but does not allow to RETURN them to the program. Could somebody explain why does user need to SEE them more than program to WORK with them? Well, that is simple to add. Those changes can be also made is different ways so the question is which will be more convenient for people who are going to use the library. Any comments would be gracefully accepted! -- Sincerely, Alex SemenyakaReceived on Tue May 18 2004 - 15:12:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC