Re: Carbon: scroll bar rendering problem

2007-03-03 Thread David Reitter

On 3 Mar 2007, at 00:58, YAMAMOTO Mitsuharu wrote:


(Cocoa) Emacs.app seems to do something uncommon to other
platform/toolkit ports with respect to the scroll bar width and the
frame internal border width in order to get rid of the gap between the
rightmost scroll bars and the right edge of the frame.  But that also
introduces some display glitches that are not seen on other platforms
(try C-x 3 or (set-frame-parameter nil 'internal-border-width 10)).


It seems that the gap appears on the left side of the buffer instead,  
which is much nicer. I see a scrolling glitch with C-x 3, but apart  
from that, nothing out of the ordinary (Emacs.app 9.0 pre-3).  There  
is still the vertical gap between the tool-bar and the scroll-bar,  
but that's another story and presumably easy to fix.


Would this be hard to do? (Andy said he was going to take a quick  
look at the code.)





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: emacs-22.0.95 successful installs

2007-03-03 Thread Eli Zaretskii
> From: James J Dempsey <[EMAIL PROTECTED]>
> Date: Fri, 02 Mar 2007 10:36:36 -0500
> Cc: 
> 
> Do you want this kind of testing status sent to emacs-pretest-bug?

Yes, please.

Thanks.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Carbon: scroll bar rendering problem

2007-03-03 Thread YAMAMOTO Mitsuharu
> On Sat, 3 Mar 2007 08:57:02 +, David Reitter <[EMAIL PROTECTED]> said:

> On 3 Mar 2007, at 00:58, YAMAMOTO Mitsuharu wrote:
>> (Cocoa) Emacs.app seems to do something uncommon to other
>> platform/toolkit ports with respect to the scroll bar width and the
>> frame internal border width in order to get rid of the gap between
>> the rightmost scroll bars and the right edge of the frame.  But
>> that also introduces some display glitches that are not seen on
>> other platforms (try C-x 3 or (set-frame-parameter nil
>> 'internal-border-width 10)).

> It seems that the gap appears on the left side of the buffer
> instead, which is much nicer. I see a scrolling glitch with C-x 3,
> but apart from that, nothing out of the ordinary (Emacs.app 9.0
> pre-3).  There is still the vertical gap between the tool-bar and
> the scroll-bar, but that's another story and presumably easy to fix.

With (set-frame-parameter nil 'internal-border-width 10) and C-x 3,
the scroll bar of the left window and the left fringe of the right
window get overlapped on Emacs.app 9.0rc1.

> Would this be hard to do? (Andy said he was going to take a quick
> look at the code.)

Sorry, I don't understand what you mean by `this'.  If you mean
porting Emacs.app code to Carbon Emacs, I'd not take a risk to make
the code different from other platforms and introduce bugs like above
especially at this stage.

 YAMAMOTO Mitsuharu
[EMAIL PROTECTED]


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Pretest?

2007-03-03 Thread Eli Zaretskii
> From: Chong Yidong <[EMAIL PROTECTED]>
> Date: Thu, 01 Mar 2007 18:38:43 -0500
> 
> I have rolled a 22.0.95 tarball, which can be found at the usual
> location:
> 
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95.tar.gz
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.94-22.0.95.xdelta

I tested this with:

   . GCC 3.4.2 (mingw-special), Binutils 2.15.91 20040904 and MinGW
 v3.7 on Windows XP

   . GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5), Binutils 2.16.91 20060118 on
 Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006
 x86_64 GNU/Linux

The pretest builds okay on both platforms and appears to run fine.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc

2007-03-03 Thread Jan Djärv



Chong Yidong skrev:

Problem seems to be that LIB_XFT on Solaris 10 does NOT include -lX11,
despite what it says in src/Makefile.in.

This patch (reverts Jan 26 change) fixes it for me on Solaris 10,
don't know if it breaks anything else. It can't hurt to include -lX11
twice, can it?

*** Makefile.in 17 Feb 2007 02:36:10 - 1.338
--- Makefile.in 2 Mar 2007 22:48:07 -
***
*** 403,410 
  #endif /* not USE_X_TOOLKIT */
  
  #if HAVE_XFT

- #undef LIB_X11_LIB /* XFT_LIBS includes -lX11 */
- #define LIB_X11_LIB
  [EMAIL PROTECTED]@
  #endif /* HAVE_XFT */
  
--- 403,408 


Jan, this was your patch.  Can you comment on the proposed fix?


What is the point of not having -lX11 in XFT_LIBS?  Sounds like a bug in the 
installed Xft to me.  Where did it come from, is it part of Solaris 10 or 
added on later.  I guess two -lX11 couldn't hurt.


Jan D.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


tar-untar-buffer fails on Emacs pretest tar ball

2007-03-03 Thread Ralf Angeli
Trying to untar an Emacs pretest tar ball (22.0.94) with
`tar-untar-buffer' results in the following backtrace:

Debugger entered--Lisp error: (error "Invalid search bound (wrong side of 
point)")
  re-search-forward("[
\n]\\([^[
\n]*\\)[]*Local Variables:[ ]*\\([^
\n]*\\)[
\n]" 342875 t)
  find-auto-coding("/home/angeli/test/emacs-22.0.94/AUTHORS" 89643)
  select-safe-coding-system(253232 342875 no-conversion nil 
"/home/angeli/test/emacs-22.0.94/AUTHORS")
  write-region(253232 342875 "emacs-22.0.94/AUTHORS")
  tar-untar-buffer()
  call-interactively(tar-untar-buffer)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

When looking at the tar buffer after the error happened point is
located at a new page character (^L).

The bug makes it impossible to install a package containing such
characters in certain files with install.el which uses
`tar-untar-buffer' for the extraction of files from a package.


In GNU Emacs 22.0.95.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-03-03 on neutrino
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--with-gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Tar

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
C-x C-f e m  .   y M-x t a r - u 
n t a r   M-x r e p o r t - e m  


Recent messages:
File emacs-22.0.94.tar.gz is large (35MB), really open? (y or n) 
Loading jka-compr...done
uncompressing emacs-22.0.94.tar.gz...done
Loading tar-mode...done
Parsing tar file...done
Extracting emacs-22.0.94/AUTHORS
find-auto-coding: Invalid search bound (wrong side of point)
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Problem compiling on Redhat Enterprise WS 3 with X11

2007-03-03 Thread James J Dempsey
Apparently the first time I built emacs-22.0.95 on redhat Enterprise WS 3,
it defaulted to not use X11, probably because this machine didn't have the
X11 header file RPMs installed.  After installing them, I reconfigured with:

./configure --prefix=/local --x-libraries=/usr/X11R6/lib 
--x-includes=/usr/X11R6/include --with-x-toolkit=yes

and when I do, I get the following compile error:

gcc -c -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src 
-I/local/emacs-pretest/emacs-22.0.95/lib-src 
-I/local/emacs-pretest/emacs-22.0.95/lib-src/../src -D_BSD_SOURCE   -g -O2  
-Demacs  /local/emacs-pretest/emacs-22.0.95/lib-src/movemail.c
/local/emacs-pretest/emacs-22.0.95/lib-src/movemail.c: In function `strerror':
/local/emacs-pretest/emacs-22.0.95/lib-src/movemail.c:952: conflicting types 
for `sys_errlist'
/usr/include/bits/sys_errlist.h:28: previous declaration of `sys_errlist'
make[1]: *** [movemail.o] Error 1

Looking around, it appears that linux (at least Redhat) has strerror.  I
worked around this problem by adding

#define HAVE_STRERROR 1

to src/s/gnu-linux.h.  Not sure if that is the right solution or not.

--Jim Dempsey--





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


tramp not respecting file-coding-system-alist (?)

2007-03-03 Thread Jose Figueroa-O'Farrill


I am using

GNU Emacs 22.0.94.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
of 2007-03-02 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 1.0rc1

I customized file-coding-system-alist and its present value is

(("\\.dz\\'" no-conversion . no-conversion)
 ("\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'" no-conversion . no-conversion)
 ("\\.tgz\\'" no-conversion . no-conversion)
 ("\\.html\\'" . utf-8)
 ("\\.tbz\\'" no-conversion . no-conversion)
 ("\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'" no-conversion . no-conversion)
 ("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'" no-conversion . no-conversion)
 ("\\.elc\\'" emacs-mule . emacs-mule)
 ("\\.utf\\(-8\\)?\\'" . utf-8)
 ("\\(\\`\\|/\\)loaddefs.el\\'" raw-text . raw-text-unix)
 ("\\.tar\\'" no-conversion . no-conversion)
 ("\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'" . latexenc-find-file-coding-system)
 ("" undecided))

In particular, HTML files should be encoded/decoded using utf-8.

I visit a utf-8 encoded HTML file on a remote Linux system via tramp
and the file fails to be decoded in utf-8.  I ftp the file locally and
visit it here and it decodes properly.

Cheers, José


-- 
Prof José M Figueroa-O'Farrill  | Phone: +44 (0) 131 6505066
School of Mathematics   | Fax: +44 (0) 131 6506553
University of Edinburgh | Mobile: +44 (0) 7870 239186
Edinburgh EH9 3JZ, Scotland, UK | URL: http://www.maths.ed.ac.uk/~jmf


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Problem compiling on Redhat Enterprise WS 3 with X11

2007-03-03 Thread Chong Yidong
James J Dempsey <[EMAIL PROTECTED]> writes:

> Apparently the first time I built emacs-22.0.95 on redhat Enterprise WS 3,
> it defaulted to not use X11, probably because this machine didn't have the
> X11 header file RPMs installed.  After installing them, I reconfigured with:
>
> ./configure --prefix=/local --x-libraries=/usr/X11R6/lib 
> --x-includes=/usr/X11R6/include --with-x-toolkit=yes
>
> and when I do, I get the following compile error:
> ...
>
> Looking around, it appears that linux (at least Redhat) has strerror.  I
> worked around this problem by adding
>
> #define HAVE_STRERROR 1
>
> to src/s/gnu-linux.h.  Not sure if that is the right solution or not.

configure should have put HAVE_STRERROR into src/config.h, so there is
likely something wrong the way you ran configure.  Could you
reconfigure with just

  ./configure --prefix=/local

and see if the problem persists?



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc

2007-03-03 Thread Chong Yidong
Jan Djärv <[EMAIL PROTECTED]> writes:

>>> *** Makefile.in 17 Feb 2007 02:36:10 - 1.338
>>> --- Makefile.in 2 Mar 2007 22:48:07 -
>>> ***
>>> *** 403,410 
>>>   #endif /* not USE_X_TOOLKIT */
>>> #if HAVE_XFT
>>> - #undef LIB_X11_LIB /* XFT_LIBS includes -lX11 */
>>> - #define LIB_X11_LIB
>>>   [EMAIL PROTECTED]@
>>>   #endif /* HAVE_XFT */
>>>   --- 403,408 
>
> What is the point of not having -lX11 in XFT_LIBS?  Sounds like a bug
> in the installed Xft to me.  Where did it come from, is it part of
> Solaris 10 or added on later.  I guess two -lX11 couldn't hurt.

In that case, I've applied rgm's patch.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: tar-untar-buffer fails on Emacs pretest tar ball

2007-03-03 Thread Chong Yidong
Ralf Angeli <[EMAIL PROTECTED]> writes:

> Trying to untar an Emacs pretest tar ball (22.0.94) with
> `tar-untar-buffer' results in the following backtrace:

I checked in a fix for this.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc

2007-03-03 Thread Richard Stallman
I tried to compile the latest pretest on my SPARC workstation running
Solaris post-10 ("Nevada b57"), using this configuration

What was the last pretest (or CVS Emacs version) that did build?


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: emacs-22.0.95 successful installs

2007-03-03 Thread Richard Stallman
Do you want this kind of testing status sent to emacs-pretest-bug?

You may as well report successes only to me.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc

2007-03-03 Thread Richard Stallman
This patch (reverts Jan 26 change) fixes it for me on Solaris 10,
don't know if it breaks anything else. It can't hurt to include -lX11
twice, can it?

Jan made that change in Makefile.in, probably to fix a bug.
Just removing it is probably not a good idea.

Jan, what was that bug?


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: diff ESC documentation

2007-03-03 Thread Richard Stallman
Would you please install your patch, then ack?


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: completion-setup-function shouldn't set default-directory to nil

2007-03-03 Thread Richard Stallman
I wonder whether this code at the beginning of
`completion-setup-function':

(if minibuffer-completing-file-name
(with-current-buffer mainbuf
  (setq default-directory (file-name-directory mbuf-contents

shouldn't perhaps be more like this, to avoid setting
default-directory to nil:

Thanks.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Partial completion

2007-03-03 Thread Glenn Morris
Johan Bockgård wrote:

> $ emacs -Q -l complete
> Insert (defma )
> Place point after "a" and run M-x PC-lisp-complete-symbol
>
>   => Wrong type argument: sequencep, t

How about the following patch? The 1+ part fixes a different bug that
seems to be present in 21.4 as well.


*** complete.el 03 Mar 2007 15:51:14 -0800  1.59
--- complete.el 03 Mar 2007 16:04:05 -0800  
***
*** 617,623 
  
  ;; If ambiguous, try for a partial completion
  (let ((improved nil)
!   prefix
(pt nil)
(skip "\\`"))
  
--- 617,623 
  
  ;; If ambiguous, try for a partial completion
  (let ((improved nil)
!   prefix temp
(pt nil)
(skip "\\`"))
  
***
*** 662,668 
  (setq skip (concat skip
 (regexp-quote prefix)
 PC-ndelims-regex)
!   prefix (try-completion
(PC-chunk-after
 ;; not basestr, because that does
 ;; not reflect insertions
--- 662,668 
  (setq skip (concat skip
 (regexp-quote prefix)
 PC-ndelims-regex)
!   temp (try-completion
(PC-chunk-after
 ;; not basestr, because that does
 ;; not reflect insertions
***
*** 674,679 
--- 674,680 
 (when (string-match skip x)
   (substring x (match-end 0
 poss)))
+   (if (stringp temp) (setq prefix temp))
  (or (> i 0) (> (length prefix) 0))
  (or (not (eq mode 'word))
  (and first (> (length prefix) 0)
***
*** 709,715 
;; Record which part of the buffer we are completing
;; so that choosing a completion from the list
;; knows how much old text to replace.
!   (setq completion-base-size dirlength)))
  (PC-temp-minibuffer-message " [Next char not unique]"))
nil)
  
--- 710,716 
;; Record which part of the buffer we are completing
;; so that choosing a completion from the list
;; knows how much old text to replace.
!   (setq completion-base-size (1+ dirlength
  (PC-temp-minibuffer-message " [Next char not unique]"))
nil)
  



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Partial completion

2007-03-03 Thread Glenn Morris
Glenn Morris wrote:

> The 1+ part fixes a different bug that seems to be present in 21.4
> as well.

Whoops, no it doesn't. I don't use partial completion, but it seems to
be pretty broken when one selects completion from a list.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Partial completion

2007-03-03 Thread Glenn Morris
Glenn Morris wrote:

> Glenn Morris wrote:
>
>> The 1+ part fixes a different bug that seems to be present in 21.4
>> as well.
>
> Whoops, no it doesn't. I don't use partial completion, but it seems to
> be pretty broken when one selects completion from a list.

This patch seems to do better, but is pretty much just
trial-and-error.

*** complete.el 03 Mar 2007 15:51:14 -0800  1.59
--- complete.el 03 Mar 2007 16:36:13 -0800  
***
*** 617,623 
  
  ;; If ambiguous, try for a partial completion
  (let ((improved nil)
!   prefix
(pt nil)
(skip "\\`"))
  
--- 617,623 
  
  ;; If ambiguous, try for a partial completion
  (let ((improved nil)
!   prefix temp
(pt nil)
(skip "\\`"))
  
***
*** 662,668 
  (setq skip (concat skip
 (regexp-quote prefix)
 PC-ndelims-regex)
!   prefix (try-completion
(PC-chunk-after
 ;; not basestr, because that does
 ;; not reflect insertions
--- 662,668 
  (setq skip (concat skip
 (regexp-quote prefix)
 PC-ndelims-regex)
!   temp (try-completion
(PC-chunk-after
 ;; not basestr, because that does
 ;; not reflect insertions
***
*** 674,679 
--- 674,680 
 (when (string-match skip x)
   (substring x (match-end 0
 poss)))
+   (if (stringp temp) (setq prefix temp))
  (or (> i 0) (> (length prefix) 0))
  (or (not (eq mode 'word))
  (and first (> (length prefix) 0)
***
*** 709,715 
;; Record which part of the buffer we are completing
;; so that choosing a completion from the list
;; knows how much old text to replace.
!   (setq completion-base-size dirlength)))
  (PC-temp-minibuffer-message " [Next char not unique]"))
nil)
  
--- 710,716 
;; Record which part of the buffer we are completing
;; so that choosing a completion from the list
;; knows how much old text to replace.
!   (setq completion-base-size (1- beg
  (PC-temp-minibuffer-message " [Next char not unique]"))
nil)
  



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc

2007-03-03 Thread Richard Stallman
What is the point of not having -lX11 in XFT_LIBS?  Sounds like a bug in 
the 
installed Xft to me.  Where did it come from, is it part of Solaris 10 or 
added on later.  I guess two -lX11 couldn't hurt.

You installed this to fix a bug, didn't you?  What was the bug?


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: diff ESC documentation

2007-03-03 Thread Kevin Rodgers

Richard Stallman wrote:

Would you please install your patch, then ack?


Sorry, I don't have CVS write access.

--
Kevin Rodgers
Denver, Colorado, USA



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc

2007-03-03 Thread Jan Djärv



Richard Stallman skrev:

This patch (reverts Jan 26 change) fixes it for me on Solaris 10,
don't know if it breaks anything else. It can't hurt to include -lX11
twice, can it?

Jan made that change in Makefile.in, probably to fix a bug.
Just removing it is probably not a good idea.

Jan, what was that bug?


The bug was that Emacs crashes when some gnome themes are used.  This is 
because Xft gets loaded and unloaded with dlopen, but pointers to its internal 
data remain.  There is a bug filed on Xft/fontconfig.  As a workaround we link 
Emacs with Xft to keep it from being unloaded.


As long as we link the same libraries we should be fine.

Jan D.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug