Has anyone else faced this problem before? How can I fix this ?
Thank you.
Just removed flyspell from my init file and the issue was fixed.
Not sure how flyspell can be the cause. It must be an issue with your capture template.
I’ve got the same issue and disabling flyspell fixes it for me too. I’m loading my template from a file instead of a simple string. This doesn’t does happen too when the template is a simple "%?" string. I don’t think what is in the :target property matters for this to be triggered.
I can’t seem to be able to make this happen in a reliable way.
Should I share my config here or make a new thread?
@vp275 Would your org-roam directory happen to be within a git repository or submodule?
I think I narrowed down my case to only when I try place the captured file within a nested submodule… Weird.
I still have the issue without submodules when I try to use templates from files. 
This thread is a little confusing to understand. Is the following correct understanding of the current state?
- The issue is duplicate
#+titlein the same way as originally reported by @vp275; the duplicate issue happens when you capture a new note viaorg-roam-captureandorg-roam-node-find - Disabling
flyspelldoes not fix the issue - It does not always happen – when it starts to happen, relaunching Emacs initially fixes the issue; however, after a while, it starts happening again
- When it starts happening, you do not see any pattern but it appears to occur randomly
- Existence of git submodules is NOT relevant
Hello, sorry for making it confusing. As a dev myself I don’t like doing that but, at the same time, I’ve struggled a lot trying to pin down the source of the issue and I wanted to spark a discussion.
As a PSA: I’m quite new to Emacs (as in I’m actively using it for only a few months) so I might not know some of the internals that lead to this happening. I’m using Doom Emacs (and I wonder if @vp275 does too, as it looks alike, but it’s bare assumption). Just in case, my config can be found at Jérémy "Vrakfall" Lecocq / doom.d · GitLab
Now to answer your questions:
- Yes, the issue appears as the same, even yasnippet pops up with the same error message. The only thing that doesn’t seem to happen for me is the
flyspellerror message in the message buffer (even in its history) and I don’t usehunspellanyway. I’m guessing @vp275 was trying to enable it just before the screenshot. - Now it’s going to become hard to answer these next questions with certainty: many of the things I tried seemed to work for some time then at some point the issue re-appeared without modification of the config. Disabling
flyspellis one of those, except I never got to find out if the issue comes back after a while because I didn’t test it for long enough; I decided whatever solution I find for my config should happen withflyspellenabled as I like what the package does. That being said, I’ll try to run Emacs withoutflyspellfor a while and see if the issue comes back. - Now here is where it becomes weirder: Restarting Emacs sometimes fixes the issue, sometimes not, sometimes a config rebuild (aka
doom sync) helps and sometimes none of it helps. Now, what I just noticed today is that a complete reboot of the computer is more reliable on fixing it which makes me wonder if it’s not a problem with some cache. When restarting Emacs, the issue came back at some point. I’ve yet to see it come back with rebooting the computer, I’ll keep you posted. This makes me wonder if trying to change/add templates would make it happen again. - Yes, when it happens I try disabling/re-enabling separate things, restart emacs, etc… Sometimes I think I found what caused it and theeeeen… it comes back and re-testing what I thought was the cause is unreliable.
- Like with git submodules, it was fairly consistent when I tried that; and the problem came back anyway.
Some things I’ve got to add: I never had the issue before I started adding my own templates. The default one was fine. I then tried to load templates from files which made me think it was the issue but it happened with a simple "%?" string later anyway.
I’m going to keep fiddling around, test things along and report back these next few days/weeks as it’s something I run into a lot and I really wanted the templates to work to improve my workflow.
It might be a time sink-hole to try and find the problem from an external point of view until I could do more testing.
Thank you for answering, I feel less left alone with the issue.
Let’s try to avoid this issue sprialing into a time-sink for our sanity 
Doom is a big and complex layer on top of Emacs. For an outsider like me, it’s a big black box that can do anything unexpected. This is with good intentions for most of the time, but when it turns against you, it bites you hard from an unexpected angle – I used it for a while, leart a lot, but in the end I decided it was doing too much extra for me to manage – it was an evil beast I could not tame.
On a practical matter, if we set aside Doom, Emacs should not really cache data without your knowing it (in general, you are the one responsible for the cache via your explicit configuration or custom code; or a package’s documentation should make it explicit for you). And usually caching data is stored in memory. So… in general, relaunching Emacs should give you a clean slate for caching. It’s not like a browser, which tends to persist a lot of data on cookies, etc. and you’d need to manually clean it if you suspect caching is an issue.
In your situation, I’d normally suggest to try Emacs without Doom. But I guess that’s not an option you would like to take.
Another typical suggestion is to debug the code interactively when the issue happens – this is also not an easy one for you to take, as you cannot reliably reproduce the issue at the moment – if you could, edebug-defun should be one of your best friends.
My current assumption is something in Doom’s module automatically adds the extra "#+title: ". It does not seem to be Yasnippet – it would have added more than just "#+title: " by the looks of the snippet for Org.
I am not worried about this “random” nature – Doom (and you can do it yourself; I deliberately do it too in my personal configuration) “defers” loading of many libraries until called by your command. This is mainly because you want to shorten the time to launch Emacs. So the state of Emacs may change before and after a certain, single command – you may not be even aware of the fact your calling a command has just loaded a bunch of libraries (because this is configured as part of Doom, not your explicit configuration – another aspect of the evil beast).
Next time when you start seeing the duplicate “#+title” again, I suggest you take note of the values of the following variables:
org-capture-mode-hook
org-roam-capture-preface-hook
org-roam-capture-new-node-hook
org-capture-after-finalize-hook
org-capture-before-finalize-hook
org-capture-prepare-finalize-hook
These are the hooks that automatically call some functions/something to influence the Org capture process – Org in general, and Roam-specific, but both can potentially change the capture process.
I may be casting potentially too narrow a net (or too wide – not sure).
Thank you really much for your inspired answer! While digging more info about Emacs, I became quite aware of the dichotomy of opinions with regards to using Vanilla or not. Doom is what got me started on Emacs (and it’s really good at that when you come from an IDE like IntelliJ and you wanna be sure you switch to a new tool that has all the bells and whistles) and who knows I’ll probably try the Vanilla journey at some point just like when I switched for more DIY Linux and Unix distros (i.e., Arch and FreeBSD).
My goal is to always be learning, that’s also why I’ll try a declarative distro when I’ve got the time. But time is the very rare resource that everyone wishes it was infinite. Doom works very well for my use case at the moment and there are many things that require more of my attention right now. This is actually the very first obscure issue I cannot easily fix that I run across. This is not to say that I won’t switch, it’s a really good suggestion, but now is not the time.
I still need to learn edebug-defun, I’ll try as soon as I can and run into the issue again.
I knew Doom was lazily-loading a lot of stuff but I didn’t think it would go to that extent. On a side note, I make heavy use of ZFS so this might actually just be wasted effort to gain some seconds while loading.
Tho, I didn’t know it would go to such extents so as to create heavy state mutations like this. This totally sounds like what I’m facing.
Thank you really much, this will really help a lot understanding those mutations! At least I know where to look further. I’ll also try to remember what I did to trigger the issue and dig into the libraries used by those commands.
In the meantime, today I was waiting for the issues to re-appear to disable flyspell and see how it goes but somehow it never did! It sure feels like this happen mostly when I’m tinkering with the template config.
Thank you really much for your help, time and patience. I’ll keep you posted on how this goes!
And yes, sanity is an underrated thing these days. 
@nobiot
I forgot to mention that sometimes it gets to a state where the issue doesn’t happen for a small amount of characters for a node title but it does for a bigger one.
I just got it to a state where trying to capture any node with 10 characters or less is fine but any more than that brings back the issue.
The values of the hooks you mentioned are the following:
org-capture-mode-hook
Value:
(+org-show-target-in-capture-header-h
evil-insert-state)
Original Value:
nil
org-roam-capture-preface-hook
Value:
(org-roam-dailies--override-capture-time-h
org-roam-capture--try-capture-to-ref-h)
org-roam-capture-new-node-hook
Value:
(org-roam-capture--insert-captured-ref-h)
Original Value:
nil
org-capture-after-finalize-hook
Value:
(+org-capture-cleanup-frame-h)
Original Value:
nil
org-capture-before-finalize-hook
Value:
nil
org-capture-prepare-finalize-hook
Value:
(org-roam-capture--install-finalize-h)
Original Value:
nil
Afterwards, I restarted Emacs’ daemon with Systemd and it stayed the exact same. I then rebooted my computer and it was then fine to create nodes with 36 characters or less but no more. I rebooted another time and now the amount is way up there (I’m not sure of how many characters but it did happen with a string almost the size of my screen). This seems very random but so far, with today’s quick testing, it seems like the issue is always there, it’s just that the amount of title characters required to trigger it is random.
Edit:
- Also interesting to mention, on the last test, I did exactly nothing before trying to capture a new node. It was the very first action I did after Emacs opening, I did not even reload my last session.
- I just made it happen with flyspell disabled and another uber-long string title.
What’s the command you use? I’d put edebug-defun to it and step through the process line-by-line.
@nobiot
I’m using org-roam-node-find and org-roam-node-insert, both seemed to have the same behaviour except for the obvious final action.
Now, this is quite amusing (and also not, since it’s not precise enough): I was using edebug to try and follow the process line by line, learning it as I went, when I got it “stuck” at some occasions (it was probably some intentional temporary buffer but I couldn’t get back to debugging). That “stuck” buffer with some debug links I couldn’t understand is hard to describe, anyway it’s outside my current point.
Most of the time it was enough to simply restart emacs’s daemon and re-run the debugged function. But at some point I got emacs to a point it wouldn’t even start anymore without any error message; starting it without daemon would show an almost black (with my theme, I suppose) black window that seemed either in infinite loop or deadlocked with race conditions. No amount of restarting would help.
So I thought, what if I would just erase all of .config/emacs/.local.cache’s directory content and run doom sync afterwards (unsure if it matters with this directory but it recreated a subdirectory); I’m using zfs anyway and the old content would only be a snapshot away. Aaaand, it rebooted just fine and now I’m unable to reproduce the issue (well, at least for now, I know how consistent it is at appearing fixed then showing back up again)! No matter the node size.
As a side note: Buffer history is stored in there, isn’t it? This makes me think that I use undo-tree and it has a history of spamming a buffer’s history, maybe it matters, I don’t know. I should switch to vundo at some point regardless.
I will report back later to tell if the issue appeared back again or not, I don’t want to get my hopes too high too fast.
This is not “standard”. I think the whole config/emacs/.local is doom specific.
It sounds to me that the issue has somehow disappeared and not reliably reproducible any longer – so I guess you are now monitoring the situation…
The challenge for me and anyone other than you is:
- I don’t use doom (so I don’t have
config/emacs/.local) - I don’t use any package for undo (such as
undo-treeandvundo) so I have no “buffer history” for undo persisted as a file (it’s all in the memory which gets deleted when I quit Emacs, if I understand it how it works) - I don’t use
zfs(I don’t believe it’s relevant, but it is a difference) - I don’t use daemon (I don’t believe it is relevant)
Basically… not many people can have the same environment as you to help you in a directly meaningful way… But if I take 3 and 4 out of the equation, 1 and 2 boil down to the fact you have doom and I don’t.
This is my reason to have suggested that you move away from doom. It was not meant to be a permanent shift, but just to see if doom should contain the cause of the issue (somewhere in its vast layers of doom stuff) – but I understand without doom, probably your emacs becomes useless to you, so this is not a path you can take.
At this point, I don’t know how we, as a community, could assist you with this issue… At least I am completely useless.