Insertion point and TMUX

[Michael Longval]

Hello, 

This is what I was going to write: 

"""I am looking at npyscreen, finding it very interesting and thought about using it in a small project for an EMR (Electronic Medical Record) system.

My problem is that when I try the examples, they function as expected, execept that I ofter cannot see or figure out where the insertion point, or "cursor" is.

ie: while the name of a field will be "highlighted" to indicate that it is active, there is no "cursor" or "insertion point" in the actual field.

"""

But then I thought to myself: "Self, maybe it's NOT npyscreen, but rather your work stack....."

My current stack is (on MacOS):  Python3, zsh, tmux, iTerm2.

So I tried the examples WITHOUT TMUX and behold it works beautifully.

So the question now is, what option in tmux do you think I have to tweak?

Thanks very much for a very nice tool!

Mike

[Nicholas Cole]

On Mon, Sep 8, 2014 at 4:29 PM, Michael Longval <mlon...@gmail.com> wrote:

Hello, 

This is what I was going to write: 

"""I am looking at npyscreen, finding it very interesting and thought about using it in a small project for an EMR (Electronic Medical Record) system.

My problem is that when I try the examples, they function as expected, execept that I ofter cannot see or figure out where the insertion point, or "cursor" is.

ie: while the name of a field will be "highlighted" to indicate that it is active, there is no "cursor" or "insertion point" in the actual field.

"""

But then I thought to myself: "Self, maybe it's NOT npyscreen, but rather your work stack....."

My current stack is (on MacOS):  Python3, zsh, tmux, iTerm2.

Hi Mike,

Thanks for that.  Let me know if you need any help with your project.

I don't use tmux, but I suspect that the problem is the value of the TERM environment variable.

What happens if you type: "export TERM=xterm-256color"

under tmux and then run the example?

N.

 

[Nicholas Cole]

On Mon, Sep 8, 2014 at 4:56 PM, Nicholas Cole <nichol...@gmail.com> wrote:
>
>
> On Mon, Sep 8, 2014 at 4:29 PM, Michael Longval <mlon...@gmail.com> wrote:
>>
>>
>> Hello,
>> This is what I was going to write:
>>
>> """I am looking at npyscreen, finding it very interesting and thought
>> about using it in a small project for an EMR (Electronic Medical Record)
>> system.
>> My problem is that when I try the examples, they function as expected,
>> execept that I ofter cannot see or figure out where the insertion point, or
>> "cursor" is.
>> ie: while the name of a field will be "highlighted" to indicate that it is
>> active, there is no "cursor" or "insertion point" in the actual field.
>> """
>> But then I thought to myself: "Self, maybe it's NOT npyscreen, but rather
>> your work stack....."
>>
>> My current stack is (on MacOS): Python3, zsh, tmux, iTerm2.

One other suggestion, because I don't use iTerm2 either.

While running iTerm2 without tmux, type "echo $TERM" to see what the
value of TERM is.

I suspect that tmux will reset it when you enter tmux, so you need to
set it back to whatever iTerm2 expects!

N.

[Michael Longval]

Nicolas, aye, yer a smart one Sir! 

> echo $TERM

gave me:  TERM=screen-256color 

which had been erroneously set in my .tmux.conf file, buy some jackass (probably myself).

So upon fixing that, and now echo $TERM ===>  TERM=xterm-256color (and doing a "tmux kill-server")

now when I run the EXAMPLE.py I get:

Much better, but there still seems to be a problem with the character background color being changed.... some other config problem probably.

Thanks, 

Mike

[Michael Longval]

Ok, I found a way to circumvent the background color issue.

Firstly I think that it is a problem with iTerm2. Because with the stock MacOS terminal it is not a problem.

so I added these 3 lines to the EXAMPLE.py program

(I use them in my stuff regularly)

from subprocess import call
clearScreen = lambda: call('clear', shell=True)
clearScreen()

at the very beginning so that the program clears the screen.  

Works great now.

Thanks again Nicholas.

Yes I would be interested in some help with my EMR project. 

What type of collaboration did you have in mind?

Mike

On Monday, September 8, 2014 11:29:57 AM UTC-4, Michael Longval wrote:

[Nicholas Cole]

On Mon, Sep 8, 2014 at 6:20 PM, Michael Longval <mlon...@gmail.com> wrote:

Ok, I found a way to circumvent the background color issue.

Firstly I think that it is a problem with iTerm2. Because with the stock MacOS terminal it is not a problem.

It sounds as if you still don't have quite the right $TERM variable setting for iTerm2.  I've no idea what it expects... 

[snip] 

Yes I would be interested in some help with my EMR project. 

What type of collaboration did you have in mind?

Well, if you need any help creating forms or widgets, or integrating application and user interface logic let me know.  I'm always on the lookout for things that would improve the library for other people, and you may hit problems that generic solutions would solve.  There's no better test of a library like this than solving real-world problems!

N. 

[Michael Longval]

Well I’ve been trying a few things.

On my system:
MacOS 10.9.4
with Homebrew (updated)

Using the latest “npycurses” I noticed the following bugs:

***Assuming zsh, tmux or screen (either one - I tried both), and Terminal.app or iTerm2 are setup properly… ( $TERM=xterm-256color ) ***

If I run npycurses EXAMPLE.py with python3 on any combination of zsh or bash and Terminal.app or iTerm, I have no problems with the proper display of the cursor on npyscreen forms.

If I run EXAMPLE.py under either multiplexer (screen OR tmux), on either Terminal.app or iTerm, then the cursor in invisible on the npyscreen EXAMPLE.py form. (or any other example … for that matter.)

Colors display correctly now however (no background color problems…)

There is however the case that iTerm does NOT render the form borders exactly the same way the Terminal.app does.

In my opinion Terminal.app rendition is better, for there are no gaps between the characters that compose the vertical stripes around the form.
It is almost as if the character used by npyscreen for the border is not the same on Terminal.app as it is on iTerm2. (both terminals are set for UTF-8)

Thanks for your help.

Mike.

[Michael Longval]

Just wondering … where (in which file) is the function that waits for input in the active widget?

Thanks

[Nicholas Cole]

On Thu, Sep 11, 2014 at 5:35 AM, Michael Longval <mlon...@gmail.com> wrote:
> Well I've been trying a few things.
>
> On my system:
> MacOS 10.9.4
> with Homebrew (updated)
>
> Using the latest "npycurses" I noticed the following bugs:
>

> ***Assuming zsh, tmux or screen (either one - I tried both), and Terminal.app or iTerm2 are setup properly... ( $TERM=xterm-256color ) ***

>
> If I run npycurses EXAMPLE.py with python3 on any combination of zsh or bash and Terminal.app or iTerm, I have no problems with the proper display of the cursor on npyscreen forms.
>

> If I run EXAMPLE.py under either multiplexer (screen OR tmux), on either Terminal.app or iTerm, then the cursor in invisible on the npyscreen EXAMPLE.py form. (or any other example ... for that matter.)
>
> Colors display correctly now however (no background color problems...)

>
> There is however the case that iTerm does NOT render the form borders exactly the same way the Terminal.app does.
>
> In my opinion Terminal.app rendition is better, for there are no gaps between the characters that compose the vertical stripes around the form.
> It is almost as if the character used by npyscreen for the border is not the same on Terminal.app as it is on iTerm2. (both terminals are set for UTF-8)

Hi Mike,

All of this is pretty much down to problems with a mismatch between
your TERM environment variable and the terminal you are running on.

Terminals use special control characters to do various things, such as
put colours or special characters on the screen. The underlying
curses library knows about different terminal types and then does its
best to send the right control characters to the screen.

tmux seems to really interfere with things. I can't find a good
combination of environment variable and terminal application (I've
tried Terminal.app and xterm on OS X) that doesn't mess up at least
some of the drawing characters.

I'll make any changes to npyscreen that will provide a work-around,
but at the moment I just don't see what these are. Perhaps it is
worth raising with the tmux developers.

[Nicholas Cole]

On Thu, Sep 11, 2014 at 6:02 AM, Michael Longval <mlon...@gmail.com> wrote:
> Just wondering ... where (in which file) is the function that waits for input in the active widget?

That is all done in wgwidget.py

The actual waiting around is gone in get_and_use_keypress.

However, please do not override this function. It is not part of the
documented API and I reserve the right to change it without notice! In
fact, I have a couple of prototypes of future versions where things
are handled rather differently.

What was it you were looking to change?

N.

[Nicholas Cole]

[ snip tmux problems ]

OK. If you put

set -g default-terminal "screen-256color"

into ~/.tmux.conf

and you make sure that TERM is set to "xterm-color" (nb. not
256color), then things seem to work as expected, although the lines at
the edges of windows and in tree classes still look really ugly.

N.