Codea adds powerful new capabilities like Craft and Shade and others. These invite the creation of large and interesting Codea programs.
But Codea’s basic programming facilities are at best rudimentary. There’s no refactoring at all, not even smart rename of a class and class tab at the same time. Even Find/Replace barely works. There’s no reasonable organization of tabs, though I understand this is coming. There’s not much ability to use separate libraries, though this is at least possible. Unit testing is supported only by an unsupported add-on. (I could help with that.) Asset management is weak, given the power of the Files capability that Apple has finally given us.
It’s a bit like having a shop full of NC Lathes and Drill Presses and such, but no measuring tools or hammers or screwdrivers.
I humbly suggest that some attention to the basics would be of great value. I’d be delighted to offer feedback, and within my limits, actual work. I might be able to assist with documentation, at least.
@RonJeffries - I think that a major upgrade to Codea is in the pipeline so many of the issues you raised may be resolved in it. I have found some of the recent changes a little frustrating with editing changes, but I find Codea the best outlet for my need to program.
While I completely understand the point being made, I want to point out something Codea has over literally every other IDE I’ve worked with.
With every other IDE I’d say I spend at least 20-30% (and sometimes wayyyy more) of my time wrestling with the IDE itself just to get my code to run—changing this setting and that setting and googling and fiddling takes up sooooooo much time.
Granted, Codea is far simpler than other IDEs, but the amount of time I spend actually coding, instead of wrestling with settings, is darn close to 100%.
I don’t know how I didn’t see this the first time @RonJeffries but I’m glad it got bumped
You’re right there’s very little “smarts” in the way of code introspection. And not having them makes managing a large project scary. A lot of those issue that might be caught at build time in other tools can manifest as runtime errors
Something as simple as a class/tab rename seems easy. And I think the naive implementation (search for <Identifier> = class(...) where <Identifier> is the same as TabName) would work for almost all cases. There may be a problem if the name doesn’t match, or if someone has defined multiple classes in one tab, or someone is doing runtime class creation (or even something weird like load("x = class()"))
We also couldn’t guarantee to find the call sites of the class initialiser (<Identifier>(... params ...)) for the same reason — or we may hit false positives
I think tools refactoring tools like this could be valuable, but they need to come with really good previews. Side-by-side or inline diffs, ability to accept/reject the suggested changes before applying the operation, and the ability to revert
In the 3.x branch of Codea I’d like to:
Audit find/replace to ensure it doesn’t ever do anything destructive
Improve code readability in the editor
With 4.0 and up we will
Replace the tabs with a hierarchical code navigator
Make it easier to jump around in your code (back/forward history, quick open with fuzzy matching)
Switch out the current dependencies system for something better
Note that the current version of Codea uses Lua 5.4, which adds <const> variables. This is one (tiny) step in making guarantees about code semantics prior to running your program
Regarding assets management, this is actually possible currently.
Basically using the Files app I made a new folder in Codea called MyAssests, and then sub folders for projects and sub folders for those projects game objects, characters, whatever.
In Codea you can access these files via the assets dot notation asset.documents.MyAssets.Demo.all
You can also setup yourself some pointers like myCharacter = asset.documents.MyAssests.Demo.CharacterA
Then pull out even more nested folders or assets like this (but you lose autocomplete so you have to remember or look at your folders) runSprites = myCharacter.Run.all
What I would really like to see is a tree view with the ability to put our Codea script files into folders instead of one big scrolling tabs view ( keep the tabs and allow them to be closed but also add nested folders and tree view like other IDEs)
Interesting ideas, @Simeon … I think that real refactoring in Codea would be a Very Large Issue, and I don’t recommend going after it. I suspect your market mostly doesn’t work that way.
Asset management is improving. There may be ideas like @skar 's above that would make it easier, but it’s not terrible now. I do seem to have to look up how to move things every time but that’s perhaps because I do it so seldom. That said, a feature that moved every distance asset reference into the project might be nice.
Re dependencies: I’ve got so many tabs on my current project (32) that moving around is difficult. I’d move some stable classes off into dependencies, but the nature of work is that few classes are really stable. This relates to:
Hierarchical Tabs: If I could, in essence, declare a “folder”, i.e. a “level” in the tab hierarchy, then I could have, say, an Entities “folder” containing what’s now in the tabs for Entity, Monster, and Player. And I could have a separate “Tests” folder, perhaps, with the tests in it. (It might be desirable to be able to skip exporting those tabs, but that’s not clear, and could lead to a real mess at the import end if one had it set up wrongly.) In any case, the hierarchy sounds useful.
I’m hoping 4.x will show up soon, and can certainly live with fewer releases in 3.x if that would help.
A lot of the stuff I’m doing in 3.x is going into 4.0 (new autocomplete, improved editor text rendering, etc). Real refactoring in Lua might benefit from switching languages to something like TypeScript, but that almost seems like a new app.
I wonder if there are some minor things I can do in 3.x to make your life easier — it’s also good if those features can be taken into 4.0. A quick open feature might be good for navigating between tabs
keystroke for back to previous tab would be great. then you can search, browse, get back where you were. essentially make the stroke ignore tabs viewed via find somehow. maybe it’s tab last edited.
typescript, nah, lua is nifty. i admit typescript might be more valuable.
@RonJeffries let me know if the recent update to 3.3 improves your Find/Replace issues. I didn’t audit this code specifically, but made a lot of changes to the editor and text replacement in general that might impact it
Is there a reason not to do what seems like the common practice among IDEs these days, having a hierarchical file/folder browser on the left (screenshot attached)?
You already hide/show the left sidebar for searches and for reference, couldn’t it also be a hide/show thing to see a list of tabs?
Even if you didn’t want to enable folders in that list, or let it do anything with asset management, just having it be a list of tabs would be enormously helpful.
I think the main problem with hierarchy is that Codea works by compiling your project files from Left to Right. So if you have class inheritance your parent class has to be to the left of your child class. Tree hierarchy typically works by using alphabetical order. So Codea would need something like a load order setting/global comment/etc in each file to know which to load first.
I wish we had tree hierarchy and sub folders also.
@RonJeffries by creating folders and adding files to them. The folders will exist on the file system but they won’t automatically monitor their contents for updates and only track files you’ve explicitly added to them (similar to how Xcode does things)
@simeon hitting the search key on screen does go to the search box and select what’s there. Command-F on the magic keyboard does not. Please fix that when you have a chance. Thanks!
P.S. If you touch a tab, or maybe touch on a search element in the search list, and then hit the find button on the virtual keyboard, it doesn’t go to the Search field. It’s a question of whether the cursor is in the tab, I think.
P.P.S. If the cursor is in the tab, and you tap the X to delete the search text, the cursor should perhaps go into the search box. (Argument against: I might just be trying to clear the irritating yellow bits, and planning to edit.)
P.P.P.S. If there’s a selection in the tab, neither the search virtual key nor command-F work.
