liftTarget max depth

I understand that deeply nested blocks might not be common but it would be nice to have a max depth argument in liftTarget:

export function liftTarget(range, maxDepth = range.depth) {
  let parent = range.parent
  let content = parent.content.cutByIndex(range.startIndex, range.endIndex)
  for (let depth = Math.min(range.depth, maxDepth);; --depth) {
    let node = range.$from.node(depth)
    let index = range.$from.index(depth), endIndex = range.$to.indexAfter(depth)
    if (depth < range.depth && node.canReplace(index, endIndex, content))
      return depth
    if (depth == 0 || node.type.spec.isolating || !canCut(node, index, endIndex)) break

If you want to elevate a block above a particular node type you can start by getting the depth of that type and then use liftTarget with maxDepth to find the correct depth instead of the first possible match.

Why not create a node range at the depth you’re interested in instead?

Ok, I understand now, I missed the depth param for NodeRange

I’m probably missing something here, but I’m back to my original question.

If I don’t use blockRange but instead create my own NodeRange at my desired depth the correct content is no longer selected.

If i have a selection that spans 2 paragraphs, and those paragraphs have many siblings, I want to lift up those paragraphs and not the siblings. I want to lift them up thru many nested containers. If i create my own NodeRange higher up I will lift up the highest container and not the paragraphs?

let content = parent.content.cutByIndex(range.startIndex, range.endIndex)

content here will no longer be just my two paragraphs(the siblings will be included)?

I still think it would be nice to modify liftTarget to allow this functionallity.

I’m not entirely sure, but I think that style of lifting, where you split multiple parent nodes in the process, isn’t supported by the built-in split functions.

I have noticed you can’t toggle out of a blockqoute for example if there is a container between your selection and the blockqoute node. But i really want this behavior. I guess I could recursively lift the selection until i reach my desired depth and then rewrap the selection in all container nodes except the last one i want to lift out of.

But this doesn’t seem very performant when checking if a toggle is possible or not.

Writing these kinds of commands in a schema-independent way is pretty tricky, but you might be able to use assumptions about your schema to implement them much more easily. There’s nothing magical about the built-in Transform methods—similar things can be done in user code.