microsoft/vscode

Add read-only mode

Opened this issue ยท 229 comments

  • VSCode Version: 0.10.11
  • OS Version: Fedora 23, 64bit

Details:

  • Please add read-only mode and its keyboard shortcut.
  • It should be a switch. When turned on, opening new files will be in read-only mode.
  • It should be persistent across restarts.

This feature should be very useful for code reviewing. And I think it's not hard to implement.

Thank you,

I agree that a read-only mode that can be toggled would be super useful, though I would prefer it to be a temporary state, and apply just to the current open document. So maybe it could work as haibison says when applied at a folder level, but be a temporary state when applied at an individual file level?

For me, something like an "editor.action.ToggleReadOnly" shortcut would be great. That would disable edits, and prevent saving of the currently open file. Ideally it would have some sort of obvious visual indicator as well, so if it's toggled accidentally the user will understand why they can't make changes.

Thank you @coe-jeubanks

I often review code, so I think making that option persistent across restarts is useful. But you and other people might like it as a temporary switch. So my idea to dev team is maybe we could have an option to switch between "persistent" and "temporary" modes?

One scenario is when opening multiple files at a time: read-only option should be "remembered", or the code reviewer will have to manually mark those files read only one by one. It sounds simple, but I used to work with Geany -- which has read only mode. When doing so (opening multiple files, then switching to each tab to mark the file read-only), and doing so every day, it feels that a switch would help me a lot.

So when you're in "code review mode," you don't need to have any other files open for editing at the same time (taking notes, etc.)? That was why I thought a read-only at the folder level would work for you--you could put all of your files you are reviewing into one folder, and open that folder in Code, marking it (perhaps permanently) read-only. Then you'd still be able to create and save documents into other folders at the same time you are reviewing the read-only files. Below is a mock-up of what I mean. In my example, all of the folders except Notes are toggled to read-only, and you could individually set files in Notes temporarily to read-only if you want to review them. Yet you would still retain the ability to create and update other files in Notes.

vs_ro_mockup

My typical use for read-only is when I'm editing one file and need to have a second one open for comparison or reference, but I don't want to inadvertently make any changes to the reference file. I used to use UltraEdit, which has a toggle-able read-only option for an open file.

I do hope they can create an enhancement that meets both of our needs!

I also would like option of setting read-only for an open file to prevent changes.

Would really like this or something similar to it.
eg. #12227

A command line argument to optionally open each file(s) as read only would be nice.

Throwing my support in for a command line option to open a file as read only. Would be really handy for my workflow

I would also like this on a file level and persistent. Alternatively, it could be a temporary setting that I could set on an open file.

I want to set it on babel transpiled output files. I sometimes open these to check where errors in the browser occurred, but only want to edit the original source files. This option would stop me from forgetting and accidentally editing the transpiled output.

Other issues that requests this feature #33823 #17670

The editor has an option readOnly that would need to be exercised by the workbench => removing editor label.

This would be very helpful

I too would like to see a command line option to open a file as read-only:

My use case:

I use file manager tools (e.g. Total Commander) to navigate through source files and have a need for opening files for read-only to just view the code without accidentally changing the code.

I previously used Notepad++ for editing and viewing source code, and this worked perfectly because Notepad++ have a command line option to open the file as read-only.

I have since switched to VS Code as an editor, and I really miss the option to call VS Code from the file manager and have VS Code open the file as read-only.

I prefer to use VS Code instead of Notepad++ as I'm working on different platforms and can have VS Code on all my platforms, but the missing read-only option in VS Code forces me to still have Notepad++ as my code viewer when I'm on Windows.

When will this feature be available?

Another use-case: when viewing application log files, I do not wish to accidentally change a file.

I need read-only mode for code-workspace's root-folders.

opening files (or folders) as read-only would be a great addition I would get a lot of use out of.

Would love to see this. I'm currently using vscode for debugging and vim for editing and sometimes I get my alt-tabs mixed up and end up editing files in vscode accidentally.

I remember long long ago Visual Studio had this. You could simply right-mouse click in the editor and there was an option to set the file to read-only. Actually, it didn't even set the file on disk to read-only, it was just in the editor.

Would love to see this in Visual Studio Code.

This could be useful for when the user opens a system file via go to definition or the debugger, e.g., a file in an installed Ruby gem.

Any updates? Would love this ability.

I found this request while trying to figure out how to mark a file read-only in the editor. I had two files open, one for reference and one that I was editing. Naturally I wound up editing the reference file and not the one I intended. It would be very helpful to be able to open a file, right-click and set a read-only/no-edit option for the open document.

One simple scenario: In my node app code base, I navigate to node_module files a lot to read source code, but more than a few times that I found changing the files with mistaken finger typing. IntelliJ would make an alert for this. I'd like this feature available in vscode. Thank you very much.

I need readonly since I'm viewing a file's hexdump on VSCode but have to close out everytime I rerun it since two programs can't be writing to the same file.

Any updates on this feature?

I use Go language, and sometimes I would like to take a look at those built-in libraries. I need this feature to prevent modification on them. Any work on this will be appreciated.

I have looked far and wide for a solution to this! From a teacher standpoint, this feature is vital when demonstrating code on-screen with a range of 20-30 in-class students. Together with Visual Studio's Live Share, this feature is an absolute necessity!

+1 upvote for in-class setting

I would love this feature. I would want it to detect Unix file permissions and prevent the user from accidentally spending time editing files they don't have write permission for.

Are we there yet?

Is there any new state of update here?
I'm using a source control in the way of lock/edit and commit. In this way of source controlling it is very important to recognize which files are read-only to lock them up befor change anything.

At the moment I do not need to lock them to have the possibility to change something. Result is, that somtime this ends up into a merge procedure, which I actually try to prevent by the kind of source control i use.
I would be very pleased if this feature would be implemented.

For me, it mainly relates to my build output... I often peek at those files and it is all to easy to start editing the files, save, do a build, and overwrite my changes. From my perspective, it would be great to be able to list a file match pattern to treat as read only in the editor, e.g. dist-*/**

Adding a partial answer, see top answer here: https://stackoverflow.com/questions/30140112/how-do-i-hide-certain-files-from-the-sidebar-in-visual-studio-code files: exclude

Above is not a perfect solution but it does make me think hard if I want to open a built file, which is half the battle. But, it's disconcerting to not be able to see my built files easily.

@fischeme

easy to start editing the files, save, do a build, and overwrite my changes.

That's exactly my use case. Hiding them won't work because I want to debug with the built files, setting breakpoints and making use of the line numbers in error output. Several times I've accidentally edited the built files, only to have to copy the changes back to my source or just rewrite them.

I added a chmod command to my build script to prevent me from saving the changes and forgetting about it entirely, and I even installed a plugin to display a file's permissions in the status bar. But it still lets you type, and info in the status bar isn't exactly conspicuous.

So many use cases more than mine :D.
In my case, I would like to edit a file while having few other files opened to refer from. Would love to have those reference files open in read-only mode.
Any extensions that allow this? Did a quick search and couldn't find any on Marketplace

ldong commented

Not sure about windows users, but for Mac and Linux users. You could try the following:

cd my-project
chmod -R -w my-project # making it readonly
code my-project

Now VSCode would do something like this.

image

Of course, you can always change files permissions, later.

Cheers!

@ldong That notification is helpful when accidentally attempting to save. Many (myself included) might prefer that writing in the editor immediately triggers feedback if the user ultimately won't be able to save anyway. But I also wouldn't want to discard the current behavior for those that prefer that (allow changes until the user attempts to save, then notify).

Maybe we break it down into two features:

  1. A "read-only" flag for each editor tab, to be set via the methods suggested in this thread (file explorer context menu, "code review mode" global toggle, commands, command line arguments, inference from file permissions, files listed in settings.json, ...)

  2. Control over how read-only editors behave. (notify on save, notify on change, ignore input outright, ...)

There's something like a read-only flag in VSCode already: when the settings.json editor is open, the "Default User Settings" alongside it will ignore input and display a small message near the cursor: "Cannot edit in read-only editor". But (unless I'm missing something) there's no way for users to employ that behavior in other editors.

Another use-case: when viewing application log files, I do not wish to accidentally change a file.

up!

I really need this.
Both detection of an os level set read-only and the possibility to toggle it if possible,
but especially a user set read only flag that don't set the actual os level read-only flag but only the current editor buffer or what it's called in vscode terms ( Notepad++ style: "Main Menu->Edit->Set Read-Only", Emacs style: M-x read-only-mode), for reviewing log files, 3rd. party code, configuration files, etc... I.e. files that I don't want to edit directly, but have to be writable for external tools invoked by me.
And a command line option for the current editor buffer version would be a blessing too.

I really need this for code review

It would be nice to have this feature for vendor and node_modules directory. In order to view the implementation of framework methods/classes. Right now I'm using chmod to modify the bits to remove write access.

echo "This script makes vendor read only for all users, even the owner";

find $(PWD) -type d -exec chmod 0551 {} \;
find $(PWD) -type f -exec chmod 0444 {} \;

ojde commented

I would appreciate this feature greatly, too.

xuto2 commented

The same here - it would be much helpful when we want to check existing code without changing them by accident

Throwing my support in for a command line option to open a file as read only. Would be really handy for my workflow

I agree. Would really like a command line option for read only.

I am looking forward to this API.

Because there are some files, we don't want users to modify it, such as node_modules.

With this API, we can set it to read-only by extension.

This should improve the user experience

I would appreciate this feature greatly, too. Any update?

Does anyone think there's a way of doing this with extension. Is there a way to make an editor 'read-only' via the extension API? Or perhaps blocking a save?

I admit I haven't read all the comments above, as a potential option to earlier remarks, would it be an option to enable read-only on a file-by-file (and diredtory-by-directory too) level, but also have a setting to enable it as 'read-only by default' or 'read-write by default' ?

Therefore if I typically want to make one file read-only (or 'lock it' - maybe could involve VCS too), so I don't accidentally make changes to the wrong file, I leave the option as read-write by default, and lock one file or a directory as I need it. For the others above who would like a persistent setting for code review, they have read-only by default, and need to unlock any files they would like to edit before being allowed to change them.

I would love to have this feature as well (and I like the command line argument option)
In my company, we'd like to use vscode to open python files in read-only mode without the possibility to "overwrite" it, so our linters would run and we can quickly review a python file without changing it by mistake.
Also, this seems to already be available in vscode, for example when you "> Open Default Settings (JSON)", if you try to type anything, nothing happens but a popup showing up next to the cursor telling you you can't edit the file.

I also would like a read-only mode for the same reasons others have mentioned above.

This would be great for those who takes a lot of time reading code, to avoid writing by mistake.

I like the idea of a workspace configuration as in #12227. My main use case is that I will be providing multi-part documents with content spread over multiple files. Some of these files should be directly editable by clients but others should only be editable by automated processes (including VSCode extensions). Managing this through OS permissions is a pain, particularly since it has to run on multiple OS's and be manageable in the field by non-programmers. (I can't just hide the non-editable files, because they need to be available for viewing.)

For my use-case, which is the Flutter SDK, I can't set it read-only on the OS as it needs to be updated by me periodically through git.

My use case: I want to use github flow, which means I should not edit files in master branch, but should be able to merge branches into master. I am not talking about making files in the disc readonly. This should be in the vscode.

Here is my use case:

In the repository I work on, I need to perform many postgres isolation tests while reading the output of these tests through the vscode, and postgres test suite basically needs a temporary cluster directory within that repository to perform those tests. But, as I guess, as vscode locks the directories againt writes, my tests isolation tests fail due to "permission denied".

I use this in emacs all the time (toggle-read-only-mode, bound to F1). With gigantic ass screens it's easy to forget what has the keyboard focus, think it's somewhere else, start typing and then realize, "oops, I'm typing into an open code buffer". By keeping all buffers read only by default unless I actually am typing in them, I avoid this hazard.

VSCode Editor already have a readOnly option which is cool. Although, is there a way to open an editor in readOnly from an extension? I see we have several methods to open documents and editors from a Document, but none of those let you open an Editor in read-only.

vscode.workspace.openTextDocument
vscode.window.showTextDocument

A command to toggle all open editors to read-only and all new open editors as read-only would be a very nice feature.

Hello @nmorenor, you stated VSCode Editor already have a readOnly option which is cool. How do you actuate that option?

Hello @nmorenor, you stated VSCode Editor already have a readOnly option which is cool. How do you actuate that option?

@edburns: I think what @nmorenor refers to is what @alexdima mentions in the comment on PR 82748, though how to implement it (in an extension or a PR), I, right now, consider beyond my skill level. But maybe this could be an opening for someone with the knowledge to come up with something that could be approved?

ctf0 commented

+1
This is a much-desired feature for me too. Here is my use case: I often open several boilerplate repositories in a workspace to refer to while I code new services. It would be great to have a switch to make these folders areas only.

Stumbled on this and I think there still isn't a practical way to achieve this yet. I still don't know what readOnly setting meant by @alexdima @nmorenor.

At some point on this thread, I read #82748 and @alexdima said vscode already has a readOnly option.

I opened the mentioned link that lead me to editorOptions.ts. I noticed minimap and mouseStyle are one of the symbols written there, then I thought I should try auto-complete typing them (for example "editor.minimap" or "editor.mouseStyle") from the vscode's settings.json, and they all seemed to work successfully with the exception of readOnly. "editor.readOnly" did not auto-complete despite readOnly mentioned there. I tried just writing "editor.readOnly": true anyway, still unsuccessful.

I am still unaware of any practical way to achieve this. It would be really nice if vscode has this read-only switch that can be toggled on a working file

I want to carefully review log textfiles without accidentally overwriting them because they may be in the middle of being written. So I made a secondary guest account, then just right click > Properties > Security (on Windows 10), then made this account not have a write permission over the directory containing the log files

This would be nice to have when I'm making edits to code files on two machines, minor edits via command line (SSH) and major edits from my desktop.

  1. I'd commit the file, push it to git, then set it read only on my desktop,
  2. Clone it on the remote machine, try and run it, while leaving the full file open on my desktop for reference.
  3. If it needs minor adjustment, edit it using lighter tools on the remote machine, then commit / push back to git
  4. Set read/write on my desktop, repeat the cycle

So do I understand correctly that there is still not "read-only" switch for a file that is currently open in the VS Code editor?

@haimat not that I know of, no

Yes, this really bothers me. I can't tell you the number of times I didn't know where the keyboard focus was, started typing, and was horrified to see I was changing code. Of course, you can Undo, but in Emacs I bind F1 to "toggle-read-only" and keep it on unless I am actively editing the buffer.

As mentioned above, Geany has this feature and it works really well for the outlined scenarios and can be the deciding factor for using Geany over VSCode in a given situation.
It would be great to add this to VSCode and, perhaps, extend the functionality to pinned tabs.

My use case: I want to ensure that some of my files should only be created and re-created by running a script (for instance npm run generateFoo), and never modified manually. I hope to set these rules in the .vscode folder.

A longtime follower of this issue here.
Just gonna shoot some bullets of frustration:

  • This has been on the backlog since -->2 april 2016<--.
  • A PR, Added toggle read-only mode (Alt + Shift +R) #82748, that actually worked at the time, was shot down in flames. (Ok,- that's an overstatement, and please don't click if you don't like good music :-) )
  • As I understand it (I'm probably wrong so please do enlighten me), the promising internal readOnly option in editorOptions.ts is not exposed to the api and therefore not available to extensions developers, hence the request can't be fulfilled with an extension?

Anyone got some ideas what the technical and "political" blockers are for this request (read-only mode)?

I just needed this feature too, but it seems it is implemented ? To stay on context we create our own Extensions with a custom Filesystem Provider.

Anyway i just want to log out some messages, first try was createOutputChannel it is working but i cant delete it manually it seems only dismiss and this is not what i want and more important i need multiple of them.

Second try was now create a virtualFile.

TextDocumentContentProvider

/** output channel is nice but ... we cant close it only dismiss (sucks) */
class LogView implements vscode.TextDocumentContentProvider {
    provideTextDocumentContent(): vscode.ProviderResult<string> {
        return `lets go`;
    }
}
vscode.workspace.registerTextDocumentContentProvider("vsqlik-out", new LogView())

load the virtual file

const file = vscode.Uri.parse('vsqlik-out:' + app.name);
const doc  = await vscode.workspace.openTextDocument(file);
await vscode.window.showTextDocument(doc, {preview: false, preserveFocus: true})

And this virtual file, i cant edit or save this is readonly. For me this will works, for a real file system maybe a bit of overkill.

Started working on this today, and I'm nearly done, just working on smoothing out the last few kinks. My commit is here if anyone wants to test it out or suggest a fix for the problem I'll outline below.

I've pretty much refactored @holeguma's PR to use the already implemented readOnly setting and added a command in the Command Palette. A recording of it in action is here:

NNeGKbk1L3

If you didn't catch the problem in the recording, the issue is when turning Read Only mode on/off through the Command Palette, it doesn't seem to update until you change to a new editor. I'm not quite sure how to fix this, I'll look into it more but if anyone can figure out how to update it smoothly, please let me know.

@sneakyfish5 Great job ๐Ÿ‘

One more thing. Is there any event that the user tries to modify the read-only editor?

eg. vendor/node_modules folder, this should be readonly.

But if the user also needs to modify, there should be an event triggered, then extensions can set readonly to false.

But if the user also needs to modify, there should be an event triggered, then extensions can set readonly to false.

I'm not familiar with how vscode extensions work, but I had to "register" the editor.readOnly setting, so now it can be changed to true/false in your settings.json file to enable/disable Read Only mode.

Finally fixed the issue I mentioned above, here's a recording of the finished product:

BclTZH7HVC

Before I go ahead and open the PR, does everything look good? If there's any sort of issue, please let me know. Commit is here in case anyone wants to download my fork and test it out.

@sneakyfish5 ๐Ÿ‘ ๐Ÿ‘ ๐Ÿ‘
I've forked it, but haven't had time to dig into it yet. (high priority on my todo list ๐Ÿ˜ƒ )

OT: FYI - Had to delete my fork of vscode to fork the fork on github otherwise I was just presented with my own vscode fork. Thought that would be automated by github? Anyway, I imagine it would be easier with a fork of your fork for later collaboration. ( Whoa, that was a lot of fork fork fork fork ๐ŸŽถ - To the tune of Monty Pythons Spam Spam Spam Spam ๐Ÿคช )
Ok - Have to fork of now ๐Ÿ˜ great work

Couple suggestions if you haven't already put it in; even having it in the command palette only is great, though. Thanks!

  • Read only folder (open a whole folder as read only)
  • Read only file+Open
  • Right click on tab and set read only like Notepad++

I get the feeling that only the command palette is easily edited, but I figure I'd mention it anyway (I haven't really looked at the VSCode source and TS / JS isn't my best language).

@amelvill-umich I'm not familiar enough with the vscode source to make that change unfortunately. However if my PR does get merged, I'll definitely look into it.

@sneakyfish5 - Just had some thoughts for when you make the PR. One of the criticism of @holeguma's PR was that his, quote: "... approach seems to touch a lot of editor areas, from the editor core to the snippet controller...", so if your PR does not get merged, maybe a fallback plan/alternative strategy would be to focus on making a, if possible, less invasive PR that enables extension developers to deliver the readOnly functionality. Even if that also would be rejected, I'm speculating, it would be easier to maintain an updated fork in sync with the upstream, and have a relative independent ReadOnly extension to provide the functionality.
But that's all talk and no action from me. Have to yet dig into the code to understand the complexity of the problem (I'm no JS/TS vscode extension ninja either) and I got this feeling my head might explode, hence the procrastination (which is an actual expertise of mine :-) )

Just had some thoughts for when you make the PR. One of the criticism of @holeguma's PR was that his, quote: "... approach seems to touch a lot of editor areas, from the editor core to the snippet controller..."

That is the main thing I kept in mind when reworking @holeguma's PR. I also made sure to stick to what @alexdima said in the PR which was that "there should be no changes inside src/vs/editor since the code editor already supports read only." The only place where I touched src/vs/editor code was one line, which was to register editor.readOnly as a setting, so as to make a command in the command palette for it. As for extension APIs, I feel like the PR I'm about to open has more of a chance of being merged than any change to the extension API, let alone me not being familiar enough with them to change it.

hence the procrastination (which is an actual expertise of mine :-)

Seems we have that in common ๐Ÿ˜„. Since you were willing to test it out and offer feedback, I'm waiting until that happens before opening the PR to make sure I didn't mess anything up. Please take your time though, after 4 years of this issue being open, I'm positive extra time to make sure it works correctly is a price easily paid.

This is great. For completeness, can you please confirm the toggle read only can be bound to a function key? If so, how can you do it?

Can you also make a setting to open all files as read-only by default?

This is great. For completeness, can you please confirm the toggle read only can be bound to a function key? If so, how can you do it?

Yup, you can bind it to any key via the keyboard shortcuts menu.

Can you also make a setting to open all files as read-only by default?

Yes, this will be possible by setting the editor.readOnly setting to true.

when will this "readonly" mode be released ?

Couple of ideas relating to this I didn't see mentioned (though I may have missed it):

  • It would be great to have a persistent way to set the default read-only status on a per filetype basis (both at the global level, and at the project level). For example, one could set all *.log files to be read-only.

  • I'd love to see a ๐Ÿšซ icon to indicate read-only status in an open (& read only) file's tab, either between the filetype icon and the filename, or perhaps even overlaid on top of the filetype icon (which might be more useful for pinned read-only files). It could be overlaid either at full size, or as a micro icon in the bottom-right of the filetype icon.

  • It might also make sense to force editor.cursorBlinking (which I presume most people have set to one of the animated options) to be solid for read-only files.

  • In case it gets overlooked somehow, read-only files definitely need to retain the ability to have code selected and copied from them. Perhaps even an option where just selecting code also copies it in read-only files.

Relevant LSP issue: microsoft/language-server-protocol#1150

This is a big problem with rust-analyzer where "go to definition" can open up source files in the standard library and accidentally allow edits.

Relevant LSP issue: microsoft/language-server-protocol#1150

This is a big problem with rust-analyzer where "go to definition" can open up source files in the standard library and accidentally allow edits.

Same with modules in node_modules. You go to a definition in the JavaScript code and the module is open for write access.

Also looking to have readonly files.

For example, I'd like to generate a document on the fly that would be readonly:

const textDoc = await vscode.workspace.openTextDocument({language: `text`, content: resultDoc, readonly: true});
const editor = await vscode.window.showTextDocument(textDoc);

It's been five years

It's been five years

Indeed it has. I just accidentally changed a file yesterday that I would have marked Read Only if I could have. No damage done as I undid it all but I wondered why some of my edits did not work only to see I edited the wrong file ๐Ÿ™„

https://code.visualstudio.com/updates/v1_57#_enable-file-system-providers-to-declare-a-file-as-readonly mentions new proposed API that came in 1.57 which may be a step towards this.

@gjsjohnmurray @Whobeu

No, No, No. I think the read-only mode is like this, just preview the code instead of changing the file to read-only mode.

Similar functions such as previewing markdown files, The editing function of the editor should close, The pointer should lose focus, And the virtual keyboard should not automatically pop up.

image

@jianboy

... The pointer should lose focus ...

I would actually welcome an option where the pointer/cursor kept focus for easier marking and coping of text with the keyboard and other typical review and search operations on a readonly text (You know, rodent free operations :-)). Otherwise agree.

@jianboy

... The pointer should lose focus ...

I would actually welcome an option where the pointer/cursor kept focus for easier marking and coping of text

The main reason I usually open a document I really do not want to edit is so I can select and copy text from it. Having to type the text in the document I want to edit would be time consuming. Definitely need to have a cursor and the select/copy capability.

For my particular workflow, I agree with the idea that the behavior of an editor being marked "read only" should be identical to that of other editors, except that it should refuse any input which would alter the buffer in any way, perhaps by issuing a plaintive 'beep'. Even a toast notification might be too much. Perhaps flash the background color with a red "read only" overlay for a moment.

The key point I am trying to make is that accidentally brushing my hand over the keyboard while a "read only" editor has focus would be an annoying experience if I had to reach for my mouse or whatever in order to dismiss a dialog which was informing me of what I already knew, namely that the editor was in "read only" mode.

I totally agree with the phrase "disable input instead of modifying file attributes", which is what I interpret the text in @jianboy 's illustration to mean.

Whether or not there are other use cases which would benefit from a "read only" editor from refusing focus at all is not something I have not put a lot of thought into. Perhaps there is. However, there are views in VSCode in which I am annoyed that I cannot use selection and/or copy/paste, such as the "Welcome" screen, and the "Release Notes" page. (I can't even right click to do 'view source').

@AltitudeApps

... However, there are views in VSCode in which I am annoyed that I cannot use selection and/or copy/paste, such as the "Welcome" screen, and the "Release Notes" page. (I can't even right click to do 'view source').

Pretty much represent my attitude on the subject (+ I really want to be able to navigate read-only text without the rat mouse).

==================================

As a developer, The cursor lost focus which means that the editing window is just a div(html)/panel(C#),

The cursor kept focus which means that the editing window is a Input Box(html)/EditText(C#).

With this understanding, it's easy to achieve.

In read-only mode, we change the state of the editor, not the state of the file!!

when VSCode editing windows lost focus it also can copy code.

image

I give a very simple example:

image

Let me emphasize, In read-only mode, we change the state of the editor, not the state of the file!!

==================================

I was thinking, having a setting like described at #12227 would work better for many use cases, rather than the ability to temporarily switch on the read-only mode. The main use case I have in mind is, marking build folders and auto generated files as read-only in a workspace.

I have an idea of what to do and I can work on a PR. Would VSCode team accept it?

Additional use case would be nice separation of states for the modal editing extensions. They provide the normal/visual and insert modes, which could be nicely mapped to read-only and editable states.

@jianboy wrote:

when VSCode editing windows lost focus it also can copy code.

Yes, with the mouse, but, to me, keeping the cursor around at text of interest is the important thing in the process of reviewing code and logs, with the possibility to mark and copy those parts. Unfocused text with a visible cursor is usually not (well, I've never seen it) supported by any widget api's.

Would be great if this read-only mode had a time-out setting, e.g. if I left my desk for more than 10 minutes the editor would lock my files and a password or at least a combination of input is required to unlock.

Would be great if this read-only mode had a time-out setting, e.g. if I left my desk for more than 10 minutes the editor would lock my files and a password or at least a combination of input is required to unlock.

That's really the OS' job, put a locking screen saver on your computer and you're done.

I really liked Geany's read-only mode, the editor tab was green, cursor and everything functional but you couldn't make changes. Simple and effective.

Would be great if this read-only mode had a time-out setting, e.g. if I left my desk for more than 10 minutes the editor would lock my files and a password or at least a combination of input is required to unlock.

That's really the OS' job, put a locking screen saver on your computer and you're done.

I really liked Geany's read-only mode, the editor tab was green, cursor and everything functional but you couldn't make changes. Simple and effective.

I agree, maybe we can leave it to an extension