Let's have a discussion on this.

In general, here is what I'm thinking:

• The editor instance is the main thing passed around and is essentially a god object
• configuration is primarily done through the editor instance, making it the most convenient place to store and retrieve references to the current config

I think what we need to be aiming for here instead is a de-coupled approach like prosekit, where the editor doesn't "have" these sorts of values, it can execute commands to move between states, but the values of these are stored elsewhere (like context).

Given that we don't have a good solution for state management at the moment, I propose here to just sweep things under the rug for a little while, and put them under an ~internal property. Using ~ makes it both cumbersome (read intentional) and shows the value last in TS autocomplete idea from standard-schema.

For configuration, I think that if the schema was defined separately, it would be much easier to configure things like tables and codeBlocks. For example:

import { defaultSchema, tableBlock } from '@blocknote/core/schema';|
import { BlockNoteEditor } from '@blocknote/core';

const editor = BlockNoteEditor.create({
  schema: defaultSchema.replace('table', tableBlock.configure({ option: true })
})

// editor.schema.table.config.option === true

Obviously, there are a lot of different ways to do it, but the point is that the editor doesn't really have to know about this.

What about all of the prosemirror plugins? It could maybe be something like:

import { BlockNoteEditor, BlockNoteExtension, getDefaultExtensions } from '@blocknote/core';

const editor = BlockNoteEditor.create({
  extensions: getDefaultExtensions.remove(['tables']).add({ myExt: BlockNoteExtension.create({ name: 'myExt', plugin: new Plugin() }) })
})

// editor.extensions.myExt.plugin

Again, different approaches here too

An alternative to this, would be to have a prosemirror plugin that gets these transactions between state updates. Perhaps that is preferable?

this is fine imo, unless there's an advantage to doing this in a plugin, but I don't think so.

Another alternative would be to emit our own event in BlockNoteEditor.dispatch - but there's a change that misses things when people use _tiptapEditor.dispatch

this is fine imo, unless there's an advantage to doing this in a plugin, but I don't think so.

Another alternative would be to emit our own event in BlockNoteEditor.dispatch - but there's a change that misses things when people use _tiptapEditor.dispatch

can't get this from this.mapping?

ah; after reading further; I suppose the answer is that you can use a single PositionStorage object to track multiple positions. That makes sense and is pretty nifty. On the other hand, having a single PositionStorage object per tracked position would make it a little bit more efficient I suppose

can this cause things to break in a weird way for the user?

I probably should clarify, this is not just deleted text, but probably more accurately described as garbage collected text (i.e. text that once existed in the document & is not in memory for either the current ydoc or the client ydoc it is synchronized with). So, very unlikely to be hit, and impossible to get a relative position that points to it.

So, I think this might be a case where throwing an error is better, since it is unlikely to happen, and would simplify the callers (since they wouldn't have to deal with an undefined that is not going to happen in practice).

hmm, instantiating this on the editor means we store the mapping of all transactions since the document starts. I'm starting to think that we don't need a "global" instance of this and the alternative approach (in my previous comment) is a bit cleaner. In that case, we also don't need to worry about the "internal" thingg)

The tradeoff here is potential for memory leaks & ease-of-use.

What you are proposing would require having each position storage listen for transactions, but, when retrieving the value, there is nothing that would clean up that listener, so it'd just keep listening and leak memory.
Having 1 listener, and one map to keep track of the transactions avoids this by storing just a singleton, meaning that when the position is no longer referenced, it can be garbage collected.

What if we just add a cleanup function? Then storing the value would be a bit more of a hassle, since you would need to unsubscribe somewhere. And in something like the prosemirror plugin it is being used in now, you typically just stop referencing the value instead of needing to destructure it so there isn't a good place for it.
What if, on read of the value, we automatically unsubscribe? It makes it inconvenient to reference the value multiple times.

My first attempt at this API did it like you described, but I found the tradeoff with the listener to be problematic later.

Can't you just unsubscribe / dispose the PositionStorage instance when the slash menu is closed, and we no longer need to track the position?

You could, but it's a less convenient API. I think I have something else that should work.

I was able to separate it from the editor instance by using a map of editor instance to the mapping. This will still use 1 mapping for the duration of an editor, but I think this is a fine trade-off for making it just as easy to store & use as a raw position value

thanks for this comment :)