add option to save file locally

[xmsid]

an option to save the file locally would be convenient so if we're coding in python so the guest can run the code to test the script, its okay for web development though.

[wijnand2]

Ran into this as well, would be a very useful extension.

[jasonrudolph]

so if we're coding in python so the guest can run the code to test the script

@xmsid: Thanks for sharing this specific use case. For any feature request, it's always helpful to know what problem people are trying to solve with the requested feature. Thanks for taking the time to explain. :bow:

Ran into this as well, would be a very useful extension.

@wijnand2: Are you also wanting to save a file so that you can run the file to execute some tests? Or do you have a different use case in mind for wanting to save the file locally?

[jasonrudolph]

Refs: https://github.com/atom/teletype/issues/228 (since it also involves tooling that requires portal files to be save to the guest's local file system)

[jasonrudolph]

As we prioritize future work, we'll be looking at feature requests like this one to determine where we can deliver the most benefit with the available engineering resources (i.e., full-time Atom engineers, community maintainers, and new contributors). In the meantime, if this is a feature that would make you smile from ear-to-ear 😁 each time you use Teletype, adding a :+1: emoji reaction to the issue body is a great way to let us know.

[wijnand2]

@jasonrudolph Yes, to clarify: say the host is working on several python files, I would like to have a copy of each on my own machine in order to run them myself.

Currently as a workaround I could use 'save as...' to put the file somewhere, but atom will not subsequently link that file to that editor window which means I have to 'save as...' each file each time I want to run it.

[jasonrudolph]

Yes, to clarify: say the host is working on several python files, I would like to have a copy of each on my own machine in order to run them myself.

@wijnand2: Thanks for sharing that context. 🙇

[teroyks]

This would be very helpful for me as well.

My daughter is learning Python coding, and regularly shares with me a script she's having problems with. Being able to try to run the script myself without having to save a copy after each change would be great once she gets to the point where I can't immediatelly tell the error just by looking at the script. :-)

[TheTimmaeh]

Me and my friend are coding JavaScript together. Whether that's client-side Javascript or a NodeJS script, I'd like to run the scripts myself while we're coding together.

If we run into issues, my friend always needs to copy the error message and send it to me if he can't figure out how to fix it.

In this context it would be cool if you could share/sync the whole project. If someone joins a shared portal like this, they will receive all files (exceptions like node_modules/* possible) to run the files even before editing anything.

[jasonrudolph]

I'd like to run the scripts myself while we're coding together.

@TheTimmaeh: Thanks for that context.

... it would be cool if you could share/sync the whole project. If someone joins a shared portal like this, they will receive all files (exceptions like node_modules/* possible) to run the files even before editing anything.

Cool. We're tracking that enhancement request in https://github.com/atom/teletype/issues/211.

[SethuSenthil]

It would also be awesome if it would update automatically update the local file, for example, its impossible to render the HTML file if its not copy-pasted into a new local file.

[CaptainJohnyAppleSeed]

We wish to understand the desired functionality for this issue. This is how we've understood this issue:

The host and guest are collaborating on a project. During this time, the guest wants local access to these files. As soon as collaboration terminates (or before the next collaboration begins), these files are removed from the local file system.

If this is the scenario, our team is looking into a possible way to solve this issue:

Upon Teletype Set-up:

• A folder is set up in ~/.atom called teletype_local (using path.dirname(atom.config.getUserConfigPath()))
• A config file (maybe .atom/config?) points to this folder.

Before Collaboration:

• On the menu bar’s package>teletype there’s another option for “choose local folder…”, which allows the user to change the default folder for guest files to be changed by modifying the entry in the config file.

Upon Collaboration:

1. Guest joins a portal
2. In the toolbar’s teletype, there is an slide option (yes-no) to “save files locally”
3. If guest chooses to accept, then all files shared by the host are saved to the folder indicated by the config file.
4. When the user or the guest saves a shared file, then the guest will save the file specified.
5. Guest can render/run files normally.
6. When the portal closes, then all of the files that were saved locally are deleted (or when teletype initializes, then the files are deleted).

We aren't ready to submit a formal RFC for this yet, as we are wondering if this is a reasonable way to start the process of solving this issue.

[jasonrudolph]

We aren't ready to submit a formal RFC for this yet, as we are wondering if this is a reasonable way to start the process of solving this issue.

@CaptainJohnyAppleSeed: Thanks for looking into this issue. :bow::zap:

While RFC-002 described the exact code that would be written, we generally prefer RFCs to discuss things at a higher level of abstraction. Consider RFC-001 and RFC-003 as examples. Notice that those RFCs don't talk about classes or functions at all; instead, they discuss the problem being solved from a product perspective. The type of thinking you've outlined above is a useful level of abstraction for an RFC.

[CaptainJohnyAppleSeed]

@jasonrudolph Thanks for clarifying the desired amount of description desired for an RFC (we'll look into it the examples that you've given us further) 😄 We are still figuring out what our next contribution will be, and we were wondering if our above interpretation for this issue is correct before we get too deep into the actual code. Thanks again for looking at this! 🙇

[JacobGood1]

Any news regarding this?

[jasonrudolph]

Any news regarding this?

@JacobGood1: We're heads down on a handful of other priorities at the moment, so it's unlikely that we'll have the bandwidth to look into this enhancement any time soon.

[JetUni]

When the portal closes, then all of the files that were saved locally are deleted (or when teletype initializes, then the files are deleted).

Maybe make this an option. In my case, I might change the location of the local folder to a location where I don't want the files to be deleted. It could be turned on by default unless the local folder has been changed by the user.

[RickJohn57]

This would be very helpful for me as well.

My daughter is learning Python coding, and regularly shares with me a script she's having problems with. Being able to try to run the script myself without having to save a copy after each change would be great once she gets to the point where I can't immediatelly tell the error just by looking at the script. :-)

This is exactly my situation as well. It is klunky to "Save As.." every time I want to execute. What happens with the Ctrl-S save, should behave such that the remote user understands what is happening, perhaps a popup like "Save As" with a default "local" filename.