Middle-clicking external links shouldn't paste

[lutzky]

This is probably Linux-specific, and possibly an issue for the underlying editor rather than silverbullet itself.

The current behavior is that, when an [[internal link]] or an [external link](url) is shown, on mouseover the cursor becomes a finger; clicking an external link opens it in a new tab, clicking an internal link opens it in the same tab; so far so good. Middle-clicking an [[external link]] opens it in a new tab - this is also great.

Unfortunately, middle-clicking an internal click in Linux pastes. That, clicking between the i and n of [link](url) changes it to [liWHATEVER WAS IN THE CLIPBOARDnk](url).

Workaround: Ctrl-click the external links.

[lutzky]

Confusingly, query results behave differently. The link under "remaining tasks" opens same-tab on single-click, and different-tab on middle-click. The original link, under "actual content", opens different-tab on single-click (...but not always!) and on middle-click behaves like middle-clicking in a text-box (nothing on chromeos; paste on Linux)

Arguably, external links (i.e. anything that's not [[...]]]) should always open in a separate tab.

[lutzky]

I think this would be mostly mitigated by fixing #1228; there wouldn't really be a reason to middle-click then.

[lutzky]

Roughly speaking, the remaining work appears to be as follows:

In editor_state.ts, above where the click handler is:

silverbullet/web/editor_state.ts

Lines 223 to 225 in 1e30517

	click: (event: MouseEvent, view: EditorView) => {
	const pos = view.posAtCoords(event);

...adding the following handler completely prevents middle-click-pasting:

mouseup: (event: MouseEvent, view: EditorView) => {
  if (event.button != 1) {
    return;
  }
  // TODO: Add some logic to check if we're pointing at a link
  event.preventDefault();
  // TODO: Add some logic to pretend we're middle-clicking
  // that link (e.g. by opening it in a new tab)
  return;
},

I think cargo-culting some of the code from the click handler would do the trick here, but I'm not sure that's the right approach.