* Is this correct?
@ 2011-02-26 6:54 Tim X
2011-02-26 8:50 ` Kevin Rodgers
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Tim X @ 2011-02-26 6:54 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 6:54 Is this correct? Tim X
@ 2011-02-26 8:50 ` Kevin Rodgers
[not found] ` <mailman.17.1298710213.28733.help-gnu-emacs@gnu.org>
2011-02-26 12:44 ` Uday Reddy
2 siblings, 0 replies; 17+ messages in thread
From: Kevin Rodgers @ 2011-02-26 8:50 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <mailman.17.1298710213.28733.help-gnu-emacs@gnu.org>]
* Re: Is this correct?
[not found] ` <mailman.17.1298710213.28733.help-gnu-emacs@gnu.org>
@ 2011-02-26 8:59 ` Tim X
2011-02-26 10:01 ` Eli Zaretskii
[not found] ` <mailman.19.1298714474.28733.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 17+ messages in thread
From: Tim X @ 2011-02-26 8:59 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 8:59 ` Tim X
@ 2011-02-26 10:01 ` Eli Zaretskii
[not found] ` <mailman.19.1298714474.28733.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2011-02-26 10:01 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <mailman.19.1298714474.28733.help-gnu-emacs@gnu.org>]
* Re: Is this correct?
[not found] ` <mailman.19.1298714474.28733.help-gnu-emacs@gnu.org>
@ 2011-02-26 22:48 ` Tim X
2011-02-27 4:02 ` Eli Zaretskii
[not found] ` <mailman.14.1298779333.29063.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 17+ messages in thread
From: Tim X @ 2011-02-26 22:48 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 22:48 ` Tim X
@ 2011-02-27 4:02 ` Eli Zaretskii
[not found] ` <mailman.14.1298779333.29063.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2011-02-27 4:02 UTC (permalink / raw)
To: help-gnu-emacs
> 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).
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <mailman.14.1298779333.29063.help-gnu-emacs@gnu.org>]
* Re: Is this correct?
[not found] ` <mailman.14.1298779333.29063.help-gnu-emacs@gnu.org>
@ 2011-02-27 7:32 ` Tim X
0 siblings, 0 replies; 17+ messages in thread
From: Tim X @ 2011-02-27 7:32 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 6:54 Is this correct? Tim X
2011-02-26 8:50 ` Kevin Rodgers
[not found] ` <mailman.17.1298710213.28733.help-gnu-emacs@gnu.org>
@ 2011-02-26 12:44 ` Uday Reddy
2011-02-26 14:07 ` Eli Zaretskii
[not found] ` <mailman.1.1298729256.15641.help-gnu-emacs@gnu.org>
2 siblings, 2 replies; 17+ messages in thread
From: Uday Reddy @ 2011-02-26 12:44 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 12:44 ` Uday Reddy
@ 2011-02-26 14:07 ` Eli Zaretskii
[not found] ` <mailman.1.1298729256.15641.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2011-02-26 14:07 UTC (permalink / raw)
To: help-gnu-emacs
> 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <mailman.1.1298729256.15641.help-gnu-emacs@gnu.org>]
* Re: Is this correct?
[not found] ` <mailman.1.1298729256.15641.help-gnu-emacs@gnu.org>
@ 2011-02-26 15:38 ` Uday Reddy
2011-02-26 15:47 ` Eli Zaretskii
[not found] ` <mailman.4.1298735259.8637.help-gnu-emacs@gnu.org>
2011-02-26 22:38 ` Is this correct? Tim X
1 sibling, 2 replies; 17+ messages in thread
From: Uday Reddy @ 2011-02-26 15:38 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 15:38 ` Uday Reddy
@ 2011-02-26 15:47 ` Eli Zaretskii
[not found] ` <mailman.4.1298735259.8637.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2011-02-26 15:47 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <mailman.4.1298735259.8637.help-gnu-emacs@gnu.org>]
* Re: Is this correct?
[not found] ` <mailman.4.1298735259.8637.help-gnu-emacs@gnu.org>
@ 2011-02-26 16:22 ` Uday Reddy
2011-02-26 16:59 ` Eli Zaretskii
[not found] ` <mailman.0.1298739618.29899.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 17+ messages in thread
From: Uday Reddy @ 2011-02-26 16:22 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 16:22 ` Uday Reddy
@ 2011-02-26 16:59 ` Eli Zaretskii
[not found] ` <mailman.0.1298739618.29899.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2011-02-26 16:59 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <mailman.0.1298739618.29899.help-gnu-emacs@gnu.org>]
* force-mode-line-update [Re: Is this correct?]
[not found] ` <mailman.0.1298739618.29899.help-gnu-emacs@gnu.org>
@ 2011-02-26 17:54 ` Uday S Reddy
2011-02-27 16:51 ` Uday S Reddy
0 siblings, 1 reply; 17+ messages in thread
From: Uday S Reddy @ 2011-02-26 17:54 UTC (permalink / raw)
To: emacs-devel; +Cc: Eli Zaretskii
[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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: force-mode-line-update [Re: Is this correct?]
2011-02-26 17:54 ` force-mode-line-update [Re: Is this correct?] Uday S Reddy
@ 2011-02-27 16:51 ` Uday S Reddy
0 siblings, 0 replies; 17+ messages in thread
From: Uday S Reddy @ 2011-02-27 16:51 UTC (permalink / raw)
To: emacs-devel
[-- 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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
[not found] ` <mailman.1.1298729256.15641.help-gnu-emacs@gnu.org>
2011-02-26 15:38 ` Uday Reddy
@ 2011-02-26 22:38 ` Tim X
2011-02-27 4:00 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Tim X @ 2011-02-26 22:38 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Is this correct?
2011-02-26 22:38 ` Is this correct? Tim X
@ 2011-02-27 4:00 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2011-02-27 4:00 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-02-27 16:51 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-26 6:54 Is this correct? Tim X
2011-02-26 8:50 ` Kevin Rodgers
[not found] ` <mailman.17.1298710213.28733.help-gnu-emacs@gnu.org>
2011-02-26 8:59 ` Tim X
2011-02-26 10:01 ` Eli Zaretskii
[not found] ` <mailman.19.1298714474.28733.help-gnu-emacs@gnu.org>
2011-02-26 22:48 ` Tim X
2011-02-27 4:02 ` Eli Zaretskii
[not found] ` <mailman.14.1298779333.29063.help-gnu-emacs@gnu.org>
2011-02-27 7:32 ` Tim X
2011-02-26 12:44 ` Uday Reddy
2011-02-26 14:07 ` Eli Zaretskii
[not found] ` <mailman.1.1298729256.15641.help-gnu-emacs@gnu.org>
2011-02-26 15:38 ` Uday Reddy
2011-02-26 15:47 ` Eli Zaretskii
[not found] ` <mailman.4.1298735259.8637.help-gnu-emacs@gnu.org>
2011-02-26 16:22 ` Uday Reddy
2011-02-26 16:59 ` Eli Zaretskii
[not found] ` <mailman.0.1298739618.29899.help-gnu-emacs@gnu.org>
2011-02-26 17:54 ` force-mode-line-update [Re: Is this correct?] Uday S Reddy
2011-02-27 16:51 ` Uday S Reddy
2011-02-26 22:38 ` Is this correct? Tim X
2011-02-27 4:00 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.