Improvement: Dockable Text Editor and Find/Replace

[ThomasMahon]

Dynamo version

0.9.2

Operating system

Win 10

Improvement Suggestion

I'm finding coding using DeisgnScript quite tedious when I have written lots of code (see image for an example). The code block cant be resized, and when I zoom in to see my code, the scroll bar is out of view...so I have to zoom out, move it, zoom back in. Its very disruptive when coding and problem solving. I end up simply selecting the text to nudge the view across to avoid this behaviour.

The other issue is simply finding the right block of code to do updates or troubleshoot definitions...where is it...more zooming in and out. No find tool. Its arduous to say the least.

My suggestion is to have a dockable text editor panel which is capable of 'collecting' all the DesignScript defs. Should then be easy to implement a find/replace tool. Anonymous code blocks can remain put to avoid 'muddying' the text editor.

[ikeough]

@Racel A great image which demonstrates the need for a better code editing environment.

[ramramps]

@Racel - We should consider this for the webui.

[dimven]

This covers my suggestion from earlier:
#4976
Could we also add identical text highlighting to the list?

[radumg]

Pardon the thread resurrection, but I would like to suggest a different avenue here. Instead of developing a code editor from scratch that lives inside Dynamo, would it not be better to provide an integration point with the various IDEs out there ?

How would this work

So instead of writing code in an editor inside Dynamo, you would write it in your favourite IDE (Visual Studio Code, Visual Studio, JetBrains, etc) and have Dynamo read that source file. All of these support Python for example and a plugin for them that provides support for DesignScript would surely be quicker and easier to write than a watered-down IDE for Dynamo. All the IDEs above have support for code completion, linting, version control, etc - none of which are trivial to implement.

Practical example

As a practical example, I recently needed to run an external python script from Dynamo (IronPython does not support numpy) and built a small CLI node for it. Similarly, I can imagine a new Core node that takes a .py file just like the current node that takes a string :

In the example above, I actually wrote the python script in an IDE (Visual Studio Code), which saved tremendous amounts of time and provided lots of functionality not available in the Dynamo editor, such as linting, further plugins for productivity enhacements, integration with vcs (GitHub) etc.

Aspects to consider

Two potential issues come to mind :

• embedding the script for sharing : some people might want to embed the script for sharing the .dyn definition without having to also upload a separate script file
• detect & show changes : Dynamo would have to watch out for changes to the script file (hashes would be quick) and perhaps give a UI warning (or error out) when the script has been modified externally.

n birds, 1 stone

As in the issue referenced by @dimven above, people are looking for this IDE-like functionality in both the DS editor and the Python one. This would potentially solve those and also add support for C#, VB, etc.

Curious to hear what you think @Racel @ikeough @dimven @ThomasMahon

[andydandy74]

@radumg - Since I wrap every single Python node I create in a custom node, I'd much rather see this capability inside Dynamo. I absolutely see the benefits of what you're suggesting, though. Perhaps a compromise might be to have an "Edit in external app" button in code blocks and Python nodes (the editor could be specified in Dynamo's Settings menu). Dynamo would then create a temporary file and launch it in the external editor. If the file is saved in the external editor Dynamo will recognize those changes and ask the user whether to reload the modfied code much like what you're suggesting above. Great work on the DateTime.Format node, btw.

[radumg]

Thanks @andydandy74 !

What you're describing above is exactly the type of functionality that could easily be built once the infrastructure teaching Dynamo to handle external script files & IDEs is in place. Great suggestion !

Might have a look at it this month if i get some time, would welcome assistance :)

[ThomasMahon]

@radumg I think its a good idea - although is this not essentially the equivalent as, for example, Visual Studio's "Attach to Process" debug process? That said, this may be too complicated for most users, or too steeped in the realm of computer programming, which I've found is a hard sell to members of the design team.

In my opinion, one big advantage of having a purpose-built debugger in Dynamo is the 'visual' aspect. What I mean by this is really in reference to GC (Bentley's Generative Components) debugger. Its purpose-built, and well designed, but here's the master stroke: as you debug your code, geometry is drawn as you step through (the 'visual' aspect). It makes debugging far more accessible and is more 'design' orientated since there is an onus on visualisation throughout - it basically removes a layer of abstraction and opens up the software to a far broader audience, not just coders or programmers. I think for this one reason alone (assuming it would also be possible to achieve in Dynamo), its a good enough reason to pursue a custom-built debugger for Dynamo as that's going to be one of the few ways to make such features possible.

Its worth adding that in my early days/years of computational design, were it not for the ability to view geometry creation as I stepped through using the debugger, it would have stifled my development. The potential here then, in particular reference to new users, shouldn't be overlooked!

Here's an example of GC's debugger drawing geometry via the debugger as the code is stepped-through:

[radumg]

Thanks for the comment @ThomasMahon, I do agree that educational value is something important to keep in mind. Don't think suggestion above detracts from it, on the contrary - it would allow beginners to interact with Python code in a much more suited & forgiving environment : IDEs that have full-featured auto-completion, linting support, etc, see issue #3378. For example, this should help avoid the myriad of posts where a tab or space is misplaced in Python code, accelerating their learning.
It would also have the side-effect of freeing up development resources from having to maintain lots of code (and potentially writing more)

On the debugger side, thanks for posting the gif, really interesting to see GC in action.
However, this issue doesn't deal with debugging (we have your other issue #6512 that deals with it) , which could still happen with or without the built-in code editor, so let's not digress.
To that end, I was suggesting a more efficient code delivery system to the internal IronPythonEvaluator (and DS too) , which take in the code as a simple string variable.

[jnealb]

In favor of integration with IDEs - which one first?

[Racel]

@ke-yu @aparajit-pratap - Any thoughts? Didn't we have a prototype for a debugger? What would it take to add search, debugging, and watching of variables in our current implementation?

FYI- @mjkkirschner

[aparajit-pratap]

@Racel @jnealb, @junmendoza revived the old DesignScript IDE/debugger to work with Dynamo CBN's so yes, it's possible and it saved the effort of rewriting a debugger for DS. There are a couple of things to keep in mind though:

• This debugger launches in a separate window outside of Dynamo upon bringing up a right-click context menu on the CBN and clicking a "Debug" menu item. The code from the CBN is automatically copied over to the debugger IDE.
• The code in this IDE does not automatically include the inputs generated from upstream nodes for the CBN unless it takes in simple integers, strings, etc. So we'll need to figure out a way to inject the upstream code as well, so that it serves as input context to debug the CBN code.
• The old IDE/debugger runs independently in a separate instance of the VM, so we will first have to update its VM to reach parity with the VM against which Dynamo runs today.

Pros are:

1. we can debug DS (CBN code) and watch variables without having to rewrite a debugger
2. we can have a better editor (IDE) to write long code blocks although outside of the Dynamo environment and save us the trouble of enhancing Intellisense and some of the other basic IDE goodies

Cons:

1. Still requires some effort, primarily in updating the older VM of the debugger to match the current one in Dynamo or refactoring the VM to make it able to be used by both
2. Needs some clever solution to recompute the upstream code and generate inputs for the CBN code to be able to debug it
3. Still an external environment that runs independently outside of the Dynamo workspace
4. More code to maintain (debugger + old IDE)

[Racel]

@aparajit-pratap - Excellent! So, do you have the prototype working in some capacity? Can you send over images/gifs/video so we can assess how much UI/UX work may be needed?

[junmendoza]

@aparajit-pratap I look forward to see the progress. It would help in my prototyping efforts. Get in touch anytime you need some collaboration

[smangarole]

@ThomasMahon Dynamo Team is working on an improved UI, which we will make available to our users.
@Racel and @kronz please note.