Terminal
Opened this issue · 11 comments
A terminal would be great to go with it and IMO would fully make it into an ide, language specific command generation would be hard and better to be added now rather than adding it separately per language later
I think the per-language commands can be added by each lang extension. A new function can be made like run_file(filename) for Griddy to call. That or just a run_command("") similar to the add_comment() function.
A terminal would indeed be great though! I think just having one would greatly power up the editor, though I'm unsure how that would fit in with the aesthetics. I suggest this theoretical terminal also get a separate tab for errors from language extensions, to make lang file development easier!
I think the per-language commands can be added by each lang extension. A new function can be made like run_file(filename) for Griddy to call. That or just a run_command("") similar to the add_comment() function.
A terminal would indeed be great though! I think just having one would greatly power up the editor, though I'm unsure how that would fit in with the aesthetics. I suggest this theoretical terminal also get a separate tab for errors from language extensions, to make lang file development easier!
@ItsTato Detecting interpreters would also be a hurdle that people who make pr's would have to define, and for the errors part, if you select a file that isn't valid, you get a warning, that's already a place where the errors could be printed,
I love how simply vs code does it, it pastes the same thing in the terminal everytime: [interpreter path] + [file path] and users can type the args by themselves
ss(args in red)(I cant draw straight at 2 AM lol):
Then I guess the user can just specify the path to each interpreter in settings?
Then I guess the user can just specify the path to each interpreter in settings?
i have no idea how vsc checks but this is crazy
My guess is VSCode has a list of common paths and scans your working directory for potential virtual environments.
A terminal would indeed be great. After thinking about where it should be located, I think it behaving like the theme picker (appearing on the left side) would be great. We could use Godot's OS.execute and read the output, then translate the ANSI colours to bbcode (RichTextLabel's feature).
Oooo. Having the terminal on the left side of your code sounds very interesting. I think styling will be a bit hard and I'm unsure as to how the actual input would work, but aside from that I think this is a very solid plan!
A terminal would indeed be great. After thinking about where it should be located, I think it behaving like the theme picker (appearing on the left side) would be great. We could use Godot's OS.execute and read the output, then translate the ANSI colours to bbcode (RichTextLabel's feature).
NOOO he did the british! He added the u to colors.
A terminal would indeed be great. After thinking about where it should be located, I think it behaving like the theme picker (appearing on the left side) would be great. We could use Godot's OS.execute and read the output, then translate the ANSI colours to bbcode (RichTextLabel's feature).
Not sure but everytime i've tried to read output from a terminal, stuff like loading screens don't render in real-time and i've only gotten the end output
A terminal would indeed be great. After thinking about where it should be located, I think it behaving like the theme picker (appearing on the left side) would be great. We could use Godot's OS.execute and read the output, then translate the ANSI colours to bbcode (RichTextLabel's feature).
Not sure but everytime i've tried to read output from a terminal, stuff like loading screens don't render in real-time and i've only gotten the end output
I can confirm, ls seems to work properly while bun --help doesn't print at all.
Since recompiling the Godot engine is out of the question, we could create a new Rust project in the Tools folder that acts as a middleman between the Shell and GriddyCode - GC sends commands to Rust, Rust runs them and sends output back to GC in real time. The issue with this is that it adds an extra step of cross-compilation and development.
I can confirm,
lsseems to work properly whilebun --helpdoesn't print at all.Since recompiling the Godot engine is out of the question, we could create a new Rust project in the
Toolsfolder that acts as a middleman between the Shell and GriddyCode - GC sends commands to Rust, Rust runs them and sends output back to GC in real time. The issue with this is that it adds an extra step of cross-compilation and development.
What about pulling the output from the execution terminal with delay such as every .25 seconds and rendering that? Another way could be literally running the terminal/pwsh/command prompt using arguments(or URi) and controlling the window pos & scale to move it. (I haven't tried Godot and I work on Unity so I have no idea if this is even possible)