The run method of inputRules's handleTextInput can return false or not?

prosemirror-inputrules is really useful, when input the last character, if the word matchs RegExp it will auto implement my code by textblockTypeInputRule API.
my question is that, in my case i need keep the last character , i have checked the source-code of InputRules Plugin, the last character is suppressed cus it return true after dispatch :

handleTextInput(view, from, to, text) {
    if (view.composing) return false;
  const { state } = view;
  const $from = state.doc.resolve(from);
  if ($from.parent.type.spec.code) return false;
  const textBefore =
      Math.max(0, $from.parentOffset - MAX_MATCH),
    ) + text;
  for (let i = 0; i < rules.length; i++) {
    const match = rules[i].match.exec(textBefore);
    const tr =
      match &&
        from - (match[0].length - text.length),
    if (!tr) continue;
    view.dispatch(tr.setMeta(plugin, { transform: tr, from, to, text }));
    return true;       // suppressed here
  return false;

i have cloned the source code in my project and changes the returned value from true to false to keep the last character, it seems worked but an error as Position X is out of range;

if i remove the delete Transaction in textblockTypeInputRule method, the error is gone but in fact i need the delete action… the textblockTypeInputRule code is :

export function textblockTypeInputRule(regexp, nodeType, getAttrs) {
  return new InputRule(regexp, (state, match, start, end) => {
    let $start = state.doc.resolve(start)
    let attrs = getAttrs instanceof Function ? getAttrs(match) : getAttrs
    if (!$start.node(-1).canReplaceWith($start.index(-1), $start.indexAfter(-1), nodeType)) return null
      .delete(start, end)   // seems delete lead to position out of range
      .setBlockType(start, start, nodeType, attrs)

where the problem occurs , any ideas? thanks a lot

I think it’d be easier to write your input rule to not replace that last character, rather than trying to do what you’re doing here. Dispatching transactions during the handling of input, but then letting the input go through after all (meaning the state of the editor is now different from the one that the input was originally interpreted against) is not supported.

ok, get it ! thanks