216
edits
GUI terminal widget: Difference between revisions
Jump to navigation
Jump to search
→International Characters Support
m (Add Category:Development) |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 42: | Line 42: | ||
# The system function may need to be modified so that external programs that expect to be running in a terminal will continue to work properly. On Unixy systems, this job can be done with ptys. I guess Windows systems can use a hidden console? But if these things are required, are we more or less back to were we were before since we used a pty and hidden console to implement the terminal widgets? I believe the Emacs start-process function must do similar things, so we might be able to reuse that code. | # The system function may need to be modified so that external programs that expect to be running in a terminal will continue to work properly. On Unixy systems, this job can be done with ptys. I guess Windows systems can use a hidden console? But if these things are required, are we more or less back to were we were before since we used a pty and hidden console to implement the terminal widgets? I believe the Emacs start-process function must do similar things, so we might be able to reuse that code. | ||
=== [[International Characters Support]] === | |||
# Does GNU Readline support Unicode input? What are the limiting factors to support Unicode? | |||
#* '''MAYBE.''' If correctly configured, reasonably recent versions of GNU readline support 8bit characters if LC_CTYPE is set to a UTF-8 locale. Versions 6.1 and newer versions should be working if the user didn't override "meta-flag", "convert-meta", or "output-meta" (maybe also others). It is unclear from the documentation whether this also means support for all UTF-8 characters (including multibyte characters). But bash uses readline and it supports UTF-8. So it should be possible. | |||
#* '''MAYBE.''' Setting LC_CTYPE to a UTF-8 locale is invalid on Windows but we could set the necessary flags manually. | |||
#** Can we manage this problem in current MXE builds? | |||
# Can the open bugs be resolved with the new solution? | |||
#* {{bug|56173}} (probably unrelated) | |||
#* {{bug|47571}} (probably resolved) | |||
#* {{bug|43099}} (probably resolved) | |||
=== Alternatives === | |||
# [https://github.com/jupyter/qtconsole qtconsole] | |||
#* (+) Fancy interactive features including plots | |||
#* (+) Contains history and a pager | |||
#* (-) Written in Python | |||
# [https://github.com/lxqt/qtermwidget qtermwidget] | |||
#* (+) Reusable component (less Octave code) as shared and development library [https://packages.debian.org/stretch/libqtermwidget5-0 Debian], [https://software.opensuse.org/package/libqtermwidget5-0 openSUSE]. | |||
#* (+) Contains history (and a pager?) | |||
#* (+) Written in C++ | |||
#* (-) AFAIK, the current implementation was forked from this implementation some years ago. It deviated quite substantially which makes merging difficult and which might suggest that the original implementation doesn't fit our needs (confirmation needed). | |||
#* (-) Not cross-platform ([https://github.com/lxqt/qtermwidget/issues/240 no Windows support]). | |||
[[Category:Development]] | [[Category:Development]] | ||