Your search is not built correctly try {Section <Event John the Baptist is arrested>}
Correction: the search generated by the context menu is not built correctly. I did not build it.
A perfect illustration of https://community.logos.com/forums/t/103515.aspx
Furthermore, compare the various < Searches > below:
The bug where right-click makes the wrong search has been reported. Sorry for the inconvenience.
(Yes, search got more powerful in L6, but also way more complex. We'll work on that, too. Stay tuned.)
Thanks, Eli. Is there a particular reason <Event Name of the Event> does not work (see screenshot above) while the other < FactbookDatatype Searchterm> searches work better?
Is there a particular reason <Event Name of the Event> does not work (see screenshot above) while the other < FactbookDatatype Searchterm> searches work better?
At least I think it should work like the others
(just noting for precision: in Bible Search. <Event xxxxx > does work in Basic Search and finds results in non-bibles)
Events in this resource behave more like regular milestones, which also don't return results for this search syntax.
For example, a search for "<Bible Jn 3:16>" in a resource doesn't highlight the text of John 3:16 (but only references to it).
Are you merely describing what is happening or are you stating that this is as it should be? In relation to Factbook, it is difficult for the user to see the logic for a different behavior for Events from that of the other categories. This is all the more so as Factbook does list Events in a given book, with links to specific passages AND the passages in question do feature the events in the context menu AND provide searchability for them. If the event is tagged in a passage and can be found by Factbook, why could it not be found by searching?
Are you merely describing what is happening or are you stating that this is as it should be?
Why can't it be both? [:)]
To expand on Bradley's (cryptic) answer:
The different search extension syntaxes reflect where in the system the information is ferreted away, which generally reflects a real/substantive difference in the nature of the information:
All three of these types of information are stored in different parts of the system and so require very different methods for the search engine to locate. So to clue the search engine into the fact that you want it to look in the milestone index rather than the normal full-text index, we have to invoke the {Milestone ...} search extension. Similarly, {Section ...} tells the search engine to check various supplemental rather than primary resource data, and that it's looking for long stretches of text rather than single words. (We'd all be very upset to get N hits per N words for these searches.)
We're aware that this division by storage mechanism puts an extra cognitive burden on users and we are working on strategies for streamlining the syntax so that there's a way to look everywhere for a piece of information without worrying about whether it's a section or a milestone or whatever. In the meantime, I hope this explanation helps.