This has been a long-standing bug with Dolphin (since KDE 4.0, I believe), but I couldn't find a bug report, so maybe it's never actually been reported. When a new text file is created, it's not empty. Instead, a 2-byte file is created with what appears to be a 'space' character in the file. Since this is a new file, I'd expect the file to truly be empty, such as is done by other applications. For example, creating a file with touch results in an empty file, opening and saving a non-existing file with Vim results in an empty file, etc. To illustrate, here are three newly created files using the processes described above. Notice the file size column: $ ls -l *.txt -rw-r--r-- 1 user user 2 2012-03-28 19:38 dolphin.txt -rw-r--r-- 1 user user 0 2012-03-28 19:38 touch.txt -rw-r--r-- 1 user user 0 2012-03-28 19:38 vim.txt This has been one of those mintor little annoyances I never felt was worth reporting before, but since it's been around for so long I figured it was time to bring it up.
For whatever reason, when I remove the two bytes from the template file, then creating an empty text file "Test" will not create the file "Test", but the file "Test.doc".
(In reply to comment #0) > So, Jared B., did you find a workaround to fix/bypass this bug? it's anoying, indeed..
holly cow!! it's just the Template file... here I fixed this just making this file empty: /usr/share/templates/.source/TextFile.txt (it had the same "space" + "new-line" characters)
Great find, wernerml. Just removing the space isn't quite enough to make it completely empty, though - it'll still have a newline in the file. This does the trick, though: # cat /dev/null >/usr/share/templates/.source/TextFile.txt And with that, I can finally create new, empty text files in Dolphin. Mostly. As Christoph previously pointed out (which I didn't understand at the time, as I wasn't aware of the built-in template file), this now prevents Dolphin from creating new text files without a .txt extension. It will ALWAYS add that .txt extension at this point. If I try to create a new file named "blah", it'll save it as "blah.txt". If I try "blah.doc", it'll save it as "blah.doc.txt". It's just not possible to create a new, empty text file without the txt extension. Has anyone from KDE actually looked into this? This bug has been around for years.
in here it always saves "without" the ".txt" extension. it saves without any extension acctually. (I have to type the ".txt" after the name) (it's ok though.. not so much trouble...) here's my /usr/share/templates/TextFile.desktop (if you want to compare with yours): _________________________________________________ [Desktop Entry] Name=Text File... Comment=Enter text filename: Type=Link URL=.source/TextFile.txt Icon=text-plain _________________________________________________ (and also, the "Name=" & "Comment=" sections has lot's and lot's of translations to other languages)
When I changed the default encoding of Kate from UTF-8 to UTF-16, the Unicode Character 'GURMUKHI LETTER TTHA' (U+0A20) appeared at the beginning of each new text file. That character looks like this: ਠ To recreate A) Right click in dolphin and Create New > Text File and save as TextFile. B) Now TextFile looks like hex dump [1] C) Open with Kate, save the file (Kate auto-adds BOM), and close Kate. D) Now TextFile looks like hex dump [2] E) Open with Kate, type a space then a newline, save, close Kate. F) Now TextFile looks like hex dump [3] [1] $ xxd TextFile 0000000: 200a => ਠ [2] $ xxd TextFile 0000000: fffe 200a => {BOM}ਠ [3] $ xxd TextFile 0000000: fffe 200a 2000 0a00 =>{BOM}ਠ{Space}{NewLine} The last hex dump was just to illustrate what a {Space}{Newline} looks like in UTF-16 encoding. The ਠ character prints because Dolphin adds hex 200a to the beginning of each textfile. UTF-16 encoding is big-endian, so hex 200a becomes hex 0a20. This matches the offset for the ਠ character (U+0A20). Bottom line: Before varying character encodings are introduced, this bug is a matter of preference; some people prefer an automatic space and newline, others dont. With varying character encodings, this bug is a definite problem, because most people do not want to start their text files with the 'GURMUKHI LETTER TTHA'.
*** Bug 340927 has been marked as a duplicate of this bug. ***
The bug is still here on KDE 4.14.2 Also, as said above, removing the empty space from the template file makes Dolphin add the ".txt" extension automatically to newly created text files.
Still here 2016.
I can confirm this on Dolphin 17.12.3 / Kubuntu 18.04 bionic beaver. Manually editing the template file, as recommended in #c3 works perfectly for me. I don't want to sound entitled, but this seems like such a simple thing to fix that I'm wondering why after 6 years nobody has bothered to remove those additional characters from the text file? Is this a conscious design decision? I could imagine that this is a papercut that is bothering a lot of users.
Can confirm the bug is still present with Dolphin 18.04 and frameworks 5.47.
The original commit that introduced that change[1] mentions the file mimetype, which is still true; what's happening here is that QMimeDatabase can identify mimetypes based on the file extension, so a .txt file gets a proper icon. But if you remove the file extension, you'd end up with a file with a blank icon. Also: $ file 'Text File.txt' Text File.txt: ASCII text Removing the space and new line from the file: $ file 'Text File.txt' Text File.txt: empty so making the file empty would mess with the mimetype of the file. [1] https://invent.kde.org/unmaintained/kde-baseapps/-/commit/d04a9df14daa636cc75666529e3fb01a93f2f508
Oh I see, my quirky brain always assumed "Text File" in this context meant something like "Generic File". Turns out I'm just using it wrong :'D So to sum up: Suffix '.txt' + content ' \n' is a text file Suffix '.txt' + content 'Some Content' is a text file Suffix '.txt' + content '' is a text file Suffix '' + content ' \n' is a text file Suffix '' + content 'Some Content' is a text file Suffix '' + content '' is NOT a text file Suffix '.py' + content ' \n' is a python script Suffix '.py' + content 'Some Content' is a python script Suffix '.py' + content '' is a python script The only combination between suffix and content which falls out of line seams to be the empty-empty one. I think there are a few options to improve the situation: - Turn the existing "Text file" option in to something more generic which only copies the template if file name does not contain a '.' (probably not a good idea since it would require a lot of changes in KNewFileMenu) - Ignore the special case since the UI already proposes a '.txt' suffix in the dialog (if someone removes the suffix they might know what they are doing) - Add a "File" .desktop file and template to KIO which creates always an empty file regardless of the suffix. - Make the mime hint more visible to reduce the feeling that the user is experiencing a bug (e.g. "Text File Content"). This might also educate the user that this is really a feature to create "text files" and not generic files (the opposite of directories).
*** Bug 446019 has been marked as a duplicate of this bug. ***
- Changing the contents of the new text file template based on the extension would make the code more complex - The experience would be a bit confusing, you create a "new file" and sometimes it has a " \n" and sometimes not - A file without an extension and 0 size has mimetype application/x-zerosize, and a blank icon The default template should cater to the typical use case, i.e. a user who wants to create a simple text file. Note that you can customize the behaviour: - Copy https://invent.kde.org/frameworks/kio/-/blob/master/src/new_file_templates/TextFile.desktop to the templates dir (by default it's ~/Templates) - create a dir ~/Templates/.source/, and inside it create a "Text File.txt" file, put whatever text you want there or make it blank ...etc. KNewFileMenu will pick that ~/Templates/TextFile.desktop over the one baked into KIO (as a QResource).
Thanks for the hint with the Templates directory! > The default template should cater to the typical use case, i.e. a user who wants to create a simple text file. I tend to disagree with the premise that the typical use case is creating a "simple text file". But I wouldn't have any data to disprove it. From all the files which are created with this action I don't know how many will have a .txt suffix as opposed to a .py, .xml, .ini or what ever else suffix... It just seams improbable to me that in most cases the extension will be .txt. And than again how often will a user on purpose create a file with no extension and expect it to be a "text file", I don't know. Still you might be right! That all said, would you oppose a MR which adds a "File" .desktop file and template to KIO which always creates an empty file regardless of the suffix? The "Text File" entry would stay and there just would be an extra entry which would just be called "File" since it would not create a new "text file" but a file in the most generic sense of the word, just an empty file with a extension chosen by the user. Could this be a compromise which would not change the existing option but improve the current situation to seemingly at least some users?
A "new text file" should be an empty (0-sized) file with a .txt or a .text extension. The user's intention is hers and should not be subject to any assumption or whatsoever. The aim of that thing is (should be?) to help the user create some new user-generated text file. With no assumption in mind, that file needs to be empty (0-sized). Actually also the so-called "file extension" choice should be left to the user, as this is Linux, not DOS (or even worse...). If that was a "new executable file" (which is machine generated/machine readable) then I could agree that an empty (0-sized) files is not a proper "executable". But you would not use Kate of the context menu to create, wouldn't you? "New HTML file" puts 168 bytes of pre-indented HTML code. But this is still machine-readable stuff. I can understand the reasoning while still totally disagreeing. A user that wants to "create a new HTML file" is lilely willing to enter all of its content by hand. What about a shell script? Would you put "#!/bin/bash", "#!/bin/sh", "#!/usr/bin/env ..." or what ? I wouldn't personally even put the "#!". But text file is an agnostic thing. Making assumptions there sounds like forcing someone else's decision. Finally, a user should use templates to adapt the behavior to her will, to to bring things back to the basics. This is my opinion: no facts to support it. Just simplicity considerations.
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kate/-/merge_requests/765
I have modified my MR on KIO to also have ability to add an empty file without extension (https://invent.kde.org/frameworks/kio/-/merge_requests/866). This file can be created when MIME type application/octet-stream is passed to KDirOperator::setNewFileMenuSupportedMimeTypes. I have also submitted an MR on Kate to replace to create a text file by an empty file (https://invent.kde.org/utilities/kate/-/merge_requests/765)
Git commit da65b36c78644ce39fcb8c2db1b02461644eb81d by Ahmad Samir, on behalf of Alain Laporte. Committed on 29/06/2022 at 11:17. Pushed by ahmadsamir into branch 'master'. Add template for empty file A +0 -0 src/new_file_templates/EmptyFile A +10 -0 src/new_file_templates/EmptyFile.desktop M +2 -0 src/new_file_templates/templates.qrc https://invent.kde.org/frameworks/kio/commit/da65b36c78644ce39fcb8c2db1b02461644eb81d
Not really closed in Kate until the https://invent.kde.org/utilities/kate/-/merge_requests/765 was merged. And for others applications, the EmptyFile must be used instead of TextFile.
Git commit fc3c6ce28e63842316507effecfb887ee65987c0 by Christoph Cullmann, on behalf of Alain Laporte. Committed on 02/07/2022 at 21:34. Pushed by cullmann into branch 'master'. When present, replace new text file entry by a real empty file * not useful to be able to create a text file (which is not empty) * due to empty file template introduced in KIO 5.96 (https://commits.kde.org/kio/da65b36c78644ce39fcb8c2db1b02461644eb81d), when KIO at lower version is used, we fallback to text file template M +7 -3 addons/filebrowser/katefilebrowser.cpp https://invent.kde.org/utilities/kate/commit/fc3c6ce28e63842316507effecfb887ee65987c0
*** Bug 479014 has been marked as a duplicate of this bug. ***