[code] [scinterm] [patch] deferred curses initialization & build-system integration

From: Robin Haberkorn <robin.haberkorn.att.googlemail.com>
Date: Fri, 26 Jun 2015 16:24:31 +0200

Hello,

sometimes, you may want to operate your Scinterm-based editor in
command-line mode, i.e. running scripts that access internal structures
of your editor without showing a GUI. This is exactly what SciTECO
does, using Scinterm for its terminal port.

Unfortunately, in order to use Scinterm, curses must already be
initialized (i.e. initscr() must have been called). Even more
unfortunately, curses cannot be initialized without interacting with
your terminal in one way or the other. E.g. on ncurses/UNIX, calling
initscr() will write to stdout; using newterm() it is possible to avoid
stdio streams/fds but not to avoid terminal interaction during curses
initialization in general. I even went as far as initializing curses on
the /dev/null device, later reopening the stdio streams used by curses
on a real terminal device; this however is not foreseen by the ncurses
authors and will trigger ncurses bugs that make it impossible to handle
CTRL+C interruptions using cbreak() which is the only sane and at
least partially portable way to handle user input during lenghty
processes that call curses functions. Also even this hack "worked" only
on ncurses/UNIX; not for instance PDCurses. You can read up on the gory
details in this "bug-ncurses" thread:
http://lists.gnu.org/archive/html/bug-ncurses/2015-06/msg00011.html

I found the easiest way to achieve what I want is to patch Scinterm so
it defers use of curses to the point where it really needs to access
curses functions and data structures. Furthermore I took the freedom to
fix Scinterm's inline API documentation - also mentioning when curses
has to be initialized and when it doesn't - and adding support for a
CURSES_CFLAGS Makefile variable that is very useful if you have
different versions of curses installed. The latter patch is also useful
when integrating the Scintilla/Scinterm build process into a larger
one which allows central configuration of the Curses library used; which
is as I have argued earlier the only sane way to make your program
depend on Scintilla and keep it easy to build from source.
The implementation of the former patch keeps API compatibility, while
it might be wiser to introduce a new API function that must be called
by Scinterm users in order to explicitly initialize those parts of
Scinterm that access curses.
Since we're already talking about API changes: I think it would be wise
to keep curses window refreshing out of scintilla_refresh(), so users
can decide whether to use the wrefresh() or the wnoutrefresh()
functions. Alternatively, there should be a
separate scintilla_noutrefresh() function. scintilla_refresh() could
then be a wrapper around scintilla_noutrefresh() followed by doupdate().

The patches are attached and you can also refer to the sciteco-dev
branch of the SciTECO scinterm-mirror:
https://github.com/rhaberkorn/scinterm-mirror/compare/scinterm_1.6...sciteco-dev

Best regards,
Robin

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Fri 26 Jun 2015 - 10:24:31 EDT

This archive was generated by hypermail 2.2.0 : Sat 27 Jun 2015 - 06:26:39 EDT