[Emacs-diffs] Changes to emacs/admin/FOR-RELEASE [emacs-unicode-2]

[Miles Bader]

Index: emacs/admin/FOR-RELEASE
diff -c emacs/admin/FOR-RELEASE:1.5.2.7 emacs/admin/FOR-RELEASE:1.5.2.8
*** emacs/admin/FOR-RELEASE:1.5.2.7     Fri Nov 12 02:53:04 2004
--- emacs/admin/FOR-RELEASE     Fri Nov 19 06:55:12 2004
***************
*** 2,11 ****
  
  * NEW FEATURES
  
- ** Test the mbox branch of Rmail.
- 
- ** Install the mbox branch of Rmail.
- 
  ** Face remapping.
  
  ** Let mouse-1 follow links.
--- 2,7 ----
***************
*** 36,41 ****
--- 32,84 ----
  
  ** Clean up flymake.el to follow Emacs Lisp conventions.
  
+ ** Fix up url-ldap.el.
+ 
+ * BUGS
+ 
+ ** Mailabbrev should quote addresses to correspond to RFC 822.
+ See http://article.gmane.org/gmane.emacs.devel/27585
+ 
+ ** The '@' character should not expand addresses in mailabbrev
+ See http://article.gmane.org/gmane.emacs.devel/27585
+ 
+ ** Bug in url-http-parse-headers, reported in
+ From: Vivek Dasmohapatra <address@hidden>
+ Date: Tue, 28 Sep 2004 16:13:13 +0100
+ 
+ Fetching a url with url-retrieve can reult in an anrbitrary buffer
+ being killed if a 401 (or possibly a 407) result is encountered:
+ 
+ url-http-parse-headers calls url-http-handle-authentication, 
+ which can call url-retrieve. 
+ 
+ This results in the current buffer being killed, and a new http buffer 
+ being generated. However, when the old http buffer is killed, emacs 
+ picks the top buffer from the list as the new current buffer, so by the 
+ time we get to the end of url-http-parse-headers, _that_ buffer is marked 
+ as dead even though it is not necessarily a url buffer, so next time the 
+ url libraries reap their dead buffers, an innocent bystander buffer is 
+ killed instead (and an obsolete http buffer may be left lying around too).
+ 
+ A possible fix (which I am currently using) is to call set-buffer
+ on the return value of url-http-parse-headers:
+ 
+       (case url-http-response-status
+       (401
+        ;; The request requires user authentication.  The response
+        ;; MUST include a WWW-Authenticate header field containing a
+        ;; challenge applicable to the requested resource.  The
+        ;; client MAY repeat the request with a suitable
+        ;; Authorization header field.
+        (url-mark-buffer-as-dead (current-buffer))
+        (set-buffer (url-http-handle-authentication nil)))
+ etc ....
+ 
+ which makes sure that it is the right http buffer that is current when 
+ we come to mark the http buffers as dead.
+ 
+ 
+ 
  * GTK RELATED BUGS
  
  ** Make GTK scrollbars behave like others w.r.t. overscrolling.
***************
*** 108,166 ****
  Update: Maybe only reveals itself when compiled with GTK+
  
  
- ** Clicking on partially visible lines fails
- 
- From: David Kastrup <address@hidden>
- Date: 27 Apr 2004 16:42:58 +0200
- 
- I had gnus display a mouse-highlighted line (a URL from browse-url)
- partially at the bottom of its window.  If I click with middle mouse
- key on it, the window gets recentered while I hold the mouse key
- pressed.  If I release it, the window returns into its old position
- (cursor in top row) and nothing happens, presumably because the click
- was not registered on the line itself, but on the magically
- recentered version.
- 
- That is a nuisance.  Recentering of even partially visible click
- targets should only happen if window-point moves there, but not at
- the time of the click.  From the moment I hold down a key until it
- gets released, the displayed window portion should not change, with
- the sole exception of scrolling when dragging at the edge of the
- screen.
- 
- 
- ** Can't drag modeline when mouse-autoselect-window is set
- 
- From: Klaus Zeitler <address@hidden>
- Date: Mon, 11 Oct 2004 11:14:49 +0200
- 
- 1. start emacs -q --no-site-file
- 2. set variable mouse-autoselect-window to t
- 3. split-window-vertically
- 
- now I can drag the modeline only upwards but not downwards
- 
- 
- ** line-spacing and (recenter -1)
- 
- From: SAITO Takuya <address@hidden>
- Date: Mon, 31 May 2004 02:07:57 +0900 (JST)
- 
- (recenter -1) does not show point at the bottom of the window
- if line-spacing is set to positive integer.
- 
- Start emacs -Q, and evaluate below:
- 
- (progn
-   (setq line-spacing 1)
-   (dotimes (i (window-height))
-     (insert "\n" (int-to-string i)))
-   (recenter -1))
- 
- Then, point is displayed at the center of the window.
- But point should be displayed at the bottom of the window like Emacs-21.3.
- 
- 
  ** line-spacing and Electric-pop-up-window
  
  From: SAITO Takuya <address@hidden>
--- 151,156 ----
***************
*** 177,182 ****
--- 167,198 ----
  Electric-pop-up-window can use it.
  
  
+ ** Partial highlighting of wrapped overlay
+ 
+ From: Ralf Angeli <address@hidden>
+ Date: Mon, 18 Oct 2004 19:09:19 +0200
+ 
+ If you put
+ 
+ (let* ((length (+ (- (window-width) (current-column)) 40))
+        (start (point))
+        (end (+ (point) length))
+        (string (make-string length ?x))
+        ov)
+   (insert string)
+   (setq ov (make-overlay start end))
+   (overlay-put ov 'mouse-face 'highlight)
+   (overlay-put ov 'display string))
+ 
+ into the *scratch* buffer and type `C-x C-e' with point at the last
+ parenthesis, you will get a string which does not fit into the line
+ and has to be wrapped.  If you move over it with your mouse, you
+ should see that only the part on the second line is being highlighted.
+ The full string is highlighted only if the 'display property is not
+ set.
+ 
+ 
+ 
  * DOCUMENTATION
  
  ** Document Custom Themes.
***************
*** 264,270 ****
  lispref/compile.texi     "Luc Teirlinck"
  lispref/control.texi     "Luc Teirlinck"
  lispref/customize.texi
! lispref/debugging.texi
  lispref/display.texi
  lispref/edebug.texi
  lispref/elisp.texi       "Luc Teirlinck"
--- 280,286 ----
  lispref/compile.texi     "Luc Teirlinck"
  lispref/control.texi     "Luc Teirlinck"
  lispref/customize.texi
! lispref/debugging.texi   Joakim Verona <address@hidden>
  lispref/display.texi
  lispref/edebug.texi
  lispref/elisp.texi       "Luc Teirlinck"