Tab title no longer showing first line of unsaved file. Always "Untitled" - except for Plaintext files

[johnathanz]

trafficstars

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

1. Start Sublime Text
2. Start a new Tab / buffer
3. Set syntax to Markdown
4. Type "Abc" in the first line of the empty tab / buffer
5. Set syntax to Plaintext
6. Remove all text in the tab, add line "Def" to the first line of the empty tab / buffer

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

[BenjaminSchaaf]

Does it happen in safe mode?

[keith-hall]

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)

[johnathanz]

@BenjaminSchaaf it happens in safe-mode too!

[deathaxe]

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.

[BenjaminSchaaf]

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.

[johnathanz]

Thanks for the background @deathaxe . The preference option totally fixed the issue :D

[KES777]

@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.

[deathaxe]

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:

1. Create a new view
2. type some text
3. copy that text
4. create another view
5. paste

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.

[KES777]

@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?

[deathaxe]

You'll have to ask the inventor this question. I wouldn't have restricted it at all.

[BenjaminSchaaf]

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.

[keith-hall]

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.

[KES777]

@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.

[BenjaminSchaaf]

@keith-hall HTML, HTML derivatives including markdown and LaTeX have a text. scope. Of those only markdown possibly starts with a title.

[WoodrowShigeru]

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 with SELECT *, 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?