Lyndon wrote: > But you're still dealing with the issue of tracking the > column counter. A binary string can contain printable > characters
Not allowed to zputlit. > 2) What happens to the terminal state when the program is > interrupted in the midst of printing to the terminal? You are > potentially leaving the terminal using a non-default colour scheme > (which can be a pain to recover from), or worse, you can leave the > terminal completely locked up, recovery from which might require > blowing away they entire login session (think power cycling a > terminal on a serial port that uses full hardware handshaking, > forcing a logout when CD goes away). A binary blob emitter cannot > know the state of the terminal, so it can't recover intelligently. > A purpose built formatter knows the state of the terminal, and can > register an atexit() handler that resets the terminal's state if > that's necessary. I'm not sure what scenario you have in mind, but if the user needs a "purpose built formatter", maybe etc/scan.highlighted isn't appropriate for them. So be it. That format file won't get in their way if they don't use it. For my scenario of using an xterm to run scan on some other host, I don't want a purpose built formatter with an atexit() handler. If the comm link breaks, there is no way scan could reset my terminal. David _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
