Docs say how a look resolves a relative path: the looking pane's directory, then each jump-list pane's, most recent first

fs.md's look section and tags.md said nothing of where a relative path
is looked for, so a look that found a file in a directory visited an
hour ago, or not in an open pane never visited, was a surprise. The
order is written as look.zig's resolveLookTarget has it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 6 insertions, 0 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 43980973..85be803d 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -227,6 +227,12 @@ go. An `exec` line's blanks at either end are trimmed.
   nothing is: said on the message row and logged as an `err`, the write
   still answered. A file that is there but will not open (no permission to
   read it, say) fails the write, with why.
+- a relative path is resolved where the click was, then where you have
+  been: first against the looking pane's own directory, then against the
+  directory of each pane in the jump list, most recent first, each
+  directory tried once; the first that names a file (or a pane open on
+  that path) wins. A pane never visited (not in the jump list) is not
+  searched. `./x` and `../x` are the looking pane's directory's alone.
 - `@p<serial>:<addr>` addresses a pane by serial, a terminal's logical lines
   too.
 - a directory types `ls` into a terminal idle there, else opens one there.