Feature Request: option to not use §

[mediapathic]

As far as I can tell, the § convention is falling out of favor with the ZK community. In private communication with sfast, he implied strongly that he no longer uses it in most note titles, and has relegated it to some specific meaning. And it's quite a few keystrokes to replicate in emacs :).

Therefore, can we have a flag that toggles whether or not functions that use § do so? I almost never use it, and every time I create a note link I have to delete it.

From my understanding, this should be fairly easy in terms of file creation, the only thing I see that might make this hard is the zd-avy-link-search, but I don't really understand the internals of that. And personally I never use that anyway, so if that function requires the § I'm ok with that.

Thanks!

[EFLS]

That's a good suggestion to make the package more universally usable.
I'll have to look into it, but it should be possible, although zd-avy-link-search would indeed be affected.

EDIT: Another issue would be the fontification. Currently, § type IDs are easily detected. I'd have to think of an alternative way of highlighting links.

[mediapathic]

For the record, since I never used § links, I did not even know you highlighted links, so I would not miss that feature :)

[mediapathic]

Would it make sense to just define a link as anything within [[]]? or is that too limiting?

[EFLS]

I've made some adjustments so that you can change the § if you like. Do so by changing the zd-link-indicator variable. You should also be able to set it to nil.

Take a look at the changes in this commit.

Make sure to (setq zd-link-indicator nil) before loading zetteldeft.

I hope I didn't break anything else!

How does this work in The Archive? Are links always included in [[? I haven't chosen that option, because of potential clashes with the way org-mode handles links.

[mclearc]

For what it's worth I just use [[]] and have no problem. Any finds everything with a [[ fine:

(defun zd-avy-link-search ()
  "Call on avy to jump and search link ids indicated with [[.
Opens immediately if there is only one result."
  (interactive)
  (save-excursion
    (avy-goto-char-2 ?\[?\[)
    (zd-search-global (zd-lift-id (zd-get-thing-at-point)))))

though I'm also just working in markdown. But I don't see why this would be a problem in org as well, unless you're doing a lot of other linking?

[mediapathic]

I've made some adjustments so that you can change the § if you like. Do so by changing the zd-link-indicator variable. You should also be able to set it to nil.

Cool, I'll take a look when I have some time to play with it. Thanks!

How does this work in The Archive? Are links always included in [[? I haven't chosen that option, because of potential clashes with the way org-mode handles links.

The Archive always uses [[]] for links. I don't know that it's the optimal solution, because org sees that as a link to a header in the file, and asks if I want to create the header every time I accidentally activate one.

[mediapathic]

I just updated, but I can't test this yet because #6 means that I can't actually do searches. I mention it here just in case the two are related.

[EFLS]

@mediapathic I can't seem to replicate the issue. With zd-link-indicator set to nil, I'm still able to do actions like zd-copy-id-current-file and zd-find-file-id-insert.

Could you share your deft and zetteldeft setup?

[mediapathic]

Hey, sorry about the delay. I include the relevant lines from my .init, but there's really nothing particularly weird that I see here. I have just realized that I'm setting my deft-extensions twice, and that is dumb, but I doubt it's relevant.

However, in looking through the customize options and the way they write to the customize block in my init, I note:

` '(zd-link-indicator "nil")

Which I think means that it's reading "nil" as a literal string. I can't figure out how to set it to actually nil. In customize I've tried nil, 'nil, and just deleting the string, but it always seems to be interpreted literally and thus searches return that string instead of what it should be. Can you ELI5 how to actually make that nil?

Just in case, here's my init details:

;;;; deft ;;

(setq deft-extensions '("md" "org" "txt"))

(use-package deft
 ; :bind ("<f8>" . deft)
  :commands (deft)
  :config (setq deft-directory "~/Dropbox/Writing/Zettel/org/org-zettel"
                deft-extensions '("md" "org" "txt")
                deft-recursive nil
                deft-use-filename-as-title t
                deft-use-filter-string-for-filename t
                deft-default-extension "md"
                deft-auto-save-interval 10.0
                )
  )

;;;; Zetteldeft 

(use-package zetteldeft
  :quelpa (zetteldeft :fetcher git :url "https://github.com/EFLS/zetteldeft.git")
  :ensure t)

[EFLS]

You should use (setq zd-link-indicator nil) to set it to nil (no quotes or anything). The problem with your line, I'd guess, is that it doesn't include setq.

You could add that line to the :config part of your use-package zetteldeft setup.

To just execute the setq line, move to the closing bracket and hit C-x C-e.

Finally, to see whether that worked, you can hit C-h v zd-link-indicator to check its value.

As an aside, there are many good introductions to elisp. This one by Barry Schwartz, for example, might be of help to grasp the basics: https://harryrschwartz.com/2014/04/08/an-introduction-to-emacs-lisp.html

[mediapathic]

You should use (setq zd-link-indicator nil) to set it to nil (no quotes or anything). The problem with your line, I'd guess, is that it doesn't include setq.

I was unclear: that line is part of the auto-generated customize block, so it is already implicitly part of a setq statement. I just copied and pasted the line in isolation for clarity. What I was asking was, in the Customize interface, is the correct thing to set the field to nil or just leave it blank. I suppose in my case that doesn't matter if I'm setting it in use-package but just to note this may be unclear to future users.

Finally, to see whether that worked, you can hit C-h v zd-link-indicator to check its value.

When I eval (setq zd-link-indicator nil) and check that variable, it is indeed set to nil, so I guess that's not the issue, sorry about the red herring.

But, nonetheless, ids are still not working. zd-find-file-id-insert inserts nothing, zd-copy-id-current-file copies nothing.

Any other thoughts of avenues to explore?

[EFLS]

Very strange. I can't reproduce it, and don't really have much to go on.
Nothing else in your custom block that maybe interferes with zetteldeft?

And what about other functions? Could you report the following for me:

• what happens when you run zd-find-file? And zd-find-file-full-title-insert? Are those two (some of the most basic functions) working at least?
• what the value is of variables zd-id-regex and zd-id-format?

Finally (or maybe test this first), what is the result when you evaluate the following code?
(zd-lift-id "2018-11-09-1934 This is a test title")

I'm not really experienced in tracing bugs, so guessing a little here on how we could see what's going on behind the scenes.

[mediapathic]

Very strange. I can't reproduce it, and don't really have much to go on.
Nothing else in your custom block that maybe interferes with zetteldeft?

And what about other functions? Could you report the following for me:

• what happens when you run zd-find-file? And zd-find-file-full-title-insert? Are those two (some of the most basic functions) working at least?

These work as expected. I get a helm search with all my zk, the first opens the file, the second inserts the title.

• what the value is of variables zd-id-regex

zd-id-regex is a variable defined in ‘zetteldeft.el’.
Its value is "[0-9]\{4\}\(-[0-9]\{2,\}\)\{3\}"

and zd-id-format?

zd-id-format is a variable defined in ‘zetteldeft.el’.
Its value is "%Y%m%d%H%M"
Original value was "%Y-%m-%d-%H%M"

I don't read regex very well, but is that regex trying to pick up ids with dashes in them? If so, this would be odd, because searches with the non-dash id used to work.

Finally (or maybe test this first), what is the result when you evaluate the following code?
(zd-lift-id "2018-11-09-1934 This is a test title")

I see no result from evaluating that.

I'm not really experienced in tracing bugs, so guessing a little here on how we could see what's going on behind the scenes.

I appreciate your continuing effort! I hope it will turn out that this is an actual problem I am helping you solve and not just a mistake on my part.

[EFLS]

Ah I see what's happening. Setting the value of zd-id-format is disrupting the id functions.

In the documentation of the variable, I explain:

Be warned: the regexp to find these IDs is set separately.

I should update the documentation, because now it is severely lacking.

Anyway, you should update the zd-id-regex so that it can find your customized IDs. Try the following:

(setq zd-id-regex "[0-9]\\{4\\}\\([0-9]\\{2,\\}\\)\\{3\\}")

[mediapathic]

So close! That was definitely the issue, because the id functions work now. However, I think the regex is wrong, because it is consistently chopping off the first part of the id. So, for example,

201901231754 BOOK - Delaney On Writing

becomes

1901231754

ie, chopping off the leading "20". This seems to be a consistent pattern in the sparse couple of files I've tested with.

[EFLS]

Okay, so we have at least identified the cause.

I don't know why I suggested that terrible regex in my earlier reply (lack of time, I guess), because it could be much simpler. Since your IDs consists of 12 digits, it could be as easy as setting it to that. To make it a little more strict, however, I suggest the following:

(setq zd-id-regex "20[0-9]\\{10\\}")

Now it will only detect a sequence of 20 followed by 10 other digits.

Let me know if it works. I'll update the documentation of zd-id-format to include a note that users have to configure the regex as well.

[mediapathic]

Fantastic! That seems to work great. Thank you so much!

I would recommend for documentation including this particular regex as an example at least, as I suspect most people who want to change their id style will want to change it to this, which I believe is currently the most popular style.

Again, thank you for all the support.

[EFLS]

Great to hear that it works now. I updated the documentation to make things more clear.