ToME Wiki
Problem
I've run into this problem more than once. If you macro the escape key (\e) by mistake then delete the macro it results in the escape key becoming really slow to evaluate. For an example, exiting the inventory screen by pressing escape takes over a second on a modern computer (>2ghz)... Ironically, if you macro anything to do a \e, it is fast and works as normal.
JulesBean: This means you have a macro which begins with \e (the trigger, not the replacement). This is a simple implementation feature of macros: if there is a multi-key macro and one of the initial keys is pressed, the game has to wait an amount of time (and it doesn't matter how fast your computer is, it waits 'real time') to see whether you are going to press the second key. Example: Suppose you macro 'ii' to the identify spell. Then when you type 'i' the computer waits a second to see if you are going to type anything else. If you type something which is not another 'i' then it immediately processes the first 'i' as the inventory command. If you type another 'i' you get your macro. If you type nothing for a second, it realises nothing else is coming along and executes the 'i' as the normal inventory command. The solution to this problem is never to use multi-key triggers, unless the first key is one which you never use for a normal command. Unfortunately, under some systems, such as unix-style systems with curses, the cursor keys may well be sent as 'escape' sequences, and this may may the escape key slow (depending what actual character is send by the escape key on your system).
NeilStevens: And here we have another example of why I wanted ToME to move to one, unified SDL interface. That would allow us to get consistent behavior and improved interface everywhere ToME is run. It's not going to happen, though, so I don't know what to suggest.
Additionally, Append macros to a file has somewhat a serious bug. It always appends the whole macroset to the file, therefore, it adds all the other macros and default keys every time you save your macros creating a huge redundancy in the file. It also wont save if you remove your macro since it will read it from the earlier full saves, resulting in old unwanted macros still active.
This one should be easy to fix.
JulesBean: I prefer 'misfeature' :-P Append macros to a file does exactly what it says on the tin: it appends the macros to a file. I absolutely agree that this is undesirable, causes all hell to break lose if you do it more than once, and provides you with no way to delete macros from the file. It's just not particularly cleverly implemented.
FWIW, here is my suggestion for an also slightly hacky but more robust solution: The default .prf file system should automatically load a file called '<Char Name>-automacro.prf' if it exists. The '@' menu should provide the option to overwrite in entirety (not append to!) this file with your custom macro definitions. Additionally, IMO, the standard '^X' to save key should also save your macros.
Easiness to fix is a relative measure
I agree that there are no particularly challenging programming hurdles to leap, but I htink fixing macros properly will require quite an investment of time. It's not going to be high on my coding priorities list, I'm afraid. Anyone who does think about fixing this should consider making a patch for vanilla angband also; I think the macro code is common between the two versions and most variants, and most variants would benefit from having it fixed.
Chatter
SoulWynd: This thing is really annoying me now. I've tried loading a diferent macroset, restarting ToME, removing any /e macro, etc etc etc. It only goes back to normal if I play a diferent character.
I just fixed it, but I had to open the .prf file and remove every single instance of it... There were lots because I saved the macros over 10 times... I also removed the redundancy from my .prf file, but it will still grow whenever I save the macros again.
JulesBean Don't do that then! The best work-around I know for the current system is to delete the .prf file before you append to it. If you want to get deeply into prf file magic, note that prf files do have an 'include' feature (I:, I think) which you could use to make things more sane.
SoulWynd: It would be just too easy to open the file stream without the append flag and add that function to whatever ^X calls. I mean, that's a two lines fix.