This IDE will use custom editing routines to ensure that key delays don't vex you anymore!

FWIW, OS key delays can be easily manipulated through OSInit* functions declared in kbd.h ( http://debrouxl.github.io/gcc4ti/kbd.html ). The KerNO crash protection does it. Also, OSdequeue() + kbd_queue() are fast enough for most purposes, most TICT programs use them. TI-Chess has its own keyboard reading code, but does de-bouncing (effectively limiting the input rate to 4 or 5 keypresses per second anyway) and most of all, maybe AMS' AUTO_INT_1 handler is not called at all, making OSdequeue() + kbd_queue() inoperative.

- It will be full screen and (hopefully) use the small font as well.

You'll probably want to use fast character / string drawing routines, like the TICT eBook reader (ebook) and several others are doing.

- It will be a hybrid of TI-Basic and C.

Mixed BASIC / C execution is a world of slowness (for calling C from BASIC, as shown by the overhead of calling flib/flib2, vertel and suchlike libraries) and hurt (for calling BASIC from C, due to all the errors it can throw if something goes wrong). Some file explorers, such as TICT-Explorer, do not even attempt to provide this functionality, given how hard doing it correctly is: they just paste the invocation to the Home Screen Line and bail out.

Well, I have decided that I will use my own keyboard layout for editing and make the user hold down modifier keys, so I'll have to kill interrupts and use direct keyboard access.

Using your own keyboard layout definitely wouldn't require using direct keyboard access, but changing the way modifier keys are handled looks harder to do without using direct keyboard access, indeed.

And since I will only call C from BASIC (not the other way around), I'll try doing so, and if it's too slow, then I'll make the frontend C as well. (By the way, why would this happen?)

It happens because of the need of creating twins from archived variables, etc.

By the way, where are the fast drawing routines?

In the source code of the programs I mentioned, which is why I mentioned them ?
The latest version should be in ebook. The setup routine reads the font data directly from the OS area, accounting for AMS 1.xx, AMS 2.xx/3.xx, and PedroM, which require different methods to retrieve this information.

P. S. I've never heard of the OSInit functions. Thank you for telling me that!

You should spend some more time browsing the GCC4TI documentation, which I've linked above and is in my signature anyway
I've learnt lots of things that way. By now, the number of documented ROM_CALLs has probably reached a thousand (out of 15xx on the most recent versions), the remainder of undocumented things being mostly made of useless / hard to use functions (although some of my '2002-2003 contributions are probably still missing, I added them myself years later to GCC4TI). Beyond that, there are other routines in the library.

Some overhead for launching a native code program occurs even when the target program is unarchived (which opens the door to data losses in the event of a crash / power loss, of course). It is very likely that launching an unarchived ASM program is faster than launching an archived ASM program, due to the overhead of creating a twin, though I don't remember benchmarking that aspect.

TI tried to make it hard to launch a native code program from another native code program. The net result was the development of such radical approaches as patching the OS to completely disable the silly RAM execution protection (HW2Patch, HW3Patch and tiosmod+amspatch; modern versions of PreOS do it as well, but it's not as easy to detect as an OS patch). Being the maintainer of / a contributor to some of the program launchers led me to explicitly advocate, for at least half a decade, to just rely on OS patches for disabling the RAM execution protection.
It just makes programmers' lives easier, and has marginal impact on users: not only users have to patch the OS just once (each time they transfer a new OS version, but that's a pretty infrequent operation), but as far as 89T users are concerned, there is simply no other sane way to achieve multi-chunk programs with two-way control transfers between chunks. Everybody is happier (programs are easier to make and smaller) when the silly RAM execution protection is disabled, as shown by the http://tict.ticalc.org/downloads/launchmultiple.tar.bz2 PoC.

Sounds like an interesting project, good luck with it!

Due to e-mail notifications being broken for weeks, I missed quite a number of posts on Omnimaga, starting with this topic...

Have you found out how to use the "faststr" routines, by examining e.g. ebook ? There needs to be a setup phase before you can use the drawing routines.

Also, maybe the fast font drawing routines Lionel mentioned in his post should be added to the GCC4TI libraries?

Indeed, the "faststr" family of routines could and should have been added to TIGCC a decade ago...
However, since he became the only active member of the team, the TIGCC maintainer was a major roadblock to advancing the library and documentation. He explicitly refused my "faststr" series, my "fastitoa" series, someone else's fast fread / fwrite, and various other (potential) contributions which would have been useful to users; even among the contributions that he accepted in principle, he let lots of work languish, for instance a contribution making sprite routines faster and smaller while supporting an additional drawing mode.
GCC4TI broke the community free from his counter-productive stranglehold, but let's be realistic, GCC4TI occurred too late to have any meaningful impact on the activity in the TI-68k native code programming community. I did integrate a subset of my work to GCC4TI, but not the faststr and fastitoa series.

Yup, it's been that way since 2006-2007, and GCC4TI in 2009+ didn't change much the outcome, though nearly all active developers use GCC4TI instead of the unmaintained TIGCC, for obvious reasons.

Did you make the faststr routines from ebook work in your program ?

Is the slowdown from calling C/ASM from BASIC due to having to search through the VAT like on Z80 calcs? I remember that calling ASM programs from Z80 BASIC was very slow because of that and it would get worse and worse as your RAM got lower, so people relied on Flash APPS that installed ASM libs via parser hooks instead, which was much faster.