xhartae/chapter/chapter_4.h

/*
Copyright (c) 2023 : Ognjen 'xolatile' Milan Robovic

Xhartae is free software! You will redistribute it or modify it under the terms of the GNU General Public License by Free Software Foundation.
And when you do redistribute it or modify it, it will use either version 3 of the License, or (at yours truly opinion) any later version.
It is distributed in the hope that it will be useful or harmful, it really depends... But no warranty what so ever, seriously. See GNU/GPLv3.
*/

#ifndef CHAPTER_4_HEADER
#define CHAPTER_4_HEADER

#include "chapter_0.h"
#include "chapter_1.h"
#include "chapter_2.h"
#include "chapter_3.h"

/*
I believe that this chapter should be a breakpoint for you to write a simple C program. So far, we've learned in:

- chapter 0: To format our code properly in order to increase readability and we've implemented some core functions for memory management, strings and input / output.
- chapter 1: To declare and define functions, and we've covered character and file descriptor related functions, as well as ASCII table and discussed C keywords.
- chapter 2: To use external variables, function pointers and minor part of 'libncurses' reimplementation that doesn't care about portability.
- chapter 3: To use standard library 'printf' function, and to implement variadic argument functions, while also covering switch statement in more depth.

From this moment onwards, some chapters will have few functions called 'program_*', which we can use to forge even larger programs. They'll each have their own dependencies, for
example, some of them will require functions from some or all previous chapter source and header files, but I'll make sure not to use in them functions that'll be in future
chapters. Instead of that, we'll (re)implement newer stuff with different approach if necessary. That way, you can be sure that if you're reading chapter four, for example, it'll
only use functions and variables defined in chapters zero to three. Lets begin.

I'll write this huge 'syntax_render_file' function in somewhat procedural style of programming, so to say, and in the next chapter, we'll use more modular way, using many more
functions. Learning anything, including the C programming language, is like a journey. Maybe you think it won't last long, and it ends up being quite long journey, or maybe you
think it'll be very long, that you'll walk miles and miles, and it ends up being short (you rage-quit). The final destination you're going towards always depends on where you
left-off and where you're coming from. For example, if you wrote Ada, you'll like chapter four, if you wrote C++, you'll like chapter five.

I'll also list a few "traps" right here, where most programmers get caught in:

- My program needs to be cross-platform, fully portable, to run on Windblows, Machos, Leenoocks, Raspberries and on Commodore 64.
- My program needs to be huge, multiple files and folders, everything is abstracted out, even the wrappers for some library.
- My program doesn't need to free used memory, my operating system will do it for me, I don't care about memory leaks, only nerds do.
- My compiler warns about stupid things, I don't want to fix all compiler warnings, it'll make the code look bad.

First of all, there are a lot of standards, people who don't have more important work to do make those. There are a lot of CPU architectures, x86-64 being used a lot, then ISA
(instruction set architecture) such as CISC, RISC, MISC, OISC, and even more things that should't matter for you like SIMD, AVX, ST, MMX, XMM, YMM, ZMM, et fucking cetera. Then,
we have many many GPU hardware, they each have some part of their own ISA, writing direct code for one GPU won't work on other GPUs, so we need to use OpenGL, Vulkan or Direct3D.
Do you see where this is going, adding complexity on top of complexity, abstracting the abstractions, due to standardization.

If every company make their own standard, thinking they're smartest, there's no standardization. Just look at the mirror, at your PC, laptop, whatever, then take a look outside
the window, and say out loud "My program will be written in C, it will run on 64-bit CPUs, it will depend only on Vulkan API, it will use XCB for display.". Take a deep breath,
you're not writing some part of the program for the company, you're having fun, you're sane. Then again, pray to Khronos, your OS maintainers or developers and your GPU vendor
that your GPU supports Vulkan, that someone there, out in the big white world wrote a driver for it.

Keep in mind that I don't work for any programming related company and I want to, also I don't have college, I learned C by writing it a lot and reading it from time to time. Now,
hear me out, if 1000 people with some CS degree wrote a simple C program, all of those would look very similar. That's because they've been programmed into that line of thinking,
which is dangerous in my opinion for one reason: They think they're always right. I learned a lot from talking with smart people, some of them have CS degree, some not, so I don't
own what I know, no one owns anyones' knowledge, but they weren't always right. So, if you don't have a CS degree, you can learn C easier, that's my point.
*/

extern int  syntax_define (int enrange, int derange, char * begin, char * end, char escape, int colour, int effect);
extern int  syntax_select (char * string, int * length);

extern void syntax_highlight_c   (void);
extern void syntax_highlight_ada (void);

extern void syntax_render_file (char * text_file, int x, int y);

#endif