On Tue, Sep 21, 2021 at 02:41:12PM +0300, Valery Ushakov wrote:
>
> Right, right, but this is ... deeply embarassing. Please, can we get
> this fixed?
>
We can at least try modifying the termios on start and see what happens.
I think that we probably should defer the change until after the NetB
On Tue, Sep 21, 2021 at 17:24:16 +0930, Brett Lymn wrote:
> On Tue, Sep 21, 2021 at 07:08:16AM +0300, Valery Ushakov wrote:
> >
> > nl/nonl are defined to affect *input* translation, turning off ICRNL,
> > so that apps can distinguish carriage return key. I *guess* that the
> > code changes ONLC
On Tue, Sep 21, 2021 at 07:08:16AM +0300, Valery Ushakov wrote:
>
> nl/nonl are defined to affect *input* translation, turning off ICRNL,
> so that apps can distinguish carriage return key. I *guess* that the
> code changes ONLCR in lockstep out of lazyness, so that for apps that
> run with echo/
On Tue, Sep 21, 2021 at 07:43:28 +0930, Brett Lymn wrote:
> On Mon, Sep 20, 2021 at 02:44:21PM +0300, Valery Ushakov wrote:
> > >
> > > Not always. You are right it is ttys that is doing it. The bug was
> > > that cursor down with onlcr on always moved the cursor to the first
> > > column of th
On Mon, Sep 20, 2021 at 02:44:21PM +0300, Valery Ushakov wrote:
> >
> > Not always. You are right it is ttys that is doing it. The bug was
> > that cursor down with onlcr on always moved the cursor to the first
> > column of the next line.
>
> Right, right, and my question is: why do we have on
On Mon, Sep 20, 2021 at 07:37:55 +0930, Brett Lymn wrote:
> On Fri, Sep 17, 2021 at 02:32:39PM +0300, Valery Ushakov wrote:
> >
> > Huh?! ^J does NOT have that side effect, ttys onlcr does. Which
> > should be turned off for curses output, shouldn't it?
> >
>
> Not always. You are right it i
On Fri, Sep 17, 2021 at 02:32:39PM +0300, Valery Ushakov wrote:
>
> Huh?! ^J does NOT have that side effect, ttys onlcr does. Which
> should be turned off for curses output, shouldn't it?
>
Not always. You are right it is ttys that is doing it. The bug was
that cursor down with onlcr on alwa
On Fri, Sep 17, 2021 at 07:33:00 +0930, Brett Lymn wrote:
> which was the case with the previous bug I squashed. That one had been
> there since curses was imported into NetBSD, every other terminal in
> popular use must use ^J for cud1 which had the side effect of moving the
> cursor to the begi
On Thu, 16 Sep 2021, Brian Buhrow wrote:
hello. No. the .lss file change doesn't work because there's no text
rendered to
highlight.
That is odd, because with these things done, I now also get an
ASCII border around the pop-up window:
https://postimg.cc/s1Ls8mQ6
1. Use POSIX (US-
On Thu, 16 Sep 2021, Brian Buhrow wrote:
hello. Okay. I tried -nocolor with lynx + ncurses. It works fine and
doesn't
demonstrate the same problem.
My mistake, then. I thought you wanted pop-up selections to be highlighted
and not just indicated with the cursor. `-show_cursor' wor
On Thu, Sep 16, 2021 at 02:48:16PM -0700, Brian Buhrow wrote:
> hello. Okay. I tried -nocolor with lynx + ncurses. It works fine and
> doesn't
> demonstrate the same problem. This is a different problem -- the select
> choices in the pop-up
> window are not rendered at all, it's not tha
hello. No. the .lss file change doesn't work because there's no text
rendered to
highlight. The showcursor problem is a different one and I think that one has
been solved with
Brett's current fix, but until the current non-rendering of pop-up selections
is fixed, I can't
say for
hello. Okay. I tried -nocolor with lynx + ncurses. It works fine and
doesn't
demonstrate the same problem. This is a different problem -- the select
choices in the pop-up
window are not rendered at all, it's not that they're rendered in a transparent
color, they're
just not there. I
On Thu, 16 Sep 2021, Brian Buhrow wrote:
Hello. If that is the problem, why does lynx not demonstrate this
problem when linked
against libncurses?
Try running lynx+ncurses with `-nocolor'.
-RVP
Hello. If that is the problem, why does lynx not demonstrate this
problem when linked
against libncurses?
-thanks
-Brian
On Sep 16, 8:57am, RVP wrote:
} Subject: Re: Help with libcurses and lynx under NetBSD-9 and -current?
} On Wed, 15 Sep 2021, Brian Buhrow wrote:
}
} This
On Wed, 15 Sep 2021, Brian Buhrow wrote:
Hello Brett. My apologies for taking so long to look at this issue.
Your fixes improve
the situation, but don't appear to entirely solve it. Specifically, in lynx,
if trying to
select from a drop down menu, the options for the drop down menu
hello Brett. I'm wondering if you saw my feedback to the PR you worked
on regarding the
libcurses issue?
Here it is, in case you missed it.
-thanks
-Brian
--- Forwarded mail from "Brian Buhrow"
From: Brian Buhrow
Date: Tue, 10 Aug 2021 11:48:09 -0700
In-Reply-To: <20210720165501.8dd34
On Tue, Feb 02, 2021 at 09:50:43AM +, Roy Marples wrote:
>
> That was mainly for Brian incase there is something we can spot that's wrong
> with his $TERMCAP string.
>
Ah, ok. Brian, it may be a good idea to add your TERMCAP string to the
PR you raised, it may be helpful.
--
Brett Lymn
--
hello Roy and Brett. As usual in these cases, there was a bit of noise
in the beginning
of this process while I figured out what was wrong and what I was doing wrong.
Here is my
current understanding of the situation:
1. By default, terminfo reads the TERMCAP environment variable and
On 02/02/2021 09:44, Brett Lymn wrote:
Why don't you post your $TERMCAP and infocmp output here?
Umm I don't have a problem with using terminfo. I am more interested in
working out why lynx is misbehaving in window. I suspect that is
something I did wrong when I fixed another PR to do with t
On Mon, Feb 01, 2021 at 02:28:08PM +, Roy Marples wrote:
> On 01/02/2021 09:53, Brett Lymn wrote:
> > The TERMCAP variable has some severe liitations, the worst being it can
> > only be 256bytes in size which was more than adequate for a vt100
> > definition but a modern colour xterm definition
On Mon, 1 Feb 2021, Brett Lymn wrote:
That really is just a kludge, it would be much better to get to the
bottom of why the lynx/window combination is misbehaving.
The TERMCAP variable has some severe liitations, the worst being it can
only be 256bytes in size which was more than adequate for a
On 01/02/2021 09:53, Brett Lymn wrote:
The TERMCAP variable has some severe liitations, the worst being it can
only be 256bytes in size which was more than adequate for a vt100
definition but a modern colour xterm definition simply won't fit in that
space, terminfo does not have these limitations
On Wed, Jan 27, 2021 at 10:07:30PM +, RVP wrote:
> On Wed, 27 Jan 2021, Brian Buhrow wrote:
>
> > 1. How do I get pkgsrc/www/lynx to compile using -ncurses instead of the
> > native curses
> > library? I tried setting various options in /etc/mk.conf, but it looks
> > like it really wants
As Roy wrote TERMINFO_COMPILE is defined by default so it
should parse $TERMCAP by default. If that does not work
properly, it is either an issue with the termcap->terming
translation, or with the termcap entry.
christos
> On Jan 27, 2021, at 4:21 PM, RVP wrote:
>
> On Wed, 27 Jan 2021, Christo
On Wed, 27 Jan 2021, Brian Buhrow wrote:
1. How do I get pkgsrc/www/lynx to compile using -ncurses instead of the
native curses
library? I tried setting various options in /etc/mk.conf, but it looks like
it really wants
to compile using the native curses library. I tried changing options.m
On Wed, 27 Jan 2021, Christos Zoulas wrote:
I think we can make our libterminfo do the same by shuffling a few ifdefs
around :-)
Is that how libterminfo is going to be built from on (with $TERMCAP
support restored)?
-RVP
On Wed, 27 Jan 2021, Brian Buhrow wrote:
So, while our curses library isn't as broken as I originally thought, I
do think there is
an issue with the library in that it produces this strange behavior with lynx
when using select
menus.
If you have the ~/.term{cap,info*} files in place
hello. The PREFER.curses=pkgsrc
workd fine to get lynx to link against the ncurses library.
the ncurses library uses a terminfo database, but it's incompatible
with the NetBSD
libterminfo library. Fortunately, the NetBSD libterminfo library can exist
with just a file
called .t
On 27/01/2021 17:52, Christos Zoulas wrote:
In article ,
RVP wrote:
This might be due to the fact that window(1) relies on setting a
custom TERMCAP environment variable to inform programs running
under it of the term. capabilities it supports, and the curses
library no longer makes use of that
On Wed, 27 Jan 2021, Christos Zoulas wrote:
I think we can make our libterminfo do the same by shuffling a few ifdefs
around :-)
Is that how libterminfo is going to be built from on (with $TERMCAP
support restored)?
-RVP
On Wed, 27 Jan 2021, Brian Buhrow wrote:
1. How do I get pkgsrc/www/lynx to compile using -ncurses instead of the
native curses
library? I tried setting various options in /etc/mk.conf, but it looks
like it really wants
to compile using the native curses library. I tried changing options.mk
On Wed, 27 Jan 2021, Brian Buhrow wrote:
hello. Just to clarify. Right now, the cursor is tracking properly
when displaying
regular screens, but when select popup menus are in use, the cursor goes to the
bottom of the
screen. I think this is, again, probably due to a translation err
On Wed, Jan 27, 2021 at 08:49:26 -0800, Brian Buhrow wrote:
> 1. How do I get pkgsrc/www/lynx to compile using -ncurses instead
> of the native curses library? I tried setting various options in
> /etc/mk.conf, but it looks like it really wants to compile using the
> native curses library. I tr
hello. Just to clarify. Right now, the cursor is tracking properly
when displaying
regular screens, but when select popup menus are in use, the cursor goes to the
bottom of the
screen. I think this is, again, probably due to a translation error between
the termcap spec
for the termina
hello. Thanks again for the tip. After reading the terminfo library
sources, I realized
that while I had a terminfo description of the terminal, it wasn't being used
because, even
though the library opens a plain text file containing the terminal description,
it only uses
the compiled
In article ,
RVP wrote:
>This might be due to the fact that window(1) relies on setting a
>custom TERMCAP environment variable to inform programs running
>under it of the term. capabilities it supports, and the curses
>library no longer makes use of that.
>
>With ncurses, building it with the `--
termcap and terminfo that works with
vi, more, top,
etc. but isn't good enough for lynx.
-thanks
-Brian
On Jan 27, 9:17am, RVP wrote:
} Subject: Re: Help with libcurses and lynx under NetBSD-9 and -current?
} This might be due to the fact that window(1) relies on setting a
} custom TERMCA
On Wed, 27 Jan 2021, RVP wrote:
The ncurses(w) in pkgsrc is not built with that option, so, I
compiled the latest ncurses from source with that option added
and lynx -show_cursor worked just fine under window(1).
You could also compile a custom terminfo DB entry using the
capabilities window(
This might be due to the fact that window(1) relies on setting a
custom TERMCAP environment variable to inform programs running
under it of the term. capabilities it supports, and the curses
library no longer makes use of that.
With ncurses, building it with the `--enable-termcap' option
makes it
hello. I'm trying to use lynx, pkgsrc/www/lynx, with NetBSD-9 and
NetBSD-current,
under the window(1), misc/window package, and I'm having trouble similar to the
trouble
described in lib/54263. I use the -showcursor option to lynx, so the
cursor tracks the links on the page. Under NetBS
41 matches
Mail list logo
