At some point, python became the language I use the most. And its IDEs… are frankly not really great. They are doing their best, but given the dynamic nature of the language, the experience of using autocomplete and other similar features is often jarring enough, when it doesn't do what you want it to do, to be annoying.
So I mostly stuck with really simple text editors (first likes of notepad++, geany and gedit, later switched to barely customized vim). You learn the language, you learn its standard lib, you learn the libraries you use often, you learn to navigate their docs. You learn the project you are working on, and remember how things are named. I do use a simple autocomplete (ctrl+n in vim), but it's more of a typo preventer (or a typo propagator, depending on how you look at it). It autocompletes every word in open files. Which might be more handy than it sounds, because it will autocomplete stuff not typically being autocompleted in IDEs, like json keys, or file names in the open directory listings, or even outputs in the open terminal session.
As for navigating unfamiliar code bases and "go-to-definition": it's grep. Just search for a substring in the whole project. You will find the definition. You will also find some other interesting stuff, which "normal" IDE tools wouldn't look into. Heck, you'll find interesting comments, interesting name clashes, interesting usecases for a thing you were looking for. And it's a language agnostic skill. You don't need another bespoke IDE, you don't need to configure some weird LSP to navigate unfamiliar code base even in not so familiar language.
Yes, raylib does support android. I have a slightly incomplete build script I use for my raylib projects (obviously you need to take better care of signing, you probably want to build for other targets besides aarch64, your SDK is probably not installed in /home/denis, and I'm not sure whether I'm adding .so files to apk in a way modern android prefers, but it still works).
Some time ago many people in Russia wished that Russia will become a normal European country. I guess the wishes were granted, but not in a way we wanted.
I started with the basic family of languages. VB6, QBasic (yes in this strange order), VB.Net, PowerBasic, FreeBasic.
FreeBasic was probably the most fun of them to me: cross-platform, compiles to fairly fast running binaries, can easily interface with libraries written in C, and has qbasic syntax mode.
Modding a game means that you have a specific starting point, the original game, which you are probably a fan of. And you may want your creation to be a part of this original world, share some (or most) of gameplay elements, design elements, story elements etc.
People modded Half-Life not only because modding Half-Life was somewhat easier than making an FPS game from scratch, but also because they wanted to explore the original story from another angle, or they liked how engine feels to play, or for whatever other reason wanted a starting point to be a complete game. Kind of the original asset store: the assets of the game you are modding.
With modern tooling packaging pure python code to be used by other python developers is a relatively painless process.
The main problem with python packaging is that it's often C/C++ packaging in disguise, among multiple OSes and CPU architectures, and that's far from being solved. Building such python wheel is essentially like building a "portable" (aka one you don't need to properly install into the system) linux/windows/macos application. That comes with a variety of caveats and requires some specialized knowledge one wouldn't pick up playing around with just python alone.
We prefer option c: add a new table/column with similar looking name. Then few years later start wondering why there're two almost identical entities, and why one of them behaves weirder than another.
So I mostly stuck with really simple text editors (first likes of notepad++, geany and gedit, later switched to barely customized vim). You learn the language, you learn its standard lib, you learn the libraries you use often, you learn to navigate their docs. You learn the project you are working on, and remember how things are named. I do use a simple autocomplete (ctrl+n in vim), but it's more of a typo preventer (or a typo propagator, depending on how you look at it). It autocompletes every word in open files. Which might be more handy than it sounds, because it will autocomplete stuff not typically being autocompleted in IDEs, like json keys, or file names in the open directory listings, or even outputs in the open terminal session.
As for navigating unfamiliar code bases and "go-to-definition": it's grep. Just search for a substring in the whole project. You will find the definition. You will also find some other interesting stuff, which "normal" IDE tools wouldn't look into. Heck, you'll find interesting comments, interesting name clashes, interesting usecases for a thing you were looking for. And it's a language agnostic skill. You don't need another bespoke IDE, you don't need to configure some weird LSP to navigate unfamiliar code base even in not so familiar language.