Yes, I am using the gap cursor plugin, but I am not sure where that gap cursor would show. It doesn’t seem to show in the situation mentioned above for me. But maybe I need to include some extra CSS or so?
Yes, style/gapcursor.css from the gapcursor package. I’ve added some docs to make this harder to miss.
Thanks! I see, I guess I just assumed it would work the same as dropcursor, as that one didn’t require any extra CSS.
Is there a recommended way of controlling where the gapcursor goes? I have a set document structure like this:
doc(article(title(...),...,body(...)))
If there is only a table in the body and I move the cursor with the arrow keys to the right from the last table cell, the gap caret blinks horizontally and is being put after the article node:
doc(article(title(...),...,body(table(...)))|)
Rather than, as I would expect, after the table:
doc(article(title(...),...,body(table(...)|)))
If the user inputs any keys with the gap cursor there, the input goes into the last table cell rather than starting a new paragraph after the table. If I hit “Enter”, I would expect for a new, empty paragraph to be formed after the table, but nothing happens.
Could you open a separate thread about this? It’s helpful if threads stay somewhat on topic.
1 Like
I’m currently working 99% of my time on finishing a CMS using prosemirror (i’ll give links and free accounts when it’s ready). As you noticed i come back often here to reflect problems i can find (that are sometimes not on my side).
I’m not asking you wait for me to finish, but i have the feeling i could report more small problems in the next few days (about one week or so). For example the first time i tried gapcursor it was throwing errors at me so i stopped, but i am willing to try harder later this week.
So maybe today you set a deadline like xxth october final release ? To give us the few days to report back final issues ?
Does this mean that things like Mark location and behavior have fully stabilized and will hold steady through the 1.x series? Sorry if this is addressed and I missed it.
My team is very excited about the work we’re doing around Prosemirror and can’t wait to see what grows up around it now that it’s reaching a stable release.
Yes, in that any further changes will be backwards-compatible.
1 Like
The thing is that there’s always something going on, and if you keep pushing the release date back for each new thing that goes on, you never actually get to the point where you release. I’m letting this thread sit for a few more days to give people a chance to respond, but no more.
No big conceptual changes are going to be made anymore anyway, and bug fixes can also be made after the 1.0 release.
1.0 means stability. I’m definitely in favor of that.
With a 1.0 announcement will you be listing projects that use ProseMirror? Although mines not 100% where I want it yet, I’d definitely love for my project to be in any list! If so, maybe start another thread to gather projects that want to be listed?
Much love and very excited about 1.0!
I’ve been keeping such a list for CodeMirror, and I’ve found it gets kind of tedious to maintain (and I’m planning to get rid of it there). So probably not. I’ll gladly tweet or retweet projects from the twitter account though.
I noticed that the prosemirror-tables module still depends on 0.23.0. Is there any non-trivial change blocking it from being updated to the 0.24.0 version? I guess this would be the only thing blocking a 1.0.0 release from my perspective.
Apart from that, releasing 1.0.0 sounds good! Congrats on the overall stability ProseMirror has attained by now 
I’m looking forward to the release!
No—it’ll catch up at some point. Note that I’m not directly maintaining this module, so it’s not part of my workflow. (Which, after 1.0, will be less jarring because versions won’t have to be kept in lockstep anymore.)
1 Like
That sounds great. I haven’t had too much trouble in upgrading between the 0.x versions, but it’d be nice to track a stable release for a while.
Sounds good to me.
Would it be possible to include type definitions in the release and maintain them there instead of in the DefinitelyTyped repository.
No. I am going to put some energy into automatically generated type definition at some point, but I’m not going to delay 1.0 for that.
I agree there’s no need to delay 1.0 for type definitions, but I’m with @davidka on having them be maintained within the repo. Whether they are automatically generated or not. I would be willing to help maintain the typings, I just have never been a fan of the DefinitelyTyped workflow.