this is a bug in xemacs. there's a lot of precedent regarding the
interpretation of "buffer-local" wrt redisplay variables.
in general, yes, things that control redisplay should be specifiers, but it may
not be worth changing here.
the patch to fix this is easy [untested]:
src/ChangeLog addition:
2001-11-13 Ben Wing <ben(a)xemacs.org>
* window.c:
* window.c (window_truncation_on):
* window.c (syms_of_window):
truncate-partial-width-windows should respect the buffer being
displayed, like other redisplay vars.
working Patch (bash -ci "cvs-diff -cvs-command=crw -no-changelog
src/window.c"):
Index: src/window.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/window.c,v
retrieving revision 1.58
diff -u -r1.58 window.c
--- src/window.c 20 Sep 2001 06:29:17 -0000 1.58
+++ src/window.c 13 Nov 2001 22:59:23 -0000
@@ -123,6 +123,8 @@
/* List of freed window configurations with 1 - 10 windows. */
static Lisp_Object Vwindow_configuration_free_list[10];
+Lisp_Object Qtruncate_partial_width_windows;
+
#define SET_LAST_MODIFIED(w, cache_too) \
do { \
(w)->last_modified[CURRENT_DISP] = Qzero; \
@@ -756,7 +758,8 @@
/* If truncate_partial_width_windows is true and the window is not
the full width of the frame it is truncated. */
- if (truncate_partial_width_windows
+ if (!NILP (symbol_value_in_buffer (Qtruncate_partial_width_windows,
+ w->buffer))
&& !(window_is_leftmost (w) && window_is_rightmost (w)))
return 1;
@@ -6146,6 +6149,8 @@
/* Qother in general.c */
#endif
+ DEFSYMBOL (Qtruncate_partial_width_windows);
+
DEFSUBR (Fselected_window);
DEFSUBR (Flast_nonminibuf_window);
DEFSUBR (Fminibuffer_window);
"Stephen J. Turnbull" wrote:
Changing this would require internal changes. Followups to
xemacs-beta.
>>>>> "Yoichi" == Yoichi NAKAYAMA
<yoichi(a)eken.phys.nagoya-u.ac.jp> writes:
Yoichi> (make-local-variable 'truncate-partial-width-windows)
Yoichi> (setq truncate-partial-width-windows nil)
Yoichi> on buffer B. Then it is possible to control truncation in
Yoichi> buffer B by truncate-lines, I thought.
Yoichi> With GNU Emacs, it is possible regardless of the position
Yoichi> of cursor. But on XEmacs, it shows different behavior.
[I.e., in XEmacs t-p-w-w gets the value for the current buffer, so
when the cursor is in B, truncate-lines rules, when it is not, t-p-w-w
in the other buffer determines whether truncate-lines has an effect or
not.]
I think the GNU behavior (and the traditional behavior of
truncate-lines, for that matter) is an abuse of the term
"buffer-local", although the GNU behavior is desirable in these cases.
The current buffer should determine the value of a buffer-local
variable in Lisp, not the current focus of the redisplay engine.
Ben? Should these variables be specifiers? Can we reasonably draw
the distinction that local variables used to control redisplay should
be specifiers, and buffer-locals should be used to control Lisp?
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.