If at all the top of the note AND collapsed (like torb mentioned in regard to noteplan) would be a good place. Actually i would be satisfied with both places, note or sidebar, but definitely i prefer the sidebar for the already mentioned reasons.
Obsidian is definitely the secret love of us bear users: we don’t use it but if we miss something in bear we point to obsidian
Yeah, that’s near to perfect. Actually a scrollable preview over hovered stuff would make sense also in other parts: in second pane notes list and search results, wikilinks and so on. In logseq app you even can type into the hovered preview and thus change a note without opening it
The question is: how much text is acceptable to not disturb the design and how much text is necessary to give a value
I am going to repeat an old idea in a different way: why don’t you use panda (if at all it will be released as file based app) as a tool for a slightly different user base which prefer some of the more geeky and complex stuff. Based on the same foundation and design principles both apps could take a different route. Also you as a company could benefit from that if the user bases increase because different needs are addressed
We discussed the 4th column here in the forum mostly in regard to backlinks but also the table of content is an important tool for serious writing of long texts. That should be considered in the discussion
The reason I don’t think hover preview is as crucial in Bear is that it is super easy to cmd+click and open the equivalent of a “popup” note - AS LONG AS you get the auto-scroll to the linked section. If you don’t get that and you are forced to do an in-note search just to find the link you clicked on … well, then that would be pretty painful. In electron-based systems, the friction of opening a note just to see the linked reference is too steep and wonky as you don’t get native windowing.
Panda is a file-based app. The architecture to make links work for files is completely different from Bear’s SQLite database. In fact, it is much harder to do file-based linking because each note is its own independent entity. Thus you need an external database just to keep track of note links. Then imagine changing a note title. Now you need to update not only every note that contains a link to that changed-title note, but you also have to update your external database reference. Ditto for tracking tags. Having everything in a single database makes that kind of stuff easier. So no, I can’t imagine Panda implementing a new architecture to support file-based linking and backlinking. As a stand-alone markdown editor, on the other hand (akin to Typora, et. al.) - that I can see. There certainly seems to be a market for such products.
That annoys me when searching in bear and opening the founded note that i do not come to the part of the text that is shown in the search results of the second pane as snippet. These little details would highly improve the ux. In that context it is necessary to mention that you can’t open a note from second pane in its own window without the mouse. CMD+Click obviously cannot work
I am no programmer and do not know nothing about such stuff. But naive as i am i have the following question: couldn’t panda work exactly like bear with its sql-lite-database but additionally to that it just saves files to the disc. I mean following route: editor → database → file. So that panda is not working with the files but just saves it as a copy of the content what is in the database.
Or maybe we need a third app called grizzly? Just joking!
Kinda, sorta, but not completely. Think about this: you create your note in “Grizzly” (great name!) and save it out as an .md file. Which means any markdown editor can (and should be able to) edit that file. So now you open your new file with TextEdit to make a quick tweak and then re-save the file. Grizzly has no idea the file just changed, because it’s not continually “polling” all the files in its “vault”. To be a file-based app means that you write AND read from the .md file. That file is the true source of the note. Anytime that note is changed - by any app - the truth of the note has changed. So no, you can’t really be a database-centric app AND a file-based bidirectional note app at the same time - not without a lot of separate code.
That no scroll-to-first-found-result is incredibly frustrating for me as well. Here’s what it takes to get your search results highlighted and note scrolled to the first one:
cmd+shift+f
type in search term
down arrow to select desired note
RETURN (or click) to enter the note
cmd+f (for in-note search)
type in your search term again
RETURN
And then, after those 7 steps, you have arrived in your note at the first found result. For short notes, it’s no big deal - you don’t need any scrolling and Bear does a super nice job of yellow-highlighting the found results. But for long notes, it is awfully painful. Especially compared to something like Obsidian: cmd+shift+f, type in search term, click on result. Done.
Wow absolutely awesome that there will be backlinks with not only linked and unlinked but a little bit of context. I’m back to Bear from a hiatus to LogSeq, Reflect, and NotePlan so have seen this done a variety of ways and like others have mentioned sidebar is ok and context is crucial! Thank you and I am excited for this release. Hopefully on all platforms before years end. Just signed up for a year of Bear so ready for the next version.
Any chance some form of built in templating is a possibility? This would stop me from having to use so many Shortcuts
Not to forget that you only see the first result in the preview of the notes list and not all results. That makes searching significantly more difficult. In regard to search i would prefer obsidians way to list multiple snippets from the same not. On the other side this way also has its flaws: when typing short terms or even just a single letter you receive an endless list. A good way for me seems that the opened note is already in search mode with the pattern from the filterbar in second pane
Ok, i understand. But on the other side: does that matter in regard to wikilinks which are not written by another apps just by panda itself? As i said i have no clue about such things
I agree, I think if we do 1~4, 5,6,7 has to be done automatically. That is, once note is selected following the search, it should automatically provoke in-note search and take us to the first highlight. Then we can press escape or x to exit the search.
If it is done automatically from point 5 on, it would be strange to see a second search bar with the same content like the bar from second pane. As long as that bar from notes list is used and therefore the search results appear yellow in the note itself the right and left arrow could appear in the bar above the note. The up and down arrows on the keyboard already can cycle from note to note, the left and right arrow could cycle through the results of one note
The thing is, search yields a slightly different result wit Bear 2.0(at least for now) where the second pane only search through text, and the in-note search search through text AND images. Also, having to have notes cycle separate to in-note search seems just unnecessary. Although it might look a little ugly, it is not hindering anything either.
Search in Bear 2 was completely rewritten and improved! Without leaving the search you can now get directly to the result, cycle between results in the same note, move to a new note, and start again.
So the steps on the top are now:
cmd+shift+f
type in a search term
select the result (or not, if you already had a note selected)
This is a great set of features and more than I expected!
One question: I make heavy use of wiki links to specific headers within a note rather than linking to the overall note title. Will these appear in the backlinks too?
