Add disable-hclip function

[junjihashimoto]

When environment is linux's terminal without xwindow,
hclip does not work, and killring does not work too.
Because DISPLAY variable is unset.

This PR adds disable-hclip-function and uses local-variable instead of hclip.

[Fuuzetsu]

Two main complaints, rest of the code changes will follow by themselves once addressed.

[Fuuzetsu]

1. Don't store String, use YiRope straight away.
2. Get rid of this global IORef completely, what's the point of it? YiM can carry the state you need. If you really want an IORef, put the IORef in YiM and update it that way. getClipboard can then determine where to read clipboard state from.

[junjihashimoto]

This is just a emulation of Hclip's function, so it uses String and a global variable.

[junjihashimoto]

1. We do not need performance. Clipboard is poor one.
   When vty-mode, Hclip calls a command of xclip, it is really slow.
   　So I think we do not need YiRope.
2. I know YiM can carry the clipboard data.
   I just do not want to increase the mutable state of YiM.
   If you do not want to use IORef by all means, I'll use the state of YiM.

[Fuuzetsu]

1. We do not need performance. Clipboard is poor one.

There's zero reason to throw away performance. In this case it's more about convenience of any users: why force them to convert from string all the time? Further, String sucks for space, there's no reason to hold onto the clipboard contents as String and put completely unnecessary pressure on GHC's copying GC.

2. I just do not want to increase the mutable state of YiM.

Just add it to YiM state, it's a lot easier to reason about than some random floating globals.

[junjihashimoto]

Hi @noughtmare ,
Do you have any comments?

[noughtmare]

I believe that quality is very important, especially when an objectively better solution is known. I understand that it is not always possible, a balance needs to be struck between effort and quality.

I will explain my interpretation of @Fuuzetsu's proposal in more detail. The proposal consists of two parts. Firstly, to have the virtual clipboard provide and store YiStrings, to prevent conversion between YiStrings and Strings which saves memory and CPU time. The system clipboard can then has to explicitly convert the YiStrings to Strings, because the system clipboard can't store Strings. The second part is to use the dynamic state inside the YiM monad to store the virtual clipboard contents, instead of a loose reference.

I think the first part of the proposal is objectively an improvement. We don't expect performance from the clipboard, but we do expect it from the editor as a whole and many small performance deficiencies can add up.

The second part, however, is not so clear-cut. The loose reference is not exposed by the Yi.Clip module, so it will not be accessible to other parts of the editor. Storing the clipboard contents in the YiM monad will make it accessible to the whole editor, to me that sounds harder to reason about.

@Fuuzetsu and @junjihashimoto have I convinced you or do you still have objections?

[Fuuzetsu]

YiString

Agree, use it.

Storing the clipboard contents in the YiM monad will make it accessible to the whole editor, to me that sounds harder to reason about.

This is not a Bad Thing™. If anything, this allows you to make getClipboard and setClipboard run in YiM instead of IO: this means you can actually stop someone using these somewhere arbitrary and things changing uncontrollably.

It's a bit like using global IORef instead of ReaderT with IORef in the env… I don't like it.

Having said that, this is about emulating system clipboard which is arguably this global system thing. So I don't care too strongly about it. If you want it in IORefs, hide them in the module and I'll stomach it.

[Fuuzetsu]

Make strict.

[junjihashimoto]

Use strict. Thank you for your reviewing.

[junjihashimoto]

@noughtmare and @Fuuzetsu, Thank you for comments and reviewing.
Changed get/setClipboard's variable from String to YiString.
And add some notes for IORef variable.