Re: Cursor libraries
In <10eu4mh122cup5 3@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
[color=blue]
>Dan Pop <Dan.Pop@cern.c h> wrote:[color=green]
>> You're missing my point which was that, for portable code, you have to
>> rely on the original BSD specification. Which means that you cannot
>> support function keys. It's the age old trade off between functionality
>> and portability.[/color]
>
>or else use a portable library.
>
>It's been easily 5 years since anyone but me has built lynx with BSD curses.[/color]
In the absence of external constraints, it is up to the programmer to
decide how portable his code should be. For maximal portability, there
is nothing better than what I have suggested in this discussion.
If you had a reason for using old BSD curses, it is not unconceivable that
someone else might have such a reason, too (e.g. a Domain/OS fan[atic]
using the 4.3BSD environment).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
In <10eu4mh122cup5 3@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
[color=blue]
>Dan Pop <Dan.Pop@cern.c h> wrote:[color=green]
>> You're missing my point which was that, for portable code, you have to
>> rely on the original BSD specification. Which means that you cannot
>> support function keys. It's the age old trade off between functionality
>> and portability.[/color]
>
>or else use a portable library.
>
>It's been easily 5 years since anyone but me has built lynx with BSD curses.[/color]
In the absence of external constraints, it is up to the programmer to
decide how portable his code should be. For maximal portability, there
is nothing better than what I have suggested in this discussion.
If you had a reason for using old BSD curses, it is not unconceivable that
someone else might have such a reason, too (e.g. a Domain/OS fan[atic]
using the 4.3BSD environment).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Comment