Pass editor view as parameter to markerDOM function

kochrt commented

2023-09-11 19:04:20 +02:00

(Migrated from github.com)

I'd like to configure fold indicators based on another StateField I have active. I've messed around with CSS solutions and other ways of getting this info to the markers but I think just passing the view to the markerDOM function may be the best solution, so we can do something like

foldGutter({
  markerDOM: (open: boolean, view: EditorView) => {
    const fieldValue = view.state.field(myField)
    if (fieldValue) {
      // return something different
    }
    return !open ? rightCaret() : downCaret();
  },

In my specific case I want to hide the markers so that they only show when that range is folded or the user is hovered over/has a selection in a foldable block. I could do that by returning a different DOM element or adding a CSS class or something.

I hope that makes sense!

I'd like to configure fold indicators based on another StateField I have active. I've messed around with CSS solutions and other ways of getting this info to the markers but I think just passing the view to the `markerDOM` function may be the best solution, so we can do something like ```js foldGutter({ markerDOM: (open: boolean, view: EditorView) => { const fieldValue = view.state.field(myField) if (fieldValue) { // return something different } return !open ? rightCaret() : downCaret(); }, ``` In my specific case I want to hide the markers so that they only show when that range is folded or the user is hovered over/has a selection in a foldable block. I could do that by returning a different DOM element or adding a CSS class or something. I hope that makes sense!

marijnh commented

2023-09-11 21:00:17 +02:00

(Migrated from github.com)

Your use case sounds like it would require the widgets to be re-rendered when some editor state changes. But they wouldn't be—these may be left in the DOM across any change that doesn't remove the marker. Isn't is more robust to put the information you need into the marker object and make sure it is replaced with a marker with different data when appropriate?

kochrt commented

2023-09-11 21:22:11 +02:00

(Migrated from github.com)

Thanks for the quick reply, first of all!

Isn't is more robust to put the information you need into the marker object and make sure it is replaced with a marker with different data when appropriate?

That sounds fine to me, I guess my question would be where would I do that? The only information I have when the marker is created is whether it is open or not, right?

Admittedly now that I write it out I'm not even sure this PR would do the job either - having access to the view still wouldn't give me the necessary information to be able to associate a marker with a specific foldable block.

Thanks for the quick reply, first of all! > Isn't is more robust to put the information you need into the marker object and make sure it is replaced with a marker with different data when appropriate? That sounds fine to me, I guess my question would be where would I do that? The only information I have when the marker is created is whether it is open or not, right? Admittedly now that I write it out I'm not even sure this PR would do the job either - having access to the view still wouldn't give me the necessary information to be able to associate a marker with a specific foldable block.

marijnh commented

2023-09-12 07:57:58 +02:00

(Migrated from github.com)

Oh indeed, I was thinking about gutter markers in general—in this case, the fold gutter is regenerating its marker set on every change, so you really don't want to do anything expensive in them, or anything that makes them unique enough to require re-renders all the time.

I can imagine using the view in such a method to attach some kind of event handlers to markers, but since pointer interaction on these is already handled by the library, I don't think that is very useful here.

Given how the fold gutter works, I don't think markers that depend on the folded (or foldable) content are realistic. You can try to build something like that, but you'd have to set up an entirely custom gutter.

Oh indeed, I was thinking about gutter markers in general—in this case, the fold gutter is regenerating its marker set on every change, so you really don't want to do anything expensive in them, or anything that makes them unique enough to require re-renders all the time. I can imagine using the view in such a method to attach some kind of event handlers to markers, but since pointer interaction on these is already handled by the library, I don't think that is very useful here. Given how the fold gutter works, I don't think markers that depend on the folded (or foldable) content are realistic. You can try to build something like that, but you'd have to set up an entirely custom gutter.

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Rows
Columns

Pass editor view as parameter to markerDOM function #6

Pull request closed