Re: sysutils/screen-ncurses port
On Tue, May 05, 2020 at 02:29:00PM +0200, Baptiste Daroussin wrote: > On Tue, May 05, 2020 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > > On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > > > > > This way ports with random termcap info to add would be able to do it > > > > > witho= > > > > > ut > > > > > the requirement to wait for a commit in base and a MFC. > > > > > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > > > > > I will then. > > > I added that to my TODO > > > > Can you also see at termcap/ncurses related code? > > Latest commit in base do unusable sh/tcsh w/ emacs > > tramp mode and inside screen. > > I am not aware of sh/tcsh being unsable at all. I heard about an emacs thingy > but not being an emacs guy myself I haven't reproduced. > > I can have a look but I would need a more specific feedback with examples of > failures. Do you see this my mail https://lists.freebsd.org/pipermail/freebsd-stable/2020-April/092251.html ? This is reproduce by different gay too. tcsh inside screen at editing near to end of screen produce grabadge at multiple lines. Not sure about 100% reproduce this. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Tue, May 05, 2020 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > > > This way ports with random termcap info to add would be able to do it > > > > witho= > > > > ut > > > > the requirement to wait for a commit in base and a MFC. > > > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > > > I will then. > > I added that to my TODO > > Can you also see at termcap/ncurses related code? > Latest commit in base do unusable sh/tcsh w/ emacs > tramp mode and inside screen. I am not aware of sh/tcsh being unsable at all. I heard about an emacs thingy but not being an emacs guy myself I haven't reproduced. I can have a look but I would need a more specific feedback with examples of failures. Best regards, Bapt signature.asc Description: PGP signature
Re: sysutils/screen-ncurses port
On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > This way ports with random termcap info to add would be able to do it > > > witho= > > > ut > > > the requirement to wait for a commit in base and a MFC. > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > I will then. > I added that to my TODO Can you also see at termcap/ncurses related code? Latest commit in base do unusable sh/tcsh w/ emacs tramp mode and inside screen. And paste from screen too (many unneed trailing space from lines). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Mon, May 04, 2020 at 06:35:03AM -0700, Cy Schubert wrote:
> In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste
> Daroussin wr
> ites:
> >
> >
> > --ma2vde2ykv3k7k6b
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --mvhxgm4zl62unzlf
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> > 20
> > > > > Daroussin wr
> > > > > ites:
> > > > > >=3D20
> > > > > >
> > > > > > --vwrr5drfobpkyvop
> > > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > > Content-Disposition: inline
> > > > > > Content-Transfer-Encoding: quoted-printable
> > > > > >
> > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> > t th=3D
> > > > at=3D3D
> > > > > > =3D3D20
> > > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> > for =3D
> > > > this=3D3D
> > > > > > =3D3D20
> > > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> > t ex=3D
> > > > ist =3D3D
> > > > > > in=3D3D20
> > > > > > > termcap(5). People who want that extra functionality would be adv=
> > ised=3D
> > > > to=3D3D
> > > > > > =3D3D20
> > > > > > > install the alternative pkg or build the sysutils/screen port wit=
> > h th=3D
> > > > e=3D3D20
> > > > > > > appropriate option.
> > > > > > >=3D3D20
> > > > > > > Or, simply change the default from whatever ncurses is available =
> > to a=3D
> > > > lway=3D3D
> > > > > > s=3D3D20
> > > > > > > install devel/ncurses. People could always select one of the othe=
> > r op=3D
> > > > tion=3D3D
> > > > > > s.=3D3D20
> > > > > > > Personally, I'm not enamoured with this approach.
> > > > > >
> > > > > > I think it is a terrible idea, and we should fix the initial proble=
> > m in=3D
> > > > stea=3D3D
> > > > > > d of
> > > > > > workarounding it.
> > > > > >
> > > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> > ey a=3D
> > > > re
> > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > > >=3D20
> > > > > I came to this conclusion last night after sending this email thread =
> > oud=3D
> > > > =3D20
> > > > > and will test it some time today.
> > > > >=3D20
> > > > > >
> > > > > > 2/ we should allow our base ncurses to get informations from newer =
> > term=3D
> > > > cap(=3D3D
> > > > > > 5) if
> > > > > > needed.
> > > > > > So far the default TERMCAP is
> > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> > =2Edb}
> > > > > >
> > > > > > First the user can be advise to point configure the $home/.termcap =
> > this=3D
> > > > is =3D3D
> > > > > > for
> > > > > > quick now.
> > > >
> > > > that is in your scope via a pkg-message :D
> > > >
> > > > > >
> > > > > > Second for later futur proof mechanism we could modify our termcap =
> > read=3D
> > > > er (=3D3D
> > > > > > we
> > > > > > use our own, not the one in provided by ncurses). to be able to fet=
> > ch t=3D
> > > > ermc=3D3D
> > > > > > ap
> > > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > > >
> > > > > > This way ports with random termcap info to add would be able to do =
> > it w=3D
> > > > itho=3D3D
> > > > > > ut
> > > > > > the requirement to wait for a commit in base and a MFC.
> > > > >=3D20
> > > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > > >=3D20
> > > > I will then.
> > > > I added that to my TODO
> > >=20
> > > There's already a utility in devel/ncurses called infotocap (and its=20
> > > corresponding captoinfo) that already does this. Both are links to tic. O=
> > ur=20
> > > ncurses import includes tic. Looks like all that's needed is add it to=20
> > > buildworld.
> > >=20
> > > I can look at it later tonight. Seems like a quick win.
> > >=20
> > That is not the point, tic won't work here except if create your own versio=
> > n or
> > use infotocap. Tic is for terminfo databases while we are still using the=
> > =20
> > termcap for historical reason
>
> I'm not suggesting replacing all of termcap. Just adding some converted
> screen.* entries.
>
> >
> > Having both ncurses from ports and ncurses from base installed at the same =
> > time
> > can open a special can of worm so imho that is not really something we want=
> > to
> > look forward.
>
> Some ports require ncurses from ports. Same can of worms as installing a
> kerberos or openssl port.
>
On head, no ports should have to now.
Best regards,
Re: sysutils/screen-ncurses port
In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste
Daroussin wr
ites:
>
>
> --ma2vde2ykv3k7k6b
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > Daroussin wr
> > ites:
> > >=20
> > >
> > > --mvhxgm4zl62unzlf
> > > Content-Type: text/plain; charset=3Dus-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> 20
> > > > Daroussin wr
> > > > ites:
> > > > >=3D20
> > > > >
> > > > > --vwrr5drfobpkyvop
> > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > Content-Disposition: inline
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> t th=3D
> > > at=3D3D
> > > > > =3D3D20
> > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> for =3D
> > > this=3D3D
> > > > > =3D3D20
> > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> t ex=3D
> > > ist =3D3D
> > > > > in=3D3D20
> > > > > > termcap(5). People who want that extra functionality would be adv=
> ised=3D
> > > to=3D3D
> > > > > =3D3D20
> > > > > > install the alternative pkg or build the sysutils/screen port wit=
> h th=3D
> > > e=3D3D20
> > > > > > appropriate option.
> > > > > >=3D3D20
> > > > > > Or, simply change the default from whatever ncurses is available =
> to a=3D
> > > lway=3D3D
> > > > > s=3D3D20
> > > > > > install devel/ncurses. People could always select one of the othe=
> r op=3D
> > > tion=3D3D
> > > > > s.=3D3D20
> > > > > > Personally, I'm not enamoured with this approach.
> > > > >
> > > > > I think it is a terrible idea, and we should fix the initial proble=
> m in=3D
> > > stea=3D3D
> > > > > d of
> > > > > workarounding it.
> > > > >
> > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> ey a=3D
> > > re
> > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > >=3D20
> > > > I came to this conclusion last night after sending this email thread =
> oud=3D
> > > =3D20
> > > > and will test it some time today.
> > > >=3D20
> > > > >
> > > > > 2/ we should allow our base ncurses to get informations from newer =
> term=3D
> > > cap(=3D3D
> > > > > 5) if
> > > > > needed.
> > > > > So far the default TERMCAP is
> > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> =2Edb}
> > > > >
> > > > > First the user can be advise to point configure the $home/.termcap =
> this=3D
> > > is =3D3D
> > > > > for
> > > > > quick now.
> > >
> > > that is in your scope via a pkg-message :D
> > >
> > > > >
> > > > > Second for later futur proof mechanism we could modify our termcap =
> read=3D
> > > er (=3D3D
> > > > > we
> > > > > use our own, not the one in provided by ncurses). to be able to fet=
> ch t=3D
> > > ermc=3D3D
> > > > > ap
> > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > >
> > > > > This way ports with random termcap info to add would be able to do =
> it w=3D
> > > itho=3D3D
> > > > > ut
> > > > > the requirement to wait for a commit in base and a MFC.
> > > >=3D20
> > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > >=3D20
> > > I will then.
> > > I added that to my TODO
> >=20
> > There's already a utility in devel/ncurses called infotocap (and its=20
> > corresponding captoinfo) that already does this. Both are links to tic. O=
> ur=20
> > ncurses import includes tic. Looks like all that's needed is add it to=20
> > buildworld.
> >=20
> > I can look at it later tonight. Seems like a quick win.
> >=20
> That is not the point, tic won't work here except if create your own versio=
> n or
> use infotocap. Tic is for terminfo databases while we are still using the=
> =20
> termcap for historical reason
I'm not suggesting replacing all of termcap. Just adding some converted
screen.* entries.
>
> Having both ncurses from ports and ncurses from base installed at the same =
> time
> can open a special can of worm so imho that is not really something we want=
> to
> look forward.
Some ports require ncurses from ports. Same can of worms as installing a
kerberos or openssl port.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste
> Daroussin wr
> ites:
> >
> >
> > --mvhxgm4zl62unzlf
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --vwrr5drfobpkyvop
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > Would people be open to the idea of a sysutils/screen-ncurses port th=
> > at=3D
> > > > =3D20
> > > > > depends on devel/ncurses instead of ncureses in base? The reason for =
> > this=3D
> > > > =3D20
> > > > > is there are screen.* terminfo entries in devel/ncurses that don't ex=
> > ist =3D
> > > > in=3D20
> > > > > termcap(5). People who want that extra functionality would be advised=
> > to=3D
> > > > =3D20
> > > > > install the alternative pkg or build the sysutils/screen port with th=
> > e=3D20
> > > > > appropriate option.
> > > > >=3D20
> > > > > Or, simply change the default from whatever ncurses is available to a=
> > lway=3D
> > > > s=3D20
> > > > > install devel/ncurses. People could always select one of the other op=
> > tion=3D
> > > > s.=3D20
> > > > > Personally, I'm not enamoured with this approach.
> > > >
> > > > I think it is a terrible idea, and we should fix the initial problem in=
> > stea=3D
> > > > d of
> > > > workarounding it.
> > > >
> > > > 1/ why those are not in our termcap(5) ? they should be added if they a=
> > re
> > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > >=20
> > > I came to this conclusion last night after sending this email thread oud=
> > =20
> > > and will test it some time today.
> > >=20
> > > >
> > > > 2/ we should allow our base ncurses to get informations from newer term=
> > cap(=3D
> > > > 5) if
> > > > needed.
> > > > So far the default TERMCAP is
> > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > > >
> > > > First the user can be advise to point configure the $home/.termcap this=
> > is =3D
> > > > for
> > > > quick now.
> >
> > that is in your scope via a pkg-message :D
> >
> > > >
> > > > Second for later futur proof mechanism we could modify our termcap read=
> > er (=3D
> > > > we
> > > > use our own, not the one in provided by ncurses). to be able to fetch t=
> > ermc=3D
> > > > ap
> > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > >
> > > > This way ports with random termcap info to add would be able to do it w=
> > itho=3D
> > > > ut
> > > > the requirement to wait for a commit in base and a MFC.
> > >=20
> > > This is probably outside of my scope at the moment but, yes, agreed.
> > >=20
> > I will then.
> > I added that to my TODO
>
> There's already a utility in devel/ncurses called infotocap (and its
> corresponding captoinfo) that already does this. Both are links to tic. Our
> ncurses import includes tic. Looks like all that's needed is add it to
> buildworld.
>
> I can look at it later tonight. Seems like a quick win.
>
That is not the point, tic won't work here except if create your own version or
use infotocap. Tic is for terminfo databases while we are still using the
termcap for historical reason
Having both ncurses from ports and ncurses from base installed at the same time
can open a special can of worm so imho that is not really something we want to
look forward.
Best regards,
Bapt
signature.asc
Description: PGP signature
Re: sysutils/screen-ncurses port
In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste
Daroussin wr
ites:
>
>
> --mvhxgm4zl62unzlf
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=20
> > Daroussin wr
> > ites:
> > >=20
> > >
> > > --vwrr5drfobpkyvop
> > > Content-Type: text/plain; charset=3Dus-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > Would people be open to the idea of a sysutils/screen-ncurses port th=
> at=3D
> > > =3D20
> > > > depends on devel/ncurses instead of ncureses in base? The reason for =
> this=3D
> > > =3D20
> > > > is there are screen.* terminfo entries in devel/ncurses that don't ex=
> ist =3D
> > > in=3D20
> > > > termcap(5). People who want that extra functionality would be advised=
> to=3D
> > > =3D20
> > > > install the alternative pkg or build the sysutils/screen port with th=
> e=3D20
> > > > appropriate option.
> > > >=3D20
> > > > Or, simply change the default from whatever ncurses is available to a=
> lway=3D
> > > s=3D20
> > > > install devel/ncurses. People could always select one of the other op=
> tion=3D
> > > s.=3D20
> > > > Personally, I'm not enamoured with this approach.
> > >
> > > I think it is a terrible idea, and we should fix the initial problem in=
> stea=3D
> > > d of
> > > workarounding it.
> > >
> > > 1/ why those are not in our termcap(5) ? they should be added if they a=
> re
> > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> >=20
> > I came to this conclusion last night after sending this email thread oud=
> =20
> > and will test it some time today.
> >=20
> > >
> > > 2/ we should allow our base ncurses to get informations from newer term=
> cap(=3D
> > > 5) if
> > > needed.
> > > So far the default TERMCAP is
> > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > >
> > > First the user can be advise to point configure the $home/.termcap this=
> is =3D
> > > for
> > > quick now.
>
> that is in your scope via a pkg-message :D
>
> > >
> > > Second for later futur proof mechanism we could modify our termcap read=
> er (=3D
> > > we
> > > use our own, not the one in provided by ncurses). to be able to fetch t=
> ermc=3D
> > > ap
> > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > >
> > > This way ports with random termcap info to add would be able to do it w=
> itho=3D
> > > ut
> > > the requirement to wait for a commit in base and a MFC.
> >=20
> > This is probably outside of my scope at the moment but, yes, agreed.
> >=20
> I will then.
> I added that to my TODO
There's already a utility in devel/ncurses called infotocap (and its
corresponding captoinfo) that already does this. Both are links to tic. Our
ncurses import includes tic. Looks like all that's needed is add it to
buildworld.
I can look at it later tonight. Seems like a quick win.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
> On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste
> > Daroussin wr
> > ites:
> > >
> > >
> > > --vwrr5drfobpkyvop
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > > =20
> > > > depends on devel/ncurses instead of ncureses in base? The reason for
> > > > this=
> > > =20
> > > > is there are screen.* terminfo entries in devel/ncurses that don't
> > > > exist =
> > > in=20
> > > > termcap(5). People who want that extra functionality would be advised
> > > > to=
> > > =20
> > > > install the alternative pkg or build the sysutils/screen port with
> > > > the=20
> > > > appropriate option.
> > > >=20
> > > > Or, simply change the default from whatever ncurses is available to
> > > > alway=
> > > s=20
> > > > install devel/ncurses. People could always select one of the other
> > > > option=
> > > s.=20
> > > > Personally, I'm not enamoured with this approach.
> > >
> > > I think it is a terrible idea, and we should fix the initial problem
> > > instea=
> > > d of
> > > workarounding it.
> > >
> > > 1/ why those are not in our termcap(5) ? they should be added if they are
> > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> >
> > I came to this conclusion last night after sending this email thread oud
> > and will test it some time today.
> >
> > >
> > > 2/ we should allow our base ncurses to get informations from newer
> > > termcap(=
> > > 5) if
> > > needed.
> > > So far the default TERMCAP is
> > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > >
> > > First the user can be advise to point configure the $home/.termcap this
> > > is =
> > > for
> > > quick now.
>
> that is in your scope via a pkg-message :D
>
> > >
> > > Second for later futur proof mechanism we could modify our termcap reader
> > > (=
> > > we
> > > use our own, not the one in provided by ncurses). to be able to fetch
> > > termc=
> > > ap
> > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > >
> > > This way ports with random termcap info to add would be able to do it
> > > witho=
> > > ut
> > > the requirement to wait for a commit in base and a MFC.
> >
> > This is probably outside of my scope at the moment but, yes, agreed.
> >
> I will then.
> I added that to my TODO
Thank you Bapt, I know a visually impared person that is battling in
this space often that this should help to reduce the pain level a
fair bit.
>
> Bestr regards,
> Bapt
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste
> Daroussin wr
> ites:
> >
> >
> > --vwrr5drfobpkyvop
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > =20
> > > depends on devel/ncurses instead of ncureses in base? The reason for this=
> > =20
> > > is there are screen.* terminfo entries in devel/ncurses that don't exist =
> > in=20
> > > termcap(5). People who want that extra functionality would be advised to=
> > =20
> > > install the alternative pkg or build the sysutils/screen port with the=20
> > > appropriate option.
> > >=20
> > > Or, simply change the default from whatever ncurses is available to alway=
> > s=20
> > > install devel/ncurses. People could always select one of the other option=
> > s.=20
> > > Personally, I'm not enamoured with this approach.
> >
> > I think it is a terrible idea, and we should fix the initial problem instea=
> > d of
> > workarounding it.
> >
> > 1/ why those are not in our termcap(5) ? they should be added if they are
> > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
>
> I came to this conclusion last night after sending this email thread oud
> and will test it some time today.
>
> >
> > 2/ we should allow our base ncurses to get informations from newer termcap(=
> > 5) if
> > needed.
> > So far the default TERMCAP is
> > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> >
> > First the user can be advise to point configure the $home/.termcap this is =
> > for
> > quick now.
that is in your scope via a pkg-message :D
> >
> > Second for later futur proof mechanism we could modify our termcap reader (=
> > we
> > use our own, not the one in provided by ncurses). to be able to fetch termc=
> > ap
> > capabilities from /usr/local/share/misc/termcap/*.conf for example
> >
> > This way ports with random termcap info to add would be able to do it witho=
> > ut
> > the requirement to wait for a commit in base and a MFC.
>
> This is probably outside of my scope at the moment but, yes, agreed.
>
I will then.
I added that to my TODO
Bestr regards,
Bapt
signature.asc
Description: PGP signature
Re: sysutils/screen-ncurses port
In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste
Daroussin wr
ites:
>
>
> --vwrr5drfobpkyvop
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > Would people be open to the idea of a sysutils/screen-ncurses port that=
> =20
> > depends on devel/ncurses instead of ncureses in base? The reason for this=
> =20
> > is there are screen.* terminfo entries in devel/ncurses that don't exist =
> in=20
> > termcap(5). People who want that extra functionality would be advised to=
> =20
> > install the alternative pkg or build the sysutils/screen port with the=20
> > appropriate option.
> >=20
> > Or, simply change the default from whatever ncurses is available to alway=
> s=20
> > install devel/ncurses. People could always select one of the other option=
> s.=20
> > Personally, I'm not enamoured with this approach.
>
> I think it is a terrible idea, and we should fix the initial problem instea=
> d of
> workarounding it.
>
> 1/ why those are not in our termcap(5) ? they should be added if they are
> missing. and MFC asap (prior 11.4 and 12.2 would be nice)
I came to this conclusion last night after sending this email thread oud
and will test it some time today.
>
> 2/ we should allow our base ncurses to get informations from newer termcap(=
> 5) if
> needed.
> So far the default TERMCAP is
> ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
>
> First the user can be advise to point configure the $home/.termcap this is =
> for
> quick now.
>
> Second for later futur proof mechanism we could modify our termcap reader (=
> we
> use our own, not the one in provided by ncurses). to be able to fetch termc=
> ap
> capabilities from /usr/local/share/misc/termcap/*.conf for example
>
> This way ports with random termcap info to add would be able to do it witho=
> ut
> the requirement to wait for a commit in base and a MFC.
This is probably outside of my scope at the moment but, yes, agreed.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> Would people be open to the idea of a sysutils/screen-ncurses port that
> depends on devel/ncurses instead of ncureses in base? The reason for this
> is there are screen.* terminfo entries in devel/ncurses that don't exist in
> termcap(5). People who want that extra functionality would be advised to
> install the alternative pkg or build the sysutils/screen port with the
> appropriate option.
>
> Or, simply change the default from whatever ncurses is available to always
> install devel/ncurses. People could always select one of the other options.
> Personally, I'm not enamoured with this approach.
I think it is a terrible idea, and we should fix the initial problem instead of
workarounding it.
1/ why those are not in our termcap(5) ? they should be added if they are
missing. and MFC asap (prior 11.4 and 12.2 would be nice)
2/ we should allow our base ncurses to get informations from newer termcap(5) if
needed.
So far the default TERMCAP is
${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
First the user can be advise to point configure the $home/.termcap this is for
quick now.
Second for later futur proof mechanism we could modify our termcap reader (we
use our own, not the one in provided by ncurses). to be able to fetch termcap
capabilities from /usr/local/share/misc/termcap/*.conf for example
This way ports with random termcap info to add would be able to do it without
the requirement to wait for a commit in base and a MFC.
Best regards,
Bapt
signature.asc
Description: PGP signature
