Open johnathanz opened 2 years ago
Does it happen in safe mode?
Not sure how this was working for you before, but probably you'll want to update the SetUnsavedViewName
event listener to ignore which syntax is chosen:
--- Shipped Packages/Default/set_unsaved_view_name.py 2021-04-02 13:30:54
+++ Packages/Default/set_unsaved_view_name.py 2020-12-03 11:17:13
@@ -1,7 +1,6 @@
import string
import functools
import unicodedata
-
import sublime
import sublime_plugin
@@ -35,14 +34,14 @@
view_name = view.name()
# Only set the name for plain text files
- syntax = view.settings().get('syntax')
- if syntax != 'Packages/Text/Plain text.tmLanguage':
- if cur_name:
- # Undo any previous name that was set
- view.settings().erase('auto_name')
- if cur_name == view_name:
- view.set_name("")
- return
+ # syntax = view.settings().get('syntax')
+ # if syntax != 'Packages/Text/Plain text.tmLanguage':
+ # if cur_name:
+ # # Undo any previous name that was set
+ # view.settings().erase('auto_name')
+ # if cur_name == view_name:
+ # view.set_name("")
+ # return
# Name has been explicitly set, don't override it
if not cur_name and view_name:
@@ -65,7 +64,6 @@
first_line = view.substr(line)
first_line = first_line.strip(self.dropped_chars)
-
# Filter non-printable characters. Without this the save dialog on
# windows fails to open.
first_line = ''.join(c for c in first_line if unicodedata.category(c)[0] != 'C')
And also to check you don't have the set_unsaved_view_name
preference set to false (related: https://github.com/sublimehq/sublime_text/issues/5509)
@BenjaminSchaaf it happens in safe-mode too!
ST's default behavior hasn't changed since ST3.
In case it's primary Markdown you are worried about and if you happen to use MarkdownEditing - it sets the title to the first heading found in an unsaved document.
A change in MDE 3.1.6 was made to respect set_unsaved_view_name
setting. Unfortunatelly it doesn't fallback to True
as default value in case the setting is not present. That's why setting tab title is now disabled by default.
Adding "set_unsaved_view_name": true,
to your Preferences re-enables old behavior.
The intention is to not set the view name for source-code files. set_unsaved_view_name
should check the scope instead of checking for a specific syntax.
Thanks for the background @deathaxe . The preference option totally fixed the issue :D
@deathaxe Thank you for the option. It is really useful. Would be nice, if you put description for this variable into Preferences->Settings-Default.
EDIT Found an issue, where people asked same: https://github.com/sublimehq/sublime_text/issues/5509 +1
@BenjaminSchaaf Sorry, I did not understand how naming for untitled tabs interfere with file syntax? I always have many unsaved tabs and I often copy/paste code there. And before coping I need to write something on first line and then paste. This behavior is annoying =(
Would be better if editor just took first line of file and name untitled view.
I don't have access to ST's default Preferences.
If you mean the one of MarkdownEditing... It just re-uses an existing "core" setting. Adding it to MDE's preferences template, would augment ST's default value and the description was available only, if MDE is installed.
Hence, it should probably be added to ST's default Preferences.sublime-settings, instead.
I've solved the issue by adding it to my Defaults override package: https://github.com/deathaxe/sublime-commands/blob/4da46a9baa357d25f6dedc1c53b6531a405f5bec/Preferences.sublime-settings-hints#L17-L20
With regards to copy & paste:
Just try the following:
The title is updated and now equal to the first view, as you copied "plain text" and pasted it as "plain text". The title is updated via on_modified_async
event hook, which doesn't care about whether text was typed or pasted.
It's just the syntax of the copied text, which is assigned to an empty view when pasting, which disables the functionality of updating tab titles, because they are updated only for "Plain Text" views.
@deathaxe
they are updated only for "Plain Text" views.
Tell me please, what is the reason to restrict this behavior only to Plain Text
views?
You'll have to ask the inventor this question. I wouldn't have restricted it at all.
The intention is for this feature to be used for notes, where the first line often contains a title or something else relevant. Code rarely starts with anything signifying the name of a file, instead having shebangs, imports, includes, {
, /*
, etc. Hence why the name is only set from the first line on plain text files.
That makes sense, but I believe there is an argument that could be made that it should work on other types of text file - not just plain text. For example, a Markdown file - whose scope starts with text.
(as opposed to source.
) often starts with a heading like # Heading
and it could be useful to see that instead of untitled
when it is not yet saved.
@BenjaminSchaaf I do next thing: copy code and write the description as first line. And most of time I want to setup correct syntax to see correct highlights for the code. I use this like notes.
Would be nice if ST will not have such restriction on syntaxtype.
@keith-hall HTML, HTML derivatives including markdown and LaTeX have a text.
scope. Of those only markdown possibly starts with a title.
Code rarely starts with anything signifying the name of a file, instead having shebangs, imports, includes, {, /*, etc.
@BenjaminSchaaf Even so, you could distinguish your files better if they were …
two files that start with
/*
, then the one that starts withSELECT *
, then the one that starts with* [x] first TODO today
, then one that starts with// this is file so-and-so
… as opposed to five files that all say "untitled". What benefit is there to have the title say "untitled" as opposed to {
?
Please don't impose your work habits onto others. There is no need to check for syntax.
One compromise solution would be to make it a preference. Another would be to make "untitled" a prefix: untitled: {
.
@deathaxe Btw, I do not get the described results for the (undocumented?) set_unsaved_view_name
preference. Is this a MarkdownEditing preference? Has it been recently removed since your comment?
this has been bugging me for years now... apparently i have at some point already spent some time looking into why this stopped working and added the mysterious
"set_unsaved_view_name": true,
to my main preferences, but my titles still aren't auto-changing when editing markdown files.
any ideas how i can re-enable this highly useful feature?
... looking into why this stopped working ...
It actually didn't stop working. Tab titles are only updated for plain text documents per design.
That's why this issue is marked "enhancement" to suggest to possibly remove those restrictions.
any ideas how i can re-enable this highly useful feature?
Read comments of of this issues to learn about it.
i thought i did, but i don't seem to understand what else i can do... so is there a way to get this running for markdown syntax again (as it did some years ago)?
MarkdownEditing sets first heading text as tab title of unsaved views.
Description of the bug
Before build 4126 Sublime Text on Mac. Whatever first line I used in an unsaved markdown file (e.g. # Cool file) will always update the Tab Title with that first line.
Since 4126, any new tabs I open will remain "untitled" for any syntax other than "Plaintext".
For Markdown, Python, or Javascript for example, regardless of buffer contents, the tab title will always be "untitled"
So now it's impossible to tell which file has what content.
This only seems to affect the Mac 4126 build. The Windows 4126 build works as it did previously
Steps to reproduce
Expected behavior
At step(4) above, Tab title should be changed to "Abc"
At step (6), after changing Syntax to Plaintext, Tab title is changed to "Def"
Actual behavior
At step(4) above, Tab title remains as "Untitled"
At Step (6) above, with the Plaintext syntax, Tab title shows "Def" which is expected behaviour we need for all syntax
Sublime Text build number
4126
Operating system & version
Mac V12.6 Monterey (21G115)
(Linux) Desktop environment and/or window manager
No response
Additional information
No response
OpenGL context information
No response