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

Support for getting terminal width & height #50

Open
richard-uk1 opened this issue Dec 13, 2015 · 9 comments
Open

Support for getting terminal width & height #50

richard-uk1 opened this issue Dec 13, 2015 · 9 comments

Comments

@richard-uk1
Copy link
Contributor

Getting the terminal width and height is something you cannot do presently with the Terminal trait. It prevents implementation of something like termbox on top of Terminal trait.

The linux implementation looks something like (from termbox)

    struct winsize sz;
    memset(&sz, 0, sizeof(sz));

    ioctl(inout, TIOCGWINSZ, &sz);

    termw = sz.ws_col;
    termh = sz.ws_row;

whilst in windows the relevant function is kernel32::GetConsoleScreenBufferInfo

@richard-uk1
Copy link
Contributor Author

I've had a look at implementing this - the main problem as I see it is that currently the unix implementation does everything with terminfo, therefore not needing to make any system calls directly. The best way to get the console dimensions is to issue an ioctl to populate the winsize struct, but that may not be possible with serial consoles for example.

According to https://unix.stackexchange.com/questions/93173/how-does-less-know-the-terminal-resolution the program less takes the approach of using ioctl if available, and then using some tricks to try and figure out the width/height (e.g. environment variables).

So questions:

  1. Do you want/mind linking to libc on linux?
  2. Do you therefore think that the size function should return an Option, with none if it wasn't possible to calculate the size?

@richard-uk1
Copy link
Contributor Author

You can see my messings about at https://github.com/derekdreery/term :master

@Stebalien
Copy link
Owner

  1. I'm fine with that.
  2. When Error handling overhaul #49 gets merged, we can use a NotSupported error variant.

As for getting this working on unix, given that #49 will be a breaking change anyways I plan on reworking the internals quite a bit (after it lands) so this will probably get much easier.

@richard-uk1
Copy link
Contributor Author

http://docs.freebsd.org/44doc/usd/13.viref/paper.html#section5f seems like a good strategy?

@Stebalien
Copy link
Owner

@derekdreery Yes, that looks good. However, I'm probably going to reorder those a bit (use ioctl first, then the environment, then the terminfo database.

@xSke
Copy link

xSke commented Jan 3, 2016

Would this be possible in Windows too?

@Stebalien
Copy link
Owner

Yes but I won't be able to do that myself (I don't use windows).

@richard-uk1
Copy link
Contributor Author

I put the windows function on the top of this thread - I can implement it - waiting on some constants in libc at the moment

@richard-uk1
Copy link
Contributor Author

... a long time later

I've submitted PR #77 to implement this.

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

3 participants