Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

I want to gripe a bit, in a good cause, making Codea better.

in Suggestions Posts: 1,094

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.



  • Posts: 2,370
    @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.
  • Posts: 1,094

    Oh I love it. I've written at least 200 articles about it. I just want it to get better for real work.

  • Posts: 1,316

    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%.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    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

    You can use them like:

    local x <const> = 10
    -- x can not be reassigned
  • edited March 17 Posts: 172

    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

    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)

  • Posts: 1,094

    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.



  • SimeonSimeon Admin Mod
    Posts: 5,708

    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

  • Posts: 1,094

    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. :)

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @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

  • Posts: 1,316

    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.

  • Posts: 1,094

    i'd hate to waste the screen space for that, but it would be better than current infinite row. i think ver 4 has something like that?

  • Posts: 1,094

    @Simeon def better, will report further from the good ipad.

  • Posts: 172

    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.

  • Posts: 1,094

    yes argh, i forgot the left to right rule. yucch.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @skar @RonJeffries my plan was to use top-to-bottom in the hierarchical navigator

    @UberGoober yes I have a working concept of this for version 4

  • Posts: 1,094

    how will hierarchy be defined?

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @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)

  • edited April 9 Posts: 1,094

    @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.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @RonJeffries this is fixed in 3.3.1 beta. Thanks for your report!

    Unsure on whether to change the behaviour of the last item so that clearing the search box also focuses it. Do you have a preference either way?

  • Posts: 1,094

    My guess is that if the user tries command-F or the magnifying glass they know what they want, and it should do the move to search thing unconditionally. Those are not likely to be done by accident.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    Oh I was thinking more when you hit the "X" to clear the text. Do you think it should focus the text field after clearing?

  • Posts: 1,094

    Yes, but I'm not totally certain, esp since in the new scheme, command F or the search key will select what's in there. The x is almost unneeded.

  • Posts: 1,094

    @Simeon I believe that in 3.6 you've changed it so that touching in a selected area does not clear the selection. So if you've selected a whole method, for example intending to paste it into an article :smile: you can't set the cursor anywhere in that method unless you touch outside of it first.

    I'm not sure that's ideal. And if you've selected the whole tab ... I'm not sure what you do to get the cursor back.


  • SimeonSimeon Admin Mod
    Posts: 5,708

    @RonJeffries 3.3.1 is out with the Cmd+F / Find fixes. Let me know if this works better for you

  • Posts: 1,094

    will do, thanks

  • Posts: 1,094

    so far so good. still seemed to be times when command f didn't take me to search. i'll try to isolate. also there is no keystroke to take me back to the tab i was in. (tab would be a good choice). often i use search just to see the list, never touch it. again, i'll try to do a more clear example. i think it is better ... except ...

    i think it used to be that if i double-touched a method or variable to select, then hit search, that string was now in search. that was cool and seems not to happen. p.s. should not happen if the selection contains a newline

Sign In or Register to comment.