Closed EFLS closed 4 years ago
Maybe this would be an opportunity to polish the documentation a bit more and start releasing versions?
@EFLS The link-indicator might still be useful if it was extended to automatically wrap different types of links - for example [[]]
for file links or []
for org-mode style links. I think as it stands as Note indicator it is not very effective, since the follow-link
or avy-file-search
can work without it.
Perhaps I could keep the link indicator and add a link suffix, so that users of The Archive can use [[
]]
to wrap their links, like you suggested.
Perhaps I could keep the link indicator and add a link suffix, so that users of The Archive can use
[[
]]
to wrap their links, like you suggested.
I think that would be a great idea! By default the link-suffix
could be nil, but setting it to ]]
allows for easy Wiki-style links without having to create override functions.
The link indicator grew on me. I really like it when I invoke zetteldeft-avy-file-search-ace-window
(suggested to be bound to C-c d F
) and zetteldeft-follow-link
because it highlights that link indicator for me to choose that link if I have multiple links on one note.
But I think those would just highlight the first character anyways, so if a note id were 2020-04-23-00-00
, then the first 2 would be highlighted. It's not bad, but I like how that link indicator is a placeholder for the highlight. I hope that makes sense. Also, thanks for asking for community feedback.
Is there an easy way to type the link indicator? Personally I like the [[link]] style links used in org mode.
Is there an easy way to type the link indicator? Personally I like the [[link]] style links used in org mode.
@mannd For now there's a way to accomplish it by doing a little bit of elisp hacking. Warning! I am very much not an Emacs expert so this could possibly the wrong way of achieving this. Usual "Works on my machine", YMMV disclaimers apply.
First, set zetteldeft-link-indicator:
(setq zetteldeft-link-indicator "[[")
Next, you will need to create two private functions to extend the existing zetteldeft functions:
Finally, add a couple of function overrides to your init.el
(advice-add 'zetteldeft-find-file-id-insert :override #'my-private-function/zetteldeft-find-file-id-insert)
(advice-add 'zetteldeft-find-file-full-title-insert :override #'my-private-function/zetteldeft-find-file-full-title-insert)
If it works correctly, you should be able to use the zetteldeft-find-file-id-insert
to insert [[link]] style links now.
@mannd If you want to use org-mode links together with Zetteldeft, you might be interested in this: https://gist.github.com/EFLS/b64e2914fc9c51164131265a375a994a
But a more general question: why do you need to insert the link indicator manually? It should happen automatically when you use the zetteldeft-find-file-*-insert
functions, for example.
@EFLS, @avggeek: Thanks for the suggestions. I realize this isn't the help page for Zetteldef! I have just started using it and will try out your recommendations.
I second some proposals here (note: I've only recently started building my own zettelkasten and only have 141 zettels inside). I've been using Zettlr and I'm considering switching to Emacs for which I know the basics of it.
In order for the package to suit a maximum of users whatever horizons they may be coming from, I second the idea of having a prefix and a suffix for links ([[ and ]] for me).
I understand that some tools use either a full filename (without extension .md) in a link (meaning an ID would not work) or the ID only (meaning a full filename would not work). I'd suggest having the ID only, trying to match it against the beginning of a filename, and if there's no file, launching a search in deft/avy (I haven't yet looked up the differences) and let the user choose what to open.
Since we're into links, could it be possible to make a link clickable like Org does?
The latest update includes a customizable zetteldeft-link-suffix
!
For use with Markdown, check out Introducing Zetteldeft.
@EFLS I just tried out zetteldeft 20200509.1040
and the new zetteldeft-link-suffix
seems to behave in an slightly unexpected way.
Create a "source" markdown file as follows:
# 0000-00-00-0001 Meta Zettel
Contains all
Next create a "target" markdown file:
# 2020-10-05-1556 Foo
Contains bar
Now if I run M-x zetteldeft-find-file-full-title-insert
and filter for the "source" file, the "target" file is updated as :
# 2020-10-05-1556 Foo
Contains bar
[[0000-00-00-0001]] Meta Zettel
Notice that the file title is outside the Markdown link syntax. Is there anyway to include the complete title inside the "[[" and "]]"?
Is the unexpected behaviour you refer to only the fact that ]]
appears directly after the link, and not after the full title?
In any case, that was the idea of the link-suffix
: to have it appear directly after the link, not the full title. I tried to emulate what I saw from screenshots of The Archive.
Currently, the link-suffix
is considered part of the link itself, which means it should go directly after it (and not have other text between ID and suffix, such as a title).
Including the title within the brackets with a full-title-insert
isn't difficult, but it would break the concept of the link-suffix
being part of the link, thus preventing things such as zetteldeft-follow-link
from detecting these as links...
@EFLS Ah I see. I did take a look at some other The Archive articles and get what you are saying. I guess my workflow may not be very common then? I use the note-link-janitor which automatically inserts backlinks across all of my zettels. However, it does require the link within the [[
and ]]
to include the title else it does not work.
Now that you mention that zetteldeft-follow-link
does not work, I realize that zetteldeft-avy-*
is not working either 😞. Which is strange because I could have sworn it was working when I closed #44.
Yeah, the follow
and avy
functions expect a link to include 3 things (as of the recent update): the indicator, the id, and the link suffix. So if the suffix isn't there, it won't detect your links.
As a temporary work around, you could set the suffix to ""
(an empty string, which it is by default), and the link indicator to [[
. Then you need to include the closing brackets manually when inserting links, but the follow
functions should work.
I'll see whether I can think of a fix later.
Yeah, the
follow
andavy
functions expect a link to include 3 things (as of the recent update): the indicator, the id, and the link suffix. So if the suffix isn't there, it won't detect your links.As a temporary work around, you could set the suffix to
""
(an empty string, which it is by default), and the link indicator to[[
. Then you need to include the closing brackets manually when inserting links, but thefollow
functions should work.
Thanks for the explanation. I do have some function overrides that add the closing brackets manually (which is what I was using till you added support for the link-suffix
). I did as you suggested and the follow / avy functions now work again. I can live with this for now.
FWIW, sublime_zk does offer an optional setting to include Note title when creating links: https://github.com/renerocksai/sublime_zk#insert-links-with-or-without-titles
Note that Zettlr's way of doing [[links]] is to just add the ID, not ID+title inside the link. So, the way it functions now is just perfect for me!
@stampf Yeah and that's the default for The Archive and _sublimezk as well. I'm not proposing that EFLS change the defaults, just potentially add an optional setting to include title.
Been doing some more research and it appears that there is a fork of the note-link-janitor app I linked to above, that supports the [[ID]]-style linking. Will give that a shot and if that works, I might not need the ability to add title in either!
Got the forked version of the app I mention earlier working by switching zetteldeft-id-format
to %Y%M%D%H%m
. Which means now I can use the new link-suffix
and tweaks to font-lock-keywords
as well 🎉
This is not quite related, but I do like having the link indicator. I'm experimenting with IDs that are more like Luhmann-style (hierarchical note sequences with a "section" leader, like "zk-1a7b12").
This contorts my zetteldeft-id-regex
quite a bit, but also makes the links short; they wouldn't stand out so much without a link indicator, and I fear that font-lock would tend to highlight too many things that would not be links.
And I refer to it as "that beautiful §
symbol".
I'm experimenting with IDs that are more like Luhmann-style (hierarchical note sequences with a "section" leader, like "zk-1a7b12").
Oh that's interesting. Feel free to share your experiences here or in a separate issue on Github, I'd be interested in learning how it goes.
I'll open up a separate discussion thread. There are things I'm not sure how to do within the current zetteldeft structure, but there are some funny advantages to doing this digitally (like I can refile things by renaming files and updating all the referencing links and titles). It gives me a sense that I will be able to keep things better organized as I learn the technique over time.
Thanks to everyone for weighing in. Zetteldeft will keep its idiosyncratic link indicator.
I'm rewriting the
avy
related functions (used to jump to and open links) to rely onavy-jump
rather thanavy-goto-char
. This means that we can jump to regular expressions such as thezetteldeft-id-regex
, instead of jumping to thezetteldeft-link-indicator
-- also known as "that stupid§
symbol".More importantly, this means that we can completely drop the link indicator, and use
2020-04-15-1818
to link to notes, rather than§2020-04-15-1818
. It would also remove the conceptual distinction between a link and a note ID.In other words: the link indicator can be dropped completely.
Before I do that, I'd like some input of people who use Zetteldeft. Does this make sense? It might require some adjustments to currently existing Zettelkästen, but also make things easier, especially for interoperability with other Zettelkasten implementations.
What do you guys think? Should I keep the link indicator and simply allow people to set it to
nil
if they want to, or completely remove it from the code?