New note namer

[luginf]

Hello,

I'm not using Setext md style and had to remove the ============ for every new note. I've discovered the new note script which allows to use Atx style instead. It is working quite well, but some points could be improved. I've tried to keep most of the original behaviors and make the workflow easier and quickier (pre-filled dialogs). It also allows to use custom syntax (mediawiki, dokuwiki, txt2tags), or even start the document with a level 2 heading (## instead of # )

@diegovskytl , @Mystechry what do you think?

Original script behavior

Settings: extraDialogForFileName (boolean) + underlineHeading (boolean).

• Creating a note from any source (menu or search): always shows a title dialog asking for the note name.
• underlineHeading: chooses between ATX (# Title) or Setext (Title\n=====) heading style.
• extraDialogForFileName: shows a second dialog to enter a file name different from the title — pre-filled with the useless placeholder "File name".
• File name auto-derived from the title (strips # for ATX, uses the raw first line for Setext).
• If QOwnNotes' own headline prompt was also enabled in settings, two title dialogs appeared in sequence.

---

Improvements by this PR

• No title dialog when creating from search: when a search term is present, it is used directly as the note name — no dialog. The dialog only appears when creating from the menu (no pre-existing headline). This made the useSearchTermAsName toggle redundant; it was removed.
• No double dialog: when QOwnNotes already provides a headline (its own prompt or a search term), the script uses it directly instead of asking again.
• Expanded heading style: the underlineHeading boolean replaced by a three-option selection — ATX (# Title), Setext
  (Title / =====), Custom (with configurable opening and closing tags). Applies uniformly to both creation flows.
• File name dialog pre-fill: extraDialogForFileName now pre-fills with the derived title (heading markers stripped) instead of the "File name" placeholder.
• Code simplification: removed useSearchTermAsName, _pendingSearchTerm, and noteOpenedHook, which were intermediate machinery that became unnecessary once the headline hook was understood correctly. The script went from ~150 to ~90 lines.

[luginf]

Here is the complete behavior according to the option checked:

Source	Dialog: note title	Dialog: file name	Title	File name
Search "foo"	☐	☐	# foo	foo
Search "foo"	☑	☐	dialog pre-filled with foo	foo (search term, independent from title)
Search "foo"	☐	☑	# foo	dialog pre-filled with foo
Search "foo"	☑	☑	dialog pre-filled with foo	dialog pre-filled with foo
Menu (no search)	—	☐	dialog (no pre-fill)	= entered title
Menu (no search)	—	☑	dialog (no pre-fill)	dialog pre-filled with entered title

[pbek]

Are these changes breaking the settings of the script for existing users?

[diegovskytl]

thanks for your interest in the script!

Are these changes breaking the settings of the script for existing users?

maybe, as names in settingsVariables change?

[luginf]

thanks for your interest in the script!

Are these changes breaking the settings of the script for existing users?

maybe, as names in settingsVariables change?

I hope it won't break existing workflow for some people, but since there are no specific configuration besides checking a few checkboxes, I suppose it would just mean recheck them. I've also included a full readme with the explanations, and I could also recreate the previous workflow by testing the current version of the extension. The only difference would be to get the search term prefilled instead of "File name"

@pbek I've run npx prettier --check on the README.md, but the CI/CD is still detecting errors

[pbek]

new-note-namer/README.md

Did you also run it on the readme? 😉

[luginf]

new-note-namer/README.md

Did you also run it on the readme? 😉

sure:

npx prettier --check README.md
Checking formatting...
All matched files use Prettier code style!

and it's the version I've commited and pushed

[pbek]

Generally we don't want a script update to break the workflow for all users of the script. If that can't be mitigated it's better to create a new script...