emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-diffs] Changes to emacs/etc/PROBLEMS


From: Jason Rumney
Subject: [Emacs-diffs] Changes to emacs/etc/PROBLEMS
Date: Mon, 14 Jan 2002 16:07:59 -0500

Index: emacs/etc/PROBLEMS
diff -c emacs/etc/PROBLEMS:1.104 emacs/etc/PROBLEMS:1.105
*** emacs/etc/PROBLEMS:1.104    Mon Jan 14 08:51:13 2002
--- emacs/etc/PROBLEMS  Mon Jan 14 16:07:59 2002
***************
*** 40,46 ****
  
  The error message might be something like this:
  
!  Converting d:/emacs-21.1/leim/CXTERM-DIC/4Corner.tit to quail-package...
   Invalid ENCODE: value in TIT dictionary
   NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code
         '0xffffffff'
--- 40,46 ----
  
  The error message might be something like this:
  
!  Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package...
   Invalid ENCODE: value in TIT dictionary
   NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code
         '0xffffffff'
***************
*** 342,350 ****
  An inactive cursor remains in an active window after the Windows
  Manager driven switch of the focus, until a key is pressed.
  
! Windows 2000 input methods are not recognized by Emacs (as of v21.1).
! These input methods cause the keyboard to send characters encoded in
! the appropriate coding system (e.g., ISO 8859-1 for Latin-1
  characters, ISO 8859-8 for Hebrew characters, etc.).  To make this
  work, set the keyboard coding system to the appropriate value after
  you activate the Windows input method.  For example, if you activate
--- 342,350 ----
  An inactive cursor remains in an active window after the Windows
  Manager driven switch of the focus, until a key is pressed.
  
! Windows input methods are not recognized by Emacs (as of v21.1).  Some
! of these input methods cause the keyboard to send characters encoded
! in the appropriate coding system (e.g., ISO 8859-1 for Latin-1
  characters, ISO 8859-8 for Hebrew characters, etc.).  To make this
  work, set the keyboard coding system to the appropriate value after
  you activate the Windows input method.  For example, if you activate
***************
*** 353,364 ****
  appropriate keyboard encoding automatically, but it doesn't do that
  yet.)
  
! Multilingual text put into the Windows 2000 clipboard by Windows
  applications cannot be safely pasted into Emacs (as of v21.1).  This
! is because Windows 2000 uses Unicode to represent multilingual text,
! but Emacs does not yet support Unicode well enough to decode it.  This
  means that Emacs can only interchange non-ASCII text with other
! Windows 2000 programs if the characters are in the system codepage.
  Reportedly, a partial solution is to install the Mule-UCS package and
  set selection-coding-system to utf-16-le-dos.
  
--- 353,364 ----
  appropriate keyboard encoding automatically, but it doesn't do that
  yet.)
  
! Multilingual text put into the Windows clipboard by other Windows
  applications cannot be safely pasted into Emacs (as of v21.1).  This
! is because Windows uses Unicode to represent multilingual text, but
! Emacs does not yet support Unicode well enough to decode it.  This
  means that Emacs can only interchange non-ASCII text with other
! Windows programs if the characters are in the system codepage.
  Reportedly, a partial solution is to install the Mule-UCS package and
  set selection-coding-system to utf-16-le-dos.
  
***************
*** 521,530 ****
  
  The solution is to downgrade to an older version of the Cygwin DLL
  (version 1.3.2 was reported to solve the problem), or use the stock
! Windows FTP client, usually found in the `C:\WINDOWS' directory.  To
! force ange-ftp use the stock Windows client, set the variable
! `ange-ftp-ftp-program-name' to the absolute file name of the client's
! executable.  For example:
  
   (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe")
  
--- 521,530 ----
  
  The solution is to downgrade to an older version of the Cygwin DLL
  (version 1.3.2 was reported to solve the problem), or use the stock
! Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT'
! directory.  To force ange-ftp use the stock Windows client, set the
! variable `ange-ftp-ftp-program-name' to the absolute file name of the
! client's executable.  For example:
  
   (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe")
  
***************
*** 788,793 ****
--- 788,801 ----
  cleanly before exiting Emacs. For more details, see the FAQ at
  http://www.gnu.org/software/emacs/windows/.
  
+ * Windows 95/98/ME crashes when trying to run non-existant subprocesses.
+ 
+ When a subprocess you are trying to run is not found on the PATH,
+ Windows might respond by crashing or locking up your system.  In
+ particular, this has been reported when trying to compile a java
+ program in JDEE when javac.exe is installed, but not on the system
+ path.
+ 
  * Mail sent through Microsoft Exchange in some encodings appears to be
  mangled and is not seen correctly in Rmail or Gnus.  We don't know
  exactly what happens, but it isn't an Emacs problem in cases we've
***************
*** 1202,1208 ****
  events with the modifiers Right-Alt and Left-Ctrl.  Since Emacs cannot
  distinguish AltGr from an explicit Right-Alt and Left-Ctrl
  combination, whenever it sees Right-Alt and Left-Ctrl it assumes that
! AltGr has been pressed.
  
  * Under some Windows X-servers, Emacs' display is incorrect 
  
--- 1210,1217 ----
  events with the modifiers Right-Alt and Left-Ctrl.  Since Emacs cannot
  distinguish AltGr from an explicit Right-Alt and Left-Ctrl
  combination, whenever it sees Right-Alt and Left-Ctrl it assumes that
! AltGr has been pressed.  The variable `w32-recognize-altgr' can be set
! to nil to tell Emacs that AltGr is really Ctrl and Alt.
  
  * Under some Windows X-servers, Emacs' display is incorrect 
  
***************
*** 1497,1520 ****
        }
        else {
  
- * Problems running DOS programs on Windows NT versions earlier than 3.51.
- 
- Some DOS programs, such as pkzip/pkunzip will not work at all, while
- others will only work if their stdin is redirected from a file or NUL.
- 
- When a DOS program does not work, a new process is actually created, but
- hangs.  It cannot be interrupted from Emacs, and might need to be killed
- by an external program if Emacs is hung waiting for the process to
- finish.  If Emacs is not waiting for it, you should be able to kill the
- instance of ntvdm that is running the hung process from Emacs, if you
- can find out the process id.
- 
- It is safe to run most DOS programs using call-process (eg. M-! and
- M-|) since stdin is then redirected from a file, but not with
- start-process since that redirects stdin to a pipe.  Also, running DOS
- programs in a shell buffer prompt without redirecting stdin does not
- work.
- 
  * Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs:
  
  There are two DJGPP library bugs which cause problems:
--- 1506,1511 ----
***************
*** 1591,1601 ****
  This character seems to be trapped by the kernel in Windows 95.
  You can enter M-f6 by typing ESC f6.
  
! * Typing Alt-Shift has strange effects on Windows 95.
  
  This combination of keys is a command to change keyboard layout.  If
  you proceed to type another non-modifier key before you let go of Alt
! and Shift, the Alt and Shift act as modifiers in the usual way.
  
  * `tparam' reported as a multiply-defined symbol when linking with ncurses.
  
--- 1582,1594 ----
  This character seems to be trapped by the kernel in Windows 95.
  You can enter M-f6 by typing ESC f6.
  
! * Typing Alt-Shift has strange effects on Windows.
  
  This combination of keys is a command to change keyboard layout.  If
  you proceed to type another non-modifier key before you let go of Alt
! and Shift, the Alt and Shift act as modifiers in the usual way.  A
! more permanent work around is to change it to another key combination,
! or disable it in the keyboard control panel.
  
  * `tparam' reported as a multiply-defined symbol when linking with ncurses.
  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]