Thanks for your answer. Pressing [New Chat] unfortunately doesn't fix the problem. I've also tried, toggling the chat box, restarting Joplin and rebooting. In the overall troubleshooting process, I reinstalled the Jarvis Plugin. Maybe the removal wasn't quite as clean. Maybe there is some left over that is the cause of the problem. I've reinstalled the Jarvis plugin again. Strangely it remembers the settings. So I think that uninstalling Jarvis doesn't remove the data and the settings completely, so the problem persists. Oh man, I'm sorry. I'm new to this.
Thanks for reporting this @HeBu, I finally found the bug and published v0.13.1 with the fix. The chat panel was only published last week, and you are probably the first to test it with a stricter-than-usual API. The new release should become available on the Joplin plugin marketplace in the next few hours.
I've installed the update and now it works! Thank you! Jarvis is such a great tool!
v0.13.2
- added: Note mode in the chat panel which scopes the chat to the currently open note, threaded with the panel's history (equivalent to Chat with Jarvis from the end of the note, only from the panel)
- the mode toggle becomes a 3-state rotation (click or Shift+Tab): Collection → Note → Chat
- each reply is tagged with a clickable link back to the source note; the note tracked updates per turn as you switch notes
- sending in Note mode with no note open is blocked with an actionable message
- renamed: Notes mode → Collection mode (RAG over your whole note collection), to distinguish it from the new Note mode
Many, many thanks for these updates. A vast improvement in useability. Just stunning work!
That said I wonder if there is an issue with the implementation of the new chat UI element? Using exactly the same edge collection query I'm getting basically a null returned in the chat box, but a good reply triggering the search from a note via the Tools/Jarvis sub-menu. Could there be a bug?
Hi @plutoBase, there could be an issue, it's a new feature after all. But more information would be helpful in order to reproduce this.
The two modes share almost all their code, so I'd expect very similar results, up to model randomness and a small effect from the note's title on the search. Both modes also feed recent conversation history into the search query - the note chat reads it from the note body, the panel from the current panel chat. So for a fair comparison, both need to start empty: a new collection chat (New Chat button) and a fresh query in a blank note. Same query, both with no prior turns.
If you still get null from the panel but a good result in the note, could you tell me:
- was the panel chat empty when you sent the query, or was it mid-conversation?
- which note was open/selected in the editor at the time, and does it contain a
jarviscommand block?
Thanks for your reply! Was 99% certain I ran the test case mentioned above as you describe, ie new chat in the panel, new note to run the query from. But tried the same query again and the sidebar generated a response, but almost certainly because the prior Jarvis reply from the in line query was stored in a note! So something recent to latch on to!
Fwiw, i then deleted that note with the saved query, and ran a new query from the sidebar on the collection, but got an error "Chat failed: No note selected". Is that expected given it was a query against the collection, not a specific note?
Anyway, I then selected a random note, ran the 2 tests again, and largely as i initially described, with the sidebar not quite generating a null, but it was a very poor answer basically regurgitating my test questions I have used evaluating various frameworks within the past month or so.
Whereas the in-line query generated a good answer, that was based on digging in to my notes.
Generally, I also get the impression that in line query responses seem fuller that those from the side panel, although I haven't tried to compare this systematically - Is that intended behaviour?
Thanks for looking in to this!
EDIT: I didn't specifically answer your question about a Jarvis command block! Not quite sure what that is tbh!!
Thanks @plutoBase, the "Chat failed: No note selected" error should not happen, but it was caused exactly by the panel and note-chat sharing the same code: the panel chat borrowed the note that's open in the editor for search context (title / tags), even in collection mode. That dependence also explains the quality difference you saw.
I just published v0.13.3 which fixes this: the panel now ignores the open note entirely. Could you update and re-run your test? From a fresh chat, the two modes should now give very similar answers and cite similar source notes.
(Your earlier observation about the panel latching onto a saved reply is expected - saved chats are ordinary notes, so they join the collection like anything else, unless you exclude their notebook from the Jarvis database.)
Thanks very much! Not showing an available update in the plugin options currently. Will update and test as soon as i see it!
OK, now updated!
A) Fat fingered mis-press on return in sidebar having only written "what is know". Got a long answer on LLM setup which is a frequent theme recently! I suppose unavoidable given the architecture but interesting!. More saliently the blue marked original question/user input seems to have vanished. Would be nice to have that back...
B) Second, fully formed query in the sidebar was preserved with the blue highlight having hit new chat. Strange
C) But answer looks decent.
D) However, the answer from the query from note text ->Tools/Jarvis is still noticeably fuller and more detailed
Could it be a cache thing somewhere?
Tried a slightly different approach: until now had been consistently querying the sidebar first and then the inline note method after.
This time I reversed the order, and and got a 2,300 char response in the inline query, and a 2,306 char response in the sidebar!
Is it possible the first response is somehow entering the mix for the second turn, no matter where it is triggered from?
Thanks @plutoBase, there are two possible explanations here, and you can tell them apart from the links at the end of the panel reply.
An inline chat is saved in the note itself, so it becomes part of your collection and gets embedded into the database (this happens when you switch to another note, or within ~10 minutes). A panel chat is not saved unless you press Save. So after your inline query, your collection may have contained a note with this exact question and a complete answer, and the panel found it and answered from it.
The other possibility is that the chat note hadn't been embedded yet, and both modes simply retrieved the same sources - which is the intended behaviour after the fix.
Check the citations in the panel reply: if they point to the note with your inline chat, it's the first case; if they point to the same notes as the inline reply, it's the second. If you'd rather keep conversations out of search results either way, move them to a notebook excluded from the note DB (the "Folders to exclude from note DB" setting).
Thanks. I had made sure to delete the note relic containing the in line query to level the playing field (also from the trash which is how I ended up with a null active note!).
But just went back and tried the original process of sidebar query first with a 1,831 char reply then in line note generating a 2,784 char response. Understand randomness is to a certain extent baked in, and see the logic of your position that the 2 should be identical. But that is just not how I am experiencing it 
Could there be something different in the way the Joplin API is processing things, passing metadata into the equation? Just throwing ideas at you here!
I think that a better comparison than character count is the citation lists at the end of the reply (after saving the panel chat to a note): if both replies cite the ~same notes, the difference is just generation randomness. In my case the differences were small, and so was the difference in quality between the replies.
There is one real difference left between the modes. Jarvis embeds a note's title into the search, and a fresh note gets auto-titled with its first line - the question you typed in. So your inline query is effectively reinforced by its own title (no new information however), while the panel query doesn't. You can test this: rename the chat note to something generic (e.g. "test") before running the chat command. If the two modes then behave the same, that's the whole story. Nothing else enters the equation through the Joplin API.
Aha, I see, I hadn't realised the note links are sent to the saved notes. Am away from my regular gpu for a few days on my laptop with an older gpu running some smaller models.
Fyi the straight character comparison produced very similar results 3,729 vs 3,917. But clearly much more than on my much higher powered gpu (should maybe have mentioned this is all using local models)
And on this machine the 4 citations used in both queries were very similar but not identical. On one note the long note hex ID was the same but the #tag at the end was different. Does that refer to a different chunk, or is it an internal document placeholder?
Also the order they were listed in was slightly different, but I suppose that is not material
among similar chunks the ranking may change a little due to the small differences I mentioned above between note / panel. a different #tag points to a different chunk in the note. BTW, you may increase the number of chunks that go into the context by changing the setting Notes: Context tokens (the default is about 4 chunks, but if you run a model with a large context window, you can easily increase this 4x-8x). other settings that affect the chat context to watch are Chat: Memory tokens. these may improve the responses that you get, and usually also make the selected list of chunks more similar (larger selection --> larger intersection for slightly different queries).