#1

I can’t find the difference when i am searching for something using line: … , block:… or section:… The results are exactly the same (there is no any difference in search panel results). I expected to see different “depth” of search results - but line: and section: do not differ , while the section result must be “deeper” , “longer” cover text from heading to heading, but nothing close. Does anybody have the same results?

1 Like
#2 
# sec1

cat 
dog

# Sec 2

This will get matched in section:(cat dog) but not in line:(cat dog)

This note

# sec1

cat dog

# Sec 2

will get matched by both

#3

Oh , it is a little tricky.
So search operator used only to find variously located words in original note? To define search words more accurately?
I thought that the main purpose of search operators it to display in different way (different number of symbols) in search results…

1 Like
#4

Is it intentional that the sections aren’t nested for the purposes of the operation?

For example:

# sec1

## subsec1

cat

## subsec2

dog

section:(cat dog) won’t match that one.

Came up today because I was actually trying section:(/foobar/ -"## Key") which should have found all foobar in the file except for the ones in the top Key section.

However, since that section was split into ### Sub1 ### Sub2 etc, I couldn’t exclude the whole key that way. Instead I had to do section(/foobar/ -"### Sub1" -"### Sub2"). As it happens, that worked in that file, but only because Sub1/Sub2 were unique to the key. Otherwise I’d have to flatten out the Key section to use bold plaintext instead of true subheaders.

I could see the intention going either way, and the heading to heading search with no nest awareness is definitely easier technically. However, transclusion works nested, and I’d probably expect this to work like transclusion and other header-aware functionality, where a line is part of multiple sections at once.

#5

yes, it is intentional. Otherwise we should have section, subsection, subsubsection, subsubsubsection and so on.

1 Like
#6

I have no idea if the engine that does essentially the same thing for outlining and transclusion purposes could handle it, but a new operator for heading:(foo bar) that considered whether they were under any common header parent at all would be nice.

I realize that a # Header1 over the entire doc would essentially make that useless, but for practical reasons–mostly that there’s already a title bar that can’t be suppressed–I’ve always used ## Header2 as the top so that the doc ends up composed of several “islands” of ## Headings.

I don’t think that’s uncommon, since one company I was at that ran on Wiki broadly had the same habit. For docs like that this would let you localize to a broad section. I could probably model the same behavior using a transcluded doc for each section, but a header span-sensitive operator would be way more convenient.

Alternatively, maybe an operator like in:"## Key" that only matches if the next subquery is in a span called that in the doc? Negating that would have had the same benefit for my query, and the behavior would be more precise. At that point header names can basically be treated as block tags, and common naming can serve cross-file queries.

3 Likes