Is this correct?

Is this correct?

[Tim X]

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

Re: Is this correct?

[Kevin Rodgers]

On 2/25/11 11:54 PM, Tim X wrote:
>
> 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]
> `----

Before digging into the details of whether the code implements the behavior
described in the doc string, do we understand the doc string?

* What if the current buffer is not displayed?

* Does ALL mean all buffers?  All windows?  All visible windows?  All frames?
   All visible frames?  Or some other interpretation?

* The menu bar and frame title are frame-local, right?  If so, I think that
   would imply that force-mode-line-update should by default (when ALL is nil)
   update all displayed buffers in the current frame, and should update all
   displayed buffers on all frames (when ALL is non-nil).

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Is this correct?

[Tim X]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> On 2/25/11 11:54 PM, Tim X wrote:
>>
>> 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]
>> `----
>
> Before digging into the details of whether the code implements the behavior
> described in the doc string, do we understand the doc string?
>
> * What if the current buffer is not displayed?
>

It isn't very clear. My assumption would be that mode-line, menu and
header lines are irrelevant for buffers that are not displayed, so would
assume if the current buffer is not displayed, do nothing?
 
> * Does ALL mean all buffers?  All windows?  All visible windows?  All frames?
>   All visible frames?  Or some other interpretation?
>

Yes, its not clear to me. I have been assuming (without much
justification BTW) that ALL would mean all buffers displayed in all
frames (including frames that may be on 'other' virtual desktops (and
therefore not visible) and/or frames that may be under the current
frame. I'm not even sure if 'visible' means frames that are on other
desktops (or consoles with emacsclient etc). 

> * The menu bar and frame title are frame-local, right?  If so, I think that
>   would imply that force-mode-line-update should by default (when ALL is nil)
>   update all displayed buffers in the current frame, and should update all
>   displayed buffers on all frames (when ALL is non-nil).

That would seem like a reasonable interpretation. Would those other
frames be considered visible (I've always thought so).

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Is this correct?

[Eli Zaretskii]

> From: Tim X <timx@nospam.dev.null>
> Date: Sat, 26 Feb 2011 19:59:39 +1100
> 
> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> 
> >> ,----[ 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]
> >> `----
> >
> > Before digging into the details of whether the code implements the behavior
> > described in the doc string, do we understand the doc string?
> >
> > * What if the current buffer is not displayed?
> >
> 
> It isn't very clear. My assumption would be that mode-line, menu and
> header lines are irrelevant for buffers that are not displayed, so would
> assume if the current buffer is not displayed, do nothing?

Why is this an issue?  A buffer that is not displayed will have its
mode line not displayed as well.  Whether Emacs wastes CPU cycles
recomputing a mode line that isn't displayed or not should be of no
consequence to the Lisp programmer.

Or are we talking about some subtle magic that runs off mode-line
updates, which wants to be run even in buffers that are not displayed?

> > * Does ALL mean all buffers?  All windows?  All visible windows?  All frames?
> >   All visible frames?  Or some other interpretation?
> >
> 
> Yes, its not clear to me.

All buffers are considered, but only those that are displayed will
have any effect on the screen.

> > * The menu bar and frame title are frame-local, right?  If so, I think that
> >   would imply that force-mode-line-update should by default (when ALL is nil)
> >   update all displayed buffers in the current frame, and should update all
> >   displayed buffers on all frames (when ALL is non-nil).
> 
> That would seem like a reasonable interpretation. Would those other
> frames be considered visible (I've always thought so).

The menu bar is computed in the context of the current buffer, so it's
not really frame-local.

I'm not sure what does this have to do with the issue at hand, though.

Re: Is this correct?

[Uday Reddy]

On 2/26/2011 6:54 AM, Tim X wrote:

>
> (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.

That would be quite magical if it were true.  My guess is that the 
parentheses have been misplaced.  It should have been

     (if all (with-current-buffer (other-buffer)
                 (set-buffer-modified-p (buffer-modified-p)))
     (set-buffer-modified-p (buffer-modified-p))

This doesn't make it right of course.  The "other-buffer" doesn't equate 
to "all" buffers, and pretty often, the "other-buffer" is an invisible 
buffer.  It is not guaranteed that the current-buffer is a visible 
buffer either.  So, this code would seem to be wrong at many levels!

Cheers,
Uday

Re: Is this correct?

[Eli Zaretskii]

> Date: Sat, 26 Feb 2011 12:44:15 +0000
> From: Uday Reddy <uDOTsDOTreddy@cs.bham.ac.uk>
> 
> On 2/26/2011 6:54 AM, Tim X wrote:
> 
> >
> > (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.
> 
> That would be quite magical if it were true.

??

> My guess is that the parentheses have been misplaced.

????? Doesn't force-mode-line-update work for you?

> It should have been
> 
>      (if all (with-current-buffer (other-buffer)
>                  (set-buffer-modified-p (buffer-modified-p)))
>      (set-buffer-modified-p (buffer-modified-p))
> 
> This doesn't make it right of course.  The "other-buffer" doesn't equate 
> to "all" buffers, and pretty often, the "other-buffer" is an invisible 
> buffer.  It is not guaranteed that the current-buffer is a visible 
> buffer either.  So, this code would seem to be wrong at many levels!

I gets better: `(set-buffer-modified-p (buffer-modified-p))'
apparently does nothing, because it sets the buffer's modified flag to
the same value it has already.  So this function actually does nothing
at all, right?

Re: Is this correct?

[Uday Reddy]

On 2/26/2011 2:07 PM, Eli Zaretskii wrote:

>> My guess is that the parentheses have been misplaced.
>
> ????? Doesn't force-mode-line-update work for you?

No, it isn't working.  We had an outstanding bug report in VM and Tim 
has finally tracked it down to this problem.

 
http://groups.google.com/group/gnu.emacs.vm.info/browse_thread/thread/20a83d2fd969386c/b81b15ca3baa29d2?lnk=gst&q=menu+bar#b81b15ca3baa29d2

    https://bugs.launchpad.net/vm/+bug/605799

VM is calling force-mode-line-update in a Folder buffer, which is 
generally invisible.  The function is updating its menubar, but not that 
of the currently visible buffer.  Even after I change it the way I 
mentioned in my previous post, it still doesn't work because the 
"other-buffer" also turns out to be the Folder buffer for some reason or 
the other.

> I gets better: `(set-buffer-modified-p (buffer-modified-p))'
> apparently does nothing, because it sets the buffer's modified flag to
> the same value it has already.  So this function actually does nothing
> at all, right?

That would be logical, but I am guessing from force-mode-line-update's 
doc string that this has the effect of updating the mode line, menu bar 
and the rest.

It is a pity that set-buffer-modified-p's doc string doesn't do justice 
to all that it does!

Cheers,
Uday

Re: Is this correct?

[Eli Zaretskii]

> Date: Sat, 26 Feb 2011 15:38:26 +0000
> From: Uday Reddy <uDOTsDOTreddy@cs.bham.ac.uk>
> 
> On 2/26/2011 2:07 PM, Eli Zaretskii wrote:
> 
> >> My guess is that the parentheses have been misplaced.
> >
> > ????? Doesn't force-mode-line-update work for you?
> 
> No, it isn't working.  We had an outstanding bug report in VM and Tim 
> has finally tracked it down to this problem.

Does it fail to work at all, in all circumstances, or just in this
special case?  If the latter, then your arguments seem to be
inaccurate, because they seem to say that it should never work.

Re: Is this correct?

[Uday Reddy]

On 2/26/2011 3:47 PM, Eli Zaretskii wrote:

> Does it fail to work at all, in all circumstances, or just in this
> special case?  If the latter, then your arguments seem to be
> inaccurate, because they seem to say that it should never work.

By "this special case", you mean the case when the other-buffer happens 
to be the same as the current-buffer?  Yeah, I suppose that is an odd 
special case.  You are saying that it works fine otherwise?

Cheers,
Uday

Re: Is this correct?

[Eli Zaretskii]

> Date: Sat, 26 Feb 2011 16:22:01 +0000
> From: Uday Reddy <uDOTsDOTreddy@cs.bham.ac.uk>
> 
> You are saying that it works fine otherwise?

I'm asking _you_ if it does.

force-mode-line-update [Re: Is this correct?]

[Uday S Reddy]

[Following up on a discussion in the gnu.emacs.help newsgroup.]

On 2/26/2011 4:59 PM, Eli Zaretskii wrote:

>> You are saying that it works fine otherwise?
>
> I'm asking _you_ if it does.

Right, I suppose I asked for it :-(

I tested similar code to force-mode-line-update by using a different 
buffer than "other-buffer".

	 (when (and vm-user-interaction-buffer
		    (buffer-live-p vm-user-interaction-buffer))
	   (with-current-buffer vm-user-interaction-buffer))
	 (set-buffer-modified-p (buffer-modified-p))

vm-user-interaction-buffer is the active buffer where the user issued a 
command to change the menubar.  And, the buffer where this code got 
executed is an invisible Folder buffer.

It didn't work, i.e., the menubar didn't get updated.  I needed to click 
for a second time somewhere in the menubar for it to get updated.  And, 
after trying it a few times Emacs crashed with the message

   The instruction at "0x7c911766" referenced memory at "0x0084fffd". 
The memory could not be read.

This is using the current pretest, Sean Sieger's build.  The DrMinGW 
backtrace is below.

I could not reproduce this crash on Emacs 23.2.1.  However, doing this 
seems to have put it in an unstable state.  Doing something else 
afterwards crashed it.  I am also attaching the report from DrMinGW for 
that crash.

Cheers,
Uday
-----------
Crash backtrace for 23.2.94

emacs.exe caused an Access Violation at location 7c911766 in module 
ntdll.dll Reading from location 00690070.

Registers:
eax=00850190 ebx=00850000 ecx=7ffde000 edx=00850608 esi=0069006b 
edi=00000003
eip=7c911766 esp=0082e408 ebp=0082e628 iopl=0         nv up ei pl nz ac 
pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000 
efl=00000212

Call stack:
7C911766  ntdll.dll:7C911766  RtlInitializeCriticalSection
011CDFAE  emacs.exe:011CDFAE  add_menu_item  w32menu.c:1494

011CE25B  emacs.exe:011CE25B  fill_in_menu  w32menu.c:1592

011CE20B  emacs.exe:011CE20B  fill_in_menu  w32menu.c:1583

011CCD03  emacs.exe:011CCD03  set_frame_menubar  w32menu.c:626

011CC397  emacs.exe:011CC397  x_activate_menubar  w32menu.c:285

0100B56D  emacs.exe:0100B56D  kbd_buffer_get_event  keyboard.c:4419

010094BA  emacs.exe:010094BA  read_char  keyboard.c:3081

0101292D  emacs.exe:0101292D  read_key_sequence  keyboard.c:9567

010065C5  emacs.exe:010065C5  command_loop_1  keyboard.c:1645

01020614  emacs.exe:01020614  internal_condition_case  eval.c:1492

01005FE3  emacs.exe:01005FE3  command_loop_2  keyboard.c:1362

01020165  emacs.exe:01020165  internal_catch  eval.c:1228

01005F49  emacs.exe:01005F49  command_loop  keyboard.c:1327

0100588E  emacs.exe:0100588E  recursive_edit_1  keyboard.c:956

010EC664  emacs.exe:010EC664  read_minibuf  minibuf.c:744

010EE2C6  emacs.exe:010EE2C6  Fcompleting_read  minibuf.c:1827

01014F1E  emacs.exe:01014F1E  Fexecute_extended_command  keyboard.c:10622

01022AE3  emacs.exe:01022AE3  Ffuncall  eval.c:3031

0111932A  emacs.exe:0111932A  Fcall_interactively  callint.c:869

01022B2E  emacs.exe:01022B2E  Ffuncall  eval.c:3037

010226CC  emacs.exe:010226CC  call3  eval.c:2857

01014D52  emacs.exe:01014D52  Fcommand_execute  keyboard.c:10562

010076E0  emacs.exe:010076E0  command_loop_1  keyboard.c:1914

01020614  emacs.exe:01020614  internal_condition_case  eval.c:1492

01005FE3  emacs.exe:01005FE3  command_loop_2  keyboard.c:1362

01020165  emacs.exe:01020165  internal_catch  eval.c:1228

01005F9C  emacs.exe:01005F9C  command_loop  keyboard.c:1342

0100588E  emacs.exe:0100588E  recursive_edit_1  keyboard.c:956

010059F7  emacs.exe:010059F7  Frecursive_edit  keyboard.c:1019

010028F5  emacs.exe:010028F5  main  emacs.c:1835

010010DB  emacs.exe:010010DB
01001178  emacs.exe:01001178
010036D0  emacs.exe:010036D0  _start  unexw32.c:131

7C817077  kernel32.dll:7C817077  RegisterWaitForInputIdle

-----------

Crash report for Emacs 23.2.1

emacs.exe caused an Access Violation at location 71b225b9 in module 
MPR.DLL Reading from location 5a287ce4.

Registers:
eax=00000000 ebx=00000001 ecx=5a287cb0 edx=00000000 esi=00000000 
edi=0082d80c
eip=71b225b9 esp=0082d7e8 ebp=0082d7f4 iopl=0         nv up ei pl nz na 
pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000 
efl=00000202

Call stack:
71B225B9  MPR.DLL:71B225B9  WNetGetConnectionW
71B223FB  MPR.DLL:71B223FB  WNetGetConnectionW
71B2431D  MPR.DLL:71B2431D  WNetCloseEnum
71B22348  MPR.DLL:71B22348  WNetGetConnectionW
71B222FD  MPR.DLL:71B222FD  WNetGetConnectionW
71B24505  MPR.DLL:71B24505  WNetUseConnectionW
71B24B51  MPR.DLL:71B24B51  WNetUseConnectionA
71B24AE0  MPR.DLL:71B24AE0  WNetAddConnection2A
01094A38  emacs.exe:01094A38
01095E76  emacs.exe:01095E76
0107349C  emacs.exe:0107349C
010734FE  emacs.exe:010734FE
010234B3  emacs.exe:010234B3
0116966B  emacs.exe:0116966B
010225E2  emacs.exe:010225E2
01020ECA  emacs.exe:01020ECA
0116A003  emacs.exe:0116A003
01023BF1  emacs.exe:01023BF1
010236D0  emacs.exe:010236D0
0116966B  emacs.exe:0116966B
01023BF1  emacs.exe:01023BF1
010236D0  emacs.exe:010236D0
0116966B  emacs.exe:0116966B
01023BF1  emacs.exe:01023BF1
010236D0  emacs.exe:010236D0
0116966B  emacs.exe:0116966B
01023BF1  emacs.exe:01023BF1
010236D0  emacs.exe:010236D0
0116966B  emacs.exe:0116966B
01023BF1  emacs.exe:01023BF1
010238DC  emacs.exe:010238DC
010227AE  emacs.exe:010227AE
0101F7D3  emacs.exe:0101F7D3
010223B2  emacs.exe:010223B2
0101F665  emacs.exe:0101F665
010223B2  emacs.exe:010223B2
0101F665  emacs.exe:0101F665
0102076E  emacs.exe:0102076E
010223B2  emacs.exe:010223B2
0101F665  emacs.exe:0101F665
01023BA5  emacs.exe:01023BA5
01023767  emacs.exe:01023767
01022F93  emacs.exe:01022F93
011672D7  emacs.exe:011672D7
01023507  emacs.exe:01023507
0102309F  emacs.exe:0102309F
01014F3A  emacs.exe:01014F3A
0100787F  emacs.exe:0100787F
01020FD4  emacs.exe:01020FD4
01005F66  emacs.exe:01005F66
01020AC5  emacs.exe:01020AC5
01005F1C  emacs.exe:01005F1C
0100580E  emacs.exe:0100580E
01005972  emacs.exe:01005972
010027C6  emacs.exe:010027C6
010010B6  emacs.exe:010010B6
01001148  emacs.exe:01001148
010036EB  emacs.exe:010036EB
7C817077  kernel32.dll:7C817077  RegisterWaitForInputIdle

Re: Is this correct?

[Tim X]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 26 Feb 2011 12:44:15 +0000
>> From: Uday Reddy <uDOTsDOTreddy@cs.bham.ac.uk>
>> 
>> On 2/26/2011 6:54 AM, Tim X wrote:
>> 
>> >
>> > (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.
>> 
>> That would be quite magical if it were true.
>
> ??
>
>> My guess is that the parentheses have been misplaced.
>
> ????? Doesn't force-mode-line-update work for you?
>
>> It should have been
>> 
>>      (if all (with-current-buffer (other-buffer)
>>                  (set-buffer-modified-p (buffer-modified-p)))
>>      (set-buffer-modified-p (buffer-modified-p))
>> 
>> This doesn't make it right of course.  The "other-buffer" doesn't equate 
>> to "all" buffers, and pretty often, the "other-buffer" is an invisible 
>> buffer.  It is not guaranteed that the current-buffer is a visible 
>> buffer either.  So, this code would seem to be wrong at many levels!
>
> I gets better: `(set-buffer-modified-p (buffer-modified-p))'
> apparently does nothing, because it sets the buffer's modified flag to
> the same value it has already.  So this function actually does nothing
> at all, right?
>

I looked at the C code that implements set-buffer-modified-p at it seems
to me (who freely admits not understanding the low C level of emacs!)
that as a side effect, the function updates mode-lines etc regardless of
the setting/value for buffer-modified-p. Therefore, my interpretation
was that this would call the function without actually changing the
state of the modified flag and by side effect, result in an update of
the mode-line. 

I do agree it doesn't look right and personally don't like code which
does something via a non-intuitive/obvious side effect. While possibly
convenient, from a maintenance standpoint, it would be better if it was
more deliberate/obvious IMO.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Is this correct?

[Tim X]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim X <timx@nospam.dev.null>
>> Date: Sat, 26 Feb 2011 19:59:39 +1100
>> 
>> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
>> 
>> >> ,----[ 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]
>> >> `----
>> >
>> > Before digging into the details of whether the code implements the behavior
>> > described in the doc string, do we understand the doc string?
>> >
>> > * What if the current buffer is not displayed?
>> >
>> 
>> It isn't very clear. My assumption would be that mode-line, menu and
>> header lines are irrelevant for buffers that are not displayed, so would
>> assume if the current buffer is not displayed, do nothing?
>
> Why is this an issue?  A buffer that is not displayed will have its
> mode line not displayed as well.  Whether Emacs wastes CPU cycles
> recomputing a mode line that isn't displayed or not should be of no
> consequence to the Lisp programmer.
>
> Or are we talking about some subtle magic that runs off mode-line
> updates, which wants to be run even in buffers that are not displayed?
>
>> > * Does ALL mean all buffers?  All windows?  All visible windows?  All frames?
>> >   All visible frames?  Or some other interpretation?
>> >
>> 
>> Yes, its not clear to me.
>
> All buffers are considered, but only those that are displayed will
> have any effect on the screen.
>
>> > * The menu bar and frame title are frame-local, right?  If so, I think that
>> >   would imply that force-mode-line-update should by default (when ALL is nil)
>> >   update all displayed buffers in the current frame, and should update all
>> >   displayed buffers on all frames (when ALL is non-nil).
>> 
>> That would seem like a reasonable interpretation. Would those other
>> frames be considered visible (I've always thought so).
>
> The menu bar is computed in the context of the current buffer, so it's
> not really frame-local.
>
> I'm not sure what does this have to do with the issue at hand, though.
>
Hi Eli,

thanks for response. I think, form the other thread where you have been
discussing this with Uday, this is probably clearer now. Just for the
record ....

We have an issue with a package that modifies the menu. After chaning
the menu, it calls force-mode-line-update. However, this is not actually
working to update the display of the menu-bar. Once the menu-bar has
been modified, some other event must occur before the menu-bar is
updated. That even could be another mouse click, movement of the cursor,
switching frames or even just waiting a minute or so (I'm guessing that
in that time, some other event triggers the update, such as updating the
load display in the mode-line, gc or something else). 

To try and track this down, I was trying to understand exactly how
force-mode-line-update works and what pre-conditions it may have re:
visible/current buffers etc. So, my questions were supposed to help
clarify my understanding of both how force-update-mode-line was supposed
to work and how it actually works.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Is this correct?

[Eli Zaretskii]

> From: Tim X <timx@nospam.dev.null>
> Date: Sun, 27 Feb 2011 09:38:14 +1100
> 
> > I gets better: `(set-buffer-modified-p (buffer-modified-p))'
> > apparently does nothing, because it sets the buffer's modified flag to
> > the same value it has already.  So this function actually does nothing
> > at all, right?
> >
> 
> I looked at the C code that implements set-buffer-modified-p at it seems
> to me (who freely admits not understanding the low C level of emacs!)
> that as a side effect, the function updates mode-lines etc regardless of
> the setting/value for buffer-modified-p. Therefore, my interpretation
> was that this would call the function without actually changing the
> state of the modified flag and by side effect, result in an update of
> the mode-line. 

Yes.  My text was ironic: it was supposed to hint that there _is_ some
magic here.

> I do agree it doesn't look right and personally don't like code which
> does something via a non-intuitive/obvious side effect. While possibly
> convenient, from a maintenance standpoint, it would be better if it was
> more deliberate/obvious IMO.

Nothing about the Emacs redisplay is intuitive or obvious.

Re: Is this correct?

[Eli Zaretskii]

> From: Tim X <timx@nospam.dev.null>
> Date: Sun, 27 Feb 2011 09:48:24 +1100
> 
> We have an issue with a package that modifies the menu. After chaning
> the menu, it calls force-mode-line-update. However, this is not actually
> working to update the display of the menu-bar. Once the menu-bar has
> been modified, some other event must occur before the menu-bar is
> updated. That even could be another mouse click, movement of the cursor,
> switching frames or even just waiting a minute or so (I'm guessing that
> in that time, some other event triggers the update, such as updating the
> load display in the mode-line, gc or something else). 

If you can show a small reproducible test case for this problem, I
could try looking into it.

Btw, this discussion now moved to emacs-devel (which is where it
should have been in the first place, IMO).

Re: Is this correct?

[Tim X]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim X <timx@nospam.dev.null>
>> Date: Sun, 27 Feb 2011 09:48:24 +1100
>> 
>> We have an issue with a package that modifies the menu. After chaning
>> the menu, it calls force-mode-line-update. However, this is not actually
>> working to update the display of the menu-bar. Once the menu-bar has
>> been modified, some other event must occur before the menu-bar is
>> updated. That even could be another mouse click, movement of the cursor,
>> switching frames or even just waiting a minute or so (I'm guessing that
>> in that time, some other event triggers the update, such as updating the
>> load display in the mode-line, gc or something else). 
>
> If you can show a small reproducible test case for this problem, I
> could try looking into it.
>

It is hard to reproduce in a small recipe. I've even noticed that
while the problem occurs most of the time, now and again, it works as it
should. 

> Btw, this discussion now moved to emacs-devel (which is where it
> should have been in the first place, IMO).
>

I didn't put it on emacs-dev initially as I wanted to be sure it wasn't
just something I misunderstood before adding to the traffic on that
list. I stated this in the original post. 

Uday has progressed things further and moved it to the dev list. He has
a better understanding of the internals of the package where we have
encountered the problem, so it is probably best left in his hands rather
than have me muddy the waters with ignorance. 

Tim
-- 
tcross (at) rapttech dot com dot au

Re: force-mode-line-update [Re: Is this correct?]

[Uday S Reddy]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

Hi Eli, here is a test case that shows that force-mode-line-update is 
not updating the menu bar.

I have also tried to find a test case that reproduces the crash but I 
wasn't successful.  I will keep trying.

Please let me know if I should file a bug report instead.

Cheers,
Uday


[-- Attachment #2: menu-test.el --]
[-- Type: text/plain, Size: 1702 bytes --]

;; Test case for force-mode-line-update.
;;
;; Load this file into a new buffer.
;;
;; It should give a menu called "AAA" with a "Switch to BBB" item.
;; Clicking on the item switches the menu to BBB, which is again a
;; similar menu which allows you to switch back to AAA.
;;
;; Using the "Force to BBB" menu item, on the other hand, doesn't switch
;; the menu.  Another event somewhere is needed for the menu bar
;; change to take effect.

(defvar test-map (make-sparse-keymap))

(defun menu-A ()
  (define-key test-map [menu-bar]
    (make-sparse-keymap "Menu"))
  (define-key test-map [menu-bar menu-a]
    (cons "AAA" (make-sparse-keymap "AAA")))
  (define-key test-map [menu-bar menu-a force]
    '(menu-item "Force to BBB" test-force-mode-line-update))
  (define-key test-map [menu-bar menu-a switch]
    '(menu-item "Switch to BBB" test-toggle-menubar)))

(defun menu-B ()
  (define-key test-map [menu-bar]
    (make-sparse-keymap "Menu"))
  (define-key test-map [menu-bar menu-b]
    (cons "BBB" (make-sparse-keymap "BBB")))
  (define-key test-map [menu-bar menu-b force]
    '(menu-item "Force to AAA" test-force-mode-line-update))
  (define-key test-map [menu-bar menu-b switch]
    '(menu-item "Switch to AAA" test-toggle-menubar)))


(defun test-toggle-menubar ()
  (interactive)
  (if (lookup-key test-map [menu-bar menu-a])
      (menu-B)
    (menu-A))
  (force-mode-line-update t))

;; This is the same as toggle except that it changes buffer beforehand.
;; Tests if force-mode-line-update truly updates all buffers.

(defun test-force-mode-line-update ()
  (interactive)
  (with-current-buffer (get-buffer-create "dummy")
    (test-toggle-menubar)))

(menu-A)
(use-local-map test-map)