Re: vi copy/paste - maybe a bit OT
On 2019-07-04, at 1:22 PM, Bill Cole wrote: > On 4 Jul 2019, at 14:55, Michael wrote: >> or is there some way to get that data back when you leave full-screen mode? >> (is there a second output buffer that can be switched between somehow?) > > Yes. There's the "Show Alternate Screen/Hide Alternate Screen" commands in > Terminal's View menu. Do those not do what you want? They might; I did not know about them until now. Thank you.
Re: vi copy/paste - maybe a bit OT
On 4 Jul 2019, at 5:32, Christoph Kukulies wrote: I’m asking it here although the vi in macOS surely isn’t a macport but I’m asking anyway: Whenever I copy/paste a file content in vi (started from a Terminal) using CMD-A or select-CMD-C to select all to put it elsewhere into a text receiving object (like Notes) using CMD-V, I’m getting the whole history of that terminal window. Not only the file contents. That’s confusing once you forget about that fact. You paste the contents, e.g. a certificate, into a webbrowser and later you are wondering about all that stuff in thet text widget which you didn’t intend to get there. I understand why it might be correct that CMD-A copies the whole terminal window contents, not only the vi-part, but it’s weird anyway. Is the a way to circumvent this problem? In short: No. At length: Terminal.app (or any equivalent tool) operates through a tightly-defined set of ancient interfaces to the OS: the termios line discipline and layers on top of that like ptmx, terminfo, and (n)curses. Terminal.app talks to programs like vi, bash, etc. through a full-duplex asynchronous serial stream of bytes. Terminal manages its data as the stream of characters it has drawn into its window, and it has no knowledge of what program it is talking to on the other side of the terminal emulation layers. Terminal doesn't know that you're running vi, it just knows what to send to the pty## device associated with a window based on your typing or pasting of text and how to draw characters into the window based on the stream of bytes it gets from that same pseudo-terminal. It does not know (or have any way of knowing) that you are running a text file editor on the other end of that pseudo-terminal link. There is no mechanism in the terminal emulation layers for a terminal emulator to communicate that sort of information or to request a logical "all data" of a program on the other end that may have a file-based concept of its current data set. Terminal only knows about the interpreted and rendered data in its window and scrollback buffer. One the other end, vi knows nothing about the system clipboard. As a practical matter, MacOS has always used the Mac-only Command key to construct menu equivalents for GUI programs, so there's no standard way to translate "Cmd-A" or any other "Cmd-*" combination into a stream of bytes on a pseudo-terminal device based on a 1980s concept of physical terminals. In principle, a terminal emulation program like Terminal *could* have a command to select everything visible in a window in addition to or instead of a command to select the entire scrollback. I don't use it, so I am not certain exactly it offers, but I know that iTerm provides a more complex set of selection behaviors from the keyboard. Finally, if all you want is to access the MacOS clipboard from the command line, pbcopy and pbpaste exist. As you might guess, pbcopy does a "Edit->Copy" from its stdin, pbpaste does a "Edit->Paste" to its stdout. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: vi copy/paste - maybe a bit OT
On 4 Jul 2019, at 14:55, Michael wrote: On 2019-07-04, at 3:03 AM, Richard L. Hamilton wrote: AFAIK, if your terminal display is restored after exiting vi, the terminal provides (and vi uses, via the smcup and rmcup terminfo strings) an alternate buffer, for full-screen use. Ideally, that alternate buffer should NOT include any scroll back, so I think the behavior you describe might even be a bug. This "Separate screen" behavior has always irked me. It means that as soon as I leave a curses-based display -- such as anything going through "less" as a pager -- such as man pages -- then I lose all the information I was looking at a moment ago. 'export LESS=-FRX' is a line I put in ~/.bashrc or ~/.shrc on every machine I log in to. If you only want to eliminate the clear-on-exit, you can omit 'FR' or see 'man less' for all of the options. Obviously this is only for 'less' and not other programs like vi(m). The problem for me is always that switching to a termcap/terminfo setting that doesn't have this problem results in other settings being lost because it's too generic. Right now, I use "TERM=ansi", because I cannot stand that "We'll clear your screen of the info you wanted now" behavior. What's the best term setting to use for maximum abilities without losing that data, That's a very good question. I suspect that there's some ansi/vt220/xterm variant that disables the alternate screen buffer but retains xterm-like functionality, but I'm not sure what it is. There's a page at https://www.shallowsky.com/linux/noaltscreen.html which offers advice on this and a "xterm-noalt" definition which may or may not do what you want. I have NOT tested anything there, it is just the 1st result from searching for 'xterm alternate screen' or is there some way to get that data back when you leave full-screen mode? (is there a second output buffer that can be switched between somehow?) Yes. There's the "Show Alternate Screen/Hide Alternate Screen" commands in Terminal's View menu. Do those not do what you want? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: vi copy/paste - maybe a bit OT
On 2019-07-04, at 3:03 AM, Richard L. Hamilton wrote: > AFAIK, if your terminal display is restored after exiting vi, the terminal > provides (and vi uses, via the smcup and rmcup terminfo strings) an alternate > buffer, for full-screen use. Ideally, that alternate buffer should NOT > include any scroll back, so I think the behavior you describe might even be a > bug. This "Separate screen" behavior has always irked me. It means that as soon as I leave a curses-based display -- such as anything going through "less" as a pager -- such as man pages -- then I lose all the information I was looking at a moment ago. The problem for me is always that switching to a termcap/terminfo setting that doesn't have this problem results in other settings being lost because it's too generic. Right now, I use "TERM=ansi", because I cannot stand that "We'll clear your screen of the info you wanted now" behavior. What's the best term setting to use for maximum abilities without losing that data, or is there some way to get that data back when you leave full-screen mode? (is there a second output buffer that can be switched between somehow?) If it matters, this is for 10.9.5.
Re: vi copy/paste - maybe a bit OT
Use the GUI version of vim (/Applications/MacPorts/MacVim.app). Or use regular vi / vim in a different terminal emulator that doesn't behave as you describe. AFAIK, if your terminal display is restored after exiting vi, the terminal provides (and vi uses, via the smcup and rmcup terminfo strings) an alternate buffer, for full-screen use. Ideally, that alternate buffer should NOT include any scroll back, so I think the behavior you describe might even be a bug. Maybe there's a preference that I don't remember that would fix that for Terminal.app; or maybe some other escape sequence settings for smcup and rmcup might fix that. If there's a really complete list of escape sequences for Terminal.app (aside from those of a color xterm, if there are any differences), I don't know where to find it, unfortunately. > On Jul 4, 2019, at 05:32, Christoph Kukulies wrote: > > I’m asking it here although the vi in macOS surely isn’t a macport but I’m > asking anyway: > > Whenever I copy/paste a file content in vi (started from a Terminal) using > CMD-A or select-CMD-C to select all to put it elsewhere into a text receiving > object (like Notes) using CMD-V, I’m getting the whole history of that > terminal window. Not only the file contents. > > That’s confusing once you forget about that fact. You paste the contents, > e.g. a certificate, into a webbrowser and later you are wondering about all > that stuff in thet text widget which you didn’t intend to get there. > > I understand why it might be correct that CMD-A copies the whole terminal > window contents, not only the vi-part, but it’s weird anyway. > > Is the a way to circumvent this problem? > > — > Christoph > >