I've been using Multi-Edit since before Windows - I'm actually still using a pre Win95 16-bit version :-\ and except for Visual Studio I have managed to stay pretty much ignorant of other editors. Having said that, I think it's the bee's knees, but of course, this old version is really showing its age. Even at that, the worst thing I can say about it is that an upgrade to the current version would cost $200 (essentially the new purchase price). The other thing is that it's strictly a Windows program. I've wondered about Jedit, which looks like it might have a lot in common with Multi-Edit, including a built-in macro language, but is available cross-platform. I could be tempted into using a program that works the same under both Windows and Mac OSX. Plus, it's even open-source and free. I just haven't had the motivation and time to dig into it. One big red flag for me with Jedit is is that it's written in Java, and most Java apps I've used exhibit some behaviors which are very jarring for a long-time Windows user (who hates having to reach for the mouse when editing text). Does anyone have any informed opinions on Jedit or any other similar cross-platform programmer's editors?

Well, thanks for trying and welcome to the club! I've scanned around a bit and it seems that there are numerous people who have the same or similar problems (also includes things like the computer taking a long time to respond to the command to shut down or hibernate), and there are a lot of suggestions regarding RAM size, startup config, disk defragmentation, spyware infestations, virus checkers etc etc, but it's all stuff which IMHO has nothing to do with this problem (my computer's performance is otherwise satisfactory, which wouldn't be true if one of these other causes was at work) and certainly no one seems to have the appropriate silver bullet ... - Mannat

Actually, *within* any app I never have problems with keyboard response of any kind. Based on that, my previous notion about the app being last in line would seem to be wrong - but on the other hand, I have found that assigning a particular key combo or even single keystroke (e.g., F5) as a keyboard shortcut to a shortcut on the desktop will prevent any app from seeing that keystroke. So it does seem that the OS can decide quickly that it should not pass a particular keystroke event to the app that has the input focus, but if the keystroke is assigned to a desktop shortcut, it may take a very long time to finally respond. But you asked for examples. I use many Alt-Shift- and similar combinations in my text editor - a *very* old version of Multi-Edit (actually, a 16-bit version, I think). For example: Alt-Shift-L to begin marking text line-by-line, Alt-Shift-B to begin a rectangular text mark, Alt-Shift-U to clear the mark, Alt-Shift-D to delete marked text, Ctrl-K to comment out a line, Ctrl-Shift-K to uncomment, etc. In the same app I use F10 with various combinations of Shift, Ctrl and Alt to open or switch to one of a small set of specific files that I often work with. And of course, every other app has Ctrl- and Alt- combinations for editing and menu shortcuts, all of which work without problems. Following "convention" for keyboard shortcuts assigned to Windows shortcuts, I mostly use Ctrl-Alt- combos for the application shortcuts: Ctrl-Alt-M to open Multi-Edit, Ctrl-Alt-U for Eudora, Ctrl-Alt-W for Winamp, Ctrl-Alt-B for IE (i.e., 'B'rowser), etc. Actually, where a letter key is involved, Ctrl-Alt is the default, with either Ctrl-Shift or Shift-Alt or all three also possible - but single Fn keys without modifiers can also be used. There are also a few Ctrl-Alt- combinations defined in my editor, and they work fine there, as long as there is no Windows shortcut assigned to the same key combo. Anyway, the Windows shortcut usage is the one that often exhibits long delays. Sometimes, the delay is a long one the first time I use a particular one of these shortcuts in a session, and the next time is very short for the same shortcut - but not always. By the way, I use these assignments to open applications, but delays occur in the same way with shortcuts to files or even folders.

Neither / nor - in fact, both CPU activity and kernel times appear to drop to zero during these intervals of hesitation when they occur. As to whether this could be related to a particular installed app - I have my doubts about that, but then I don't know much about the processing of keyboard shortcuts. (Probably, many of you out there know exactly how this works.) My impression is that the OS has a list of potential destinations (e.g., assignments to shortcuts, etc) which is checked first, and that the event gets handed to the app that has input focus if it hasn't been absorbed somewhere else. But the OS list apparently can include vast numbers of (actually unwanted and irrelevant) potential destinations, and under some circumstances my desired shortcut assignments get pushed far down in the list. Anyway, that's how I am able to explain this to myself. But I don't know where this list might exist and how to control what's in it. Am I even on the right track?

(Apologies up front if this message is posted to an inappropriate forum. All suggestions on an alternative are welcome. This is not a programming question, but my previous searches online for info on this topic have turned up little useful info.) I hate using the mouse for non-graphical operations and have keyboard shortcuts assigned for opening various apps that I use frequently. Specifically, they are assigned to various shortcuts located in C:\Documents and Settings\{username}\Start Menu\Programs. The response to these keyboard shortcuts is highly variable - sometimes it's brisk, but it can and often does take up to half a minute for the computer to respond in any noticeable way - i.e., the hard disk is not grinding during that time. Instead, nothing seems to be happening at all. This delay may occur when opening an app or simply when switching to an app which is already open. I've also encountered it after clicking on a file - e.g., a .doc file - in Windows Explorer in order to open the file in its associated app, or after clicking on a web link in an email in Eudora in order to open the link in an IE window. In both of those cases, the delay can occur regardless of whether the associated app is already open, and can be just as long (in the former case, even after a new Word window finally opens, it may still take 20-30 sec for the selected file to start loading, while in the latter case, Eudora grabs the topmost IE window if one or more IE windows is open, rather than opening a new one - and in both cases, the respective app is effectively frozen for any other UI operations in the interim). By contrast, opening or switching to apps by clicking on a program shortcut icon in the Quick Launch bar is always nearly immediate, as is switching apps using Alt-Tab. I've had this problem on more than one computer. It seems to me that it wasn't always that way, but instead has come on over time. Although I don't really remember anymore, I have the vague recollection of noticing that it suddenly became noticeably worse at a certain point in time - maybe after a Windows update, but again I'm not really sure. Does anyone have any notions as to what is going on here, and more importantly, what can be done about it?