Syntax Selection Persists on the File Level

[pa-0]

Current issue

If I am working on multiple files in a folder, I may switch back and forth between files as required by my workflow. I've noticed that (for example) if I am working in my dotfiles folder, for instance on my zsh configuration, I must choose the appropriate syntax every time I switch back to the same file. Upon returning to the file, I find that the syntax has reverted to None.

The solution you'd like

It would make for a better user experience if CotEditor remembers syntax selection for a file, especially if the file had just been accessed seconds prior and a syntax chosen for that file.

Alternatives you've considered

Alternatively, a setting could be added that, when enabled, prompts the user anytime they select a syntax for a new file extension, if they would like to add the immediate file's extension to the relevant syntax definition so that whenever a file with that extension is opened, that syntax is selected by default.

In cases such as dotfiles (e.g., .zshenv, gitconfig, .bash_profile, etc.), if a user selects a syntax for such files (that have no extension), CotEditor could instead prompt the user to choose whether they would like to add the file_name_ to the syntax definition to associate that filename with the particular syntax by default.

Just a thought!

CotEditor version

latest

macOS version

Sequoia 15.2

Additional context

As a side note, just a suggestion related to the GitHub issues template you use:

If you wrap the existing template in markdowncomments, it can still illustrate an example for the user, without requiring them to 'clean' up their draft before submitting (by deleting any leftover text). Markdown comments can be created like so:

[//]: # ( This is one way to create comments in Markdown.)
[//]: # ( This is likely the syntax compatible with the most Markdown parsers.)

<!-- ⚠️⚠️ This syntax also works to create Markdown comments in GFM ⚠️⚠️ -->
<!-- Either/or works, BUT I think this syntax is less portable  -->

so in this case,

Ex. I'm always frustrated when [...]

would become:

[//]: # ( Ex. I'm always frustrated when [...])

which will still be visible to the user, but not visible once the user presses Submit