Version: 3.2 (using KDE KDE 3.4.0) Installed from: Compiled From Sources Compiler: gcc-3.2.3 OS: Linux IMHO it would make sense if the "Tools -> Read Only Mode" gets activated when opening a file that is in fact read only. Otherwise it is possible that you first realize the write protection after 15 minutes of precious work. There are certainly some users out there who would like that kind of self-protection :-) This behavior should at least be configurable.
this should be done by kate in fact.
Created attachment 29039 [details] Patch for the wish above mentioned.. Checks a file for write permission and warns the user if it is not writable. It locks the editor in read only mode. The user can unlock it from the Tools Menu.
*** Bug 154896 has been marked as a duplicate of this bug. ***
*** Bug 111493 has been marked as a duplicate of this bug. ***
I dislike that a lot. Normally, I want to type stuff and if it is read-only, I can still change where to save the file or make it read-write per konsole/save-dialog. This is just annoying behaviour if kate doesn't allow to type only because you can't save the file there.
This annoyed me today (17 years later). If it can't just be the default, please at least consider making it a setting.
I don't think this is likely to get fixed. The argument that you realize some time later that the file is read only is not true. The work is not lost, you can still save it in many ways including copy pasting and save as etc. Further more, it will likely clash with the feature where we ask the user for password on Save if the file is read only. Thus I think we can close this.
Yeah, I am not sure how helpful this is, either. You can save the file with a different file name, you can just want to type stuff there and not even save ever. To auto make such files read-only will just be extra effort for a lot of people that then need to make it read-write again.
> The argument that you realize some time later that the file is read only is > not true. The work is not lost, you can still save it in many ways including > copy pasting and save as etc. The patch does something unnecessary (loud warning about read-only). This is not what is being asked for. The important part of the patch is the part that enables read-only mode for read-only files. It is a matter of correct behavior. If the file is read-only, then the editor opens it in read-only mode, and this can be overridden as needed. Dealing with read-only headers and read-only documentation gets very tiring as they get unintentionally edited simply because the editor refuses to honor read-only file permissions. We already have a read-only mode. Editing a read-only file in the fixed scenario, where read-only mode gets auto-enabled, would be as easy as disabling read-only mode. And we would still be able to save these files, the same way we already do. It is not by chance this bug has so many duplicates: This is the expected behavior.
(In reply to Roc Vallès from comment #9) > > The argument that you realize some time later that the file is read only is > > not true. The work is not lost, you can still save it in many ways including > > copy pasting and save as etc. > > The patch does something unnecessary (loud warning about read-only). This is > not what is being asked for. The important part of the patch is the part > that enables read-only mode for read-only files. > > It is a matter of correct behavior. If the file is read-only, then the > editor opens it in read-only mode, and this can be overridden as needed. > Dealing with read-only headers and read-only documentation gets very tiring > as they get unintentionally edited simply because the editor refuses to > honor read-only file permissions. > > We already have a read-only mode. Editing a read-only file in the fixed > scenario, where read-only mode gets auto-enabled, would be as easy as > disabling read-only mode. And we would still be able to save these files, > the same way we already do. > > It is not by chance this bug has so many duplicates: This is the expected > behavior. As said, it creates additional work for people that want to edit the files, even without a warning. Without any hint, it will even be more confusing. Why shall I not write into that buffer? And no, it is not expected behavior. Other editors like "Visual Studio Code" behave exactly like we do. Naturally not all behave that way, Emacs for example seems to go to some read-only mode. But if I want to follow an example, then rather that of a modern GUI editor.
> Without any hint, it will even be more confusing. > Why shall I not write into that buffer? All I am reading is that adding such a hint would resolve any possible confusion. Which is, in any event, a separate issue. Read-only mode does already exist, so this issue does already exist. It would just become more prominent as we'd see read-only mode enabled more often. That's about it from me; Annoying as this issue is, it is not a hill worth dying on.
(In reply to Roc Vallès from comment #11) > > Without any hint, it will even be more confusing. > > Why shall I not write into that buffer? > > All I am reading is that adding such a hint would resolve any possible > confusion. > > Which is, in any event, a separate issue. > > Read-only mode does already exist, so this issue does already exist. It > would just become more prominent as we'd see read-only mode enabled more > often. > > That's about it from me; Annoying as this issue is, it is not a hill worth > dying on. Yeah, we have read-only mode, but actually more or less only because that was required to be an read-only component. We use that normally nowhere automatically. And as said, the current behavior is consistent with what other popular editors do, therefore I fail to see why we should alter this.