rendering oddity

[bdarcus]

The only UX eccentricity that I've noticed is what happens after I insert a new citation. When I move my cursor beyond the bracket, it looks like this:

... but if I move a single space more, it reverts to this, and I then have to take some action to get it to render:

Is there anything you can do about that?

[andras-simonyi]

Could you be more specific about how you insert the citation? using citar-insert-citation?

[bdarcus]

Ah, right; no, using citar-capf in this case.

[andras-simonyi]

Does the first image show the correct rendering (including the red foreground color) or something else? I tried to reproduce the problem using citar-capf but was unable to do it, although I've also experienced a glitch:

If I start to write a citation from scratch:

[cite:@s
        ^

(^ indicates the cursor's position) then insert a key using citar-capf

[cite:@smith1971
                ^

and finish the citation by adding the closing bracket then I end up with

[cite:@smith1971]
                 ^

that is, the citation is correctly fontified but not yet rendered. I have to move the point one position back and forward to activate rendering and then I end up with

(Smith 1971)
            ^

What happens on my system is also a bit annoying and happens because of some unholy interaction between fontification
and cursor-sensor mode, but seems to be different from what you described.

[bdarcus]

Does the first image show the correct rendering (including the red foreground color)?

Correct, but wrong color.

I see the same as you, but it doesn't render after I add the space, IIRC.

[andras-simonyi]

I see the red foreground only when a part of a citation is changed (e.g. deleted) while it is in a rendered/preview state. Is it possible that you are modifying the citation while the preview is shown? In theory, if the citation is well-formed then one only needs to move the cursor from a position inside the citation to a position outside to trigger the preview/rendering, no modification is needed. (Similarly, the preview/rendering should disappear when the cursor moves inside the citation from an external position.)

[bdarcus]

I see the red foreground only when a part of a citation is changed (e.g. deleted) while it is in a rendered/preview state. Is it possible that you are modifying the citation while the preview is shown?

I don't think so.

If my cursor is right after the parenthesis, and then I move one to the left, I then see this:

EDIT: but the odd thing is if I move right instead of left, I get the same thing.

[andras-simonyi]

So if the cursor is right after the parenthesis and you move the cursor one to the left and immediately one to the right it doesn't trigger the appearance of the preview? Very strange. (I suppose the cursor-sensor minor mode is turned on in the buffer.)

[bdarcus]

So if the cursor is right after the parenthesis and you move the cursor one to the left and immediately one to the right it doesn't trigger the appearance of the preview?

Actually, no; if I do exactly that, it does render.

But if I add a new citation, with the capf, and then a space to the right, it does not render.

EDIT: so in other words, I have to move cursor back to the citation for it to render.

Shrug.

(I suppose the cursor-sensor minor mode is turned on in the buffer.)

Yes.

[andras-simonyi]

Well if you add a space as well after the bracket then I guess you need at least one more cursor movement to reach the inside of the citation and then get out of it to trigger the rendering... The main problem what I see is that when a well formed citation is created by adding a closing bracket then the cursor movement is not yet registered as leaving the citation so one has to go back and out again to trigger rendering. On my system this exact problem is not present because I use smartparents-mode, so the closing bracket is already there when I insert a key and I'm definitely inside the citation when it's created. I will try to look into whether adding something to post-command-hook could solve this problem.

[bdarcus]

On my system this exact problem is not present because I use smartparents-mode, so the closing bracket is already there when I insert a key and I'm definitely inside the citation when it's created. I will try to look into whether adding something to post-command-hook could solve this problem.

If I add this first, and then add the key, the behavior does not change for me:

[cite:]

[andras-simonyi]

If I add this first, and then add the key, the behavior does not change for me

Do you mean that the citation is not rendered when you leave it with the cursor? For me, if I start with [cite:], and add a key ending up in a state like

[cite:@smith85]
              ^

(assuming that smith85 is a valid key) a single step with the cursor to the right (or jumping to the end of the line with the <End> key) is enough to trigger the preview.

[bdarcus]

The only way I can get it to render is if there's already a space after the closing bracket.

If there's not, it doesn't render.

FWIW, I'm on a recent build of Emacs 29; so could be some bug.

[andras-simonyi]

The only way I can get it to render is if there's already a space after the closing bracket.

That is definitely different from what I see on Emacs 28.2, there is no need to add a space. Anyhow, fiddling a bit with the post-command-hook might solve this problem in general.

[andras-simonyi]

Could you try defining the the function

(defun org-cite-csl-activate--post-command ()
  (when-let ((prev-char (char-before)))
    (when (= prev-char ?\])
      (let ((prev-point (1- (point))))
	(when (and (equal (get-text-property prev-point 'cursor-sensor-functions)
			  '(org-cite-csl-activate--sensor-fun))
		   (not (get-text-property prev-point 'rendered-cite)))
	  (let ((element (org-cite-csl-activate--get-citation prev-point)))
	    (when element
	      (pcase-let ((`(,beg . ,end) (org-cite-csl-activate--get-boundaries prev-point)))
		(org-cite-csl-activate--fontify-rendered element beg end)))))))))

somewhere and adding it to the post-command-hook in Org, for example, by adding this to the Org-mode hook:

(add-hook 'org-mode-hook 
          (lambda () (add-hook 'post-command-hook 'org-cite-csl-activate--post-command nil t)))

in theory, this should render a new citation immediately when the closing bracket is added.

[bdarcus]

My initial test shows no change. Here's what I have in my test config using elpaca:

(use-package oc-csl-activate
  :elpaca (oc-csl-activate
            :host github
            :repo "andras-simonyi/org-cite-csl-activate")
  :hook
  (org-mode . (lambda ()
		(add-hook 'post-command-hook 'org-cite-csl-activate--post-command nil t))))

[andras-simonyi]

I've compiled the most recent Emacs 29 version (29.0.60) and tried to reproduce the problem with an absolutely minimal configuration, but didn't see any difference compared to the behavior of Emacs 28.2:

• Without adding the above function to the post-command hook the cursor has to be moved inside the newly created citation and to the outside to trigger rendering, but no additional space is needed,
• with the function added to the post-command hook the newly created citation is rendered as soon as the closing bracket is added.

It seems that something in your environment (settings and or packages) causes the space problem. (Maybe evil-mode, if you are a user -- I'm not.)

[bdarcus]

I normally use evil, but in this case not. Am using meow instead for modal editing.

It's good that at least you confirmed it works as expected.

[tecosaur]

For what it's worth, I've also found org-cite-csl-activate to be slightly flaky at times. For example:

https://user-images.githubusercontent.com/20903656/225192609-c66b9e92-8893-4d9a-a503-183c31e2ede1.mp4

We've implemented some similar behavior for the new LaTeX preview functionality, and while it's got some edge cases we're tracking down, in my experience so far it seems to work a bit better.

https://user-images.githubusercontent.com/20903656/225192977-9c5086a7-c6dc-4792-a8ff-004cc426d46e.mp4

[tecosaur]

@andras-simonyi I don't suppose you've been able to give this any more attention/thought?

[andras-simonyi]

@tecosaur Unfortunately I haven't, but hope to be able to look into this in the coming weeks. Any concrete improvement suggestions or reading recommendations are welcome.

[tecosaur]

No trouble, I'm entirely familiar with long cycles of busyness. While probably not enough (I'm pointing you to a ~3k elisp file that does a whole collection of things), I will say the revised Org LaTeX preview approach I mentioned has continued to work well from my experience and what I've heard from other testers. This makes me think there could be value in adjusting what org-cite-csl-activate does based on it. If this is of potential interest, I'd be more than happy to help go into what's actually going on with it :slightly_smiling_face:.