Running input rules in a code block?

1

I want to run inputRules within a code block. Is this not possible? It seems that prosemirror explicitly shortcuts the inputRules code when it’s within a spec marked as code…

for more context, line 94 of the run() function of index.js of prosemirror-inputrules short circuits for spec’s labeled as code. Everything works fine for me if I get rid of this line. Unless there’s some other workaround, can another flag be added to the spec explicitly enabling inputRules for code?

**if ($from.parent.type.spec.code)**
   return false;
1 Like
2

Indeed it does. A pull request that adds a per-rule inCode option to turn that off would be welcome.

3

Okay, I just made a pull request - my first one, so let me know how I did. Thanks.

4
5

How do we feel about this applying to code marks as well? Typing inside of a code mark it doesn’t make sense for any of the predefined rules to apply such as emdash, smart quotes etc…

6

You’ll have to check this in your input rule. Changing the behavior at this point would be a breaking change (and not appropriate in all situations).

7

Probably the right thing, I think the chosen API on this PR does make it possible though – you could have an additional value for inCode that would be non-breaking, such as “never”, “none”

8

Sorry for reviving this topic (please feel free to move my post), but I was wondering if it wouldn’t make sense to expand the inCode meaning to an explicitly provided list of code marks.

I believe it can be expected that if I don’t want to replace (random example) "" by “” in code blocks, I wouldn’t want them applied to inline code either.

I could see it working – without introducing a breaking change – by adding a code spec to marks as we have for nodes, but it could be too much for just this use case.

Another option can be supporting something like a codeMarks array when creating the input rules plugin.

What do you think?

9

Then it would make sense to add that property to the code marks in the schemas defined by core packages, at which point this could become breaking for people.

On the other hand, it is very nice if people don’t have to go out of their way to connect their input rules to their schema for such a thing to work. And for some of the pre-defined input rules, like unicode quotes, it would definitely make sense to not enable them in code marks.

So I’m thinking this should probably be a separate input rule option, something like inCodeMark, that you must set to false when defining a rule to make it not apply in code marks. Does that sound reasonable?

1 Like
10

You mean this in addition to adding a code property on mark specs? That sounds reasonable to me!

Personally though, while the flexibility won’t hurt, I don’t see any case in my own input rules where inCodeMark would be different than inCode.

11

Probably. But inCode defaults to false, so if we add this behavior, we’d be changing how existing input rules behave in potentially problematic ways. Thus, making this the same option is hard to do in a non-breaking way.

1 Like
12

I’ve released changes to this effect as prosemirror-model 1.25.0 and prosemirror-inputrules 1.5.0

1 Like
13

I noticed that we’re only checking if $from has the mark, this way if you have something like

.. ← one dot marked as code, one with no mark

The ellipsis input rule is executed after typing a third dot, and the result gets marked as code.

This is an extreme example that can be reproduced in the basic example, but this can be more common if you have input rules for **, __, etc.