in my continuing role as dain-bramaged luser, I've gotten myself into this
situation a couple of times, so I thought I'd mention it
o I do stuff, then decide to C-x C-c (usually involved some customize)
o minibuffer msg says .shadow-todo changed on disk, do I really want to
edit the buffer?
o since I don't even know what .shadow-todo is, I'm not sure how I
answered, but I think I've tried both y and n, but I'm just not sure -
in any event, after that C-x C-c fails with:
Signaling: (…
[View More]wrong-type-argument buffer-live-p #<killed buffer>)
buffer-modified-p(#<killed buffer>)
shadow-save-todo-file()
save-buffers-kill-emacs(nil)
call-interactively(save-buffers-kill-emacs)
and I have to kill the process
sorry, I know I've done something wrong to cause this, but I wonder if
XEmacs could better handle the situation, or provide more info so I'd know
the right thing to do, etc.
--
John A. Turner, Senior Research Associate
Blue Sky Studios, One South Rd, Harrison, NY 10528
http://www.blueskystudios.com/ (914) 825-8319
[View Less]
I'm being beaten by the Athena text widget. Specifically focus is not
working how I would expect it to. For instance if I click on a text widget
in XEmacs, the XEmacs frame doesn't lose the keyboard focus (this does work
if using Motif). Thus if you type, characters go to the XEmacs frame
instead of the text widget. Again this works under motif.
Also I'm not sure of the exact semantics of getting strings in and out of
the widget programmatically. I have no useable documentation.
Any help …
[View More]appreciated.
Thanks
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
[View Less]
Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> "Kardos, Dr. Andreas" <kardos(a)repas-aeg.de> writes:
> > I am that other guy. We have fixed our dependency maker in the meantime.
>
> Well, given that Andreas no longer cares, I'm happy to change it back to
> the way it was. "" is definitely more consistent with what we have done
> in other include files.
Great, thanks Tom !
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- /…
[View More] / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
[View Less]
Peter Eisentraut <e99re41(a)DoCS.UU.SE> wrote:
> > Please, don't you think we already have modularized code ?
>
> If you have 20 -I's on the compile line, perhaps not, although I'm not to
> judge here.
Please read my messages carefully. We *don't* have 20 -I one the
command line, and we don't want to. That's the whole point. Obviously, we can
rewrite particular targets in Makefile.in in order to add the proper -I flags
only to the concerned sources. We …
[View More]have to do this already at some places.
However, this is even dirtier and we want to avoid this as much as possible.
> See above what the cleanest solution for everybody might be and why this
> one certainly isn't.
This one doesn't prevent you from using the other one, if you
consider it cleaner which is arguable. On the contrary, the current state
breaks our solution, without bringing any benefit to anybody (see
Andreas'message).
> The bottom line is that what you're trying is not the way things were
> supposed to work.
"supposed to work" sounds really subjective in this context. Anyway,
that shouldn't prevent us from improving the software by making it work other
ways too (let me remind you that it worked before 7.0).
> There is no harm in having 20 -I's on the compile line unless the user has
> more than one header file with the same name on his system, in which case
> most everything else on it is going to break as well.
You can't image how much you're right !! Postgres happens to install a
header file named `config.h' in its installation directory. As a consequence,
if we follow your reasoning and if, as you suggest, we don't rely on the
semantic difference of "" and <>, no application using autoconf will be able
to compile a postgres support !! There's really nothing to be proud of :-(
> Rewriting almost every single provided macro in order to disable the cache
> surely sounds like subversion to me.
It is not. It is trying to improve autoconf when we find deficiencies
(just like I'm trying to do with you here): the autoconf developers are aware
of this and as a matter of fact, the next version of autoconf will have the
cache disable by default. Our script will little by little get simpler, as
both communities will benefit from the work. That's the way I like free
software development the more.
> > XEmacs doesn't need postgresql. It nows supports it, which means
> > people can write Emacs Lisp packages interfacing with postgres databases,
> > and benefit from the XEmacs editing features and environment.
>
> Cool.
Yes :-). Thank Steven Baur for that.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
[View Less]
Peter Eisentraut <e99re41(a)DoCS.UU.SE> writes:
> There is no harm in having 20 -I's on the compile line unless the user has
> more than one header file with the same name on his system, in which case
> most everything else on it is going to break as well.
This in fact one of the problems that caused us to switch to the newer
inclusion mechanism. (prompted by the mess that is libXawXXXX)
Jan
P.S. I would be interested in knowing what problem the user had for
which you made …
[View More]change. Maybe it is relevant for use too?
[View Less]
are these msgs about customize appropriate for xemacs-beta or should I be
posting them to comp.emacs.xemacs? it seems I may have stumbled upon some
things that qualify as bugs, but I'm never sure if it's that or just mere
user ignorance
this one in particular may very well be in the latter category...
how does one customize efs? I see this in efs.el:
(defgroup efs nil
"Transparent ftp access."
:group 'files)
but it doesn't appear under the Files menu or when doing M-x customize
files
…
[View More]?
--
John A. Turner, Senior Research Associate
Blue Sky Studios, One South Rd, Harrison, NY 10528
http://www.blueskystudios.com/ (914) 825-8319
[View Less]
I like to use uniquify with post-forward-angle-brackets, and since I'm
migrating to custom for everything (thanks for the comments on my previous
question about it - Jan, I haven't tried out the stuff you sent yet -
sorry), got rid of what I had used, i.e.:
(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward-angle-brackets)
and used customize to do the same thing - so it added:
'(uniquify-buffer-name-style (quote post-forward-angle-brackets))
in the variables section - great
…
[View More]
however, it doesn't seem to work unless I still put a
(require 'uniquify)
before the custom-set stuff
that shouldn't be necessary, should it?
--
John A. Turner, Senior Research Associate
Blue Sky Studios, One South Rd, Harrison, NY 10528
http://www.blueskystudios.com/ (914) 825-8319
[View Less]
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
In XEmacs 21.2 (beta32) "Kastor & Polydeukes" [Lucid] (i686-pc-linux, Mule) of Tue Apr 11 2000 on vx500-paulw
configured using `configure --prefix=/usr/local/stow/xemacs_cvs --with-mule --package-path=/usr/local/lib/xemacs --with-site-lisp=yes --with-clash-detection --without-prefix'…
[View More]
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
when comparing two files I get the following error:
Fatal error: assertion failed, file indent.c, line 628, elt >= 0
This error appears to happen whenever I compare any two files using
the menubar item.
here is the lisp unwind
# (unwind-protect ...)
sit-for(0)
# bind (window-min-height ctl-frame-iconified-p dont-iconify-ctl-frame deiconi
fy-ctl-frame ctl-frame old-ctl-frame lines fheight fwidth adjusted-parameters de
signated-minibuffer-frame ctl-buffer)
ediff-setup-control-frame(#<buffer "*Ediff Control Panel*"> #<x-frame "emacs"
0x2624>)
# bind (done-C done-B done-A designated-minibuffer-frame wind-B-start wind-A-s
tart use-same-frame orig-wind three-way-comparison split-window-function force-o
ne-frame ctl-frame-exists-p frame-C frame-B frame-A wind-C wind-B wind-A window-
min-height control-buf buf-C buf-B buf-A)
ediff-setup-windows-multiframe-compare(#<buffer "unixinst.mak"> #<buffer "ui">
nil #<buffer "*Ediff Control Panel*">)
# bind (control-buf buf-C buf-B buf-A)
ediff-setup-windows-multiframe(#<buffer "unixinst.mak"> #<buffer "ui"> nil #<b
uffer "*Ediff Control Panel*">)
# bind (control-buffer buffer-C buffer-B buffer-A)
ediff-setup-windows(#<buffer "unixinst.mak"> #<buffer "ui"> nil #<buffer "*Edi
ff Control Panel*">)
# (unwind-protect ...)
# bind (control-buffer control-buffer-name merge-buffer-file setup-parameters
startup-hooks file-C buffer-C file-B buffer-B file-A buffer-A)
ediff-setup(#<buffer "unixinst.mak"> "/tmp/unixinst.mak" #<buffer "ui"> "/tmp/
ui" nil nil ((lambda nil (delete-file "/tmp/unixinst.mak") (delete-file "/tmp/ui
") (if ... ...))) ((ediff-job-name . ediff-buffers)) nil)
# bind (file-C file-B file-A buf-C-file-name buf-C-is-alive buf-B-file-name bu
f-A-file-name merge-buffer-file job-name startup-hooks buf-C buf-B buf-A)
ediff-buffers-internal("unixinst.mak" "ui" nil nil ediff-buffers)
# bind (job-name startup-hooks buffer-B buffer-A)
#<compiled-function (buffer-A buffer-B &optional startup-hooks job-name) "...(
14)" [job-name ediff-buffers ediff-buffers-internal buffer-A buffer-B nil startu
p-hooks] 6 ("/usr/local/lib/xemacs/xemacs-packages/lisp/ediff/ediff.elc" . 4813)
(let (bf) (list ... ...))>("unixinst.mak" "ui")
call-interactively(ediff-buffers)
# (condition-case ... . error)
# (catch top-level ...)
here is the C stacktrace....
#0 0x402f7c11 in __kill () from /lib/libc.so.6
#1 0x80c0249 in fatal_error_signal (sig=6) at emacs.c:293
#2 0x402f7b18 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125
#3 0x402f9053 in abort () at ../sysdeps/generic/abort.c:88
#4 0x80c01ae in assert_failed (file=0x826e5eb "indent.c", line=628,
expr=0x826e727 "elt >= 0") at emacs.c:2754
#5 0x8166764 in vmotion_1 (w=0x8864f30, orig=1, vtarget=1, ret_vpos=0x0,
ret_vpix=0x0) at indent.c:628
#6 0x816739b in vmotion (w=0x8864f30, orig=1, vtarget=1, ret_vpos=0x0)
at indent.c:700
#7 0x819cddf in redisplay_window (window=143019824, skip_selected=0)
at redisplay.c:6193
#8 0x819d3cd in redisplay_frame (f=0x88ce7a8, preemption_check=0)
at redisplay.c:6455
#9 0x819d5b8 in redisplay_device (d=0x845e948, automatic=1)
at redisplay.c:6533
#10 0x819d955 in redisplay_without_hooks () at redisplay.c:6622
#11 0x81a46e8 in redisplay () at redisplay.c:6679
#12 0x8110858 in Fsit_for (seconds=1, nodisplay=137229844)
at event-stream.c:2806
#13 0x80c52d9 in Ffuncall (nargs=2, args=0xbfffeb58) at eval.c:3218
#14 0x80962e6 in execute_optimized_program (
program=0x8a88e18 "=c0=c1\211\211\211\211\211\211\211\211\032\e\034\035\036\006\036\a\036\b\036\t\036\n\036\013\016\f=ab#=cd\016\f!=ab\035=ce=cd\016\f!!=ab\025r\016\fq\210\016\017=ab\005=d0=c1!\210=d1=d2!\210)=aa\f\016\023=d4a=ac\006=d5\016\026!\210\016\f=ab\031=cd\016\f!=ab\023=ce=cd\016\f!!=ab\013r\016\fq\210\016\027)=aa\013\016\023=d4a=ae\005=d5\016\026!\026\006\016\f=ab*=cd\016\f!=ab$=ce=cd\016\f!!=ab\034r\016\fq\210=d8\016\006!=ab\005\016\006=aa\005=d9\016\032!\211\026\a\026\027)=aa\f\016\023=d4a=ac\006=d5\016\026!\210\016\a\036\e=dc =ad\027=d8\016\e!=ad\021\016\017=ab\a=dd\016\e!=aa\a=de\016\e!=df"..., stack_depth=11,
constants_data=0x8a806a8) at bytecode.c:747
#15 0x8095eb9 in funcall_compiled_function (fun=144693904, nargs=2,
args=0xbfffec74) at bytecode.c:519
#16 0x80c548f in Ffuncall (nargs=3, args=0xbfffec70) at eval.c:3253
#17 0x80962e6 in execute_optimized_program (
program=0x8a78718 "=c0=c1!\210=c2\e=c4\r!\036\006=c4\016\a!\036\b=c4\016\t!\036\n\016\006=ad\005=cb\016\006!\036\f\016\b=ad\005=cb\016\b!\036\r\016\n=ad\005=cb\016\n!\036\016\016\017=ab\e=d0\016\017!=ab\025=d1=d0\016\017!!=ab\rr\016\017q\210=d2\016\023!)=aa\013\016\024=d5a=ae\005=d6\016\027!\036\030\016\017=ab\031=d0\016\017!=ab\023=d1=d0\016\017!!=ab\013r\016\017q\210\016\031)=aa\013\016\024=d5a=ae\005=d6\016\027!\036\032\016\017=ab\031=d0\016\017!=ab\023=d1=d0\016\017!!=ab\013r\016\017q\210\016\e)=aa\013\016\024=d5a=ae\005=d6\016\027!\036\034\016\017=ab\031=d0\016\017!=ab\023=d1=d0\016\017!!=ab\013r\016\017q\210\016\035"..., stack_depth=3,
constants_data=0x8a40860) at bytecode.c:747
#18 0x8095eb9 in funcall_compiled_function (fun=144693764, nargs=4,
args=0xbfffed6c) at bytecode.c:519
#19 0x80c548f in Ffuncall (nargs=5, args=0xbfffed68) at eval.c:3253
#20 0x80962e6 in execute_optimized_program (
program=0x8a4db70 "\b=ab\026=c1\b!=ab\021=c2=c1\b!!=ab\nr\bq\210=c3\024)=aa\013\r=c6a=ac\006=c7\016\b!\210\016\t=ab\013=ca\016\013\016\f\016\r\b$\207=ce\016\013\016\f\016\r\b$\20711\231", stack_depth=5, constants_data=0x8a528d8) at bytecode.c:747
#21 0x8095eb9 in funcall_compiled_function (fun=144693708, nargs=4,
args=0xbfffee6c) at bytecode.c:519
#22 0x80c548f in Ffuncall (nargs=5, args=0xbfffee68) at eval.c:3253
#23 0x80962e6 in execute_optimized_program (
program=0x8a4da30 "=c0=c1!\210=c2 =c3 a=ab\005=c4=c5!\210=c6 =ac\004=c7\026\b=c9\016\n!=ac1\016\n=ab\031=cb\016\n!=ab\023=cc=cb\016\n!!=ab\013r\016\nq\210\016\b)=aa\013\016\r=cea=ae\005=cf\016\020!\016\021\016\022\016\023\016\n$\210=c0=d4!\207g", stack_depth=5,
constants_data=0x8a34d20) at bytecode.c:747
#24 0x8095eb9 in funcall_compiled_function (fun=144693596, nargs=4,
args=0xbfffef6c) at bytecode.c:519
#25 0x80c548f in Ffuncall (nargs=5, args=0xbfffef68) at eval.c:3253
#26 0x80962e6 in execute_optimized_program (
program=0x8a21130 "=c0=c1\n!!\022=c0=c1\013!!\023\f;=ab\a=c0=c1\f!!\024\r;=ab(=c0=c1\r!!\025=c6=c7\r!!=ac\n=c8=c9=ca=c7\r!!\"\210=c6\r!=ab\r=cb\r!=ab\b=c8=cc=ca\r!\"\210=cd=ce=cf\"\036\020\016\021=ab\e=d2\016\021!=ab\025=d3=d2\016\021!!=ab\rr\016\021q\210=d4\016\020!)=aa\013\016\025=d6a=ae\005=c8\016\027!\211\036\030\203R\005=d2\016\030!\203K\005=d3=d2\016\030!!\203B\005r\016\030q\210=d9 \210=da=db!\210=da=dc!\210=da=dd!\210=da=de!\210=da=df!\210=da=e0!\210=da=e1!\210=e2=e3!\210\016$=ab\023\016$＠＠\016$＠AL\210\016$A\211\026$=ac=ef\016%=e6s\026"..., stack_depth=7, constants_data=0x89f7928)
at bytecode.c:747
#27 0x8095eb9 in funcall_compiled_function (fun=144695500, nargs=9,
args=0xbffff074) at bytecode.c:519
#28 0x80c548f in Ffuncall (nargs=10, args=0xbffff070) at eval.c:3253
#29 0x80962e6 in execute_optimized_program (
program=0x8655008 "=c0=c1\n!!\e=c0=c1\f!!\035\016\006=ad\r=c1\016\006!=ad\a=c7=c1\016\006!!\211\036\b=ad\006=c0=c1\f!!\036\t=ca\036\013=ca\036\f=ca\036\r\n=ab\r=c1\n!=ab\b=c7=c1\n!!=ac\006=ce=cf\n\"\210\f=ab\r=c1\f!=ab\b=c7=c1\f!!=ac\006=ce=cf\f\"\210\016\020\036\021\016\022=ab\013\016\b=ac\a=ce=cf\016\006\"\210)\013;=ab\005=d3\013!\023\r;=ab\005=d3\r!\025\016\t;=ab\a=d3\016\t!\026\t=d4\n\013\"\026\013=d4\f\r\"\026\f\016\b=ab\t=d4\016\006\016\t\"\026\r=d5=c1\n!\016\013=c1\f!\016\f\016\b=ad\005=c1\016\006!\016\r=d6=ca=d7\016\013D=d7\016\fD=d8=d9\016\rD=d7\016\rDE"...,
stack_depth=16, constants_data=0x8a363b0) at bytecode.c:747
#30 0x8095eb9 in funcall_compiled_function (fun=144923556, nargs=5,
args=0xbffff1a0) at bytecode.c:519
#31 0x80c548f in Ffuncall (nargs=6, args=0xbffff19c) at eval.c:3253
#32 0x80962e6 in execute_optimized_program (
program=0x8662398 "\b=ac\003=c1\020=c2\013\f=c5\016\006\b%\207", stack_depth=6,
constants_data=0x89e0940) at bytecode.c:747
#33 0x8095eb9 in funcall_compiled_function (fun=144923500, nargs=2,
args=0xbffff2a0) at bytecode.c:519
#34 0x80c548f in Ffuncall (nargs=3, args=0xbffff29c) at eval.c:3253
#35 0x80c5b04 in Fapply (nargs=2, args=0xbffff2dc) at eval.c:3488
#36 0x80c8ee9 in apply1 (fn=144923500, arg=145341048) at eval.c:3841
#37 0x809a595 in Fcall_interactively (function=140040292,
record_flag=137229844, keys=137229844) at callint.c:394
#38 0x80c52ed in Ffuncall (nargs=2, args=0xbffff4b8) at eval.c:3218
#39 0x80c8f80 in call1 (fn=137300332, arg0=140040292) at eval.c:3867
#40 0x81125b9 in execute_command_event (command_builder=0x83ace38,
event=145527432) at event-stream.c:3832
#41 0x81132a8 in Fdispatch_event (event=145527432) at event-stream.c:4203
#42 0x80a46ab in Fcommand_loop_1 () at cmdloop.c:575
#43 0x80a491d in command_loop_1 (dummy=137229844) at cmdloop.c:490
#44 0x80c9b0b in condition_case_1 (handlers=137229940,
bfun=0x80a48e0 <command_loop_1>, barg=137229844,
hfun=0x80a3bc0 <cmd_error>, harg=137229844) at eval.c:1644
#45 0x80a4a1c in command_loop_2 (dummy=137229844) at cmdloop.c:252
#46 0x80c99d9 in internal_catch (tag=137303964,
func=0x80a49e0 <command_loop_2>, arg=137229844, threw=0x0) at eval.c:1310
#47 0x80a3f8d in initial_command_loop (load_me=137229844) at cmdloop.c:301
#48 0x80be6b7 in xemacs_21_2_b32_i686_pc_linux (argc=1, argv=0xbffff834,
envp=0xbffff83c, restart=0) at emacs.c:1873
#49 0x80c0498 in main (argc=1, argv=0xbffff834, envp=0xbffff83c)
#50 0x402f1313 in __libc_start_main (main=0x80c0390 <main>, argc=1,
argv=0xbffff834, init=0x808193c <_init>, fini=0x822d8b0 <_fini>,
rtld_fini=0x4000ac70 <_dl_fini>, stack_end=0xbffff82c)
at ../sysdeps/generic/libc-start.c:90
[View Less]
Peter Eisentraut <e99re41(a)DoCS.UU.SE> wrote:
> You cannot assume that "" does anything differently than <>. The difference
> is cosmetic.
Really, I'd like you to point me to one known C preprocessor that does
not make the difference. Standards are a good thing, but they are not
immutable, and the evolution leans towards this semantic difference between ""
and <>. It's already explicit in C++ for instance. If 99% of the preprocessors
of the planet work a …
[View More]certain way, I don't see anything wrong in following a
de-facto convention, and I'd encourage people to conform to it, in view to a
very probable standardization. That's exactly what happened in this particular
case.
> I did a quick scan of my system and both practices are used equally
> widely, so unless you intend to address all the authors of all the other
> packages as well I suggest you give it up.
That's indeed the two attitudes one can adopt. Either you do your on
personal little cruft alone in your corner, or you try to talk with people. We
usually try to "address the authors of the packages we interact with". This
policy is IMHO of a better citizenship.
> Everybody uses the '-I method'. If you have too many -I's all at once I
> suggest either not bothering, or modularizing your code.
Please, don't you think we already have modularized code ? We're not
trying to find a solution to our problem here. We're trying to find the
*cleanest* solution for *everybody*. Why don't you want to understand that ?
Without any modification on your part, we know how to fix the problem in at
least 3 different manners. But that's just not the point.
Let me rephrase what I originally wanted to underline:
- Joe provides a library libfoo.
- Joe provides a header libfoo.h, located at /usr/include/libfoo/libfoo.h in
order to use the library.
Now if this program:
| #include <libfoo/libfoo.h>
| main () {}
can't compile, then, I consider that the installation of the library is
broken, and instead of writing yet another trick in my code, I say to myself
"OK I should tell Joe about this.". What's wrong with that ?! Given that Tom
actually seems to agree with this, and given the answer of the Andres Kardos'
answer, I don't understand your attitude here.
> Just because you guys are constantly trying to subvert autoconf there's no
> reason to let it out on us. :-/
*subvert* autoconf ?! We're using autoconf exactly in the way it is
done for: to make the life of our users better.
> Okay, now *why* does XEmacs need PostgreSQL?
XEmacs doesn't need postgresql. It nows supports it, which means
people can write Emacs Lisp packages interfacing with postgres databases, and
benefit from the XEmacs editing features and environment.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
[View Less]
