microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.9k stars 29.52k forks source link

Add read-only mode #4873

Closed ghost closed 1 year ago

ghost commented 8 years ago

Details:

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

Thank you,

oaltun commented 5 years ago

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.

onurctirtir commented 5 years ago

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".

edburns commented 4 years ago

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.

nmorenor commented 4 years ago

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.

edburns commented 4 years ago

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

henrik-jensen commented 4 years ago

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 4 years ago

i think this could be done via ext using registerFileSystemProvider , also check https://github.com/alefragnani/vscode-read-only-indicator

rahulnyk commented 4 years ago

+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.

benjdewantara commented 4 years ago

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 https://github.com/microsoft/vscode/pull/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

amelvill-umich commented 4 years ago

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
haimat commented 4 years ago

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?

amelvill-umich commented 4 years ago

@haimat not that I know of, no

edburns commented 4 years ago

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.

chaeronius commented 4 years ago

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.

ZYinMD commented 4 years ago

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.

henrik-jensen commented 4 years ago

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

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

r-hannuschka commented 4 years ago

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.

jmannanc commented 4 years ago

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.

axetroy commented 4 years ago

@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.

jmannanc commented 4 years ago

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.

jmannanc commented 4 years ago

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.

henrik-jensen commented 4 years ago

@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

amelvill-umich commented 4 years ago

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

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).

jmannanc commented 4 years ago

@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.

henrik-jensen commented 4 years ago

@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 :-) )

jmannanc commented 4 years ago

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.

edburns commented 4 years ago

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?

edburns commented 4 years ago

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

jmannanc commented 4 years ago

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.

chrjorgensen commented 4 years ago

Will the solution also support a command line option? This was my main wish

I hope your PR will be accepted - keep up the good work! :-)

Den ons. 2. sep. 2020 kl. 05.37 skrev Jonathan Mannancheril < notifications@github.com>:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/4873#issuecomment-685270945, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFI7QBBDXSBMPZ2VTIND6LSDW4XJANCNFSM4B7YOQPQ .

OliverwengFiltered commented 4 years ago

when will this "readonly" mode be released ?

proimage commented 4 years ago

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

kjeremy commented 3 years ago

Relevant LSP issue: https://github.com/microsoft/language-server-protocol/issues/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.

Whobeu commented 3 years ago

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.

worksofliam commented 3 years ago

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);
jianboy commented 3 years ago

It's been five years

Whobeu commented 3 years ago

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 🙄

gjsjohnmurray commented 3 years ago

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.

jianboy commented 3 years ago

@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

henrik-jensen commented 3 years ago

@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.

Whobeu commented 3 years ago

@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.

AltitudeApps commented 3 years ago

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').

henrik-jensen commented 3 years ago

@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).

jianboy commented 3 years ago

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

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!!

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

KurtGokhan commented 3 years ago

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?

pawelurbanski commented 3 years ago

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.

henrik-jensen commented 3 years ago

@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.

EvoLandEco commented 3 years ago

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.

sogerc1 commented 3 years ago

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.

EvoLandEco commented 3 years ago

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