Fixed for 19.34.5: - fix infinite loop in etags (getpid calls itself). => remove getpid definition from lib-src/ntlib.c - include modified .el files in binary distribution -> put all .el files in separate -lisp.tar.gz file => Done. - investigate problem with return code from rcsdiff always being 0 (was correct under 19.34.2). Supposedly called like: (setq status (call-process "rcsdiff" nil t nil "-q" "-r1.151" "-c" "standard-emacs.el")) => Had commented out synch_process_alive code in sys_wait, thinking the change to sys_select made it obsolete. Not so! - problem reported by haczegledi@scaleable.com (Harold Czegledi): emacs would abort() during startup (just on one NT4.0 system) - he downloaded source and tracked it to win_msg_worker getting WM_TIMER for NULL hwnd. => No reason for win_msg_worker to abort() on unexpected messages - changed to DebPrint. Possibly symptomatic of optimizer bugs though? - put site-lisp directory ahead of normal lisp directory. => Done. Fixed in addpm.c and emacs.bat.in. - fix problems with CRTAPI1 references in sysdep.c and MSVC5.0. => Done. Always define CRTAPI1 as _cdecl in CFLAGS. - add redisplay patches: http://www.cs.washington.edu/homes/voelker/ntemacs/patches/19.34.2/redisplay-fixes.diff => Done. (Only avoids unnecessary rebuilding of menu bars on every keystroke when transient-mark-mode is enabled and mark is active.) - define a default handler for mouse-wheel events (see pretest-19.35). => Done. Used handler from Howard Melman . - change cmdproxy to pass on extra (unrecognised) args, such as /q. => Done. - change raise-frame (or select-frame?) to grab input focus as well. raise-frame should raise to front of all windows, even if Emacs is not in the foreground. -> Reply from RMS: raise-frame and select-frame should continue to work as they do now (ie. raise-frame does not transfer input focus, nor does select-frame), but other-frame should transfer input focus. => Define win32-focus-frame which gives frame input focus, even if Emacs was not the foreground application; this also brings it to the top of the Z order. other-frame now calls this on Windows. ==> [2-Aug-97] Changed x_raise_frame to make frame the foreground window by default - this fits better with the normal use of raise-frame, and users expectations when using click-to-focus. We allow the strictly correct behaviour by setting win32-grab-focus-on-raise to nil, mainly for users that choose point-to-focus (aka xmouse) and prefer the normal behaviour. -> auto-lower-mode seems to work correctly, but not auto-raise-mode. => Actually, I misunderstood what these are supposed to do (frames should auto-raise or auto-lower when the mouse moves in or out of the frame respectively); neither works for that, or rather both probably would if point-to-focus was enabled. - Change other-frame to warp mouse on win32 if win32-point-to-focus is t (this allows people to use x mouse if desired). => Done. - check if [backtab] is a proper keysym (in X) rather than [S-tab]. -> Apparently so; it is included in the keyboard.c keysym map for X. Still, I don't think it is appropriate to make S-tab appear to be backtab, since there are a number of other Windows or X specific names (eg. cut, copy and paste on X but not Windows, and lwindow, rwindow on Windows but not X). - Edit menu lists keystrokes shortcuts called cut, copy and paste! -> See previous item; X supports extra special purpose keys which have no equivalent in Windows. Should probably change keystroke equivalents listed in Edit menu though. - stop Caps lock acting as shift modifier for arrow keys, etc. -> provide win32-capslock-is-shiftlock (default nil) to control -> see patch provided by jmorey@tbi.com (John Morey) => Done (applied John's patch since it is small). - typing backspace when entering ange-ftp password (or RMAIL/GNUS pop password) aborts the password entry. -> Shouldn't [backspace] be mapped to DEL somewhere? => It is, by function-key-map, but only when input is read by read-key-sequence; ange-ftp uses read-char, apparently quite deliberately, so there is no bug here. It would be good to extend ange-ftp-read-password though. ==> It turns out there is a mechansim to tell read-char that certain non-ascii chars should be mapped to ascii (by putting the ascii_character property on the keysym symbol). Moved definitions from win32-win.el to winnt.el (since we can read keysyms in terminal mode as well), and uncommented the definitions for backspace and delete. - implement function to change process priority; possibly provide switches (/high, /low, etc) for runemacs as well. => Implemented win32-set-process-priority, and added -high and -low switches to runemacs. (Allow / as switch char in runemacs.) - debug problem with addpm.exe causing GPF on Win95. -> according to Stainless Steel Rat , this problem goes away when using the unoptimized build! (Might be a red herring though, since addpm sometimes doesn't recreate icon if already exists as required? Come to think of it, it's the optimized build addpm that does that.) => Fixed. The problem was that idDde variable was not initialized - the docs say that it must be a valid Dde session id if not 0. - fix addpm to put quotes around icon and exe paths when creating Start menu icon. => Done. - problem reported running emacs -nw by "Ray Rizzuto" : If I have a shell buffer and run the command suspend-emacs, the dos box is locked up tight. Either command alone works fine. -> on NT4.0, when exiting the dos prompt emacs seizes up. => Fixed. sys_subshell was calling wait_for_termination, which is wrong because shell is already run synchronously. (Emacs only seizes up if a subprocess was running at the time, because then we wait for it to terminate, otherwise wait() fails immediately.) - manage notion of current directory entirely within Emacs to avoid conflicts when renaming or deleting directories; on startup change real cwd to where emacs.exe is located and leave it there. Save the current_dir param to child_setup to use in CreateProcess. => Done. - work out why movemail.exe in 19.34.4 tries to load ws2_32.dll, when version from 19.34.1 doesn't. -> MSVC4.x version of wsock32.lib appears to reference ws2_32.dll, not wsock32.dll as before (quite naughty, since there is a ws2_32.lib). May need to implement fully dynamic linking. => This isn't true for version compiled (using MSVC4.2) on sweetpea. Double check on woozle. ==> Fixed. On woozle, baselibs (in ntwin32.mak) includes ws2_32.lib; this was included in $(LIBS) which was ahead of wsock32.lib - just reversed order on link line. - Christopher Stacy reports that save-file to NFS drive is much slower in 19.34.4 and 19.34.3. -> Today (5-Aug-97) Christopher reports that slowdown has stopped. Suspects that NFS was misbehaving. - Ray Peck reports that C-c C-c in shell buffer doesn't seem to work properly, either with the standard shell or tcsh. => Appears to be problem with subprocess, not something that has stopped working since 19.34.1. In any case, have provided win32-process-share-console to allow subprocesses to inherit the Emacs console, and so Emacs calls GenerateConsoleCtrlEvent as in days of old. - Guido Van Hoecke suggests changing make-temp-name to replace invalid filename chars. -> Geoff suggests that browse-url-on-region should be applying convert-standard-name to the buffer name before passing to make-temp-name. -> also fix make-auto-save-file-name to replace all invalid chars. (should simply apply convert-standard-name) => Implemented convert-standard-name in winnt.el to replace all invalid chars (not just * and ?) with !, and changed make-auto-save-file-name to use convert-standard-name. Have left make-temp-name as is for now, although I think there is a reasonable case for make-temp-name calling convert-standard-name on the prefix first. - Steve Kelem reports that 'e' in dired mode on a directory truncates the directory name on Win95. -> Could not reproduce on Win95b or NT4.0. - verify that asynchronous shell-command's work correctly. => Appear to be okay now. - Jacob Colman reports problems with 2nd frame not responding until he Alt-Tabs back to first frame. NT3.51sp5. -> Suspect that Emacs thinks frame is obscured, so makes it iconified, but it isn't really. Only when we get a WM_PAINT message, by covering and reexposing window, does it wake up. -> Maybe WM_ACTIVATE(APP), or WM_WINDOWPOSCHANGED, are good opportunities for checking in frames are visible? => Now check whether obscured frames are visible and mark them as such, not just the other way round. (Also change it so that obscured frames still appear to be "visible" to lisp, as far as frame-visible-p is concerned, but redisplay code doesn't bother with them. This means other-frame etc will still consider them as visible frames, as we expect.) When an obscured frame is found not to be obscured any more, call record_asynch_buffer_change to queue an event to ensure Emacs wakes up and calls redisplay. - investigate bug reports from Jason Rumney : + bold text has shadows when typing; refresh clears them. -> not reproduced, on NT at least. Perhaps a driver bug. + cmdproxy(?) beeps continuously under Win95 when doing texinfo-format-buffer -> Only subprocess used is "sort -fd"; on NT it doesn't work, but runs okay (doesn't like -fd). Same result on Win95b. + Emacs crashes (unhandled exception in kernel32.dll) when gnuserv communicates with Emacs while a menu is pulled down. -> Couldn't reproduce on NT4.0 or Win95b, but have seen other problems on Win95 with menu reconstruction while active. => Believe fixed by menubar change below. - Paul Kinnucan reports that selecting menu items when running on Win95 tends to crash Emacs, especially for dynamically added menus. Also, selecting menus typically takes several mouse clicks before a popup menu stays open long enough to select something? -> see report from Jason Rumney -> reproduced on Win95b: active menu becomes unusable if menu tree is rebuilt while active, and usually goes away altogether a few seconds later. After a while, usually get a GPF in user.exe which is pretty fatal to the system. (On NT, the active menu loses its "connection" with the parent menu(bar) but is still usable.) Proper fix is to implement (at least partial) lazy menu construction, and delay reconstruction while menu bar is active. -> More precisely, don't change menubar when active, and simply delete all submenus and refill with new submenus when reconstructing. Can implement "deep_p" code later. => Done. Menubar changes are locked out while menus are active; even when not active, menubar changes do not delete the root menubar itself, which I suspect is what confuses applications like DragonDictate. Instead just the contents are recreated. Also, the basic mechanism is now in place to implement lazy menu construction. - Frederick J Sieber reports that (global-set-key [escape f4] 'grep) doesn't work on Win95, but does on Unix. => Geoff posted a fix (escape wasn't being generated as a keysym). - closing Emacs frame with mouse puts up menu of choices, but does not show question. (Check how x-popup-dialog is implemented.) -> probably related bug: selecting File->Exit in menu bar gives an error "invalid argument type windowp, nil" -> probably related, "Rosbach, Hans A." : search->bookmark->Jump to bookmark gives error "Wrong type argument: integerp, nil" C-x r b works correctly => apply patch from Michael Welsh Duggan that got missed out before - Warren Jones reports that (file-directory-p "x:/") returns nil when "x:/" is the root of an 8.3 file system. Fix to map_win32_filename is included (very small). => Applied Warren's patch. - Dmitry Yaitskov reports that Cyrillic characters (typed directly in Russian input locale, or even pasted from clipboard) get turned into '?' in Emacs. (The font displays Cyrillic characters correctly, so it is definitely an input bug.) -> I suspect that NT is mapping characters from the input locale (Russian) to the Emacs process locale (ANSI codepage), and of course the Cyrillic characters aren't present in 1252 codepage so they get mapped to '?' (the default character). => Implement win32-set-locale to change the default codepage. ==> Implemented win32-set-current-locale, plus win32-get-current-locale-id, win32-get-default-locale-id, and win32-get-locale-info to provide building blocks for writing more user-friendly routines to query and change locale. - check whether auto-translate.el is broken or not - maybe make it standard as well? -> David Bassin reports that auto-translate is broken because the buffer is now empty when check-buffer-file-type is called. => auto-translate should hook into after-insert-file-functions, or something similar, not check-buffer-file-type. -> consider implementing proper auto text format detection (CRLF, LF, CR) which is automatically preserved. (Also, as a side-effect, keep all Emacs source files in their original format. :-) => done in 20.0, probably not worth doing for 19.34.5. ==> Implemented a simple mechanism to detect EOL format for text files (those for which find-buffer-file-type returns nil) - if the file uses Unix eol format, buffer-file-type is automatically reset to t by insert-file-contents. Also, the buffer-local variables buffer-file-lines and buffer-file-dos-lines are set by insert-file-contents to the number of lines (ie. LFs) and the number of DOS format lines (ie. pairs of CRLFs) respectively in the inserted file (or portion thereof). (If both are non-zero and not equal, it implies the file had a mixture of line endings, and should probably be reinserted in binary mode. A function on after-insert-file-functions could check this and prompt.) - implement functions to access the standard system menu operations (maximise, restore, minimize), and a function to activate the menu bar (to be bound to f10 by default). -> not so important now, as someone has written an external package to do this. Can provide functions to maximize and restore (minimize already exists). Activating menu bar seems more difficult - not sure how to do it. => Implemented win32-send-sys-command which posts a WM_SYSCOMMAND message with the specified code to a frame's window. The docstring lists the useful code values for maximising, minimising and restoring windows, and for activating the menubar. Bound f10 to command for activating menu bar. - check report from "David M. Fellows" that command.com does not respond when buffer directory is f:/, but does when buffer directory is c:/ (cmdproxy is SHELL). -> Could not reproduce on Win95b. => More info from David: only happens when current drive is a Netware volume (possibly just with the Novell Client32?) - David discovered that passing the current environment block to CreateProcess (instead of passing NULL which should amount to the same thing) seems to cure the problem. - investigate archive-extract from zip files using pkunzip. -> reports error on NT4.0; presumably pkzip failed because output directory is long name. Works okay on Win95. -> user reports that NT3.51 crashes (or just emacs?) => The e_lfanew field in the DOS_HEADER of the pkunzip executable was bogus. Checking that the field has a somewhat reasonable value (points inside the executable) solves the problem for now. - "Ray Rizzuto" reports that ping and Java RMI calls don't work when run from shell buffer on Win95. => Had (setenv "windir" nil) in startup file. Removing this fixed the problem. - investigate file-truename on Win95: "Ray Rizzuto" reports that xyz.c, xyz.C and XYZ.C are all treated as distinct (long filename is xyz.c). -> Couldn't reproduce on Win95b (or NT) - try Win95a => find-file-visit-truename needed to be set to t - write win32-check-configuration to warn if cmd.exe or command.com is being used as the user shell. Check shell-file-name, shell-command-switch, (getenv "SHELL"), win32-quote-process-args and anything else that's relevant. Run automatically during startup after .emacs is loaded.