help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is this correct?


From: Tim X
Subject: Is this correct?
Date: Sat, 26 Feb 2011 17:54:33 +1100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

I'm currently on a big bug fix cycle. Some of the bugs I'm trying to fix
relate to menus and I've noticed some code which I'm not convinced is
"correct" based on the documentation. I'd like some
feedback from others as I suspect it is something I am missing or don't
understand. 

force-mode-line-update has the following documentation -

,----[ C-h f force-mode-line-update RET ]
| force-mode-line-update is a compiled Lisp function in `subr.el'.
| 
| (force-mode-line-update &optional ALL)
| 
| Force redisplay of the current buffer's mode line and header line.
| With optional non-nil ALL, force redisplay of all mode lines and
| header lines.  This function also forces recomputation of the
| menu bar menus and the frame title.
| 
| [back]
`----

OK, that seems straight-forward enough. However, the code is defined as 
(I've removed the doc string to make it more concise)

(defun force-mode-line-update (&optional all)
  (if all (with-current-buffer (other-buffer)))
  (set-buffer-modified-p (buffer-modified-p)))

The bit that doesn't look quite right to me is 

(if all (with-current-buffer (other-buffer)))

I'm assuming that by calling with-current-buffer, this will temporarily
make 'other-buffer' active and as a side effect, the mode-line etc will get
updated. No problem with that. However, the documentation states that if
the arguement ALL is non-NIL if will force update of ALL mode lines and
buffer header lines. I don't see how this can be. Consider if I have
multiple frames or more than two buffers in one frame, how would this
update ALL of these?

Looking at the second line

  (set-buffer-modified-p (buffer-modified-p))

the code that implements set-buffer-modified-p appears, as a side
effect, to update the mode-line etc of all visible buffers in all frames
(judging by comments in the code). i.e. 

,----
|   /* Set update_mode_lines only if buffer is displayed in some window.
|      Packages like jit-lock or lazy-lock preserve a buffer's modified
|      state by recording/restoring the state around blocks of code.
|      Setting update_mode_lines makes redisplay consider all windows
|      (on all frames).  Stealth fontification of buffers not displayed
|      would incur additional redisplay costs if we'd set
|      update_modes_lines unconditionally.
`----

OK, now if that is the case, I'm now very confused. If
set-buffer-modified-p has the side effect of updating all visible
buffers in all frames, then what is the point of the previous line? In
fact, what is the point of having the ALL argument at all? Is this to
try and force update of non-visible buffers? If so, I don't see how it
would be all, but only the 'next' window, which may or may not be visible.

In summary, I don't understand how the ALL argument actually affects ALL
buffers - either only the next buffer is affected plus the last statement
seems to indicate that all visible buffers will be updated anyway. If I
was to call this function with no argument, I would expect, based on the
documentation, that only the current buffer mode-line would be updated,
but it seems that all visible buffers would be updated. If on the other
hand, I supplied a non-NIL argument, I would expect that ALL buffers
would be updated, but it seems only visible buffers and the buffer
returned by next-windows (which is what other-window uses to select the
next window) would be affected (together with all visible buffers).

I don't feel I understand or am clear on exactly what buffers would have
their mode-lines updated when I call the function either with a non-NIL
argument or without an argument. 

BACKGROUND
----------

The bug I'm trying to fix occurs with some code which updates the buffer
menu. There is a mode specific menu which only has mode specific menu
items. Under the help menu, is an item to "Switch to the Emacs Menubar".
When selected, it replaces the mode specific menu with the standard
Emacs menu and adds a new menu with one item that allows the user to
select the Mode specific menu again. 

The problem is that when you first select the menu option to restore the
emacs menu, initially, nothing happens. Some other event needs to occur
(either move the cursor, switch frames, click with the mouse etc) before
the new menu is displayed. I suspect it is some sort of update problem.
My first attempt to fix was to add a call to run the update-menu=-hooks,
but that doesn't seem to do anything. There is a call to a function
which essentially calls update-mode-line, which I suspect originally was
supposed to force redisplay of the menu bar for precisely this issue,
but it doesn't seem to work.

As a consequence, I want to understand update-mode-line in order to work
out what might be the issue here. It is likely it has nothing to do with
this function, but until I understand how it works, I cannot eliminate
it as a possible candidate. 

Tim

-- 
tcross (at) rapttech dot com dot au


reply via email to

[Prev in Thread] Current Thread [Next in Thread]