Add read-only mode

[ghost]

• 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,

[coe-jeubanks]

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.

[ghost]

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.

[coe-jeubanks]

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.

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!

[Bill-Stewart]

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

[alexdima]

fyi @bpasero

[rmchndrng]

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

[davenport]

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

[ianelletson]

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

[gillez]

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.

[IanEdington]

Other issues that requests this feature #33823 #17670

[alexdima]

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

[cossio]

This would be very helpful

[chrjorgensen]

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.

[ice1000]

When will this feature be available?

[NorthboundTrain]

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

[boozook]

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

[glaisne]

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

[EverettBerry]

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.

[zethon]

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.

[castwide]

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.

[bersbersbers]

I ask people here to try it out and provide feedback

Very well! I tried Insiders, I immediatly liked the feature and will use it the second it somes out in stable. I have four points of feedback:

• Why is files.readonlyInclude a dict[str, bool] (in Python terminology) and not a list[str]?
• Typing files.exclude: { "**/*": true } in a .code-workspace file and saving immediately locks the user out of that file, meaning they will have to open another editor to undo that change. Not sure if there is any way (or even need) to improve UX here.
• In a multi-root workspace (using a .code-workspace file), I cannot seem to find the right glob pattern to mark only one of the roots read-only. I think I had the same struggles before with files.exclude and search.exclude: I often add a couple of network drives to my workspaces for easy navigation that I want to navigate, read-only. I tried glob patterns based on absolute paths (which do not seem to work at all) and relative ones, which seem to be relative to any of the roots of a multi-root workspace. (Except maybe **/*, which locks files even outside the current workspace.)
• Finally, I would appreciate that if I set a folder to read-only, I cannot add or remove files from it. It is rather unexpected to not even be able to type in a file (because it's read-only - although many editors allow you to edit a read-only file, just not so save it*) but then to be able to delete it in the explorer view.

(*) Don't get me wrong, I like the fact that a read-only file cannot be edited. It just creates the impression that VS Code really makes sure that file cannot be manipulated, which is not compatible with being able to delete it.

[bpasero]

@heartacker

we need a button that can make current workspace read-only casually while precenting

To clarify, a button that turns the workspace read-only just for the session? Without changing the configured settings?

@bersbersbers

Why is files.readonlyInclude a dict[str, bool]

Due to settings hierarchy: dict gets merged, array gets replaced. Using an array makes it hard to configure on a workspace level when a user level is defined.

Typing files.exclude: { "**/*": true } in a .code-workspace file and saving immediately locks the user out of that file

The commands to toggle readonly should help, but we should probably not apply the setting on the workspace file.

In a multi-root workspace (using a .code-workspace file), I cannot seem to find the right glob pattern to mark only one of the roots read-only

You can always use the absolute path? But I agree, there is no way to target a specific folder from within a code workspace. I think this is unrelated to this feature here though, but more general.

Finally, I would appreciate that if I set a folder to read-only, I cannot add or remove files from it.

Jack and me had the discussion and I thought in the beginning we limit this to editors. But adopting it for explorer would be relatively easy. To clarify: this would only block the VS Code explorer, but e.g. not the integrated terminal?

[heartacker]

we need a button that can make current workspace read-only casually while precenting

To clarify, a button that turns the workspace read-only just for the session? Without changing the configured settings?

great.

[gjsjohnmurray]

Re the multi-root point, #127790 (comment) from @roblourens shows a syntax that can be used in Search to target a specific root. Maybe it could be implemented here too.

[bpasero]

I think that only works from the search viewlet. If I understand the request correctly, the problem is that if you use the settings node in a .code-workspace file, it is hard to formulate a relative glob pattern that targets one of the roots exclusively because each pattern gets executed over all root folders.

I had discussions about this with others from the team in the past, even in the context of #45177 and I think what is missing is some variable you can use as part of the glob pattern to point to one of the entries in the workspace file. If someone has good ideas how to do that, we can have a discussion in a separate issue.

[bpasero]

@heartacker is that a common scenario though, couldnt you just ad-hoc change the setting for this?

[bersbersbers]

@bersbersbers

Why is files.readonlyInclude a dict[str, bool]

Due to settings hierarchy

Understood, thanks!

Typing files.readonlyInclude: { "**/*": true } in a .code-workspace file and saving immediately locks the user out of that file

The commands to toggle readonly should help, but we should probably not apply the setting on the workspace file.

Oh, you are right. I had tried "Reset Active Editor Readonly", which does not work. Toggle is working!

In a multi-root workspace (using a .code-workspace file), I cannot seem to find the right glob pattern to mark only one of the roots read-only

You can always use the absolute path?

I tried it multiple times, inconclusively. Maybe I stumbled across a bug, as I noticed the following for this bug.code-workspace file:

{
    "folders": [
        {
            "name": "foo",
            "path": "C:/L1/L2/L3/L4",
            // file is "C:\L1\L2\L3\L4\name.ext"
        },
    ],
    "settings": {
        "files.readonlyInclude": {
            "C:/L1/L2/**/*": true,
            "**/L4/**/*.ext": true,
        }
    }
}

When both include lines are active, name.ext is indeed readonly. But if I comment either of the lines, the file stops being readonly. I may be doing it wrong, but I would have expected each of both lines alone to make the file readonly.

But I agree, there is no way to target a specific folder from within a code workspace. I think this is unrelated to this feature here though, but more general.

Yes (as mentioned. same with search.exclude).

If I understand the request correctly, the problem is that if you use the settings node in a .code-workspace file, it is hard to formulate a relative glob pattern that targets one of the roots exclusively because each pattern gets executed over all root folders.

Your understanding is correct, and #127790 (comment) is not working here.

Finally, I would appreciate that if I set a folder to read-only, I cannot add or remove files from it.

Jack and me had the discussion and I thought in the beginning we limit this to editors. But adopting it for explorer would be relatively easy. To clarify: this would only block the VS Code explorer, but e.g. not the integrated terminal?

I can only speak for my own expectations, but yes - I would expect the folder to be write/delete-protected from the VS Code Explorer, but not necessarily from the terminal. I would be positively surprised if deleting was blocked from the terminal; but since I believe I have a rough idea how difficult it is to make a file (or thousands of files) readonly for terminal operations inside VS Code (but not the same terminal operation outside VS Code, for example), I would not expect that at all.

[bpasero]

When both include lines are active, name.ext is indeed readonly. But if I comment either of the lines, the file stops being readonly. I may be doing it wrong, but I would have expected each of both lines alone to make the file readonly.

Are you sure the setting is correctly applied? Can you open the settings editor and go to the workspace tab to find the value of the setting matches what you edited in the file? I also think both patterns should individually match on that path.

[bersbersbers]

Are you sure the setting is correctly applied?

I would say yes (also note the lock icon)

Lock icon missing:

[bpasero]

Can you try this from a normal folder configuring this as a normal setting to see if it is at all related to multi root workspaces?

[bersbersbers]

Can you try this from a normal folder configuring this as a normal setting to see if it is at all related to multi root workspaces?

Good idea. I moved "files.readonlyInclude" to user settings. Then:

• Exact same behavior when opening L4 as a folder. (Each line alone does not make the file readonly, both together do work.)
• Different behavior when opening just the text file in a non-folder VS Code session. "**/L4/**/*.ext" works alone and in combination with "C:/L1/L2/**/*"; "C:/L1/L2/**/*" alone does not work.

[bpasero]

Thanks I can somewhat reproduce but cannot yet explain why that is. I suspect some kind of bug in our matcher around this 🤔

[bpasero]

Oh, I see what is going on. I had forgotten a fact that we even document here:

The glob patterns in these settings are always evaluated relative to the path of the workspace folder.

So when you open the folder L4 and open the file name.ext, the glob pattern will not match if itself contains L4. If you really want to match on full paths, you should rather use the absolute path of the folder and not the glob pattern. I think our reasoning is that it is much easier to formulate glob patterns relative to the workspace because then you can reuse them more easily.

[bpasero]

Oh, there is still a detail that maybe we can improve on: your other pattern C:/L1/L2/**/* does not match because matching is case sensitive and we pass in a lowercase path c:\L1\L2\L3\L4\name.ext. Good catch!!

[bersbersbers]

Thanks for the analysis! (I think you explained why each of the lines on their own does not work, and I still don't get why the combination works, but that's of less importance to me.)

So what works for me is

"files.readonlyInclude": {
    "c:/**/*": true,
}

Is that what you mean by "absolute path"? I am asking because for "absolute path", I had tried c: and c:/ and even c:/*, none of which worked. I am fine with c:/**/*, but it feels like a glob pattern (if only due to the **) :)

matching is case sensitive

That kind of thing is surprisingly frequent, compare also microsoft/vscode-pylint#332

[jackpunt]

Is that what you mean by "absolute path"?

Yes... it's always a Glob Pattern, but the pattern starts with a [absolute] 'c:/...' rather than a [workspace-relative] '...'
(Or in mac/linux [absolute] starts with a '/', I suppose);
also, IIRC a URL scheme name is not currently considered/matched, just the 'path'.

[bpasero]

We have #10633 for allowing case insensitive glob matching. I would argue for file path matching esp. on Windows and macOS, it should be case insensitive always. But we did not conclude in our discussions there.

An absolute glob or path is a glob or path that begins with a drive letter (Windows) or slash (Posix).

Btw PR #182224 is ready to be merged to:

• do not turn workspace files readonly
• let the file explorer respect the setting
• explain the settings a bit better

[bpasero]

I am going ahead and close this issue. Please file new issues for bugs and missing feature requests as you see fit.

[tjx666]

Seems my extension can be marked depracted: https://github.com/tjx666/modify-file-warning

[newbie01github]

still no READ ONLY :(

[gjsjohnmurray]

@newbie01github unless you are using the Insiders build of VS Code you'll need to wait until 1.79 ships next month.

[bpasero]

You can give our preview releases a try from: https://code.visualstudio.com/insiders/