A dream come true: the ability to resize the inspector window horizontally + syntax highlighting. Here’s a quick image mockup:
New Code Editor
3 Likes
Nice concept. If you don’t mind, I pasted your image here, since it’s a little easier to follow the flow of conversation when we can see the images in the forum itself.
1 Like
Sure, I forgot that paste ability.
This nice. I do wonder how many TB user code to this degree to underwrite the work needed. Disclaimer: I use action/export code a lot but my community support role experience argues otherwise. Having written the only really documentation for both action and export code, it’s evolutionary nature - not built for an IDE or as a deliberate API - means syntax colouring (though nice!) would probably be expensive in terms of a lot of extra testing. Action code grew by natural extension of the original macro code and isn’t a programming language.
The Inspector is an Inspector and I’m not sure should be the home to a ‘code’ window, which might best be a separate dialog. Not least, there’s the whole issue of when/if an inspector is visible vs. a dialog or pop-over.
Not arguing against, just reflecting my experience of using action/export code in Tinderbox.
Hmm, yes, I think I understand the issues raised with such a thing. Maybe it isn’t worth the effort for the most of TBX users, I don’t know, but I was having real trouble editing code in the actual small inspector window, with a very narrow width and no support for scrolling, for eg. … I have some prototypes with +50 lines of “code” and it is complicated. So I am currently editing TBX rules in an external editor (BBEdit) using PHP syntax highlighting (works quite well, and is the one active in the image above). I just need to be careful since no autocompletion of variable names there.
Don’t overlook the built-in ‘code’ prototype. Using this a note is set up with monospace font, no smart quotes, etc. You can always use it’s rule to set another note, e.g. some prototype’s rule to the text of this ‘code’ note.
50 lines? Experience (of doing lots of things I probably shouldn’t have) tells me you might be trying something best not done in Tinderbox or that you should review your workflow. One trap of good support for incremental formalisation is can lead on to just adding code for edge cases rather than going back and reviewing the data structure. I find, judicious use of extra metadata, i.e. using a user attribute to capture some state, can make rules less byzantine. Of course, complexity rather varies with the actual data task at hand. Good luck!
Thanks. I may be using TBX rules in a nonorthodox way … I’m using note’s $Name and $Prototype to set key attributes in its parent, and its parent sets key attributes in its parent; also key attributes setting values based on other key attributes; also validating my input (eg. checking if the needed key attributes are defined, which means a lot of if … else …; I know I may be duplicating things & creating redundancy, but I like the visual feedback I can have with notes in an outline view (setting colors, using $DisplayExpression to display some key attributes info…) which I can’t have with the key attributes panel on the right. My longest $Rule has almost 100 lines 
(but to my defense I use long descriptive names for key attributes).
But it works for me very well
Sounds good. If it works, it works. 
I too would be very interested to hear more and see some examples, when you have the time to spell them out.
It’s possible (but a lot of work) to develop a custom syntax package (a theme, actually) for Sublime Text 2 or 3; or a codeless language module for BBEDIT for Tinderbox export code or action code; or other editors. Might be an interesting community project. I would guess maybe 80 hours to code and test a module for BBEDIT – afterwards, the maintenance would be simpler since Tinderbox code changes are not that frequent. Not sure, but Sublime might go faster because it uses regular expressions to define syntax highlighting, where BBEDIT uses plists.
1 Like
@andreas @JFallows yes I’ll post it soon in the forum, it works to share and see what people are doing, I’ve learned a lot this way. Will make an abstract version of it soon.
That would be interesting. I’ve tried Sublime, now I have stabilized in using BBedit for general text manipulation and Visual Studio Code for web (they have a minimap now!). VSC is becoming my editor of choice, its so extensible and has a lot of community plugins. Not sure how they do syntax highlight, but I agree that RegEx seems more friendly. Maybe a GitHub project for this?
@andreas @JFallows: I’ve posted a model of how I’m using Tinderbox rules to structure notes visually in an outline: check it out in A Visual Outline Demo 
Thank you, @bmscmoreira. It looks very interesting. I’ll take a deeper look as soon as I’ll have time. Cheers!
1 Like
Sorry to resurrect this old thread but in v7.3 there’s a good opportunity to do what’s described further up. I tested editing code (just in TextEdit) and saving it to a Watched folder and, sure enough, the files appear as notes. Add a bit of action to turn them into Code notes and you have a nice automated way of bringing code in from an external IDE.
If you edit the file later the edits also find their way in and update the note accordingly.
This could be quite a handy feature.
2 Likes
Quite clever @Nick
The watched files can be other formats – e.g., HTML, markdown, etc. – as long as you save them with a .txt extension. If you watch an .html file, Tinderbox interprets it as a web page and doesn’t expose the HTML.
Gives me incentive to finish my BBEdit custom syntax highlighter for Tinderbox documents.
3 Likes
Thank you Nick, that’s great news. Only have 7.1 for now though … maybe a cyber Monday Tinderbox promo??? 
How’s your progress with the custom syntax highlighting? 
6 months past due, I’m afraid 