Closed ghost closed 1 year 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.
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?
i think this could be done via ext using registerFileSystemProvider , also check https://github.com/alefragnani/vscode-read-only-indicator
+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 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
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.
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:
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:
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:
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!
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
.
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 .
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: 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.
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.
@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.
I give a very simple example:
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
Details:
This feature should be very useful for code reviewing. And I think it's not hard to implement.
Thank you,