On 12/16/2016 07:17 PM, Nicholas Marriott wrote:
Hi
I like it, but some comments:
- The code style is not right for tmux in quite a number of ways.
I know. Until now, I was focusing on getting a fully functional
implementation and I did not care too much about the coding style.
Most of my changes are isolated so adjusting the code style shall be
quite simple if the code has to be merged back with tmux master.
- 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?
Anyways, I can easily use b64_pton
- I think it is good to make the default (s) the top buffer.
>
- Seven options is far too many to add for this. One might be
acceptable, maybe just on/off or perhaps three or four values if that
is useful. I suggest you just pick sensible defaults for the rest.
- Personally I don't see any point in supporting more than s, c, p. But
I suppose the others don't do any harm.
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'.
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.
--
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.
