11:19 p.m.
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.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
I often have many frames open on many different buffers. I frequently
close most or all but one of these frames. Having done this, sometimes
opening a frame on a buffer that I have looked at before, the visible
area and point are nowhere near where I left them when I closed the
last frame on the buffer. I don't expect point to change just because
I closed a frame.
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux sumatra 2.4.18-18.7.xbigmem #1 SMP Wed Nov 13 18:24:15 EST 2002 i686
unknown
configure '--with-mule' '--prefix=/home/kramer/install/'
XEmacs 21.4.11 "Native Windows TTY Support" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /home/kramer/install/src/xemacs-21.4.11
Installation prefix: /home/kramer/install/
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -Wshadow
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: pgsql/libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
Compiling in support for Canna on Mule.
Compiling in support for the WNN input method on Mule.
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
Load-Path Lisp Shadows:
----------------------
(/home/kramer/install/lib/xemacs/xemacs-packages/lisp/fsf-compat/thingatpt
/home/kramer/emacs-cust/thingatpt
/home/kramer/install/lib/xemacs-21.4.11/lisp/gnuserv
/home/kramer/emacs-cust/gnuserv
/home/kramer/install/lib/xemacs-21.4.11/lisp/custom
/home/kramer/emacs-cust/custom)
Installed XEmacs Packages:
-------------------------
((xslt-process:version 1.11 :type regular)
(xslide :version 1.03 :type regular)
(xemacs-devel :version 1.48 :type single-file)
(xemacs-base :version 1.71 :type regular)
(w3 :version 1.26 :type regular)
(vm :version 7.07 :type regular)
(view-process :version 1.12 :type regular)
(vc-cc :version 1.21 :type regular)
(vc :version 1.33 :type regular)
(tm :version 1.34 :type regular)
(text-modes :version 1.55 :type single-file)
(texinfo :version 1.21 :type regular)
(speedbar :version 1.24 :type regular)
(slider :version 1.13 :type regular)
(sh-script :version 1.16 :type regular)
(semantic :version 1.14 :type regular)
(scheme :version 1.12 :type regular)
(rmail :version 1.13 :type regular)
(python-modes :version 1.01 :type single-file)
(psgml :version 1.35 :type regular)
(ps-print :version 1.08 :type regular)
(prog-modes
:version
1
.67
:type
single-file)
(perl-modes :version 1.02 :type single-file)
(pcomplete :version 1.02 :type regular)
(pcl-cvs :version 1.64 :type regular)
(pc :version 1.25 :type single-file)
(os-utils :version 1.29 :type single-file)
(net-utils :version 1.28 :type single-file)
(mule-ucs :version 1.04 :type regular)
(mule-base :version 1.42 :type regular)
(mh-e :version 1.16 :type regular)
(mailcrypt :version 2.12 :type regular)
(mail-lib :version 1.54 :type regular)
(liece :version 1.1 :type regular)
(jde :version 1.38 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.28 :type regular)
(ibuffer :version 1.08 :type regular)
(hm--html-menus :version 1.18 :type regular)
(gnus :version 1.64 :type regular)
(fsf-compat :version 1.11 :type single-file)
(eterm :version 1.13 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.03 :type regular)
(efs :version 1.29 :type regular)
(edit-utils :version 1.95 :type single-file)
(ediff :version 1.44 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.12 :type regular)
(debug :version 1.16 :type regular)
(cc-mode :version 1.31 :type regular)
(calendar :version 1.19 :type regular)
(apel :version 1.25 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow java-ex jde jde-checkstyle
jde-open-source jde-ant executable jde-package jde-import
jde-which-method jde-stat jde-javadoc-gen jde-java-font-lock
jde-javadoc jde-java-grammar jde-wiz jde-complete senator eldoc
browse-url jde-gen jde-make jde-run jde-jdb jde-bug jde-dbs jde-dbo
jde-db jde-parse jde-imenu semantic-imenu semantic-java thingatpt
avltree stack-m elib-node semantic-bnf semantic-sb semantic-ia-sb
semantic-analyze semantic-ctxt semantic-cb eieio-base eieio-speedbar
eieio-custom speedbar sb-image dframe semantic-util-modes timer
semantic-util semantic assoc working jde-compile compile comint ring
cus-edit cus-load cc-mode cc-align cc-cmds cc-engine cc-styles
cc-langs cc-vars cc-menus imenu cc-defs semantic-load jde-help
jde-util jde-widgets tree-widget efc wid-edit beanshell eieio advice
advice-preload sendmail rfc822 tempo psgml-html psgml-xemacs sgml-mode
psgml makefile regexp-opt efs-cu gnuserv xemacs-stuff tag-stuff tags
etags more-hacks font-lock magic pending-del cus-face paren
blink-paren xslt-process-autoloads xslide-autoloads
xemacs-devel-autoloads xemacs-base-autoloads w3-autoloads vm-autoloads
view-process-autoloads vc-cc-autoloads vc-autoloads tm-autoloads
text-modes-autoloads texinfo-autoloads speedbar-autoloads
slider-autoloads sh-script-autoloads semantic-autoloads
scheme-autoloads rmail-autoloads python-modes-autoloads
psgml-autoloads ps-print-autoloads prog-modes-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads net-utils-autoloads mule-ucs-autoloads
mule-base-autoloads mh-e-autoloads mailcrypt-autoloads
mail-lib-autoloads liece-autoloads jde-autoloads ispell-autoloads
ilisp-autoloads ibuffer-autoloads hm--html-menus-autoloads
gnus-autoloads fsf-compat-autoloads eterm-autoloads emerge-autoloads
elib-autoloads eieio-autoloads efs-autoloads edit-utils-autoloads
ediff-autoloads edebug-autoloads dired-autoloads debug-autoloads
cc-mode-autoloads calendar-autoloads apel-autoloads lisp-autoloads
loadhist auto-show fontl-hooks x-iso8859-1 canna-leim slovenian czech
romanian ccl mule-help code-cmds gutter-items menubar-items x-menubar
mode-motion mouse itimer auto-save lisp-mode easymenu iso8859-1 page
buff-menu lib-complete cus-file derived frame text-props obsolete
cus-start custom widget cl-extra mini-cl cl cl-19 packages backquote
very-early-lisp postgresqlv7 postgresql CANNA file-coding wnn mule
lucid-scrollbars cut-buffer lucid-menubars motif-dialogs x
c-balloon-help tty-frames tty toolbar native-sound scrollbar
unix-processes multicast network-streams subprocesses modules
menu-accelerator-support menubar berkeley-db md5 xemacs xim gutter
tiff png gif jpeg xpm xbm lisp-float-type linux dialog devices
window-system base64)
Recent keystrokes:
-----------------
i n t e r f button1 button1up button1 button1up C-z
C-z G C-z o j a v a o TAB t TAB RET C-s \ b i s a \
b C-f C-z j p u b l i c . * \ b i s a \ b RET button2
button2up misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user C-z b j a v a _ TAB RET
C-s p b j s t r c C-f C-z C-k C-z C-k C-z C-k C-z C-k
C-z C-k C-] C-g C-x b d e c TAB RET M-< misc-user
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
Buffer:
Quit
No recursive edit is in progress
Buffer:
Buff JavaAbstractObjectType.java line (129 . 3)
Current buffer *srgrep*
Buff JavaAbstractObjectType.java line (129 . 3)
Setting JDE variables to startup values...
JavaAbstractObjectType.java: [#######################################] ... done
Current buffer *srgrep*
Setting JDE variables to startup values...
JavaObjectType.java: [###############################################] ... done
Declaration.java: [##################################################] ... done
Grep done
0.02%
0.02%
0.02%
Buffer:
5:02 a.m.
>>>> "Bryan" == Bryan Kramer
<kramer(a)techne.ca> writes:
Bryan> I often have many frames open on many different buffers. I
Bryan> frequently close most or all but one of these
Bryan> frames. Having done this, sometimes opening a frame on a
Bryan> buffer that I have looked at before, the visible area and
Bryan> point are nowhere near where I left them when I closed the
Bryan> last frame on the buffer. I don't expect point to change
Bryan> just because I closed a frame.
OK, that's a bug. But we need to know what modes these buffers with
changing point are in, and it would be best if you can provide us with
a recipe like
xemacs -nw
C-x C-f new-file
; insert text and move
; alternatively, find a file it happens on that you can send us or put
; up on the Web for retrieval
C-x 5 C-f some-other-file
C-x 5 o
C-x 5 0
C-x 5 b new-file
; point is wrong
Also, if it's consistently in one of the big externally maintained
packages like JDE or cc-mode, you should file bug reports with the
maintainers. It seems possible to me that one of this packages is
doing something "intelligent" outside of a save-excursion or the like;
there's nothing we can do about that kind of thing except ask the
maintainers to fix.
It's especially plausible with JDE because (a) it's very intelligent
and (b) I don't use it which is consistent with me not having observed
the bug.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:10 p.m.
On Thu, 09 Jan 2003, stephen(a)xemacs.org wrote:
>>>>> "Bryan" == Bryan Kramer
<kramer(a)techne.ca> writes:
Bryan> I often have many frames open on many different buffers. I
Bryan> frequently close most or all but one of these
Bryan> frames. Having done this, sometimes opening a frame on a
Bryan> buffer that I have looked at before, the visible area and
Bryan> point are nowhere near where I left them when I closed the
Bryan> last frame on the buffer. I don't expect point to change
Bryan> just because I closed a frame.
OK, that's a bug. But we need to know what modes these buffers with
changing point are in, and it would be best if you can provide us with
a recipe like
If you have the same buffer in multiple frames, the point of the
second frame will get the point of the first frame. This can be seen
in fundamental mode.
frame1: 1) Open a file in fundamental mode, text mode will probably work.
2) Put the mark somewhere distinctive in the buffer.
3) Leave this frame open on the file
frame2: 1) Open a new frame for the same file.
The new frame opens at the frame1's point
2) Jump somewhere else in the file.
3) switch buffers away from file.
4) switch buffers back to file.
5) My point is back to frame1's point, not where I left it
before switching buffers.
Basically, you can have multiple frames looking at a file, but you
(kind of) only get one point the multiple frames share.
-jeff
xemacs -nw
C-x C-f new-file
; insert text and move
; alternatively, find a file it happens on that you can send us or put
; up on the Web for retrieval
C-x 5 C-f some-other-file
C-x 5 o
C-x 5 0
C-x 5 b new-file
; point is wrong
Also, if it's consistently in one of the big externally maintained
packages like JDE or cc-mode, you should file bug reports with the
maintainers. It seems possible to me that one of this packages is
doing something "intelligent" outside of a save-excursion or the like;
there's nothing we can do about that kind of thing except ask the
maintainers to fix.
It's especially plausible with JDE because (a) it's very intelligent
and (b) I don't use it which is consistent with me not having observed
the bug.
2:47 p.m.
>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
Jeff> On Thu, 09 Jan 2003, stephen(a)xemacs.org wrote:
>>>>>> "Bryan" == Bryan Kramer
<kramer(a)techne.ca> writes:
>
Bryan> I often have many frames open on many different buffers. I
Bryan> frequently close most or all but one of these
Bryan> frames. Having done this, sometimes opening a frame on a
Bryan> buffer that I have looked at before, the visible area and
Bryan> point are nowhere near where I left them when I closed the
Bryan> last frame on the buffer. I don't expect point to change
Bryan> just because I closed a frame.
>
> OK, that's a bug. But we need to know what modes these buffers with
> changing point are in, and it would be best if you can provide us with
> a recipe like
Jeff> If you have the same buffer in multiple frames, the point of the
Jeff> second frame will get the point of the first frame. This can be seen
Jeff> in fundamental mode.
Yes, it's because of this:
`set-window-point' is a built-in function
(set-window-point WINDOW POS)
Documentation:
[...] The equivalence of the selected window's point with its buffer's
point is maintained throughout XEmacs. [...]
It's brain damage, but it might cause breakage if the invariant were
taken out.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11:41 a.m.
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
> Documentation:
> [...] The equivalence of the selected window's point with
its
> buffer's point is maintained throughout XEmacs. [...]
ms> It's brain damage, but it might cause breakage if the
ms> invariant were taken out.
How is it brain damage? I think it would damage one's brain if XEmacs
were to make changes at some place _other_ than the selected window's
point.
If you don't want to edit in a window, then don't select it, and if
you want to have multiple editing points for the same text, use
multiple indirect buffers, no?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
noon
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
>> Documentation:
>> [...] The equivalence of the selected window's point with
its
>> buffer's point is maintained throughout XEmacs. [...]
ms> It's brain damage, but it might cause breakage if the
ms> invariant were taken out.
Stephen> How is it brain damage? I think it would damage one's brain if XEmacs
Stephen> were to make changes at some place _other_ than the selected window's
Stephen> point.
Previous messages in this thread explain it: I conjecture this
assumption was born in the time before multiple frames. There, you
always type into the selected window, which is why you want the
invariant the way it is.
Now, it makes sense if the selected window *of the selected frame*
maintains that invariant, but not for *all* frames.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
1:42 p.m.
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> Previous messages in this thread explain it:
If they did, I wouldn't have asked. ;-)
ms> I conjecture this assumption was born in the time before
ms> multiple frames. There, you always type into the selected
ms> window, which is why you want the invariant the way it is.
And in multiple frames you can type into an unselected window? Huh?
I don't think frames have anything to do with this, except that it
makes it easier to fail to notice that a misbehaving program has
changed buffer point on you.
ms> Now, it makes sense if the selected window *of the selected
ms> frame* maintains that invariant, but not for *all* frames.
That's easy for you to say. Now turn it into a coherent specification
of a unique point associated to a buffer. And it has to be a unique
point: the OP is talking about a case where all frames containing
windows displaying that buffer have been closed, so a frame ->
frame-buffer-point mapping makes no sense.
Note first that if a window is still open, its point doesn't move. If
you don't select the window, you don't see point. When you select
that window, buffer point moves there. So what you're saying,
apparently, is that if you close that frame when the window is
_un_selected, in some cases that should move buffer point to the
unselected window's point. Huh?? How is XEmacs supposed to guess
when that is appropriate?
If it is the window point-buffer point synchronization that is causing
his problem, it must be the case that the last selected window
displaying that buffer was not the one he considers the "principal
view" of that buffer. I don't see how XEmacs can intuit which is the
"principal view"---most recently selected window is a simple rule that
will get it right almost all of the time. (Unless there are apps that
are selecting windows on buffers behind the user's back. Shouldn't
they be using `save-excursion'? Or an indirect buffer?)
Nor will the heuristic of keeping a per-frame list of buffer points
and using the last one closed get this right, because that will often
override the user's explicit last selection. This would force users
to close frames, maybe even windows, in a specific order (namely, the
window whose point they want saved in the buffer's point last).
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:51 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> Previous messages in this thread explain it:
Stephen> If they did, I wouldn't have asked. ;-)
Which is why I tried to explain once more ;-)
ms> I conjecture this assumption was born in the time before
ms> multiple frames. There, you always type into the selected
ms> window, which is why you want the invariant the way it is.
Stephen> And in multiple frames you can type into an unselected
Stephen> window? Huh?
No, but you can type into a window that's not the selected window of a
given frame---namely, the selected window, of *another* frame.
ms> Now, it makes sense if the selected window *of the selected
ms> frame* maintains that invariant, but not for *all* frames.
Stephen> That's easy for you to say. Now turn it into a coherent
Stephen> specification of a unique point associated to a buffer. [...]
I don't understand what you're saying after this at all, I'm afraid. :-(
Let me try to explain once again:
The synchronization between the window point of the selected window
and its buffer's point is necessary so that commands *you type* will
DTRT, namely act at the point where the user is typing. There's no
reason for this synchronicity to be in place in windows where the user
is *not* typing. (In this case, selected windows of unselected
frames.) There'd be no heuristics involved at all.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
3:08 p.m.
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> The synchronization between the window point of the selected
ms> window and its buffer's point is necessary so that commands
ms> *you type* will DTRT, namely act at the point where the user
ms> is typing.
I think that is wrong. The reason for the synchronization window
point -> buffer point is so that _programs_ will act at the point the
user was typing or viewing, unless explicitly told to do otherwise.
Then while the program is doing whatever it does, the reverse
synchronization (buffer point -> window point) is done so that the
user is aware of what the program did, again unless the program
deliberately conceals any motion it executed.
When the user is typing, there is no need whatsoever for a separate
concept of buffer point (except in the sense of manipulating the gap,
but that's not user-visible). Just insert/delete/twiddle/fix case/
whatever at _window point_, which is always well-defined while the
user is typing.
(This distinction is slightly incoherent, since of course user typing
is meaningless except as it invokes programs. Presumably what I mean
is programs that are invoked directly according to stable keymaps,
etc, vs programs that are invoked asynchronously from the user's point
of view, such as hooks and timers.)
ms> There's no reason for this synchronicity to be in
ms> place in windows where the user is *not* typing.
ms> (In this case, selected windows of unselected frames.)
That's a meaningless statement. Synchronicity is a property of how
buffer and window points _change_ in response to selection state
changes and buffer point motion, not of the particular buffer point
<-> window point mapping at any given time or selection state.
ms> There'd be no heuristics involved at all.
No, just complete nondeterminism. :-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:17 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> The synchronization between the window point of the selected
ms> window and its buffer's point is necessary so that commands
ms> *you type* will DTRT, namely act at the point where the user
ms> is typing.
Stephen> I think that is wrong. The reason for the synchronization window
Stephen> point -> buffer point is so that _programs_
What do you mean by "programs"? It seems you mean exactly the same
thing as what I meant by "commands"---in XEmacs, commands *are*
programs. I added the qualification "you type" to mean this whole
business only makes sense for interaction anyway.
Stephen> will act at the point the user was typing or viewing, unless
Stephen> explicitly told to do otherwise. Then while the program is
Stephen> doing whatever it does, the reverse synchronization (buffer
Stephen> point -> window point) is done so that the user is aware of
Stephen> what the program did, again unless the program deliberately
Stephen> conceals any motion it executed.
That is exactly what I meant, as well.
Stephen> When the user is typing, there is no need whatsoever for a separate
Stephen> concept of buffer point (except in the sense of manipulating the gap,
Stephen> but that's not user-visible). Just insert/delete/twiddle/fix case/
Stephen> whatever at _window point_, which is always well-defined while the
Stephen> user is typing.
Exactly.
ms> There's no reason for this synchronicity to be in
ms> place in windows where the user is *not* typing.
ms> (In this case, selected windows of unselected frames.)
Stephen> That's a meaningless statement. Synchronicity is a property of how
Stephen> buffer and window points _change_ in response to selection state
Stephen> changes and buffer point motion, not of the particular buffer point
Stephen> <-> window point mapping at any given time or selection state.
Of course, I believe it is not a meaningless statement. On the other
hand, I don't understand at all what you're saying. It reads like
complete gibberish to me. Let me repeat:
Currently, there *is* synchronicity in places where the user is not
typing, namely in selected windows of non-selected frames.
This is pointless and confusing, from the user's perspective. (Well,
point-*full*, actually ...)
This is as simple as I can put it. What do you read into this?
ms> There'd be no heuristics involved at all.
Stephen> No, just complete nondeterminism. :-)
Ah, now, what is it: is my statement meaningless or does it prescribe
non-determinism?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
7:16 p.m.
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> What do you mean by "programs"? It seems you mean exactly the
ms> same thing as what I meant by "commands"
No. Commands are programs, but so are hook functions, which need not
be commands.
ms> Currently, there *is* synchronicity in places where the user
ms> is not typing, namely in selected windows of non-selected
ms> frames.
I have no idea what that means in terms of the XEmacs I have in front
of me. If I type into a window on a buffer, then the buffer point is
synched to that window, and is not the same as the window point in a
selected window on that buffer in a non-selected frame (except by
accident, and if I move in the selected frame, it won't be any more).
At least, not in any XEmacs build I have immediately available to me.
Are you telling me that in your XEmacs if you start xemacs -vanilla,
and you do
C-x b *tmp* RET
"This is a buffer, and point is at the end of line 1 in frame 1"
C-x 5 b *tmp* RET
C-b
you see the cursor move left in both frames? It does _not_ do that
for me. Nor does the cursor move in both frames as I type text if I
start xemacs -vanilla and do
C-x b *tmp* RET
C-x 5 b *tmp* RET
"This is a buffer, and point is at the end of line 1 in frame 1"
although the text appears simultaneously in both buffers. (Lack of
cursor motion is a little disconcerting here.) Now, if I start xemacs
-vanilla and do
C-x b *tmp* RET
"This is a buffer, and point is at the end of line 1 in frame 1"
C-x 5 b *tmp* RET
C-a
C-x 5 o
C-x b *scratch* RET
C-x 5 o
C-x b *scratch* RET
C-x 5 o
C-x 5 b *tmp* RET
I am now looking at a lie (point is at the beginning of that line).
This is moderately disconcerting in this context, but fixing that would
be not be trivial, I think (you'd have to keep a viewed-buffer history
for each window). Nor is it obvious that that would produce sane
results as often as the current heuristic (on switch-to-buffer, last
selected-window-on-selected-frame wins) does.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:37 a.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> What do you mean by "programs"? It seems you mean exactly the
ms> same thing as what I meant by "commands"
Stephen> No. Commands are programs, but so are hook functions, which need not
Stephen> be commands.
ms> Currently, there *is* synchronicity in places where the user
ms> is not typing, namely in selected windows of non-selected
ms> frames.
Stephen> I have no idea what that means in terms of the XEmacs I have in front
Stephen> of me. If I type into a window on a buffer, then the buffer point is
Stephen> synched to that window, and is not the same as the window point in a
Stephen> selected window on that buffer in a non-selected frame (except by
Stephen> accident, and if I move in the selected frame, it won't be any more).
Stephen> At least, not in any XEmacs build I have immediately available to me.
Good. However, some places in the code I've stumbled upon during the
window-configuration rewrite perform exactly this kind of
synchronization. (And I think this is what the original bug report
was about, as well.) This means I was probably wrong in thinking there's
lots of code depending on that behavior.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
4:15 a.m.
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> Good. However, some places in the code I've stumbled upon
ms> during the window-configuration rewrite perform exactly this
ms> kind of synchronization.
You mean writing the value of buffer's point into "point of selected
window of selected frame"?
OK, I see what you mean. Where we currently effectively have (this is
pseudo-code):
(defvar buffer-point-really-changed-hook 'update-window-points)
(defun update-window-points (buffer)
(loop-over-windows w
(when (and (eq (window-buffer w) (buffer))
(selected-window-p w))
(set-window-point (point buffer)))))
You want
(defun update-window-points (buffer)
(loop-over-windows w
(when (and (eq (window-buffer w) (buffer))
(selected-window-p w)
(selected-frame-p (window-frame w)))
(set-window-point (point buffer)))))
Except that somehow we don't actually do the first implementation? Weird.
Weird enough to need fixing ;-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:16 a.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> Good. However, some places in the code I've stumbled upon
ms> during the window-configuration rewrite perform exactly this
ms> kind of synchronization.
Stephen> You mean writing the value of buffer's point into "point of selected
Stephen> window of selected frame"?
Stephen> OK, I see what you mean. Where we currently effectively have (this is
Stephen> pseudo-code):
Stephen> (defvar buffer-point-really-changed-hook 'update-window-points)
Stephen> (defun update-window-points (buffer)
Stephen> (loop-over-windows w
Stephen> (when (and (eq (window-buffer w) (buffer))
Stephen> (selected-window-p w))
Stephen> (set-window-point (point buffer)))))
Let me clarify:
(defun update-window-points (buffer)
(loop-over-windows w
(when (eq w (frame-selected-window (window-frame w)))
(set-window-point (point buffer)))))
I'll need to look over the code to see where it's actually happening.
Certainly the window-configuration code (did and) does something like
this.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
6:25 a.m.
>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
------------------------------------------------------------------------
frame1: 1) Open a file in fundamental mode, text mode will probably work.
2) Put the mark somewhere distinctive in the buffer.
3) Leave this frame open on the file
frame2: 1) Open a new frame for the same file.
The new frame opens at the frame1's point
2) Jump somewhere else in the file.
3) switch buffers away from file.
4) switch buffers back to file.
5) My point is back to frame1's point, not where I left it
before switching buffers.
------------------------------------------------------------------------
Are you sure? This doesn't work for me unless I arrange to have
3.5) frame1 gets focus (and therefore its window is selected).
This could also happen like
3') Close frame2 (destroying its window on buffer).
4') Open frame3 (C-x 5 b) on buffer.
But that's not what the OP is seeing, since he would not see frame2 as
the last one open on the buffer.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:57 p.m.
On Fri, 10 Jan 2003, stephen(a)xemacs.org wrote:
>>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
------------------------------------------------------------------------
frame1: 1) Open a file in fundamental mode, text mode will probably work.
2) Put the mark somewhere distinctive in the buffer.
3) Leave this frame open on the file
frame2: 1) Open a new frame for the same file.
The new frame opens at the frame1's point
2) Jump somewhere else in the file.
3) switch buffers away from file.
4) switch buffers back to file.
5) My point is back to frame1's point, not where I left it
before switching buffers.
------------------------------------------------------------------------
Are you sure? This doesn't work for me unless I arrange to have
Yes. Just checked again.
3.5) frame1 gets focus (and therefore its window is selected).
I do not have to switch focus back to frame1. Both windows and
solaris 2.4.11 versions act this way for me.
This behavior surprised me the first time I ran into it. I'm not
suggesting that it be fixed, in fact, the fix might be more
surprising.
The original reporter claims that he does not have the same
buffer opened in multiple windows, so this isn't the issue anyway.
-jeff
3:30 p.m.
>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
> Are you sure? This doesn't work for me unless I arrange to
> have
Jeff> Yes. Just checked again.
In a fresh xemacs -vanilla? I _still_ can't get that sequence to work
the way you say it does on Linux (21.4.12 prerelease), or cygwin
(21.4.10 Windows[3]).
Jeff> This behavior surprised me the first time I ran into it.
Jeff> I'm not suggesting that it be fixed, in fact, the fix might
Jeff> be more surprising.
Now that you're used to it :(. However, the behavior your describe in
a vanilla XEmacs is a bug. The selected window "saves" its point in
the buffer point, and unless you select another window and its frame
containing that buffer, that buffer point should not change, and
should be restored when you switch buffers back in the selected window.
The obvious hypothesis is that you have something in your init file
that is causing this. A second possibility would be window managers
selecting the other frame without your intervention, but it seems
unlikely in principle, and very likely that on Windows we have the
same window manager (mine is Windows 2000 [Japanese]). If it's not
one of those, I'm at a total loss.
Jeff> The original reporter claims that he does not have the same
Jeff> buffer opened in multiple windows, so this isn't the issue
Jeff> anyway.
Not for him, but I sure don't like it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:24 p.m.
Yes I'm using JDE mode. I haven't been able to come up with files that
consistently reproduces this.
I will file a bug with jde developers.
To all the follow ups, it is NOT due to the fact that I have more than
one frame open on each buffer.
Stephen J. Turnbull wrote:
>>>>>"Bryan" == Bryan Kramer
<kramer(a)techne.ca> writes:
>>>>>
>>>>>
Bryan> I often have many frames open on many different buffers. I
Bryan> frequently close most or all but one of these
Bryan> frames. Having done this, sometimes opening a frame on a
Bryan> buffer that I have looked at before, the visible area and
Bryan> point are nowhere near where I left them when I closed the
Bryan> last frame on the buffer. I don't expect point to change
Bryan> just because I closed a frame.
OK, that's a bug. But we need to know what modes these buffers with
changing point are in, and it would be best if you can provide us with
a recipe like
xemacs -nw
C-x C-f new-file
; insert text and move
; alternatively, find a file it happens on that you can send us or put
; up on the Web for retrieval
C-x 5 C-f some-other-file
C-x 5 o
C-x 5 0
C-x 5 b new-file
; point is wrong
Also, if it's consistently in one of the big externally maintained
packages like JDE or cc-mode, you should file bug reports with the
maintainers. It seems possible to me that one of this packages is
doing something "intelligent" outside of a save-excursion or the like;
there's nothing we can do about that kind of thing except ask the
maintainers to fix.
It's especially plausible with JDE because (a) it's very intelligent
and (b) I don't use it which is consistent with me not having observed
the bug.
--
Bryan M. Kramer, Ph.D., Techné Knowledge Systems Inc.
Suite 2406, One Yonge St., Toronto, ON Canada M5E 1E5
416-977-3960 x314 fax 416-644-0656
www.techne.ca <http://www.techne.ca>
6:08 a.m.
>>>> "Bryan" == Bryan M Kramer
<kramer(a)techne.ca> writes:
Bryan> To all the follow ups, it is NOT due to the fact that I
Bryan> have more than one frame open on each buffer.
1. Ie, you're sure you have one-to-one relationship between buffers
and frames. I'm glad frames seem irrelevant; they should be.
2. Does JDE do things like pop up a window to show you the definition
or declaration of function called at point? Note that the
window-to-buffer relationship is independent of the number of
frames; you can have the same buffer in multiple windows in one
frame.
If it is 2, then probably JDE (or whatever) is leaving point in the
viewer window. This would also account for difficulty in
replication. The bug would only manifest when the pop-up displayed
the same buffer (which would not happen if the declaration were in a
different file).
So a sequence like this would generate the problem:
1. A call of a function needs to use a variant class as argument.
2. Pop up the declaration, change the declaration to a parent class.
Sub-task done.
3. [Leave point at declaration.] Go read mail. Close a bunch of
frames, they're a pain.
4. C-x 5 b your-buffer. Expect to be at the call, which is what
you're working on (the pop-up is "transient", right?), but find
yourself at the declaration (grrr).
Could it be something like that?
I think that probably JDE should use an indirect buffer here, if the
feature is available in the version of XEmacs you're using. The idea
of an indirect buffer is that it's a different buffer with the same
contents. Thus it has its own point, but changes in the contents are
the same for both buffers.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8099
days inactive
8104
days old
18 comments
4 participants
participants (4)
-
Bryan Kramer -
Jeff Mincy -
Michael Sperber -
Stephen J. Turnbull