Path: utzoo!mnetor!uunet!munnari!moncskermit!goanna!yabbie!koel!cit5!olympic!jim!brw From: brw@jim.odr.oz (Brian Wallis) Newsgroups: comp.emacs Subject: emacs & process filters Message-ID: <456@jim.odr.oz> Date: 5 May 88 01:29:10 GMT Organization: O'Dowd Research Pty. Ltd., Melbourne, Australia. Lines: 33 Keywords: bug? (or feature :-) A while ago I posted an item describing an annoying bug in GNUemacs to do with query-replace-regexp replacing the wrong thing. What happens is the cursor is positioned at the end of the matched string and you decide to type `,' or ` ' to replace and what is replaced is offset one character back towards the head of the file. This happened somewhat randomly. Well, it annoyed the s$#& out of me the other day so I tracked it down. What seems to be happening is that IF between the time query-replace-regexp finds the string and you decide to replace it, the time in the mode line changes... the replace is buggered up. Hmm says I, what is this... Nasty one. display-time-filter in time.el uses the function string-match to fiddle the output from loadst in case there are two or more strings cat'd together (due to stopping emacs for a while) what this does is bugger up the values returned by match-beginning and match-end which I assume are used in some way or other to know what characters to replace when the decision is made! Try it. i-search for something and then ESC ESC (match-beginning 0). wait for the time to change and do match-beginning again, it will decrement by 1 each time the time is updated. I haven't chased this any further yet, but it looks very nasty. The process-filter for loadst must be running asynchronously and thus can bugger up any global values such as in the regexp code. Any comments?-- Brian Wallis (brw@jim.odr.oz) O'Dowd Research P/L. (03) 562-0100 Fax: (03) 562-0616, Telex: Jacobs Radio (Bayswater) 152093