[suggestion] Search functionality. I might enter a concept as a heading or as a child note, this is a constant tension. If I try to find it, I have to search twice, in the Lookup and if not found, in the vscode search, possibly in vain as I might not have entered this concept at all. It would be better and faster if Lookup could trigger the full-text search, for example if the search term is not found, or upon user request via a key press, etc.

we are thinking of making it a toggle. no ETA yet on when but if you submit a feature, we can track it on the roadmap 🙂 https://github.com/dendronhq/dendron/issues/new?assignees=&labels=&template=feature_request.md&title=

Well, I actually do not know what is a better way to do it, especially hearing the plans for a better Dendron search. Not clear what to ask for... Maybe even: - find in file names - find in headings - find in tags - find in full-text workspace-wide search as steps, or as a list in results?

you could list them in the issue to get the ball rolling. we'll probably end up splitting it out into separate issues once we start the implementation

Admittedly it would be two searches but as far as I understand you could search via lookup for filenames and in case this doesn't find anything useful use teh vscode fulltext search which should find headings, tags and any text in the notes. IIRC there is also a way to search specifically for headings

Aware of that, vscode search is very good. It is slow to switch though as I have described above

@User heads up that this is now fixed -> https://github.com/dendronhq/dendron/issues/1131

@User https://github.com/dendronhq/dendron/issues/609 is now fixed 🙂

@Usercan you see if you still experience the issue with markdowntables in v56 of dendron?

love the "first time developers" page! I think it will be great to elaborate more on it or add more learning resources, really helpful for people who are relatively new into typescript (like me) https://wiki.dendron.so/notes/70b4a93a-c7e0-4e1c-a873-3a9a291f5248.html

I've found the up and down "carets" of the nav panel clashes with prior use patterns of such elements. Visiting the Typescript resource mentioned on the "first time developers" page brought this above the unconscious level, as it uses the more common pattern,

>

, for collapsed/hidden subtopics,

down-caret

for expanded/shown subtopics. It is easier to see what open and what still hidden as these to states of the caret are more visually distinct. I had to come up with my own rational for the current behavior, an analogy to briefcase clasps, down is closed, up is open with contents exposed. I suppose this might be trying to leverage

drop-down list

, but why not use the more common convention?

thanks for the feedback. i don't have strong feelings on this one - we inherited this style from the original theme we forked from. @User @User @User - any thoughts on ☝️ ?

@User @User I have put my answer to this here https://github.com/dendronhq/dendron/pull/1193#issuecomment-906258835

It seems to no longer crash. it displays a little bit wonky, but the table is enormous and entirely unsuited for this kind of view anyway, so I wouldn't worry about that.

At the very least, I got the "this note is longer than X" to display this time around

And preview is delayed, but ok

we are also working on improving preview performance so that should get better soon 🙂

@here It's CROP time 🙂 Please vote for your favored crop 👨‍🌾👩‍🌾 1. [Option for Lower Case Title in Generated Note · Issue #1138 · dendronhq/dendron](https://github.com/dendronhq/dendron/issues/1138) 2. [Leave a trace on source note when using selectionExtract · Issue #737 · dendronhq/dendron](https://github.com/dendronhq/dendron/issues/737) 3. [Manually refresh index for One Note · Issue #916 · dendronhq/dendron](https://github.com/dendronhq/dendron/issues/916) 4. None of these (if there's an issue you'd like to add to rotation, please reply with a github issue) To vote, respond with a 1️⃣ 2️⃣ 3️⃣ or 4️⃣ to this message. voting closes Monday at noon Pacific Time

Interesting document, and I get your argument, but I personally would prefer at least an option for "spinning triangles/carets". I've been around a long time, and have spent a lot of time with

outliners

, so that informs my bias. The "Spinning Triangles" option was the best from that space, IMHO, and not covered in the design document. "Heading" - (topics), with children get an equilateral triangle: * When right pointing and 'filled' it represents subheadings are hidden, (visual metaphor - subtopics are in the triangle) * Downward pointing and 'empty', that represents subheadings are exposed, (visual metaphor - subtopics are out of the triangle) Not arguing for this specifically, just saying that we shouldn't go just for "good enough" or dumb it down. In fact, I'm liking the Typescript site elaborations more now that I've interacted with it: * uses "Spinning Carets - rt pointing + horz" * highlights the toplevel heading and subtopics as long you are within them, i.e. have a relevant note open * marks the 'current note' with a prepended 'pipe-character' * is keyboard navigable when the nav pane has focus The design document is focused on mobile friendly design, and while we want that, we shouldn't make it suboptimal for desktop usage. The design pendulum has swung toward minimalism, too far in my opinion. Wait until AR/VR swings it the other way, (of course that stuff is beginning to look like the "fifty years 'til Fusion" stuff. I'm all for easy discoverability, but leave and even enhance the expert level stuff. P.S. noticed google results is using "horizontal-carets", but even they are using a "spin" animation, and what is being "revealed", are not navigational elements, for 'notes in another pane, but in effect, the note itself.

Refactor Hierarchy selects strangely when I want to remove

w.

at the beginning of note names. It selects all kinds of things all over in addition to the correct notes. Can I force it to understand this literally? And is it as intended?

Can you try selecting with

^w[.]

Shall try. Where can I see the syntax? Also, this link is broken

Yes, this worked

Refactor Hierarchy supports Regexp, so that's what you'd want to look at. Not sure what's a resource to learn it, someone else can maybe recommend something. Thanks for catching that broken link, I'll make sure it's fixed.

No worries, if this is regex, I can figure it out

2021-08-30 CROP

https://discord.com/channels/717965437182410783/737323300967022732/882314900351881227 -> Looks like nearly all of the links in today's release announcement highlights are broken?

thanks for the heads up - looks like it was an extra parenthesis

Hey @User Circling back to you about the spaced repetition RFC. We've accepted it as a community issue: https://wiki.dendron.so/notes/f143ca38-dcc6-4cd3-b84b-997aec1160ef.html This means the following > This RFC is accepted but is not currently part of our roadmap. We will leave this as a community project for gardeners that are interested in taking this on.