[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reading the current timeout value
From: |
Sören Brinkmann |
Subject: |
Re: Reading the current timeout value |
Date: |
Sat, 15 Mar 2014 22:48:50 -0700 |
User-agent: |
Mutt/1.5.22 (2013-10-16) |
On Sat, 2014-03-15 at 02:55PM -0400, Thomas Dickey wrote:
> On Thu, Mar 13, 2014 at 09:18:56PM -0700, Sören Brinkmann wrote:
> > Hi,
> >
> > I hope this list is open and I don't need to subscribe to post.
> >
> > Anyway, I was recently writing a program and at some point I needed to
> > change things like the timeout and cursor visibility for a code section.
> >
> > For cursor visibility this is easy. curs_set() returns the current
> > visibility, so that SW can store and restore that value.
> >
> > Unfortunately I couldn't find any interface to read the current value of
> > timeout() and was pretty disappointed to see that timeout() and
> > wtimeout() are void functions.
> >
> > So, my question is, is there a way to read the current timeout and I
> > just didn't find it?
>
> no - it was overlooked. The value that you are interested in is the
> "_delay" member of the WINDOW structure. If WINDOW is not opaque,
> then you could simply refer to it, e.g.,
> win->_delay
>
> (I'm assuming that WINDOW is opaque, otherwise you would not be
> asking this question).
I actually didn't check. This works. IMHO, not as clean having an
API-call but good enough.
>
> However, with the opaque feature as currently implmented (normally
> not opaque except for the ncursest / ncursestw libraries - but I
> seem to recall some issue with some packagers renaming these...),
> the only access is a boolean.
>
> > Would it be acceptable to change the prototypes of timeout() and
> > wtimeout() to return the current timeout (see patch below)?
>
> no (these functions have well-known prototypes).
Yeah, that was to be expected.
>
> I can add another function, for the opaque configuration.
Probably a good idea. Not being able to obtain the current value seems
like a limitation in some cases.
Thanks,
Sören