Microemacs and multi edit

Microemacs and multi edit

MicroEMACS is today one of the most advanced text editors on our platform. Power and versatility are surely its main features.
The latter in particular makes it difficult to describe this editor in a few sentences, because talking about an aspect means neglecting undeservedly the other ones.
For this reason, in the past I proceeded to write a series of articles, published in the past issues of QL Magazine, where for each article I described a potentiality or illustrated the utilization of certain options.
This time I will talk about the simultaneous editing of multiple programs, and in order to do this I’ll start by describing two typical “concepts” of MicroEMACS: the window and the screen.
In this article I will use the term “screen” to indicate what is usually called “window” in other environments, such as Windows, to avoid confusion with the MicroEMACS window concept, which is something slightly different.


The screen

In MicroEMACS is called “screen” the entire editable area present in the program, so basically all main screen except for the status bar, title bar, menu and a few other things.
As we know the MicroEMACS screen is resizable and can become very large: for example a full screen resolution 1024 × 768 (you should have at least a 17 inch monitor) provides an editable area of about 60 lines for 160 columns (I’m going by memory).
So a big space, and later we will see how to take advantage of it better.
For now let’s only add that you can have multiple screens, to each of them you can give a mnemonic name of your choice and you have at your dispolsal a commands set in order to open/close/scroll through these screens ad lib using the mnemonic name you set.


The window

Each screen is divided into several parts, called Windows.
You can associate each window to a different file or to view different parts of the same file, or of mixed solutions: there are no restrictions.
Here too, as for the screens, you have at your disposal a commands set to manipulate your Windows at will.
Once clarified these two concepts, with which the beginner often gets confused, let’s see how to use them.
I’m not interested here in listing a deluge of commands. This is an article and not a tutorial, I’m interested rather in communicating using concepts.
Obviously all this has some interest when I need to edit multiple files by time or quickly switch in different areas of a very long file, or even both.


A simple example

I want to transfer the changes made in the program “GOOFY” to the program “PLUTO”. So I open both programs with MicroEMACS, and now I can opt for different solutions:

  1. I can choose for example to have two different screens, to load a program for each screen and switch from one program to another depending on my needs, typically when I have a modest video resolution or if I want to leave the screen free for other tasks.
  2. I can choose to have a single screen and split it into two windows, each of which contains a program. A convenient solution when I have a monitor with a high resolution.

As you can see MicroEMACS not only can easily adapt to your needs, but also to your tastes and your modus operandi without needing to learn different using  philosophies, but simply getting them from tools you already know.


A complex example

A typical complex example is when I have to change the parameters of transition between a main program and a deries of secondary programs.
Imagine you have a program “Donald Duck” that, in two different points of it, will call three subprograms “Huey” “Dewey” and “Louie”. You have to add input parameters.
It will be very convenient in this case to have all four programs open, showing the areas in which I will have to operate.
But having five windows on the same screen can cause too small workspaces, limiting the visibility of the program and slowing down my work.
Therefore I’ll define a screen called “MAIN” in which I’ll have maybe two windows displaying two different parts of the same file (the two points that I have to edit).
Secondly I’ll define another screen, named “CALL”.
Within “CALL” I’ll define three windows in which I’ll insert the three secondary programs.
This way I can either change the screen, or move from one window to another in an extremely easy way, while maintaining a good visibility on all programs and even a certain logical structure of my work. The secondary programs are grouped in the same screen and given that probably, once made the change on the first one I can bring the same on the other two,  it’s useful to have all three points under control.
The same concept is valid for the other screen, where the two editing points of the main program are available on the same screen.


An eye on performance

Someone might object: “why should I complicate my life this absurd way? Let’s open a different editor for each file and it’s a done deal! “.
Certainly it’s true, but this is purely an end user solution rather than a developer’s one.
In other words it’s effective but not efficient.
Let me explain better: each running program, as a matter of common knowledge, takes two memory areas: one for code, the other for data. If we use a multi file editor like MicorEMACS, we employ only one area for the program and a data area for each single file open; if we launch instead a different editor for each file we duplicate the area dedicated to the code.
The visual result does not change, the functionality is the same, but the utilization of our QL resources is very different.
Perhaps someone doesn’t realize exactly how much heavy is this last solution until he make some calculation: let’s try to make it together.
Let’s imagine for convenience of calculation that the hypothetical editor I’m using (no matter what) occupies 50 KB, and that files it opened are all the same size: 10 Kb.
In the case of the simple example (two files) we have:

50 + 10 + 10 = 70 kb used

while in the multi editor case we have:

10 + 50 + 50 + 10 = 120 Kb used

Quite a difference!
Similarly, in case of 5 open files the ram usage increases exponentially, so:

50 + 10 + 10 + 10 + 10 + 10 = 100 KB used


50 + 10 + 10 + 10 + 50 + 50 + 50 + 50 + 10 + 10 = 300 kb!

Given the memory limits of QL, this definitely appears to be an unadvisable choice; even if I have enough memory, I risk to “forget” to be almost at the end of my resources and to open some other application with the risk of computer crash and loss of all my work.
It’s up to you.