Hello,
in an application I use two non-overlapping windows which fill the whole
screen. Normally I hide the cursor (curs_set(0)), but for inputs I set
curs_set(1). But the cursor does stay in stdscr position 0,0. If I use move()
instead of wmove(), the cursor is positioned correctly. Also w
Hallo,
while wmove(stdscr, ...) seems to work fine, wmove(, ...) doesn't
move the physical cursor, even if the other window has the same position and
size as stdscr. Tested with NetBSD 7.99.39 (GENERIC.201609300910Z) amd64. Is
this a known problem? (The problem does not occur with ncurses fr
Hi Julian,
indeed it does work for simple examples. I had an off-list discussion
regarding this thread with Brett Lymm. He asked me to prepare a minimum
example which shows the issue. I was not able to produce it, i.e. the minimum
example did work. In the real application where it fails it
Julian Coleman wrote:
> Can you try the attached patch and see if that makes things work for you?
I didn't note the patch. I'll try that of course, thank you!
Brett Lymn wrote:
> On Mon, Nov 21, 2016 at 10:46:50PM +0100, Carsten Kunze wrote:
> >
> > I want to do further tests with new hints I got from Brett. If it doesn't
> work I'll try again to prepare a minimum example from scratch.
> >
>
> Just fo
There was a typo in my last mail--I meant ncursesw has significant problems
with wide chars. IIRC it did work in the past with printw, addstr, etc., but
now I use add_wchstr(). There are no problems on other UNIX systems and there
is no problem with NetBSD curses. But this is OT to this list,
chris...@astron.com (Christos Zoulas) wrote:
>
> I used this as the Makefile, and I can't reproduce it (current/amd64)
>
> $ cat Makefile
> LDFLAGS=-lcurses
> CFLAGS=-g -fsanitize=address
>
> all: main
>
> clean:
> rm -f main
This works indeed. And now also my Makefile and also the w
chris...@astron.com (Christos Zoulas) wrote:
> I used this as the Makefile, and I can't reproduce it (current/amd64)
>
> $ cat Makefile
> LDFLAGS=-lcurses
> CFLAGS=-g -fsanitize=address
>
> all: main
>
> clean:
> rm -f main
Only for a short time I could use ASAN, now it crashes again,
chris...@astron.com (Christos Zoulas) wrote:
> Hmm, I wish it had more information (or I could reproduce it).
> Whats your TERM environment variable?
That is the right question...
TERM=screen
I always start an xterm, in the xterm I start screen(1), in screen(1) I start
tmux(1). So tmux(1) lik
Hello,
printw() does output multibyte strings only correctly when compiled with ASAN.
This likely indicates a curses internal data corruption which has no effect
with the different memory layout used by ASAN.
Attached is a archive for reproducing the issue (in an UTF-8 locale).
The output is
Hello,
addstr() does ignore tab characters but printw() doesn't. For both functions I
would expect that they output tabs as such. A small example source code is:
$ cat main.c
Hello,
the Home key sends 0x162 instead of 0x106 in tmux. A small test program to be
compiled with
cc main.c -lcurses
and quit with CTRL-c shows the hex key codes:
$ cat main.c
chris...@astron.com (Christos Zoulas) wrote:
> Hmm, it works for me (gives 0x106). Also I could not reproduce your other
It is a snaphot from 4 days ago
NetBSD 7.99.42 (GENERIC.201611250700Z) amd64
the default base compiler
$ cc --version
cc (nb1 20160606) 5.4.0
I have no special compiler set
chris...@astron.com (Christos Zoulas) wrote:
> Hmm, it works for me (gives 0x106). Also I could not reproduce your other
> ASAN/vs/no-ASAN issue. Is that current on amd64? What terminal?
I forgot to say that for the ASAN-issue it is important that the encoding of
the C source is UTF-8. This sho
Brett Lymn wrote:
> What does the output of infocmp look like? Curses pulls the definitions
> of the keys from the terminfo entry. If that has mapped HOME to mean
> BEGIN (which doesn't sound unreasonable) then that is what curses will
> do.
At first infocmp in xterm (where it works):
$ infoc
Brett Lymn wrote:
> But here we see:
>
> > kbeg=\E[1~
> > khome=\E[1~
>
> So, we have two keys that map to ESC [1~ so it would depend entirely on
> how the termcap is processed as to which leaf symbol is assigned to the
> escape sequence. Looking at the source, the khome symbol
Roy Marples wrote:
> $ infocmp
> # Reconstructed from $TERMCAP
>
> I would look into the content of this environment variable.
TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\
:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH
17 matches
Mail list logo
