From: John Stone (
Date: Fri May 22 2020 - 10:56:18 CDT

Hi guys,
  I've taken the feedback to date and implemented a line editor
fall-through that prioritizes external 'rlwrap' highest
followed by 'tecla" (see notes below), followed by 'linenoise'.

I note that 'rlwrap' being ranked highest is unavoidable since
there's no way to turn it off from within VMD once started.
That said, it can be disabled prior to launching VMD by setting
the environment variable VMDNORLWRAP, which will inhibit the
startup script from using it at VMD launch time.

I investigated Giacomo's comments about linenoise, and while I have
implemented tab completion, very lean, lightweight command editor
implementation that does lack a few features experienced users would
likely expect. In working with it further, another deficiency of the
stock 'linenoise' implementation is that it only does blocking
terminal I/O, which causes the VMD event loop to pause while line
input/editing is in progress. Since it's a small piece of code
(only 1200 lines) I rewrote the terminal raw/cooked handling code
so that the VMD event loop would remain active except while the user
is in the middle of writing a command. This is still less "live"
than the conventional console input or 'rlrwap', so I decided to look
for another line editor option. The good part is that the exercise of
making linenoise work better helped me improve the console input loop
and prepare it for more sophisticated non-blocking line editor

I went looking at other line editor libraries with acceptable
licenses, and one of the high-feature-set line editors I ran
across is 'tecla':
It is a pretty sophisticated line editor capable of emulating both
Emacs and vi style editing interactions, and supports arbitrary
user-customized key-action bindings. Perhaps the most valuable
feature of tecla for VMD is that it is capable of fully non-blocking
event handling without modifications. I've implemented basic
line-at-a-time input with the tecla line editor in VMD already
(including command completion etc), but I expect to have fully
non-blocking character-at-a-time input working soon.

My expectation is that 'tecla' may be featureful enough to be a
viable alternative to 'rlwrap'. If people are willing to test
it out, I would be happy to send the tecla-enabled code for those
that can compile from src.

Like linenoise, tecla is tied closely to the details of Unix
terminal I/O, so I may have to seek yet another option for
use on Microsoft Windows, but I'll be exploring this issue
much more closely as I work on the Windows x64 builds etc.


On Thu, May 21, 2020 at 12:13:43AM +0200, JÚr˘me HÚnin wrote:
> Hi all,
> Given Giacomo's feedback, a conservative option would be to use linenoise
> as a fallback when rlwrap is not found.
> Jerome
> On Wed, 20 May 2020 at 17:07, Giacomo Fiorin <[1]>
> wrote:
> Hi John, I just built VMD using the -DVMDLINENOISE flag and linenoise.c
> added to the Makefile, and manually edited the "vmd" launcher script
> after building to remove rlwrap.
> I can confirm that with linenoise I can access the history of VMD
> commands by using the up and down arrows, and move the cursor left or
> right using the corresponding arrows.┬ Two of the most basic readline
> keys (Ctrl-a and Crtr-e, equivalent to Home and End) are able to
> navigate at the beginning and the end of the current line.┬ ┬ Also,
> Ctrl-h and Backspace delete the last character and Ctrl-l correctly
> clears the screen.
> Here are several things that differ from readline (details may be
> specific to my build on CentOS 7 with gcc 4.8):
> * Word navigation (Alt-f and Alt-b, or Ctrl-Left and Ctrl-Right) is
> not supported.
> * Ctrl-k (kill aka cut) is supported, but not Ctrl-y (yank, aka
> paste).
> * Tab inserts a tab, and does not autocomplete.┬ There may be
> something wrong in my build, since this is actually an advertised
> feature in the linenoise README.
> * There is no persistent history (people's opinions on the importance
> of this feature may differ).
> I used vmd -dispdev text, both with TERM=xterm-256color (default in
> gnome-terminal) and with TERM=xterm set by hand.
> Assuming that tab completion can be fixed, I'm frustrated by the lack of
> an explicit list of supported features: IMO, "the usual key bindings" is
> not sufficient.┬ Also IMO, word navigation and copy/paste are essential
> features of command-line editing.
> Overall, I would still prefer using rlwrap over linenoise given the
> choice.
> I would definitely welcome the ability to turn rlwrap on/off based on an
> environment variable, the default value of which should be based on most
> people's preference.┬ One quirk that I noticed was that rlwrap was
> interfering with the input/output channels handled by GNU parallel,
> which I use sometimes to process a bunch of trajectory files using the
> same script.┬ Using a custom vmd script where I stripped the rlwrap
> part fixed that problem for me, but I would very much welcome an
> environment variable for this.
> Thanks for pointing out this feature to us, please let me know if I can
> provide anything else.
> Giacomo
> On Wed, May 20, 2020 at 3:55 AM John Stone <[2]> wrote:
> Axel, et al.,
> ┬ Since people have recently been begging me to include
> 'rlwrap' with VMD by default I revisited the current crop
> of GNU readline alternatives unencumbered by problematic
> licenses.
> To my delight, I managed to find an input editing library
> that is very minimalistic-but-usable, with a BSD license,
> called "linenoise":
> ┬ [3]
> I've made initial modifications to VMD to support it,
> and thought I'd see what people think about this as an
> alternative to our current strategy of 'rlwrap' autodetection.┬
> It's in the current publically accessible VMD CVS tree, but I've
> also attached the current TclTextInterp.[Ch] files.
> If people think this is as good as rlwrap, and it holds up in testing,
> I would like to consider changing the behavior of the VMD
> startup scripts to use rlwrap only when the user requests it
> specifically (e.g. via a special env variable), which would
> also disable the built-in command editing at the same time.
> I've made an effort to maintain proper special handling of
> console redirection, MPI builds of VMD, and other cases by
> integrating the new console support with our existing code,
> but I need to run tests on several parallel MPI platforms and
> such to validate that it works as expected in these special cases.
> The new code is enabled by compiling with -DVMDLINENOISE
> and hacking in linenoise.c to the generated VMD
> Makefile manually at present.
> I haven't yet done a Windows build with this library,
> so that remains a future challenge when I get myh Windows x64
> build system completely setup.
> Best,
> ┬ John
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> [4]┬ ┬ ┬ ┬ ┬ ┬ Phone: 217-244-3349
> [5]┬ ┬ ┬
> --
> Giacomo Fiorin
> Associate Professor of Research, Temple University, Philadelphia, PA
> Research collaborator, National Institutes of Health, Bethesda, MD
> [6]
> [7]
> References
> Visible links
> 1.
> 2.
> 3.
> 4.
> 5.
> 6.
> 7.

NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801           Phone: 217-244-3349