(Latest gif in thread)


KryptonIDE has made me sad by being unfinished.

I mentioned over SAX that I don't believe it to actually be that hard to make one of these editors, and the only reason it doesn't exist is because people haven't tried, but people were skeptical, so I wanted to see if I could prove them wrong.

Here's the progress so far. Inserting/removing tokens, 4KB for undo/redo, selecting, copy/cutting/pasting.

What Aether lacks right now is proper rendering for all tokens (and a finished font), the ability to type a variety of tokens (it's just a few hard-coded ones), and a general user experience.

Here's the code so far. 900 lines of C. Project unfinished, and my programming style is very iterative, so don't mind if something looks off.
(See that, CC25 judges? All code in one file! Take that! )
https://github.com/vitalash1/aether




You know what's cool? All of the work that various people have done by documenting TI-BASIC token hex-codes (Merthsoft and contributors at the TIBasicDev wiki) and making C libraries for File I/O (MateoConLechuga) means there's practically no difficult research for this kind of project. It's just making a front-end editor.

I'll be doing some fun programming mentoring in a few days, and I'll still be working on my game project, so that may impede on this 1 a.m. editor project, but I really do want to see this through at least eventually. Further than KryptonIDE.

This is looking really great so far! I'm very happy with the progress and it would be so useful if a nicer TI-BASIC editor is finally released for people to use. Gotta admit, I'm not 100% certain how I feel about that font though Nonetheless, great job

Nice, keep it up and I'll make this the default editor in Cesium

https://github.com/mateoconlechuga/cesium/blob/8372a8ac9a80b9cb2c85c039f9993b4123808804/src/settings.asm#L562-L564

That sounds fun

Thank you

An update; the editor now supports rendering all tokens, and I started adding user token input.


Important work for future is loading/saving programs, quick-testing programs, allowing users to "goto" labels in editor, and finishing adding all the user token input.

I've always wanted an editor like this on my calculator! not sure what I think about the font though

Wow, very impressive work so far! Here's an interesting idea (I'm not sure how difficult this would be to incorporate but I think it could be pretty useful). What if there was some sort of autocomplete feature for tokens, so that you wouldn't always have to open the menu to type anything? One of my biggest gripes with TI-BASIC is the fact that you can't really type it out, and have to keep digging through menus for all the tokens. Sure, you can get used to it, but I feel like some sort of autocomplete (if you found a good way to include it in the program) could be helpful.

Keep up the great work!

Finally, great to see someone working on a third-party TI-Basic editor. I agree that it would be pretty cool to see some sort of token search/autocomplete feature in the editor, that always took a lot of time.

Any plans for Celtic CE/ICE support?

Looking forward to more updates!

Ever since I got a rev-M+ calc I got hooked to on-calc programming again. And now this new editor is on the way. It will be much easier to code because you see more characters at once. I can't wait to see what updates you have in store.

You should really add a special characters menu since some normally unreachable characters are still possible to use in pure TI-BASIC, like the accented letters, greek letters, inverted equal symbol, arrows, hashtag symbol, etc.

It's nearly good!

I added a program selector and a catalog with every token.


I added a Goto Label thing


When the cursor goes off the end of a line, it switches to a centered view of it


A bunch of menus that match the TI-OS editor's menus (your muscle memory will stay, although the 2nd and alpha keys are sticky as opposed to going away after one key press!)


I also added a hotkey to execute the TI-BASIC program, but there's currently a bug with the CE C toolchain, so I disabled it for now.
https://github.com/CE-Programming/toolchain/issues/459

Also, it now saves.

The editor is basically done. What needs to be done is
- Finishing the few user input menus left (stat/draw/distr/list/maybe more) and 2nd key inputs on keypad (and navigate to start/end of line with 2nd)
- Bug testing (probably an open beta)

Some nice things that are unnecessary to finish the editor that I may not add (but could in future if I ever feel like it)
- Find string?
- Draw pictures in "Vars" menu

If you'd like to help me find bugs, here's a current build of Aether.
[redacted link, look later in post for more up-to-date links]
I won't keep that link up forever, and I recommend you back everything up before using it because it's not been thoroughly tested by many people (only myself).

Here's a quick usage guide written at 3 am (incomplete)
- [clear] backs out of menus and closes the program
- [X,T,0,n] opens the goto menu ([enter] to confirm, [clear] to back out)
- [mode] clears the line
- alphabetical keys jump in the program selector
- [2nd] toggles archiving in the program selector
- Pressing [2nd]->[alpha] enables lower-case alpha mode.
- [alpha] lets you jump around menus the editor by multiple lines at once
- [ON] toggles light theme
- [mode] opens the latest program in the Program Selector screen


That's cool! I hope you enjoy it once it's ready I believe I got all of the unreachable characters in the 2nd->Catalog menu!




I disagree, and I think once you get used to the token menus it can be quite quick and fun. It's less keystrokes, and it's a strong benefit of being tokenized. I find it good that we don't edit with pure text, and having live-tokenizing would simply accommodate for something imperfect.
It would definitely feel a waste of my effort personally.


I don't think it's a good thing to support Celtic CE/ICE. For one, ICE is deprecated if I recall correctly. Next, Celtic CE/ICE were designed as a hack alongside the TI-OS editor I believe, and so then making an editor that supports a standard designed for imperfect editors is like an incest of an imperfectly designed system. It's kind of like how modern software is. Best would be if Celtic CE/ICE design their own standards and editors from the ground up so it can cohesively work well (outside of my scope).


I do try to be strict with my decisions because much software has too much fluff, I think.

While I admit I have gotten extremely fast at coding ti-basic on a calculator (I dont have to look at the screen or keypad) this looks really nice to code in. Some things I like about ti-basic is cesium ability to jump to lines. I cant wait to try this and see where this goes.

I wouldn't really call Celtic CE or ICE a hack alongside the TI-OS editor per se (Neither of them really have anything to do with the editor other than using TI-BASIC tokens), more just a way to use TI's already existing BASIC interface to do more. ICE could maybe be a bit more of a hack since it really is a different language from TI-BASIC, only using TI-BASIC tokens, but Celtic is a parser hook which directly acts as an add-on to TI-BASIC and there really isn't any way to go around that other than completely killing compatibility with the TI-BASIC editor and introducing new tokens (Which I'm not even sure would work with a parse hook anyway, someone more experienced would know). The point of Celtic is to work with TI-BASIC, not be a separate language, and so it works the same way as all other hybrid-basic libraries using parser hooks have worked, so that people who don't want to be stuck with lacking functionality / poor performance in TI-BASIC can still avoid it without needing to learn a new language. Integration with Celtic CE or ICE would certainly be tricky since it would require a little more work with detecting which tokens represented commands, but both already do this for their status bar hook which displays info on the current command in the top bar anyway:



Even something like this makes it easier to use. However, given that ICE and Celtic CE work just fine in the TI-BASIC editor and would even without that, it's not like an editor really can "support" either of them (they just use normal TI-BASIC tokens anyway so something that can do TI-BASIC can do ICE or Celtic). It's more about adding features which specifically tailor to those languages, and if the editor is specifically made for TI-BASIC I can understand not wanting to put in extra effort to include them. However, I wouldn't really say that making an editor that supports them is a development sin because they interface with TI-BASIC tokens for something that pure TI-BASIC.

Just for clarity: I'm not really arguing that you should spend the time to add Celtic or ICE features to the editor if you don't want to or feel like it's adding too much, and I can agree with that, but maybe not for the same reasons. If I really want it, I suppose I could always just do it myself

Do you plan to add support for OS 5.3.0? Many people still use that OS because it's the first OS that can run archived programs but also the last OS where all three ASM commands can still be used from the original Catalog.

Just found this forum and I think this program could revolutionize calculator coding. Like calculatordream, I think the font could be changed to a more sleek font, maybe like Arial, Roboto, or Verdana, just to make it easier to read and fit more code on one line. AMAZING job so far!

Arial, Roboto, or Verdana, while good fonts, aren't very good choices for this application.

For one, they aren't monospace fonts, which is an important property for a code editor's font to have.

More importantly, they're vector fonts, which means that they define the shape of each glyph, rather than bitmap fonts, which define what pixels should be black or white for a particular size of font. Vector fonts are vastly more complicated and computationally intensive to render, so fontlibc only supports bitmap fonts.

You could attempt to convert a vector font into a bitmap font, but you would lose the anti-aliasing that gives these fonts a lot of their legibility - for example, here are those fonts with anti-aliasing:

And here are the same fonts without anti-aliasing:


Overall, it's just better to pick a readable font that's a bitmap font to begin with. This repository links to a large number of them to choose from. Personally, I'm partial to GohuFont, which is the font that I chose for my terminal emulator.

Open Beta Test
I've been working on Aether, and it's nearly where I want it to be. However, what's needed is testing and ensuring no bugs (KyptonIDE flashbacks).

Your feedback - yes you - could be useful.

Back up your calculator before trying it. I've been the only tester so far. If you find crashes or other issues, that's helpful to point out, and try to see if there's a common reason it crashes.
Download (version 2023-11-21): https://drive.google.com/file/d/1sxK_oB4Qw9N169PHdKBm57SWaujN2p4y/view?usp=sharing
WARNING you should install the nightly build of the C-libs (Nov 21st) https://github.com/CE-Programming/toolchain/releases/tag/nightly as Aether's "[Apps] to run program" will cause issues in older versions of the C-libs! (specifically when it reaches the 'Stop' token).

I care less about nitpicks and "wouldn't it be great if..." ideas, because high-quality ideas are rare and require a high level of investment. I mostly want to find bugs and undesirable program behavior :)
Let me know what bugs you find. Let me know what things really shocked you.

If you really want to provide nit-picks and ideas, I've been thinking of changing obscure token menus (like Distr) away from TI-OS's editor, and instead putting commonly used tokens there. If there are any tokens that you use often but take many key-strokes to get to (such as grabbing it from the catalog), then tell me which ones those are.



There is a lot of feature parity with TI-OS's editor, so it should be mostly intuitive. However, there are differences.
[clear] closes the program (or backs out of a menu if one is opened)
[mode] clears a line
[X,T,0,n] enables the "goto label" search (clear to close)
[2nd] and [alpha] are sticky, meaning you toggle them instead of them only activating for one key-press.
[2nd]->[alpha] enables lower-case alphabetical input
[y=] toggles selection mode with the cursor.
[del] deletes a token, but in selection mode, it deletes the selection
[window] copies when in selection mode, pastes when not in selection mode
[zoom] cuts when in selection mode, pastes when not in selection mode
[trace] is Redo
[graph] is Undo
[2nd]->[sto→] outputs a ʟ
[ON] toggles light theme
[mode] opens the latest program in the Program Selector screen
[Apps] runs the program



I'd like to see people test it, find bugs, and break it on OS 5.3.0. I'm personally testing it on 5.4.0, right now. It should work on 5.3.0, but it's untested.

If you have a settings menu, then one feature suggestion I have would be to add the option to switch 2nd+Mode's line deletion function to the Clear button like in the TI-OS, because many unsuspecting programmers will try to quit the old fashioned way out of habit only to lose a line of code instead.

So far I haven't encountered any crashes or weird bugs, but I am limited in programs I can use it with since it doesn't appear to open 30 KB large files. Still awesome work, though. This looks more intuitive than the official editor, especially how fast you can scroll through the code and with how many characters you can see on the screen, thus making the code easier to read.

I added automatic visual indentation, support for up to 44,000 byte files, and bug fixes.
I noticed rendering is slow when there are hundreds of tokens on screen at once; I'll see if this can be mitigated.

(Back up your calculator before trying this beta version. More information on beta-testing/program-usage in my previous post. You may lose work. If you find bugs, that is helpful, and report them.)
[Redacted old version link]


To test the editor, I made a story game I like to call prgmTREASON




I'm quite against settings menus; I think that it's usually a sign of a program that's too indecisive about how it should be. Rather, if something is a good idea for the program long-term (beyond initial learning curves), it should probably be default functionality. CLEAR seems like an intuitive way to back out of menus though... I suppose the ON button would be the best replacement?
Luckily, if one clears a line with MODE, they may undo the clear with GRAPH.


Right now it's free for me to allow 44,000 byte-sized files, but there are some fundamental changes required to take it up to 60 KB. I did not initially plan for this and had no idea people even made programs that large

This is amazing, do you plan on posting the source code?
Maybe Open-Sourcing it? I know it's on github but the readme says, "All rights reserved, contact me for permission to use/modify/redistribute code, and i'll happily read your request'

Dark/Light mode?

It is open source. The source is in the repo. Are you just confused? The request is if you modify/redistribute.