SUMMARY STEPS TO REPRODUCE 1. Open a txt file in folder ~/mydir/myfile.txt 2. Click, New, copy/paste text into new file. 3. Click save OBSERVED RESULT File defaults to ~/, not the existing folder ~/mydir/ EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
What would you expect if you have multiple files open? Using "the others path" is not transparent to the user in this case, or?
(In reply to Dominik Haumann from comment #1) > What would you expect if you have multiple files open? Using "the others > path" is not transparent to the user in this case, or? I expected the folder to be be previous open file's folder. If I had 10 open files, it would still be based on the previous tab I had open when I clicked "New". This would then follow the behaviour of other editors I believe, Visual Studio, EditPlus etc It is such a time cost to default to ~/ for us. Of course, could make it an option...
To complete jg's request, I also have "complaints" to share regarding Kate's default save directory: 1. Why not offer a "Default Save Directory" option users could customize to their will? I totally share jg's opinion: it can be a real pain having to start from the home directory (location decided by s.o. else than the user), over and over for each new file to save. For e.g. a major part of my text files are located on a dedicated disk partition. I would like to be offered (for each new file) to save in a given directory on that partition. 2. Why not offer a "Remember Last Save Location" option, that would override the "Default Save Directory" option I suggested at section 1., that users could check (radio button)? Some people prefer to have this kind of default save behaviour. 3. Another (additional) save option could be jg's suggestion: "Remember Last Opened File Directory", that would override options I suggested at sections 1. and 2., that users could check (radio button)? 4. I'm adding another wish, a bit different in nature, but still linked to new file "saving": please _bypass_ the "File Close Confirmation" dialog box, when a) file's _current_ content is empty (whether or not users had added some text at some point in the past) _and_ b) file has never been saved to disk. Explanation: I often use Kate as a _temporary_ text editing tool, to copy/paste/rearrange some text from application A to application B. The new file I created with Kate is not meant to be saved to disk. So once emptied by me, I would like to close this temporary file without having to _confirm_ that it shouldn't be saved to disk. This is for e.g. the default behaviour of Notepad++ (very practical). Please tell me if I should open a new bug (features request) for my suggestions. - If not needed, can we change Kate's version of this bug (403956) to version 19.12.3 (since my suggestions are not implemented in version 19.12.3 - I can't tell for sure about jg's initial suggestion)? And possibly rephrase bug's title to a more generic features request? - If recommended to open a new bug (features request), can KDE team do something about this bug (403956)? I mean, take a position regarding jg's suggestion, to avoid keeping this bug open for too long (as much as possible). Thank you very much for reading, I remain available for any subsequent steps I'd have to take (just tell me).
Addendum: it looks like my suggestion #3 ("Remember Last Save Location") has already been implemented (Kate 19.12.3). Good! However, having a related option in Kate's preferences ("Open/Save" section) would even be better. To allow users to check/uncheck this option.
Hi everyone, I can confirm that the OP's wish is now implemented in Kate 19.12.3. However, since my own additional suggestions/requests have not been answered yet (see comments 3 & 4), I've changed the Version field of this bug to value 19.12.3 (current LTS version I guess). Can someone from the KDE team tell me if I should open a new bug to handle my own wishes? And/or at least share his/her opinion regarding these wishes? Thank you in advance. If a new bug is needed, then bug 403956 should be closed I believe.
Yeah, this can probably be closed, and a new bug can be opened for requests for further refinement.