https://bugs.kde.org/show_bug.cgi?id=105459
Christoph Cullmann <cullm...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INTENTIONAL
Status|REOPENED |RESOLVED
--- Comment #10 from Christoph Cullmann <cullm...@kde.org> ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
