This is a cross-post from here
Contrary to what would probably be best practice, I do all of my Mathematica development inside Mathematica itself. To support this I built out a suite of application development tools , a web site builder , a bug tracker , and a documentation writing system . Each of these worked nicely for me separately, but each of these required a palette and each one ran on notebooks, which meant that my screen filled with too many notebooks to keep track of. And then for each of these palettes and systems I had to write new resource finding code based off the palette or some arbitrarily imposed root directory or else provide some other way to specify where things would be found.
In short, it got messy.
Then, in a very relaxing hiatus from Mathematica I did some python development, writing a package for linking Mathematica to python as well as some stuff for coordinate transforms and finite differencing and other little utilities. In doing this I noticed that everything was just...better. Partly this is because python is much nicer to write significant amounts of code in, being a language that actually supports developers and with actual object orientation and modularity. But another significant part of it was in the tools available to me. In particular I had the python plugin to IntelliJ , which is also repackaged as PyCharm . The fact that I had tabbing, plugins (e.g. for Git ), a file browser inside my dev environment, etc. was at once so entirely normal (I used to be a python programmer before switching over to mostly using Mathematica) and at the same time so nice. I then tried to use the very nice and well constructed IntelliJ plugin for Mathematica but it was just too much of a hurdle to lose everything I was used to and liked about writing my code directly in Mathematica.
And that long, unnecessary background is why today we're gonna look at a Mathematica IDE written and operating entirely within Mathematica.
Mostly for the rhyme, I called this thing EasyIDE but it is pretty easy to use, too.
Install it off the Paclet Server :
This IDE system is also basically just a package and a stylesheet, so it's pretty easy to get started. Simply go to Format ? Stylesheet ? EasyIDE ? LightMode . It'll prompt you for a directory to use as the root directory. Here's a video as an example:
Format ? Stylesheet ? EasyIDE ? LightMode
You can play around with the file browser now or the plugin menus in the top right
As things currently stand, the IDE recognizes three types of files to handle in different ways. The first, of course, are plain notebooks. These can be manipulated like normal. Here's an example of making and editing a notebook file in the IDE:
Text and package files can be made in the same way--just assign the appropriate file extension.
Each of these files will work basically as a regular file would, except their contents will be saved to their original file on the disk rather than the current NotebookFileName .
One of the most useful and intuitive features of this IDE is the file browser it has built in. This allows you to quickly find files inside the active directory. Here's a screen shot of what that can look like:
Each entry in this has a ContextMenu that allows for some file- or directory-specific actions.
EasyIDE is built to be extensible. It provides a way to get different behavior depending on what would be useful for the specific type of notebook or file is being fed in. These are controlled in the EasyIDE settings, in particular at EasyIDE ? Resources ? Settings ? Mappings where there are many files that control how these should map. This directory may also be created in $UserBaseDirectory/ApplicationData and the settings there will take precedence over those in the paclet folder itself.
EasyIDE ? Resources ? Settings ? Mappings
These customizations include stylesheets, toolbars, and what to do when the file browser is active.
Probably the best feature of having something like EasyIDE is the ability to hook external code into the IDE and have it give new, more powerful capabilities. To make this easy to work with I added both a plugin system and a toolbar system (although the latter is really just a special case of the first). Plugins appear as either menus--such as the File and Project menus which are themselves just plugins--or as commands under the plugins menu. Currently I already have a decent number of these:
All of these add new functionality to the IDE based on code I'd written before. In that screenshot you can also see a toolbar, which exists right below the tabs. This can be stylesheet specific and thus adds an even more targeted way to add functionality to the system. Here's an example of the four different toolbars I've implemented as well as the different stylesheets they go with:
In that you can also see the major downside of putting everything into an IDE: when the files get big (as is the one I'm using to write this post) things can get slower. On the other hand as long as one is only writing code, this is never an issue. And even with a ~12MB file like this things are still more than fast enough to not be frustrating to work with.
EasyIDE was built to be customizable. This holds first and foremost for the stylesheets it works with. Even though currently there is only a set of LightMode styles, as DarkMode style set could be constructed without too much more difficulty. To do this, one would merely have to take the existing LightMode stylesheet, copy it, and make the necessary cosmetic changes. These changes should then propagate reasonably naturally to the extension styles if the inheritance is changed. This is on the TODO list, but if there is a quality existing DarkMode stylesheet to work off that would also make life much easier.
These may be hooked in by adding things to EasyIDE ? Resources ? Settings ? Plugins and EasyIDE ? Resources ? Settings ? Toolbars . There are a number of good examples there already.
EasyIDE ? Resources ? Settings ? Plugins
EasyIDE ? Resources ? Settings ? Toolbars
I had already implemented stuff for creating nice docs, Markdown notebooks, websites, bug tracking, paclet creation, etc. and some of this has made it in as plugins already. More is forthcoming, but for now one can always play with what's in the Plugins menu. In particular the Git plugin is useful for me as I write and develop.
EasyIDE is just a collection of functions wrapped into a single unit. These were designed to (hopefully) be modular and clean to work with. Eventually all core functionality will also make its way to being attached to a single object, the IDENotebookObject . The API for this is based off of my InterfaceObjects package and is object-oriented. This will be documented in due time, but as a taste here's what it can look like:
ide = IDENotebookObject
These "Methods" are all operations that the IDE notebook referenced to by EvaluationNotebook can perform. Here's an example of creating a message:
As the IDE grows in sophistication so will the methods the API supports. For now, though, these provide the most direct control that is possible to get with the IDE.
- Congratulations! This post is now a Staff Pick as distinguished by a badge on your profile! Thank you, keep it coming, and consider contributing your work to the The Notebook Archive!
I've found two bugs in EasyIDE () with Mathematica 12.0 under macOS 10.14.4
Similarly, if I keep the magnification at the default 100% but make the window narrower, then either the File button disappears to the left or the Plugins (and possibly the Project) buttons disappear to the right.
INTERNAL SELF-TEST ERROR: CellStyle|c|1326
Thanks for the report! Unfortunately by design of the Mathematica front end both of these will be hard to sort out but I'll think.
As for 1) both of those are due to the fact that the front end is very much so not good for controlling layouts. I need to allocate space for a reasonable number of tabs as well as for the plugin menus. But what I can do is solve the magnification issue by forcing the magnification of just those buttons to remain constant. In fact I should probably have all my GUI elements work like that...
As far as the resizings go, there is unfortunately no good way I know of to allocate "just the right amount" of space for the plugins and leave the remaining stuff for the tabs. If I find such a thing I will definitely make it work like that. I could also push the tabs onto their own row, but I need to think through the design implications of that first.
For 2) that's a by-product of the front end failing to set the CellStyle for an "attached cell" appropriately. It's something that I've tried to work around before, but haven't found a good way. There are a number of these front end INTERNAL SELF-TEST ERRORs that very standard front-end design will hit but they've never caused a crash for me. If you find a correlation between them and performance degradations (including crashes) please let me know and I'll see if I can work arount them.
Unfortunately, on my 27" iMac Retina display, with these old eyes of mine, I cannot comfortably use Mathematica at all when notebooks are at default 100% magnification. Yet when I change to 125% magnification, EasyIDE's Project and Plugins buttons just disappear from the left side of the notebook's top pane, and I cannot recover them without reverting to the untentable 100% magnification.
Can you read the tabs / menu elements at 100% or would those need to be larger too? I can try to work around some front-end idiosyncrasies/glitches to get it the menu items to work at larger magnification. On the other hand, I can easily make it so that the menu items remain at 100% while the rest of the notebook content magnifies.
Yes, the tabs, buttons, and menu elements are perfectly readable at 100% magnification. (I keep all my palettes at 100% too.)
It's only when I'm writing (and then reading) code in a notebook that I need a greater-than-default magnification.
Does EasyIDE support a "Properties" query on a notebook, e.g. to reveal the notebook's path and various timestamps? The FrontEnd lacks such an out-of-band mechanism.
I tried to use EasyIDE, but tripped. I think there was a glitch during the install. And later, when I tried to create a new File, a message popped up: "SystemDialogInput: Directory specification Inherited is not a String or a FrontEnd`FileName".
Yeah that message definitely sounds like a trip in getting set up. Means it didn't manage to get bound to a directory.
There is certainly an object-oriented API that you can use to find paths, create attached dialogs, notification messages, etc. but I don't have anything to get timestamps right now.
the installation instructions for EasyIDE show one using first:
How may one permanently install that Install.wl?
Is that package part of PublicPacletServer? If so, how install the latter? At https://github.com/paclets/PacletServer/wiki/Installation, you show:
"Site" -> "http://paclets.github.com/paclets/PacletServer/master"]
However, even after evaluating Needs["PacletManager`"], evaluating that PacletInstall expression, I get a $Failed with error messages:
PacletSiteUpdate::err: An error occurred attempting to update paclet information from site http://paclets.github.com/paclets/PacletServer.master. Does not appear to be a valid paclet site."
PacletInstall::notavail No paclet named PublicPacletServer is available for download from any currently paclet sites.
Good catch! I need to update those instructions.
This is indeed part of the public paclet server package. That's also on the paclet server so you can do:
Then you can do:
Alternately, you can download https://paclets.github.io/PacletServer/Install.wl and put it in a folder called "PublicPacletServer" in $UserBaseDirectory/Applications. Then you can load it like:
I find it cleaner to:
Create Kernel subfolder of that folder and in it put an init.wl consisting solely of:
The advantage of this bit of extra effort way is that subsequently all I need do is:
Impressive and its sad that a user had to make this.
I was also doing more work in Python recently and now its hard to come back to Mathematica.
So I hope that Wolfram Research is contributing to this and focus more on developer and deployment outside of their ecosystem.
It would definitely make sense form a business perspective.
Very nice and impressive!Does this has any options that are not provide in eclips+workbench. I have used that which allows debugging with breakpoints, Egit interface, documentation building and opening all files directly from eclips in mathematica, source browsing etc.
Especially the debugging in eclips has proven very usefull.
Currently there's nothing like a debugger, but I think its best feature is that it provides a flexible plugin/toolbar system and access to a lot of package development work I've done that allows you to hook other code and packages into it.
As an example of what this does for us I have a set of plugins I've already built in:
These are all written in pure Mathematica code so you can easily add new plugins and toolbars and whatnot to the IDE just by knowing how to use Mathematica well. I expose these three packages too in it which opens up a lot of possibilities.
I can imagine, too, that the work on a Mathematica profiler and "CodeTools" as I think WRI is calling it could be integrated directly without too much issue! Once that package is out, this could even be something that I work on integrating at a deeper level too.
The biggest benefit of this is the fact that it allows you to develop stuff in Mathematica and feed it directly back in to the IDE.
Also you can use stylesheets, front-end programming, etc. directly in your dev environment. I recently used this to add a few new themes (and anyone can write their own without too much work):