Hi On Sat, Dec 17, 2016 at 11:51:58AM +0100, Stephane Chauveau wrote: > On 12/16/2016 07:17 PM, Nicholas Marriott wrote: ... > > - I think you should use b64_pton if possible instead of implementing it > > yourself. > > I was wondering about that. b64_pton and b64_ntop are strange functions. > They just appear to be provided by some C library implementation for some > internal purposes and some applications started using them. > > The fact that tmux has to provide its own copy of b64_ntop for the cases > when it is not available is quite telling. > > I also had a more practical reason for not using b64_pton. I noticed that > XTerm is very user friendly while decoding base64. It silently ignores all > non-base64 non-space characters. In the same situation, b64_pton would fail > decoding. So at the end, the question is: Are there any badly written > applications that could send malformed base64 encoding and if so should we > support them like XTerm does?
It is better to just use b64_pton. I don't think we should jump through hoops to support programs doing weird things here. > ... > I fully agree agree with those 3 comments. > > The CUT_BUFFERS are probably not used by any application. I only added then > for completeness. As you say, they do not harm and I can imagine that 8 > resilient named buffers could be convenient for some special use cases. > > 7 options is too much but that is because I needed ways to experiment with > various ideas. One of the problems is that the 'sensible' default will > typically depend of the applications you are using. Things would be easier > if everyone was using the 's' target. Unfortunately, Emacs25 uses 'p' by > default but can also use 'c' if the CLIPBOARD is explicitly enabled. The vim > plugin at https://github.com/chromium/hterm/blob/master/etc/osc52.vim is > using 'c'. I think it should do enough for most users and not worry too much about special cases. I suspect most people only want to use one clipboard now. GNOME appears to set both PRIMARY and CLIPBOARD together, which seems sensible. I would probably make "s" create a new automatic buffer, and "c"/"p" go to the same named buffer ("clipboard"). Then if I copy in emacs or vim, it always goes to "clipboard" in tmux. (The disadvantage is that I don't have any history of the copies from emacs, but if I want that I can go and change emacs to use "s".) You could either make the option a straight "osc52-allowed" on/off, or have "osc52-buffer" with the name of the buffer for "c"/"p" and an empty string meaning off. > Another complex topic is how to interact with the OS clipboard. Should that > be done systematically or only for certain targets? That is really a matter > of personal taste. Also, people working over slow remote connections may > have specific requirements. I'd say it should always set the OS clipboard if set-clipboard is on. If you think that should be configurable, how about changing set-clipboard to have three states (maybe "off", "copy-only", "always")?. (It could preserve the target clipboard into tty_cmd_setselection, so if an application used "c" inside, tmux would pass "c" as the first argument of Ms - but that would be better as an entirely separate change after the main OSC 52 support.) Thanks -- You received this message because you are subscribed to the Google Groups "tmux-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
