Re: Compile failure due to Xaw3d include file issues

[Ulrich Mueller]

> On Wed, 18 Apr 2007, Jan Djärv wrote:

> But that is only on Gentoo.

Debian has seen it, too:



> Who knows how many Xaw3d variats there are out there? A configure
> test seems better to me.


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

Re: Compile failure due to Xaw3d include file issues

[Jan Djärv]

Chong Yidong skrev:

Ulrich Mueller <[EMAIL PROTECTED]> writes:


Hi,
not entirely sure if this is really an Emacs bug (or if X.Org is to
blame):

Emacs 22.0.97 compilation fails on a system where:
- Xaw3d is installed,
- libXaw is not installed. 


Thanks for the bug report.

Could you test the following patch?

If you could take the time, please see if it works as expected with
all 4 combinations of Xaw3d and libXaw installed/not installed.



But that is only on Gentoo.  Who knows how many Xaw3d variats there are out 
there?  A configure test seems better to me.


Jan D.


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

Re: expand-file-name leaves "/../" in expansions at times

[Jan Djärv]

Miles Bader skrev:

Chong Yidong <[EMAIL PROTECTED]> writes:

On the other hand, I just checked, and this behavior seems to have
been around since at least Emacs 20.  Glancing through the source
code, this behavior seems to be deliberate---something to do with the
"superroot directory".  Maybe someone on this list can elucidate?


I don't know anything about the Emacs code, but CMU CS had a networked
filesystem (the mach/spice project vaxes) which had the concept of a
super-root above /, accessed via "/..".  E.g. to access file "/x/y" on
machine "blargh", you'd use "/../blargh/x/y" (IIRC, "/.." was a real
directory so you could do "cd /..", "ls /.." to see all machines, etc)..

I always thought it was a rather clever idea.  It certainly messes up
assumptions some programs make, but I think the "/.." == "/" assumption
is generally rather rare in practice.  [Compare to the microsoftian "//"
superroot syntax, which messes up the far more common "//" == "/"
assumption, and just generally feels a lot more arbitrary.]



Apollo also had // as superroot if my memory is correct.  You could do
% ls //
to see all machines there as well.  I don't know if this predates Microsofts 
usage, but I suspect it does, this was late 80:s, early 90:s.


Jan D.



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

Re: Compile failure due to Xaw3d include file issues

[Chong Yidong]

Ulrich Mueller <[EMAIL PROTECTED]> writes:

> Hi,
> not entirely sure if this is really an Emacs bug (or if X.Org is to
> blame):
>
> Emacs 22.0.97 compilation fails on a system where:
> - Xaw3d is installed,
> - libXaw is not installed. 

Thanks for the bug report.

Could you test the following patch?

If you could take the time, please see if it works as expected with
all 4 combinations of Xaw3d and libXaw installed/not installed.


*** emacs/src/xfns.c.~1.681.~   2007-03-24 11:49:48.0 -0400
--- emacs/src/xfns.c2007-04-18 01:18:52.0 -0400
***
*** 72,79 
--- 72,84 
  #include 
  
  #ifndef USE_MOTIF
+ #ifdef HAVE_XAW3D
+ #include 
+ #include 
+ #else  /* !HAVE_XAW3D */
  #include 
  #include 
+ #endif /* HAVE_XAW3D */
  #endif /* USE_MOTIF */
  
  #ifdef USG
*** emacs/src/xmenu.c.~1.317.~  2007-01-20 23:18:14.0 -0500
--- emacs/src/xmenu.c   2007-04-18 01:15:43.0 -0400
***
*** 82,88 
--- 82,92 
  #include 
  #include 
  #ifdef USE_LUCID
+ #ifdef HAVE_XAW3D
+ #include 
+ #else  /* !HAVE_XAW3D */
  #include 
+ #endif /* HAVE_XAW3D */
  #endif /* USE_LUCID */
  #include "../lwlib/lwlib.h"
  #else /* not USE_X_TOOLKIT */
*** emacs/lwlib/lwlib.c.~1.55.~ 2007-02-27 23:25:05.0 -0500
--- emacs/lwlib/lwlib.c 2007-04-18 01:21:44.0 -0400
***
*** 48,54 
--- 48,58 
  #endif /* not USE_MOTIF && USE_LUCID */
  #endif
  #if defined (USE_XAW)
+ #ifdef HAVE_XAW3D
+ #include 
+ #else  /* !HAVE_XAW3D */
  #include 
+ #endif /* HAVE_XAW3D */
  #include "lwlib-Xaw.h"
  #endif
  
*** emacs/lwlib/lwlib-Xaw.c.~1.25.~ 2007-02-26 22:07:08.0 -0500
--- emacs/lwlib/lwlib-Xaw.c 2007-04-18 01:22:33.0 -0400
***
*** 35,46 
--- 35,55 
  #include 
  #include 
  
+ #ifdef HAVE_XAW3D
+ #include 
+ #include 
+ #include 
+ #include 
+ #include 
+ #include 
+ #else /* !HAVE_XAW3D */
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
+ #endif /* HAVE_XAW3D */
  
  #include 
  



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

Re: regression in diary-lib

[Glenn Morris]

Andreas Seltenreich wrote:

> I just switched from 22.0.96 to 22.0.98 and noticed that the file-local
> variables in my ~/diary file are no longer honored.  It seems like the
> following change causes buffer-local variables to be flushed on each
> call to diary-view-entries:

Fixed.



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

Re: expand-file-name leaves "/../" in expansions at times

[Miles Bader]

Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> I always thought it was a rather clever idea.  It certainly messes up
>> assumptions some programs make, but I think the "/.." == "/" assumption
>> is generally rather rare in practice.  [Compare to the microsoftian "//"
>> superroot syntax, which messes up the far more common "//" == "/"
>> assumption, and just generally feels a lot more arbitrary.]
>
> The Microsoft // doesn't mess up anything because on Microsoft
> filesystems // != /.

My point was that lots of (unixoid) _apps_ assume // = /, and it's
rather common to "prettify" filenames by doing the equivalent of "sed
[EMAIL PROTECTED]//@/@" [*] -- which screws up filenames using the MS superroot.

The reason many unixoid apps do such prettification is that filenames
inadvertently containing "//" at the beginning are pretty common too,
e.g. when you have a Makefile that does "FOO_DIR = $(INSTALL_ROOT)/foo"
and INSTALL_ROOT is "/".

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."


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

Re: expand-file-name leaves "/../" in expansions at times

[Eli Zaretskii]

> From: Miles Bader <[EMAIL PROTECTED]>
> Date: Wed, 18 Apr 2007 11:01:51 +0900
> Cc: emacs-pretest-bug@gnu.org
> 
> I always thought it was a rather clever idea.  It certainly messes up
> assumptions some programs make, but I think the "/.." == "/" assumption
> is generally rather rare in practice.  [Compare to the microsoftian "//"
> superroot syntax, which messes up the far more common "//" == "/"
> assumption, and just generally feels a lot more arbitrary.]

The Microsoft // doesn't mess up anything because on Microsoft
filesystems // != /.


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

RE: C-u C-SPC: doc string and behavior if mark = point

[Drew Adams]

> 3. A run-on sentence results from joining independent clauses
>(or sentences) without using any punctuation for the join.
>
> 4. Independent clauses joined using a comma, and without a
>conjunction, form a comma splice, not a run-on sentence.
>A semicolon should be used to join
>independent clauses (as you indicated), or the sentence
>should be split.
>
> I was taught a different definition.

It's not important. My point was not that the sentence was grammatically
incorrect. I thought it would be easier to read if split; that's all.

FWIW:

http://en.wikipedia.org/wiki/Run-on_sentence

http://en.wikipedia.org/wiki/Comma_splice



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

Re: C-u C-SPC: doc string and behavior if mark = point

[Richard Stallman]

3. A run-on sentence results from joining independent clauses (or sentences)
without using any punctuation for the join.

4. Independent clauses joined using a comma, and without a conjunction, form
a comma splice, not a run-on sentence. A semicolon should be used to join
independent clauses (as you indicated), or the sentence should be split.

I was taught a different definition.


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

Re: expand-file-name leaves "/../" in expansions at times

[Miles Bader]

Chong Yidong <[EMAIL PROTECTED]> writes:
> On the other hand, I just checked, and this behavior seems to have
> been around since at least Emacs 20.  Glancing through the source
> code, this behavior seems to be deliberate---something to do with the
> "superroot directory".  Maybe someone on this list can elucidate?

I don't know anything about the Emacs code, but CMU CS had a networked
filesystem (the mach/spice project vaxes) which had the concept of a
super-root above /, accessed via "/..".  E.g. to access file "/x/y" on
machine "blargh", you'd use "/../blargh/x/y" (IIRC, "/.." was a real
directory so you could do "cd /..", "ls /.." to see all machines, etc)..

I always thought it was a rather clever idea.  It certainly messes up
assumptions some programs make, but I think the "/.." == "/" assumption
is generally rather rare in practice.  [Compare to the microsoftian "//"
superroot syntax, which messes up the far more common "//" == "/"
assumption, and just generally feels a lot more arbitrary.]

-Miles

-- 
I'd rather be consing.


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

RE: Emacs manual node Query Replace needs cross ref to Unconditional Replace

[Drew Adams]

> Emacs manual node Query Replace says things such as this:
>
>  "Aside from querying, `query-replace' works just like
>  `replace-string'.  It preserves case, like `replace-string',
>  provided `case-replace' is non-`nil', as it normally is."
>
> You cannot understand this text without knowing details about
> `replace-string', which is described in node Unconditional Replace. So,
> we need a cross reference to that node. Otherwise, we force users to
> search for `replace-string' or look it up in the index (`i').
>
>
> In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600)
>  of 2007-03-21 on LENNART-69DE564
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'

2. Furthermore, there is no discussion of case in node Unconditional
Replace, which is the only node indexed for `replace-string'.

3. Actually, it looks as if the proper target for the missing cross
reference (in both nodes mentioned) should be node Replacement and Case.



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

Emacs manual node Query Replace needs cross ref to Unconditional Replace

[Drew Adams]

Emacs manual node Query Replace says things such as this:

 "Aside from querying, `query-replace' works just like
 `replace-string'.  It preserves case, like `replace-string',
 provided `case-replace' is non-`nil', as it normally is."

You cannot understand this text without knowing details about
`replace-string', which is described in node Unconditional Replace. So,
we need a cross reference to that node. Otherwise, we force users to
search for `replace-string' or look it up in the index (`i').


In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600)
 of 2007-03-21 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'



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

regression in diary-lib

[Andreas Seltenreich]

> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.

> Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

I just switched from 22.0.96 to 22.0.98 and noticed that the file-local
variables in my ~/diary file are no longer honored.  It seems like the
following change causes buffer-local variables to be flushed on each
call to diary-view-entries:

> Changes by:   Glenn Morris07/03/21 06:25:00

> Index: diary-lib.el
> ===
> RCS file: /sources/emacs/emacs/lisp/calendar/diary-lib.el,v
> retrieving revision 1.120
> retrieving revision 1.121
> diff -u -b -r1.120 -r1.121
> --- diary-lib.el  20 Mar 2007 07:45:06 -  1.120
> +++ diary-lib.el  21 Mar 2007 06:24:59 -  1.121
[...]
> @@ -429,7 +435,10 @@
>  (or (verify-visited-file-modtime diary-buffer)
>  (revert-buffer t t
>  ;; Setup things like the header-line-format and invisibility-spec.
> -(when (eq major-mode default-major-mode) (diary-mode))
> +;; This used to only run if the major-mode was default-major-mode,
> +;; but that meant eg changes to header-line-format did not
> +;; take effect from one diary invocation to the next.
> +(diary-mode)
>  ;; d-s-p is passed to the diary display function.
>  (let ((diary-saved-point (point)))
>(save-excursion



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

Re: Display problems with `before-string' in overlay

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:

Date: Tue, 17 Apr 2007 23:29:12 +0200
From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
CC:  [EMAIL PROTECTED],  emacs-pretest-bug@gnu.org

I am not the easiest one to convince, but it is in no way impossible.


You again are not answering the question.  I think we should end this
discussion, as it became futile.  Please read Karl Popper if you wish
to understand what kind of answer I asked for, and why I think there's
no point in continuing this discussion with you.


It is hard for me to understand how you think Popper's thinking could be 
used here so if you want me to understand I believe you must point out 
what claim of knowledge you have from a falsifiability standpoint and 
maybe how you think I relate to that.



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

Re: Display problems with `before-string' in overlay

[Eli Zaretskii]

> Date: Tue, 17 Apr 2007 23:29:12 +0200
> From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
> CC:  [EMAIL PROTECTED],  emacs-pretest-bug@gnu.org
> 
> I am not the easiest one to convince, but it is in no way impossible.

You again are not answering the question.  I think we should end this
discussion, as it became futile.  Please read Karl Popper if you wish
to understand what kind of answer I asked for, and why I think there's
no point in continuing this discussion with you.


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

Re: Display problems with `before-string' in overlay

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:

Date: Tue, 17 Apr 2007 22:08:06 +0200
From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
CC:  [EMAIL PROTECTED],  emacs-pretest-bug@gnu.org


But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your mind on this?  Following
Karl Popper, if your answer is ``nothing will change my mind'', then
this is a religious type of argument that we should just stop, because
it has no hope of any agreement whatsoever.

That is a good question.

Which you didn't answer, sigh...


In what sense did I not answer it?


In the sense that I still do not know what would convince you to
change your mind.  For example, if I would to argue with someone which
of two apples to buy, telling me that one is 10 times cheaper than the
other might make me change my mind.


I am not the easiest one to convince, but it is in no way impossible.

I tried to point out the answer. What is needed is not very different 
from when you meet other people. You must try to meet me where I am.


And I failed for similar reasons to make it possible to convince you.

You were arguing from a managerial standpoint. I tried to mix this 
standpoint with estimates of some details in the problem. If you wanted 
to convince me I then I think you should have to follow me a bit on that 
road.


It would be nice if you commented on this because I honestly fail to 
understand why you did not do that. I can of course think of a lot of 
reasons, lack of time for example. Or that you did not find my arguments 
valuable. Whichever it was I think it would have been easier to get a 
bit longer on the road to convincing me if you explained your reasons 
for the turn you took.


I tried in the prev-previous mail to do explain something similar from 
my point of view, but I think I missed something there since you thought 
I did not answer you.



I have a feeling that the difficulties to meet is for some reason mainly 
a lack of trust. That may be personal for me, I do not know. It is easy 
for me to say that I trust your experience and appreciate your concerns, 
but that I think differently. But it is not easy to get the message 
through to you.


Maybe because of the media and the way we communicate. Maybe because we 
actually have different styles of thinking as I understand it.



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

Re: Display problems with `before-string' in overlay

[Eli Zaretskii]

> Date: Tue, 17 Apr 2007 22:08:06 +0200
> From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
> CC:  [EMAIL PROTECTED],  emacs-pretest-bug@gnu.org
> 
> >>> But let me turn the table around, Lennart, and ask you: what arguments
> >>> will actually convince _you_ to change your mind on this?  Following
> >>> Karl Popper, if your answer is ``nothing will change my mind'', then
> >>> this is a religious type of argument that we should just stop, because
> >>> it has no hope of any agreement whatsoever.
> >> That is a good question.
> > 
> > Which you didn't answer, sigh...
> 
> 
> In what sense did I not answer it?

In the sense that I still do not know what would convince you to
change your mind.  For example, if I would to argue with someone which
of two apples to buy, telling me that one is 10 times cheaper than the
other might make me change my mind.


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

Re: Display problems with `before-string' in overlay

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:

Date: Mon, 16 Apr 2007 22:58:47 +0200
From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
CC: Juanma Barranquero <[EMAIL PROTECTED]>,  emacs-pretest-bug@gnu.org


But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your mind on this?  Following
Karl Popper, if your answer is ``nothing will change my mind'', then
this is a religious type of argument that we should just stop, because
it has no hope of any agreement whatsoever.

That is a good question.


Which you didn't answer, sigh...



In what sense did I not answer it?


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

Re: Display problems with `before-string' in overlay

[Eli Zaretskii]

> Date: Mon, 16 Apr 2007 22:58:47 +0200
> From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]>
> CC: Juanma Barranquero <[EMAIL PROTECTED]>,  emacs-pretest-bug@gnu.org
> 
> > But let me turn the table around, Lennart, and ask you: what arguments
> > will actually convince _you_ to change your mind on this?  Following
> > Karl Popper, if your answer is ``nothing will change my mind'', then
> > this is a religious type of argument that we should just stop, because
> > it has no hope of any agreement whatsoever.
> 
> That is a good question.

Which you didn't answer, sigh...


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

show-paren-mode prevents page-down from displaying next 1/2 page.

[Maguire, Andrew \(GE Infra, Energy\)]

Thanks,
Andrew

"If it runs, script it!"
To setup this rather strange bug, you need to:
   1. ensure show-paren-mode is enabled
   2. create a buffer and in that buffer, half way down the window,
  create a line that has some [] brackets such that the ] bracket
  is the last displayed character on the right of the screen.

  I also had characters after the ] so that the right hand "fringe"
  displayed its wrap-around icon.

  It is important that the [] line is displayed half way down the window, 
e.g on the 5th line on a window height of 10 (9 lines displayed due to wrap 
around).

   3. place point anywhere on the line with [] brackets and press the page-down 
key.

Instead of paging down, the display will flash and place point immediately 
after the ] bracket.


In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600)
 of 2007-01-01 on DTOP
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.1) --cflags  -O2 -g0 -march=i386 
-mtune=i686 -pipe -IC:/gnuwin32/include_emacs -IC:/gnuwin32/lib 
-IC:/gnuwin32/src --ldflags  -s '

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: ENG
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Perl

Minor modes in effect:
  show-paren-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-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:
  u n l e s s SPC  

 ;   
W A R N I N G . SPC C-x C-s C-x C-b   
 

   C-x 1 

   
 

 
   

Recent messages:
Checking out 
u:/swdev/users/andrewma/localisation/trans/lib/localisation/File/magik_patch.pm...done
Mark set [4 times]
Auto-saving...done
Wrote 
u:/swdev/users/andrewma/localisation/trans/lib/localisation/File/magik_patch.pm
Mark set
Wrote 
u:/swdev/users/andrewma/localisation/trans/lib/localisation/File/magik_patch.pm
Mark set [2 times]
Wrote 
u:/swdev/users/andrewma/localisation/trans/lib/localisation/File/magik_patch.pm
sw-half-scroll-down: Beginning of buffer [2 times]
Loading emacsbug...done


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

Compile failure due to Xaw3d include file issues

[Ulrich Mueller]

[Resending, since my first message didn't appear on the list for some reason.]

Hi,
not entirely sure if this is really an Emacs bug (or if X.Org is to
blame):

Emacs 22.0.97 compilation fails on a system where:
- Xaw3d is installed,
- libXaw is not installed. 

Configure defines HAVE_XAW3D=1 in src/config.h, but in spite of this
include files are expected to be in /usr/include/X11/Xaw
(e.g., Paned.h) that don't exist there (since libX11 is not
installed).

Xaw3d installs its own include files, but they are in
/usr/include/X11/Xaw3d (there is a Paned.h, too).

On the other hand, if I install libXaw on the system and compile Emacs
(the include files are there and compilation succeeds now), ldd or
scanelf show that the libXaw _library_ is not needed:

   $ scanelf -n src/emacs
TYPE   NEEDED FILE 
   ET_EXEC 
libXaw3d.so.8,libXmu.so.6,libXt.so.6,libSM.so.6,libICE.so.6,libXext.so.6,libX11.so.6,libncurses.so.5,libm.so.6,libc.so.6
 src/emacs 

So a possible workaround is to install in addition libX11 during build
time, while at run time it is not required. This doesn't look like a
clean solution, however.

See also Gentoo bug #174453: 


>From config.log:

 $ ./configure --prefix=/usr --host=i686-pc-linux-gnu 
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
--sysconfdir=/etc --localstatedir=/var/lib --program-suffix=-emacs-22 
--without-carbon --without-sound --with-x --without-xpm 
--with-toolkit-scroll-bars --without-jpeg --without-tiff --without-gif 
--without-png --with-x-toolkit=athena --without-gtk --with-x-toolkit=lucid 
--build=i686-pc-linux-gnu

   hostname = a1iulm2
   uname -m = i686
   uname -r = 2.6.20-gentoo-r5
   uname -s = Linux
   uname -v = #1 Tue Apr 10 10:47:47 CEST 2007

Error message from "make bootstrap":

   make[3]: Entering directory 
`/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/lwlib'
   i686-pc-linux-gnu-gcc  -c -D_BSD_SOURCE   -DUSE_LUCID  -D_BSD_SOURCE
-march=pentium-m -O2 -pipe -DHAVE_CONFIG_H -Demacs -I. -I../src 
-I/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/lwlib 
-I/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/lwlib/../src
 /var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/lwlib/lwlib.c
   i686-pc-linux-gnu-gcc  -c -D_BSD_SOURCE   -Demacs -DHAVE_CONFIG_H 
-DUSE_LUCID  -I. 
-I/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/src 
-D_BSD_SOURCE  -march=pentium-m -O2 -pipe dispnew.c
   
/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/lwlib/lwlib.c:51:27:
 error: X11/Xaw/Paned.h: No such file or directory
   make[3]: *** [lwlib.o] Error 1
   make[3]: Leaving directory 
`/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/lwlib'
   make[2]: *** [really-lwlib] Error 2
   make[2]: *** Waiting for unfinished jobs
   make[2]: Leaving directory 
`/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97/src'
   make[1]: *** [bootstrap-build] Error 2
   make[1]: Leaving directory 
`/var/tmp/portage/app-editors/emacs-cvs-22.0.97/work/emacs-22.0.97'
   make: *** [bootstrap] Error 2

(If I do "make -k bootstrap", there is the same issue for src/xmenu.c
and src/xfns.c.)

Ulrich


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

Re: expand-file-name leaves "/../" in expansions at times

[Chong Yidong]

Jason Rumney <[EMAIL PROTECTED]> writes:

> Chong Yidong wrote:
>>   Convert filename name to absolute, and canonicalize it.
>>
>> All your examples are consistent with this behavior.  The important
>> thing is that DEFAULT-DIRECTORY is only consulted if the filename is
>> relative.
>>   
> But shouldn't the "and canonicalize it" step involve replacing the ../
> with the actual directories they represent?

Hmm, that's true.  It seems that Emacs treats both / and /../ as
semi-independent canonical directories, which is a little
counter-intuitive.

(expand-file-name "/../a")
"/../a"

(expand-file-name "/../../a")
"/a"

On the other hand, I just checked, and this behavior seems to have
been around since at least Emacs 20.  Glancing through the source
code, this behavior seems to be deliberate---something to do with the
"superroot directory".  Maybe someone on this list can elucidate?



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

Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw

[Kenichi Handa]

In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes:

> > I found a suspicious code and just installed a patch.  Could
> > you please try with the latest source?  The page
> > www.6park.com has a character U+25CF (BLACK CIRCLE) near the
> > center of the top page.  I think the crash happened when you
> > put mouse-cursor on it, and the new code stops the crashing.

> I can confirm the fix. I tried to trigger a crash but was not able to.

Thank you for checking that.

> > And, I think the frequency of flickering is also reduced.

> Flickering is still a problem.

Yes.  What I've done is just to reduce it.  I'm now working
on improving it.

---
Kenichi Handa
[EMAIL PROTECTED]


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

Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw

[Leo]

Dear Kenichi,

- Kenichi Handa (2007-04-17) wrote:-

>> > I've just installed w3m and emacs-w3m, visited
>> > www.6park.com, moved mouse-cursor and normal cursor onto
>> > various links, but couldn't trigger a crash.
>
>> Since that website is using Chinese font and the flickering problem
>> depends on font and size, I wonder if that is why you can not reproduce
>> the crash. But I can confirm even with a font that *does not* cause
>> flickering, crashes still happen. So seems there is something wrong.
>
>> BTW, I am using CVS emacs-w3m.
>
> I found a suspicious code and just installed a patch.  Could
> you please try with the latest source?  The page
> www.6park.com has a character U+25CF (BLACK CIRCLE) near the
> center of the top page.  I think the crash happened when you
> put mouse-cursor on it, and the new code stops the crashing.

I can confirm the fix. I tried to trigger a crash but was not able to.

> And, I think the frequency of flickering is also reduced.

Flickering is still a problem.

regards,
-- 
Leo  (GPG Key: 9283AA3F)


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

Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw

[Kenichi Handa]

In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes:

> > I've just installed w3m and emacs-w3m, visited
> > www.6park.com, moved mouse-cursor and normal cursor onto
> > various links, but couldn't trigger a crash.

> Since that website is using Chinese font and the flickering problem
> depends on font and size, I wonder if that is why you can not reproduce
> the crash. But I can confirm even with a font that *does not* cause
> flickering, crashes still happen. So seems there is something wrong.

> BTW, I am using CVS emacs-w3m.

I found a suspicious code and just installed a patch.  Could
you please try with the latest source?  The page
www.6park.com has a character U+25CF (BLACK CIRCLE) near the
center of the top page.  I think the crash happened when you
put mouse-cursor on it, and the new code stops the crashing.

And, I think the frequency of flickering is also reduced.

---
Kenichi Handa
[EMAIL PROTECTED]


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

Re: expand-file-name leaves "/../" in expansions at times

[Jason Rumney]

Chong Yidong wrote:

  Convert filename name to absolute, and canonicalize it.

All your examples are consistent with this behavior.  The important
thing is that DEFAULT-DIRECTORY is only consulted if the filename is
relative.
  


But shouldn't the "and canonicalize it" step involve replacing the ../ 
with the actual directories they represent?




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

Re: Display problems with `before-string' in overlay

[Lennart Borgman (gmail)]

Stefan Monnier wrote:


I agree that this situation should be improved, but as long as the position
is chosen arbitrarily anyway, I don't see it as a big problem if this
arbitrary choice happens to be occasionally in the middle of the display
string rather than at one of its ends.



My weak memory whispers something about that this has been improved 
quite a while ago, but I am not sure.



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