The Problem

I'm too lazy to type //walls smooth_red_sandstone_slab[type=bottom] a lot. When I place one at the edge of my roof and type //hpos2 (or //hpos1, depending on which side I'm adjusting), and then //walls, my crosshair already points to the correct material. It feels frustrating to have to type it. Completion and clipboard only help some of the time.

A Solution

The //walls or //set commands could use the aimed-at material when I omit the explicit material parameter. To avoid accidents, I'd save the aimed-at material from the previous //hpos1 or //hpos2 command (one memory slot for both) and only assume it if it matches the current aim.
I'm not sure how strict the match should be about block state, though.

Alternatives

No response

Anything Else?

Thanks for WE, it's a great tool!

pos1 is already a valid pattern. not sure if we want to make hpos a valid pattern as that means doing a lot of raytracing, especially with the recent merge of suggestions for them (#2269) meaning that we'd have to do the raytracing each time command suggestions are called, which is technically async, which can cause chunk loads already....

I think pos1 (and maybe we should add pos2) is a solution to this specific problem though, so I don't think we need to care about adding a raytrace version yet.

pos2 doesn't exist as it's not well-defined for basically every non-cuboid region

I tried the pos1 pattern, but as I understand it, it's a different concept, only connected to the //hpos1 half. A lot of the time I use (h)pos1 for the obvious part (e.g. aim at wall below roof, press hotkey for //hpos1 + //hpos2 combo, press hotkey for //shift 1 u), then adjust (h)pos2 until the shape is correct. So for me, pos2 would probably be the more important part. My original idea of making a memory slot especially for hpos{1,2} still seems easiest to me.