Re: MicroEmacs siz vs functionality
Sorry for the delay in replying (I've just become a Dad and I'm over the
This is a largely unexplored area and not documented - but possible. You will
need a recent release (one with MEOSD defined in emain.h - more on that later)
but there are a few things to bare in mind first.
ME is designed to have a very powerful macro language and a very small (as
small as possible) but very flexible core. All whizzy features such as
emailing, calenders, many of the format commands etc are simply macros (emf
files in the macro directory) and are therefore not a fixed part of ME. For
example, there is only one built in spell command 'spell', it has a really
horrible, unusable interface which is not designed to be used directly by the
user. As a result the code (in spell.c) is only 2200 lines of code (3% of the
source). All the gui's are implemented as macros in spell.emf and dictionaries
in the *.edf files and if you don't use them they are not loaded!
So as the 'Insert' menu is only created when the main menu is opened and each
of the macros called from the insert menu are only loaded when they are
executed, removing the menu will not have as big an effect as you may think
and many of the commands are base functionality which simply cannot be removed
(i.e. insert-file, execute-buffer).
I think there are two reasons for cutting down the size of ME:
1. Save disk space
Switching off all compilable features of ME will only reduce the image
size by 25% (i.e. win32 binary is typically about 400Kb it can be reduced
to about 300Kb) which is not very significant. Doing this also has
drawbacks such as a non-tested version, unexpected side effects etc. This
is not to be recommended.
More significant and safer savings can be made by removing unused runtime
files, e.g. the on-line help file (me.ehf currently 1505Kb and rising),
any dictionary files (*.edf typically 500Kb each). Remove any macro files
(*.emf) you don't use, this is a slower process but currently there are
1470Kb of macro files some of which are just silly games etc.
2. Save run-time memory
Again switching off all features will save 25% of the initial memory used
but if you don't use features like spelling, the help, email etc that is
about all you will save and of course you have the same disadvantages. But
assuming you are making sure that these features aren't used and you need
to save memory then drastic action is required
There are two approaches to reducing the memory (and disk space) being used:
1. Create a new macro environment
This is the simplest and safest approach (changing the ME binary by
disabling features may introduce bugs and nasty side effects - its making
me nervous just thing about it).
Create a new empty ME macros directory and just copy the initialising
me.emf file across, edit it and remove anything that you don't think you
need, you can remove all the "Do I need to do this?" lines as well. Then
run up ME, it will probably complain but it will tell you the line thats
failed - remove it??? Once its up and running use it, what do you miss?
Find out what line sets it up in me.emf and any of the macro files you
need and copy those across and try again.
Alternatively create your own me.emf from scratch - may be quicker.
Its a bit hit and miss but is safe (should have no nasty side effects) and
will drastically reduce the disk usage and should greatly reduce the
2. Compile out unwanted ME features.
I recommend doing this only after doing step 1 and more savings are
required. The binary you will produce will not have been tested and while
I will help with any problems you have I can't promise I can fix them.
In an editor (ME hopefully :-) edit the source file emain.h near the top
you will find 'MicroEmacs Configuration options', the following twenty or
so #defines enable various ME features, by simply changing the '1' to '0'
will switch the feature off, i.e. changing:
#define MEOSD 1 /* enable OSD functionality */
#define MEOSD 0 /* enable OSD functionality */
will disable osd (all the menus and dialogs). But this means that any call
to osd will fail which means that many macros will no longer work (in fact
most things won't, me.emf sets up the main menu, hkc.emf creates a menu
and a help dialog etc), all these will have to be removed.
Disabling some features will have some unexpected side effects, e.g.
disabling HILIGHT will also disable the ident command as it uses the
Hence if you can reduce your requirements by doing step 1 first you may
reduce some of the time and frustration doing this step.
Note that when a feature is disabled the associated commands are not
'removed', they can still be executed producing the error message
"[Command not available]". This is because ME uses a fast hash table
command lookup for better macro performance and so commands cannot be
Hope this helps and if you have any suggestions on how to improve this, or
documentation on how to do this please send them my way,
> Subject: [jasspa] MicroEmacs siz vs functionality
> From: =?iso-8859-1?Q?J=F6rgen=20J=E4germon?= <jorgen_jagermon@...>
> Date: Fri, 03 Nov 2000 15:33:23 +0100
> To: email@example.com
> Hi there.
> I'm using MicroEmacs on a daily basis and would like to find out, ways
> to or documentation about
> HOW-TO recompile MicroEmacs with my own choice of options.
> For example can I remove the menu "Insert" and the underlying
> functionality, the question goes for i.e "Format", "Execute" and
> In other words eventhough MicroEmacs is much lighter than Emacs, I would
> (and maybe someothers) to make it even lighter and slimmer, into only an
> Is it possible to give MicroEmacs the possibility to support a package
> view where one could choose between all or some of the packages.
> I don't use ME for emails, calendar, insertions, formatting, etc.
> Best regards J�rgen J., Stockholm, Sweden.
> J�rgen J�germon (SC/J�J) E-mail: jorgen_jagermon@...
> Mixed Signal EDA support Tel : +46 (0)8 580 24 522
> MITEL Medical Semiconductor BU Fax : +46 (0)8 580 20 190
> Bruttov�gen 1, Box 520 Web : http://www.mitelsemi.com
> SE-175 26 J�rf�lla, SWEDEN http://www.mitel.se
> This is an unmoderated list. JASSPA is not responsible for the content of
> any material posted to this list.