New zettel in doom-emacs ends up with two TITLE-Tags
juh2 opened this issue · 18 comments
To reproduce:
Start a Deft search and type in some text
Create a new zettel with C-c C-d n and type in your filename
The new zettel has two titles:
- the one derived from the deft search
- the one you typed in
Thanks for reporting this issue, but I can't reproduce it.
Do you mean C-c d n
to call zetteldeft-new-file
? Because C-c C-d
calls a deft function to delete notes.
And could you elaborate on what you mean with "two title-tags"? Like the org-mode #+TITLE:
?
Could you also let me know whether deft-use-filter-string-for-filename
is t
? And whether setting it to nil
makes a difference?
EDIT: Never mind, I should have known that this does something completely different.
Running on Emacs Doom, I had something similar (as far as I understand the original post), whereby Zetteldeft was inserting its title text, but also I was getting the default new file template behaviour, with a standard Org or Markdown boilerplate title. I had to do: (set-file-template! 'org-mode :ignore t)
to disable the default empty file template functionality for org files, although note that this is Doom-specific syntax. But it might be worth investigating if the extra title is coming from a similar mechanism.
Yes, it is zetteldeft-new-file
deft-use-filter-string-for-filename is nil
Hi, I have the same issue with doom emacs. I tried:
- deft-use-filter-string-for-filename nil/t
- (set-file-template! 'org-mode :ignore t)
Thank you for providing zetteldeft.el
same issue here; if I type a search into the deft buffer (e.g. zetteldeft rules) I would end up with this:
zetteldeft rules
#+TITLE: normal-title-as-expected
Thanks for all the reports.
I don't use the deft search bar to create new files, but decided to look at the code. Haven't narrowed it down completely, but it seems related to the following deft
features:
- internal function
deft-auto-populate-title-maybe
is what's used to set the title - and
deft-org-mode-title-prefix
is what's used as a prefix (if new files areorg
)
Attempting to fix this will have to wait until I've got some more free time, but in the mean time, remember that you can set deft-use-filename-as-title
to nil
, and manually configure zetteldeft-title-prefix
.
@EFLS i figured it was being caused by a deft function, I’ll post a fix when I have one
I assume the first #+TITLE is generated by deft as it should be and the second comes from the doom file-templates package which also populates new org files with a #+TITLE derivated from the filename.
As others mentioned the error only happens when using the zetteldeft-new-file function. Creating notes with the standard deft interface does not have that problem.
I deactivated the file-templates package in my doom config which works for me as a workaround.
Thanks for the suggestion. Can someone with doom
(and file-templates active) check whether setting zetteldeft-title-prefix
to nil
solves the problem?
zetteldeft-new-file with (zetteldeft-title-prefix nil) gives me a single title formatted like this:
#+TITLE: 2020 04 02 1453 Test3
e: with file-templates active as suggested.
Strange to see a time stamp included in the title. Is this normal for your setup?
Oh, i forgot to mention that. Stripping the ID from the title never worked for me. It's not intentional. But i don't know why. I always wanted to check if that is another doom anomaly. I just have the default setup otherwise.
It's about 2am where I am and this issue was driving me mad…after looking at the Deft code, the problem seems to be this chunk, which was pointed out in #26 (comment):
https://github.com/glucas/deft/blob/18607d2d581d008c76726eee01c847ede4ba8c16/deft.el#L1136-L1148
Using this config made new files get written correctly:
(setq deft-use-filename-as-title t)
This ensures we bypass all of the logic of deft-auto-populate-title-maybe
due to this conditional. Zetteldeft seems to be setting the filenames manually anyhow so this doesn't cause any other funky side effects!
Ooh, good find, thanks @jahfer! I had been looking at that deft-auto-populate-title-maybe
function as the culprit, but couldn't figure out why it only affected Doom users.
Now I see that the Doom Deft module sets ...-as-title
to nil
: https://github.com/hlissner/doom-emacs/blob/110d70bdff12c61fb4bfebf8e9f6b3a18684076d/modules/ui/deft/config.el#L8.
So I think the best way forward is to set it to t
within the zetteldeft-new-file
function.
I don't have Doom, so can you confirm that this new defun
works as expected?
(defun zetteldeft-new-file (str &optional id)
"Create a new deft file.
The filename is a Zetteldeft ID, appended by STR. The ID will be
generated, unles ID is provided.
A file title will be inserted in the newly created file wrapped in
`zetteldeft-title-prefix' and `zetteldeft-title-suffix'. Filename
(without extension) is added to the kill ring. When `evil' is loaded,
change to insert state."
(interactive (list (read-string "Note title: ")))
(let* ((deft-use-filename-as-title t)
(zdId (or id
(zetteldeft-generate-id str)))
(zdName (concat zdId zetteldeft-id-filename-separator str)))
(deft-new-file-named zdName)
(kill-new zdName)
(zetteldeft--insert-title str)
(save-buffer)
(when (featurep 'evil) (evil-insert-state))))
I actually don't have Doom installed either, I think this is an issue out-of-the-box with zetteldeft + deft. The default value of deft-use-filename-as-title
is nil
, so it seems this would impact a fresh install.
Removing my manual setting and using your function does indeed let zetteldeft-new-file
do the right thing! 🎉 I also tested without your change and confirmed the original issue was still there (just to be sure!). Looks like you've got the fix. Thanks!
p.s. Zetteldeft is one of my favourite emacs packages, thanks for building it ❤️
Great! Thank you for pointing towards the fix. And glad to hear you like the package!
I'll double check and push the fix in a couple of days when I have more time.
I've pushed a fix (simply add a let
to the new file function that keeps deft-use-filename-as-title
to nil
). Please check it out and let me know whether it fixes the issue!