Re: vi copy/paste - maybe a bit OT

2019-07-04 Thread Michael


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

2019-07-04 Thread Bill Cole

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

2019-07-04 Thread Bill Cole

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

2019-07-04 Thread Michael


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

2019-07-04 Thread Richard L. Hamilton
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
> 
>