Is this an OK place to ask a question about clojure-mode (https://github.com/nextjournal/clojure-mode) ?

I found something which may be a bug, but it may also just be an artifact of something I'm doing.

@pmooser sure

I'm using clojure-mode to implement distributed text editing. That means I have a ViewPlugin that processes (local) user input, and converts it into a data structure which is sent over the wire. When the remote client picks up this data structure, it converts it into a CodeMirror transaction which it applies to its editor (along with an annotation so that we can distinguish local/remote transactions and avoid infinite loops and other stuff). What I am seeing is, if we have an editor with contents like: one two three And I select the two and delete it - everything happens correctly for the user who originated the change, and we get: one three (note that there are two spaces) On the remote host, when I receive the data about this edit, and convert it to a CodeMirror transaction, it is "correct" - that means, it correctly describes deleting just the two. However, what I see is that the ext-format-changed-lines extension used by default in clojure-mode filters the transaction so that we don't have the two spaces, and thus we end up with one three (note the single space).

It seems to me that this extension should cause that to happen in response to the originating user's edit as well, instead of just modifying the other transaction.

Does that make sense? It's a bit challenging to describe due to the different moving parts involved.

@pmooser clojure-mode is also powering the collaborative editing of Clojure code on http://nextjournal.com. Though it’s a bit different there with codemirror being embedded in a prosemirror doc. Can you check what you get for the https://github.com/nextjournal/clojure-mode/blob/master/src/nextjournal/clojure_mode/extensions/formatting.cljs#L153-L162? Maybe you need to annotate it with “noformat”.

Wow, ok. I will take a look. But today I learned that you can group constants in case expressions in a list.

I will try adding that annotation at some point today, and I'll what happens.

I notice that the paredit bindings need that extension to be present in order to not keep adding spaces ... so it would be cool if that happens to work.

In any case, thanks for your thoughtful response, and I'll try to get back to you one way or another, although it might take a day or so.

@mkvlr So that does indeed fix the issue as far as the spaces formatting, but then the paredit bindings cause edits that are incorrect. For example, if I have (foo bar) baz and I put my cursor after r and do a slurp, you'd like to get (foo bar baz). The transactions I generate as I send them across the wire look correct:

{:sequential true,
 :annotations
 [#object[Annotation [object Object]]   ;; remote
  #object[Annotation [object Object]]], ;; noformat
 :changes [{:from 8, :to 9} {:from 12, :insert ")"}]}

;; original
(foo bar) baz
0123456789ABC

;; delete right paren at 8
(foo bar baz 
0123456789ABC

;; insert right paren at 12
(foo bar baz)
0123456789ABC

can you only tag the transaction that you receive?

Does that make sense to you, or does it seem like I'm using your plugin/extensions incorrectly?

This is a "remote only" problem, meaning that it is only the remote host that has this issue.

Only the transactions that are generated from "remote data" get tagged as remote/noformat in my code, to be clear.

And that's partially what I found baffling - that something didn't run in response to user input, but only in response to transactions.

(creating a desync between local/remote cases for me in particular)

I think a way forward for me might be to just not use that formatting extension, and then maybe I'll rewrite a set of paredit bindings that don't depend upon it for correctness.

we do use that so pretty sure it can be made work with it. But it’s been a good while since we touched that code so can’t say what’s wrong unfortunately.

Well, yes, and I understand it's a burden on you since my case is reasonably complex as well.

In any case, I learned some things with your help, so thanks for that.

I'll invest a bit more time in reading the code, since there's a lot in clojure-mode that I don't understand yet,

and I'll certainly let you know if I come up with anything useful.

Thank you!

Just pushed https://clojars.org/io.github.nextjournal/clerk/versions/0.6.387, (https://github.com/nextjournal/clerk/blob/main/CHANGELOG.md#06387-2022-03-03). Full announcement coming soon:tm:. Today also marks Clerks first birthday by https://github.com/nextjournal/clerk/commit/21b84c4d37b036a2a8ed438a834610da25992df7.

Hi I asked this in a thread above but I think it got lost. I have been experimenting/trying to use Clerk with tmd datasets but running into a problem where column names are truncated to the point where you can't read them at all when there are many columns. I've been using clerk/table in the method explained here: https://clojurians.slack.com/archives/C01GH5EN7JA/p1644269714727249?thread_ts=1644268797.698559&cid=C01GH5EN7JA

This is an example of what I was seeing: https://clojurians.slack.com/archives/C01GH5EN7JA/p1646116605286769?thread_ts=1644268797.698559&cid=C01GH5EN7JA

I'm wondering if I am doing something wrong to get this result.

this looks like a css issue when the row values are really small. Asking @philippmarkovics to talk a look.

https://twitter.com/mkvlr/status/1499470357262127106