Pasting Patterns from clipboard does not work

[StachuDotNet]

trafficstars

We have a function in Fluid, pasteOverSelection, which handles pasting Exprs from a clipboard into an existing Expr.

It currently fails when trying to paste into a Pattern - it looks for an expr at the current caretTarget, doesn't find one, and fails with pasting over non-existant handler.

Currently the algorithm of this fn is roughly:

• delete whatever's currently selected in the editor
• find the expr now under cursor, where the selection was
• from the clipboard, try to create an Expr to inject, with Clipboard.clipboardContentsToExpr
• inject it (which seems to be a rather complicated process)

I suspect we should change this to, roughly,

• delete whatever's currently selected in the editor
• find the expr or pattern now under cursor, where the selection was
• if it's an expr, use existing functionality with Clipboard.clipboardContentsToExpr and the complicated Expr injection
• if it's otherwise a pattern, use a new Clipboard.clipboardContentsToPat and new relevant 'injection' code

[StachuDotNet]

in the meantime, we'd benefit from improving the error message. "Cannot find Expr at target to paste into" feels slightly better to me.

[StachuDotNet]

While we can't currently reconstruct a pattern at the root of an AST, we can reconstruct a match expression containing Patterns.

One optional/hacky way to handle this is to (and this idea is hand-wavey), wrap a copied pattern in a match, reconstruct the match expr, then extract the first (only) pattern

[StachuDotNet]

A relevant conversation is in this PR recently: https://github.com/darklang/dark/pull/4469 Worth reading through. that mainly discusses patterns within a match expr.

[pbiggar]

Is this fixed?

[StachuDotNet]

No. You can copy patterns now, but you have to be selecting at least part of a surrounding match statement. This limitation is caused by Fluid.res's getCopySelection directly calling reconstructExprFromRange - only Exprs can be reconstructed.

Those recent-ish efforts paved the way to fix this, but we still face the issue:

The next step here would probably be to update the return type of reconstructExprFromRange from option<FluidExpression.t> to option<FluidExpression.fluidMatchPatOrExpr> (along with the name), and go from there. (OP lists some of the related bits of effort)

[pbiggar]

Closing as it doesn't apply to darklang-next