-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Make cursor position a little more cross platform #1
Comments
By OS X, I assume you mean Terminal.app? Wonder if it works on iTerm. For reference, current code: Lines 52 to 53 in 3dff027
Looks like other modern terminals supports both, so I guess we could just switch to 7/8? @Qix- Thoughts? |
Note that |
However, iTerm correctly performs the escape. $ printf "first\n\x1b7second\n\x1b8third"
first
third as does Terminal.app. The escapes I've seen officially documented in lieu of $ printf "first\n\x1b[ssecond\n\x1b[uthird"
first
third However these do not work in Terminal.app. This is probably because (and I'm speculating here) Apple has hinted at being pretty starchy with their terminal additions and seem to try to keep things pretty aligned with the VT100, which IIRC doesn't support @jamestalmage what version of OS X are you running? Something that is worth mentioning is the dated-ness of ANSI escapes. Color stuff works fine because it is needed far more often in terminal output. It's solid and commonly accepted (though IMO weakly standardized) and color output is generated progressively, meaning there's no rewrites of existing buffers. Cursor manipulation, as you can tell, is hairy and not at all implemented fairly across all terminals. Using cursor operations, in my humble opinion, should only ever consist of in-line modifications in practice. This is because cursor positions are absolute to the window and not to the buffer itself (I'm sure, though, there is an emulator out there somewhere that does otherwise. Poor standardization!). This means if a window is resized or is much smaller (I commonly get some terminals down to 2 lines in a paned layout just to see the tail of logging, etc.) your out-of-line cursor manipulation escapes are going to cause undesirable effects the vast majority of the time (unless you're counting on In the cases where you need to jump between lines, use a technology much better suited, such as the In the end, I'd be inclined to say something is up with your Terminal.app configuration or that these particular OOB escapes were added in a newer version of OS X (I'm currently at El Capitan and seeing them correctly). Any more docs on them would be appreciated. EDIT: Aha, that's why. They're individual escape values derived from the Termcap database for some particular
@sindresorhus while these might work for a lot of users, using hard-coded values derived from Termcap info is definitely not the Right Way™. Depending on how complete we want this to be, it might be time to start looking at Termcap parsing like we've entertained before. Hopefully this sheds a little bit of light! |
$ echo $TERM
xterm-256color OSX Yosemite |
Must be an OS X version thing, then. That's the only explanation I can muster up. Can you confirm the output of the following command, just to humor me? 🎉 $ printf "first\n\x1b7second\n\x1b8third\n" |
|
Yeah, my guess is it's an OS X versioning thing. Let me dig really quick. |
what does this output? $ infocmp $TERM | grep -Eo '( sc=\\E..)|( rc=\\E..)' |
|
Interesting. Your Terminfo is indicating it's correct, but Terminal.app doesn't seem to like it. Still pretty convinced this is an OS X versioning thing. I don't know what else to suggest other than to not use Terminal.app if you absolutely need this functionality. Or, upgrade OS X :P Sorry I'm not more helpful >.< |
You said not to count on Is there a better to reliably detect column width? |
Eh, in my experience neither of them have been reliable. They're both obtained by the same mechanism, However I don't know of any other way to get those values. Side note: In all honesty I bet Windows has more reliable results simply because their |
So the gist of this is that everything is broken, unreliable, and inconsistent...
I would really prefer not having to go down that route.
So much for depending on termcap :p Could we just output both? ( Another solution would be to just use 7/8 when it's Terminal.app. |
Agreed. I mean yeah it would be 'complete' but I think one of the upper-hands we have with the Chalk family is that we're pretty dern lightweight. Termcap parsing would introduce a considerable overhead.
Termcap isn't wrong here; termcap goes off of whatever is in At least it's been fixed, but I mean... Apple has had almost 40 years to figure this stuff out (Apple ][, looking at you. You could have fixed this. 👊)
I mean, I don't see anything wrong with it at face value but I'd put money on the probability of some wacky terminal treating it weird. Could be useful to investigate.
That wouldn't make any difference in this particular case. |
Why not? According to James it works in Terminal.app. Or did I miss something in the discussion? |
Actually I don't think @jamestalmage ever definitively specified if this was a Terminal.app problem. I assumed it was because you mentioned it. |
Yep my problem was Terminal.app. Based on your comments here, I've abandoned cursor positioning for what I was trying to do. |
cursorSavePosition
, andcursorRestorePosition
to not work at all on OSX.The following appears to:
Source:
http://stackoverflow.com/questions/25879183/can-terminal-app-be-made-to-respect-ansi-escape-codes
I am not sure what the differences are, but it's worth exploring.
The text was updated successfully, but these errors were encountered: