feat(note): consolidate note creation options under note.* and add note.info (#575)

[acidsugarx]

feat(note): consolidate note creation options under note.* and add note.info (#575)

What does the PR do?

This PR consolidates note-creation behavior under opts.note while preserving backward compatibility with legacy top-level options.
Related to #575

1. Store default note creation options under note
   Added/normalized:

• note.id_func
• note.path_func
• note.template
• note.info (new, for preview text used in completion/hover-style docs)

2. Keep legacy config working
   Top-level:

• note_id_func
• note_path_func
  are now treated as legacy aliases:
• migrated to note.id_func / note.path_func during config normalization
• deprecation warnings are shown
• runtime compatibility is preserved

3. Normalize note creation pipeline
   Note._get_creation_opts() now carries a complete creation strategy:

• note_id_func
• note_path_func
• template
• notes_subdir
• new_notes_location
  Template customizations can now also override:
• note_path_func
• template

4. Signature consistency
   note_path_func is now consistently treated with spec:
   { id, dir, title }
   so title is available in path generation logic and typing/docs are aligned.

5. Preview customization
   Added Note.info():

• uses opts.note.info callback
• accepts callback return as string or string[]
• safely falls back to Note.display_info() if callback is missing/errors/returns invalid value
  Completion docs now call note:info(...) instead of hardcoded note:display_info(...).

PR Checklist

• The PR contains a description of the changes
• I read the [CONTRIBUTING.md] file
• The CHANGELOG.md is updated
• The changes are documented in the README.md file
• The code complies with make chores (for style, lint, types, and tests)

[neo451]

quick idea:

note.id_func and note.path_func should also get a parameter template, which will effectively replace customizations

maybe it can be the last parameter opts and all other possible context can be in there.

I at least like just some if statements then some nested tables in customizations, and code can be simplified.

what do you think

[acidsugarx]

Good idea, I like the direction. Passing template (and potentially more context) via an opts param to id_func/path_func is a clean win for the common case — if-statements in one function are definitely more readable than nested customization tables.

A couple of things I found while looking at this:
It can't fully replace customizations though. Two things customizations do that the functions can't:

• notes_subdir override — this changes base_dir before either function is called, so dir in path_func is already affected. Users could work around it with Obsidian.dir directly, but it's awkward.
• Template redirect (customization says "use template Y instead of X") — no way to do this from inside id_func/path_func.

So I'd say: add it as an additive change, keep customizations as-is. Let users pick whichever style fits:

• id_func(title, path, opts) — opts = { template = "..." }
• path_func({ id, dir, title, template }) — just add template to the existing spec

Fully backwards-compatible since Lua ignores extra args/table keys. And opts is a nice extension point for the future

Want me to put up a PR for this?

[metalelf0]

Will this allow setting up a path_func that always returns the same string to always create notes in a given folder? E.g. to setup an inbox where all new notes are created?

[neo451]

@metalelf0 this should be already possible with opts.notes_subdir = "INBOX", or current path_func, just return always appended the dir you want.

and @acidsugarx I'll need to give the changes more thought, and leave this migration stuff to next major 3.17

[metalelf0]

@neo451 oh, ok, this works! I was trying to use opts.new_notes_location for that but didn't realize it wasn't actually expecting a path and was confused about why it didn't work. Thanks!

[neo451]

ok great, I'll keep your case in mind for #79