Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wgetscrreg is not defined #60

Open
firasuke opened this issue Nov 10, 2024 · 10 comments
Open

wgetscrreg is not defined #60

firasuke opened this issue Nov 10, 2024 · 10 comments

Comments

@firasuke
Copy link

firasuke commented Nov 10, 2024

I wonder if there's a function similar to wgetscrreg in netbsd-curses. Do note that wsetscrreg is already defined in netbsd-curses.

@rofl0r
Copy link
Member

rofl0r commented Nov 10, 2024

as the setter part is already there, it shouldn't be too hard to add. though first i'd check the netbsd-src repo if it was already added upstream, if not send them a PR (or patch via ML). that way it will land in this repo automatically the next time i start backporting (which is quite some effort each time which i'm not seeing myself doing in the near future - the porting itself isn't the worst part, but ironing out new bugs and incompatibilities with the terminfo db is - that's why sabotage itself still uses 0.3.1). if they already have the code we may add it directly without a complete backport.

@firasuke
Copy link
Author

as the setter part is already there, it shouldn't be too hard to add. though first i'd check the netbsd-src repo if it was already added upstream, if not send them a PR (or patch via ML). that way it will land in this repo automatically the next time i start backporting (which is quite some effort each time which i'm not seeing myself doing in the near future - the porting itself isn't the worst part, but ironing out new bugs and incompatibilities with the terminfo db is - that's why sabotage itself still uses 0.3.1). if they already have the code we may add it directly without a complete backport.

Thank you for your work on netbsd-curses.

I have prepared a PR to upstream with the following changes to curses.h:

int	 wgetscrreg(const WINDOW *, int *, int *);

Will report back in case it gets merged.

@rofl0r
Copy link
Member

rofl0r commented Nov 24, 2024

maybe you should've put curses into the title: http://mail-index.netbsd.org/netbsd-bugs/2024/11/10/msg086293.html

I have prepared a PR to upstream with the following changes to curses.h:
int wgetscrreg(const WINDOW *, int *, int *);

that's not enough, you also need to implement the actual function.

@firasuke
Copy link
Author

that's not enough, you also need to implement the actual function.

Oh it is not implemented indeed.

Looking at curses.h provided by ncurses:

#define wgetscrreg(win,t,b)	(NCURSES_OK_ADDR(win) ? (*(t) = (win)->_regtop, *(b) = (win)->_regbottom, OK) : ERR)

I wonder how it would be implemented in NetBSD curses..

@rofl0r
Copy link
Member

rofl0r commented Nov 24, 2024

I wonder how it would be implemented in NetBSD curses..

basically the reversal of the existing wsetscrreg function.

let's say, without having looked at it, that wset... does: window->scrreg = param1; then wget... should do *param1 = window->scrreg;

@firasuke
Copy link
Author

firasuke commented Dec 5, 2024

It should be fixed by now, can you please backport the fix so I can test and report back?

@rofl0r
Copy link
Member

rofl0r commented Dec 6, 2024

try this patch https://0x0.st/X769.patch which contains the essence of the commit.

a proper version of this will land once i get around to do the next full backport session.

@firasuke
Copy link
Author

firasuke commented Dec 6, 2024

try this patch https://0x0.st/X769.patch which contains the essence of the commit.

a proper version of this will land once i get around to do the next full backport session.

I can confirm that the patch you provided works. I can now build mtm and use it as intended under netbsd-curses.

Thanks!

@rofl0r
Copy link
Member

rofl0r commented Dec 6, 2024

cool. you should give brett lymn a heads-up that it fixes your issue, since he's waiting for a reply.

@firasuke
Copy link
Author

firasuke commented Dec 7, 2024

cool. you should give brett lymn a heads-up that it fixes your issue, since he's waiting for a reply.

Already did. Feel free to close this issue.

Thanks for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants