Stefan Monnier writes: >> I think I managed to keep the semantics as they are now. What do you >> think? Does this seem like a sane approach? > > Yes, LGTM. See nitpicks below. > >> +** New function 'treesit-trnspose-sexps' > ^^ > a > >> +(defvar-local transpose-sexps-function > > I'd keep it a plain `defvar`. > >> + "If non-nil, `transpose-sexps' delegates to this function. >> + >> +This function takes one argument ARG, a number as provided >> +through running `transpose-sexps'. Its expected return value is >> +a position pair, which is a cons (BEG . END), where BEG and END >> +are buffer positions.") > > The ARG is not quite the same as the one passed to `transpose-sexps`. > I think we should say something like ".. ARG, a number. Its expected > return value is a pair of positions (BEG . END) delimiting the ARGth > sibling". > > The rest looks great, thanks. > > Something like this? If you're ok with this, maybe you can install for me, as I can't? Then I can close the relevant bugreport. Oh, and one more thing. There is a bug in in 'transpose-subr' in the case where (> arg 0). Transpose-subr-1 makes an effort to swap the conses around so that we have ranges that makes sense. However, the case in question then unconditionally jumps to (car pos2), which would be the wrong position. Either we need to change that, or add something like this to the docstring for the MOVER function: ``` The MOVER function is expected to return its conses in different orders. if `forward-word' is used for the mover function the conses will be like this, where the number is the order the position is calculated ('|' is where point is initially): first| second ^ ^ ^ ^ (2 . 1) (4 . 3) ``` What do you think? I'll open a bug report for it if the docstring isn't enough. Theo