Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow viewer to specify the file to apply the highlight in #34

Open
clarkio opened this issue Jan 27, 2019 · 9 comments
Open

Allow viewer to specify the file to apply the highlight in #34

clarkio opened this issue Jan 27, 2019 · 9 comments
Labels
enhancement New feature or request

Comments

@clarkio
Copy link
Owner

clarkio commented Jan 27, 2019

No description provided.

@clarkio clarkio added enhancement New feature or request mvp a feature that needs to be included before pre-release/release labels Jan 27, 2019
@clarkio clarkio added this to the Pre-release milestone Jan 27, 2019
@paulkling
Copy link

paulkling commented Jan 30, 2019

May want to prevent some files from being included. May want to exclude secret files, or files that people might troll on. What would happen if someone tried to mark a line in a image?

Could this be pulled from .gitignore or .twichignore or some other file?

@clarkio clarkio removed this from the Pre-release milestone Jan 30, 2019
@clarkio clarkio removed the mvp a feature that needs to be included before pre-release/release label Jan 30, 2019
@douglas-mason
Copy link

Heard on roberttables stream that there's concern of allowing people to open sensitive files if this feature auto opens the files viewers suggest. Just wanted to suggest possibly opening a VS Code notification with the filename and line number which may have an action in which you could choose to open that file from that notification. When you open the file you'll then see the highlighted line.

@clarkio
Copy link
Owner Author

clarkio commented Feb 27, 2019

From @parithon on stream today: "Should it only be able to target files in open tabs?"

@clarkio
Copy link
Owner Author

clarkio commented Feb 27, 2019

From @Spatacoli on stream today: re: bringing focus to the specific file used for the highlight command "wouldn't that be annoying? you are typing code and all of a sudden you are typing in another file?"

I agree with this as it also could serve as a potential security risk if the file contains something sensitive such as API keys or passwords. Not automatically bringing the focus to the highlight in the other, not currently in focus files, will help prevent this from happening.

@CodemanCodes
Copy link

You could have a general blacklist of files that we know commonly have secrets, then as suggested by @paulkling could optionally have an ignore file.

Could also only have the highlight show up in the highlight tree view kind of like the notification suggested by @douglas-mason , maybe a different color if the file is not in the active text editor with a click-thru action that open the file... or even better, add to the context menu to open file so there is another layer protecting the streamer from accidentally opening.

Another option if the API allows it, highlight the file in the explorer tree view.

Burden will remain with the streamer to not just click and open the file but make sure its a file they want to open.

@CodemanCodes
Copy link

This issue should reference existing issue #16 - Certain files should not be allowed for highlighting

@paulkling
Copy link

maybe .twichignore is too specific. Maybe more generic name like: .sensitiveignore, .secretsignore, .highlightignore something without a brand in it.

@parithon
Copy link
Collaborator

parithon commented Mar 9, 2019

I'm leaning toward only including files that aren't ignored in gitignore and are in the workspace folder. I believe that would encompass the majority of the scenarios. We could keep track of additional files separate from gitignore but that would require an otherwise useless file in your source or another file that would become stale over time.

@CodemanCodes
Copy link

I agree, most things that have secrets in them you wouldn't be pushing to the repo, so I think using the gitignore would work fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants