* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning [not found] ` <<83y2hut6m7.fsf@gnu.org> @ 2020-12-19 18:54 ` Drew Adams 2020-12-19 19:17 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2020-12-19 18:54 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, 24237, monnier > > > > "use of a `menu-item' construct with a :filter > > > > to create a conditional _keyboard_ key binding. > > > > In such a case, the `menu-item' construct is not > > > > a real menu item - it is not placed on any menu." > > If this is never placed on the menu bar or on any pop-down menu, then > what the manual says is not relevant, because redisplay only considers > the menus that need to be displayed. 1. The manual's description of :filter is entirely relevant to this use case - _except_ for that last paragraph, which apparently erroneously assumes that the only possible use of an extended menu item with :filter is in a menu. Extended menu items are not just for menus (in spite of the name). 2. What you've added here is what needs to be added there: a qualification to that caveat, that _when used in a menu_, "Emacs can call ... redisplay ... You should write it so it can safely be called at any time". 3. And because this use case is important and not at all obvious, the doc there should explicitly point out this use case. a. You can bind an extended menu item that uses :filter to a keyboard key, to give it a dynamic binding (explaining what that means with an example). b. If the only bindings for that extended menu item are keyboard bindings then the admonition about redisplay (see #2) does not apply. Don't assume that readers will understand that if not placed on a menu then it doesn't apply. The admonition is currently too blanket. Wrt #3: An example for this use case should be presented somewhere in the Elisp manual. If you can think of a better place than in the description of :filter, fine. If not, then that's the place. 4. As I said in the bug report, having to use an extended menu item for this feature is a hack or workaround. There's no other possibility out of the box. Better than just documenting that you can use an extended menu item with :filter to get this behavior would be to provide the behavior in another way. IOW, ideally it wouldn't be "hidden" under the misleading notion of a menu. :filter itself is not about menus. More generally, `menu-item' is not just about menus and menu items. This is not obvious. And in particular, it's not obvious that you can make good use of :filter with a keyboard key. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-19 18:54 ` bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning Drew Adams @ 2020-12-19 19:17 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2020-12-19 19:17 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, monnier, 24237-done > Date: Sat, 19 Dec 2020 10:54:06 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: larsi@gnus.org, 24237@debbugs.gnu.org, monnier@iro.umontreal.ca > > > > > > "use of a `menu-item' construct with a :filter > > > > > to create a conditional _keyboard_ key binding. > > > > > In such a case, the `menu-item' construct is not > > > > > a real menu item - it is not placed on any menu." > > > > If this is never placed on the menu bar or on any pop-down menu, then > > what the manual says is not relevant, because redisplay only considers > > the menus that need to be displayed. > > 1. The manual's description of :filter is entirely > relevant to this use case - _except_ for that last > paragraph, which apparently erroneously assumes that > the only possible use of an extended menu item with > :filter is in a menu. Since that last paragraph explicitly talks about displaying or acting on menus, I see no reason to change anything there. > a. You can bind an extended menu item that uses > :filter to a keyboard key, to give it a > dynamic binding (explaining what that means > with an example). IMO this is a kludge that we don't need to document. > More generally, `menu-item' is not just about menus > and menu items. This is not obvious. And in > particular, it's not obvious that you can make good > use of :filter with a keyboard key. menu-item is about menus, as its name says. That it can be used for other purposes is an implementation detail. And with that, I'm closing this bug report. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <<<<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>]
[parent not found: <<<<<87v9d67ox6.fsf@gnus.org>]
[parent not found: <<<<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>]
[parent not found: <<<<<83blexeod5.fsf@gnu.org>]
[parent not found: <<<<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default>]
[parent not found: <<<<83v9d5d1yd.fsf@gnu.org>]
[parent not found: <<<846fcdf8-9b51-4246-8200-b067e7006e24@default>]
[parent not found: <<<83y2hut6m7.fsf@gnu.org>]
[parent not found: <<d15a8746-eb78-44b5-a4d6-af2285969b76@default>]
[parent not found: <<838s9ttxkk.fsf@gnu.org>]
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning [not found] ` <<838s9ttxkk.fsf@gnu.org> @ 2020-12-19 19:35 ` Drew Adams 2020-12-20 0:05 ` Stefan Kangas 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2020-12-19 19:35 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, monnier, 24237-done > > > > > > "use of a `menu-item' construct with a :filter > > > > > > to create a conditional _keyboard_ key binding. > > > > > > In such a case, the `menu-item' construct is not > > > > > > a real menu item - it is not placed on any menu." > > > > > > If this is never placed on the menu bar or on any pop-down menu, then > > > what the manual says is not relevant, because redisplay only considers > > > the menus that need to be displayed. > > > > 1. The manual's description of :filter is entirely > > relevant to this use case - _except_ for that last > > paragraph, which apparently erroneously assumes that > > the only possible use of an extended menu item with > > :filter is in a menu. > > Since that last paragraph explicitly talks about displaying or acting > on menus, I see no reason to change anything there. > > > a. You can bind an extended menu item that uses > > :filter to a keyboard key, to give it a > > dynamic binding (explaining what that means > > with an example). > > IMO this is a kludge that we don't need to document. It is indeed a kludge/workaround/hack. It is also quite useful. If you refuse to elevate it to doc-worthiness, then please change this bug to an enhancement request to provide the same feature _without_ having to use `menu-item' with :filter. Otherwise, I will I guess submit such an enhancement request. Elisp users shouldn't have to resort to an undocumented kludge to get this useful behavior. > > More generally, `menu-item' is not just about menus > > and menu items. This is not obvious. And in > > particular, it's not obvious that you can make good > > use of :filter with a keyboard key. > > menu-item is about menus, as its name says. That it can be used for > other purposes is an implementation detail. > > And with that, I'm closing this bug report. Ta da. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-19 19:35 ` Drew Adams @ 2020-12-20 0:05 ` Stefan Kangas 2020-12-20 1:23 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Stefan Kangas @ 2020-12-20 0:05 UTC (permalink / raw) To: Drew Adams, Eli Zaretskii; +Cc: larsi, monnier, 24237-done Drew Adams <drew.adams@oracle.com> writes: >> > a. You can bind an extended menu item that uses >> > :filter to a keyboard key, to give it a >> > dynamic binding (explaining what that means >> > with an example). >> >> IMO this is a kludge that we don't need to document. > > It is indeed a kludge/workaround/hack. I agree that this kludge shouldn't be documented. It is very strange to bind keys to menu-bindings just for :filter, and if we document it we in effect say that this is the preferred way of doing this stuff. > It is also quite useful. If you refuse to elevate it > to doc-worthiness, then please change this bug to an > enhancement request to provide the same feature > _without_ having to use `menu-item' with :filter. > > Otherwise, I will I guess submit such an enhancement > request. Elisp users shouldn't have to resort to an > undocumented kludge to get this useful behavior. It makes sense to me to file such a feature request. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-20 0:05 ` Stefan Kangas @ 2020-12-20 1:23 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2020-12-20 1:23 UTC (permalink / raw) To: Stefan Kangas, Eli Zaretskii; +Cc: larsi, monnier, 24237-done > I agree that this kludge shouldn't be documented. It is very strange to > bind keys to menu-bindings just for :filter, It's not strange to do that for menu items. What's "strange", aka unexpected/new, is to do it for keyboard keys. > and if we document it we in effect say that this is > the preferred way of doing this stuff. Preferred way? No. It's the _only_ way (AFAIK). > > It is also quite useful. If you refuse to elevate it > > to doc-worthiness, then please change this bug to an > > enhancement request to provide the same feature > > _without_ having to use `menu-item' with :filter. > > > > Otherwise, I will I guess submit such an enhancement > > request. Elisp users shouldn't have to resort to an > > undocumented kludge to get this useful behavior. > > It makes sense to me to file such a feature request. Done: bug #45329. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>]
[parent not found: <<<87v9d67ox6.fsf@gnus.org>]
[parent not found: <<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>]
[parent not found: <<<83blexeod5.fsf@gnu.org>]
[parent not found: <<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default>]
[parent not found: <<83v9d5d1yd.fsf@gnu.org>]
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning [not found] ` <<83v9d5d1yd.fsf@gnu.org> @ 2020-12-13 19:52 ` Drew Adams 2020-12-19 10:47 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2020-12-13 19:52 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, 24237, Stefan Monnier > > "use of a `menu-item' construct with a :filter > > to create a conditional _keyboard_ key binding. > > In such a case, the `menu-item' construct is not > > a real menu item - it is not placed on any menu." > > That doesn't explain anything to me, sorry. Sorry. Does an example help? (global-set-key "\C-o" '`(menu-item "" forward-char :filter (lambda (cmd) (if (integerp prefix-arg) nil cmd)))) Stefan (cc'd), in particular, mentions this case from time to time. Here are some examples from him: In emacs-devel thread "Proposed patch for lookup-key" (2017-12-14): "bindings which are made dynamically conditional using a :filter function" In help-gnu-emacs thread "How to define minor-mode keybindings conditional on buffer's major-mode?" (2013-10-04): (define-key minor-mode-map "<<key-binding1>>" `(menu-item "" minor-mode-command :filter ,(lambda (cmd) (if (eq major-mode 'xyz-mode) cmd)))) (define-key minor-mode-map "<<key-binding2>>" `(menu-item "" minor-mode-command :filter ,(lambda (cmd) (if (not (eq major-mode 'xyz-mode)) cmd)))) In help-gnu-emacs thread "Commands with more than one keybinding in menus" (2013-08-14): You can use dynamic key-bindings, i.e. instead of binding your key to (lambda () (interactive) (if foo (CMD))), bind it to (menu-item "" CMD :filter (lambda (cmd) (if foo cmd))). In help-gnu-emacs thread "Shor-circuiting keybindings" (2010-12-09): You can create conditional key bindings: (define-key map [?\C-b] '(menu-item "dummy" <command> :filter (lambda (binding) (if <condition> binding)))) The filter function will receive <command> as argument (this is so that the same filter function can be used for several bindings) and can opt to return it or not or to return anything else (so you can create dynamic bindings, which is typically used to construct dynamic menus, such as the Buffers menu). The <command> you put as the "static binding" that gets passed to the filter is only used in cases such as where-is. In help-gnu-emacs thread "HELP: One Bindkey for Two Different Commands" (2007-11-30): How 'bout some neat hack like: (global-set-key "\M-o" '(menu-item "Foo" bar :filter (lambda (x) (if (cdr (window-list)) 'other-window 'switch-to-buffer)))) > > Define "menu function", please. ? (I don't think you answered that. If you still want to make a point about it, maybe let me know what you mean by it.) > > the case being discussed: an extended menu > > item that's bound only to a keyboard key, i.e., > > that's not used in any menu? > > I still don't understand what that means in practice. Do the examples above help? It's about using the :filter mechanism designed for menu items with a keyboard key instead, to create a key binding that's "dynamic", i.e., conditional at the time you use the key. > > > could be called whenever the display engine needs to > > > recalculate the contents and the dimensions of the menu, and that > > > could basically be every redisplay cycle, depending on circumstances. > > > > See above. There's no menu involved in the case > > being discussed (at least none that's visible to > > users, AFAIK). So there should be no need or > > possibility of recalculating menu contents and > > dimensions. > > Then you already know the answer and don't need any help, it seems. > But if you do, please explain more about the specific use case you > worry about. Please reread what I said. I'm not _aware_ of any actual menu being involved in the keyboard-key case. IF none is used, then I'm GUESSING that recalculating menu contents (what menu?) doesn't happen. But my point is only about having the doc address this specific use case - use of :filter when only a keyboard binding is used. IF that in fact doesn't involve any menus then shouldn't that paragraph be clarified to exclude that case in its caveat? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-13 19:52 ` Drew Adams @ 2020-12-19 10:47 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2020-12-19 10:47 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, 24237, monnier > Date: Sun, 13 Dec 2020 11:52:53 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: larsi@gnus.org, 24237@debbugs.gnu.org, > Stefan Monnier > <monnier@iro.umontreal.ca> > > > > "use of a `menu-item' construct with a :filter > > > to create a conditional _keyboard_ key binding. > > > In such a case, the `menu-item' construct is not > > > a real menu item - it is not placed on any menu." > > > > That doesn't explain anything to me, sorry. > > Sorry. Does an example help? > > (global-set-key > "\C-o" > '`(menu-item > "" forward-char > :filter (lambda (cmd) > (if (integerp prefix-arg) nil cmd)))) If this is never placed on the menu bar or on any pop-down menu, then what the manual says is not relevant, because redisplay only considers the menus that need to be displayed. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>]
[parent not found: <<87v9d67ox6.fsf@gnus.org>]
[parent not found: <<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>]
[parent not found: <<83blexeod5.fsf@gnu.org>]
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning [not found] ` <<83blexeod5.fsf@gnu.org> @ 2020-12-13 17:24 ` Drew Adams 2020-12-13 17:56 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2020-12-13 17:24 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, 24237 > > IF the guess is correct that this caveat does NOT > > in fact apply to this use case then no, it is > > NOT the case that "You should always write these > > filter functions as if they are called at any time." > > If that guess is correct then what you say as the > > reason for not fixing this doc bug simply isn't > > relevant. > > I don't think I understand what "this case" is, As was said in the original bug report and has been repeated in the thread, this case is the "use of a `menu-item' construct with a :filter to create a conditional _keyboard_ key binding. In such a case, the `menu-item' construct is not a real menu item - it is not placed on any menu." > but in general menu functions Define "menu function", please. Does this apply to the case being discussed: an extended menu item that's bound only to a keyboard key, i.e., that's not used in any menu? > could be called whenever the display engine needs to > recalculate the contents and the dimensions of the menu, and that > could basically be every redisplay cycle, depending on circumstances. See above. There's no menu involved in the case being discussed (at least none that's visible to users, AFAIK). So there should be no need or possibility of recalculating menu contents and dimensions. This is (only) about the hack/idiom of using an extended menu item for a keyboard key binding (only). And the use case for doing that is to take advantage of the :filter handling. I don't know where/when the :filter handling is done. Perhaps it is done as an integral part of redisplay. If that's the case, does it mean that the warning in the doc is applicable in this case? If it is thus applicable in this case, does it need to be? IOW, could handling of :filter be separated out, at least in the case where no menu is involved? Again, though, I'm not really arguing that using a `menu-item' just to get :filter behavior for a keyboard key binding is the best approach. The point is that currently it is the _only_ approach, hence the idiom. If Emacs provides a more direct way to do this, that's uncoupled from `menu-item' and its redisplay handling, great. Lacking that, this bug is about having the doc address the use case of the idiom. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-13 17:24 ` Drew Adams @ 2020-12-13 17:56 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2020-12-13 17:56 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, 24237 > Date: Sun, 13 Dec 2020 09:24:52 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: larsi@gnus.org, 24237@debbugs.gnu.org > > > I don't think I understand what "this case" is, > > As was said in the original bug report and has > been repeated in the thread, this case is the > > "use of a `menu-item' construct with a :filter > to create a conditional _keyboard_ key binding. > In such a case, the `menu-item' construct is not > a real menu item - it is not placed on any menu." That doesn't explain anything to me, sorry. > > but in general menu functions > > Define "menu function", please. Does this apply > to the case being discussed: an extended menu > item that's bound only to a keyboard key, i.e., > that's not used in any menu? I still don't understand what that means in practice. > > could be called whenever the display engine needs to > > recalculate the contents and the dimensions of the menu, and that > > could basically be every redisplay cycle, depending on circumstances. > > See above. There's no menu involved in the case > being discussed (at least none that's visible to > users, AFAIK). So there should be no need or > possibility of recalculating menu contents and > dimensions. Then you already know the answer and don't need any help, it seems. But if you do, please explain more about the specific use case you worry about. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning @ 2016-08-15 18:06 Drew Adams 2020-12-12 20:24 ` Lars Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2016-08-15 18:06 UTC (permalink / raw) To: 24237 The doc for :filter says this about the FILTER-FN: Emacs can call this function at any time that it does redisplay or operates on menu data structures, so you should write it so it can safely be called at any time. Is this true in general, or only when the extended menu item is put on a menu? A common idiom is to make use of a `menu-item' construct with a :filter to create a conditional _keyboard_ key binding. In such a case, the `menu-item' construct is not a real menu item - it is not placed on any menu. I'm guessing that in such a case this doc paragraph does not apply. If this guess is correct then please correct the paragraph, so that it says something like "If an extended menu item that uses :filter is placed on a menu then Emacs can call FILTER-FN when...". Also, is it really the case that FILTER-FN can be called anytime Emacs does redisplay? Shouldn't the doc say only that it can be called anytime Emacs "operates on menu data structures"? Does it get called by redisplay other than when redisplay operates on menu data structures? In the case mentioned above (binding to a keyboard key), would FILTER-FN ever be called during redisplay? I'm guessing that it would not. In GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=/c/usr --host=i686-pc-mingw32' ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2016-08-15 18:06 Drew Adams @ 2020-12-12 20:24 ` Lars Ingebrigtsen 2020-12-12 20:45 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Lars Ingebrigtsen @ 2020-12-12 20:24 UTC (permalink / raw) To: Drew Adams; +Cc: 24237 Drew Adams <drew.adams@oracle.com> writes: > The doc for :filter says this about the FILTER-FN: > > Emacs can call this function at any time that it does redisplay or > operates on menu data structures, so you should write it so it can > safely be called at any time. > > Is this true in general, or only when the extended menu item is put on a > menu? > > A common idiom is to make use of a `menu-item' construct with a :filter > to create a conditional _keyboard_ key binding. In such a case, the > `menu-item' construct is not a real menu item - it is not placed on any > menu. > > I'm guessing that in such a case this doc paragraph does not apply. If > this guess is correct then please correct the paragraph, so that it says > something like "If an extended menu item that uses :filter is placed on > a menu then Emacs can call FILTER-FN when...". I think making the documentation more specific here serves no purpose. The statement as is should be true: You should always write these filter functions as if they are called at any time. > Also, is it really the case that FILTER-FN can be called anytime Emacs > does redisplay? Shouldn't the doc say only that it can be called > anytime Emacs "operates on menu data structures"? Does it get called by > redisplay other than when redisplay operates on menu data structures? > In the case mentioned above (binding to a keyboard key), would FILTER-FN > ever be called during redisplay? I'm guessing that it would not. I don't see why we should specify that at all. Closing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-12 20:24 ` Lars Ingebrigtsen @ 2020-12-12 20:45 ` Drew Adams 2020-12-13 15:07 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2020-12-12 20:45 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 24237 > > The doc for :filter says this about the FILTER-FN: > > > > Emacs can call this function at any time that it does redisplay or > > operates on menu data structures, so you should write it so it can > > safely be called at any time. > > > > Is this true in general, or only when the extended menu item is put on a > > menu? > > > > A common idiom is to make use of a `menu-item' construct with a :filter > > to create a conditional _keyboard_ key binding. In such a case, the > > `menu-item' construct is not a real menu item - it is not placed on any > > menu. > > > > I'm guessing that in such a case this doc paragraph does not apply. If > > this guess is correct then please correct the paragraph, so that it says > > something like "If an extended menu item that uses :filter is placed on > > a menu then Emacs can call FILTER-FN when...". > > I think making the documentation more specific here serves no purpose. > The statement as is should be true: You should always write these filter > functions as if they are called at any time. > > > Also, is it really the case that FILTER-FN can be called anytime Emacs > > does redisplay? Shouldn't the doc say only that it can be called > > anytime Emacs "operates on menu data structures"? Does it get called by > > redisplay other than when redisplay operates on menu data structures? > > In the case mentioned above (binding to a keyboard key), would FILTER-FN > > ever be called during redisplay? I'm guessing that it would not. > > I don't see why we should specify that at all. The Elisp manual is not only for readers reading as end users. This information is needed by people writing Lisp code that uses extended menu items. And as the bug report points out, a very different use case does not involve use of a menu at all. Now perhaps Emacs should provide some alternative to using an extended menu item, specifically for this very different use case. But until and unless it does that, the behavior for this particular use case should be covered in the doc. In particular, if the caveat that is written does NOT apply for this use case, then that should be pointed out. IF the guess is correct that this caveat does NOT in fact apply to this use case then no, it is NOT the case that "You should always write these filter functions as if they are called at any time." If that guess is correct then what you say as the reason for not fixing this doc bug simply isn't relevant. This is not some obscure detail. It goes to the heart of the behavior and use of extended menu items. If you instead want to create a new Lisp construct to achieve such filtering for non-menu uses, great - that would take care of this lack in a different, equally (maybe even more) acceptable way. Just ignoring this isn't TRT. I, for one, would like to know what the case really is wrt the display engine problem when you use an extended menu item without a menu. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning 2020-12-12 20:45 ` Drew Adams @ 2020-12-13 15:07 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2020-12-13 15:07 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, 24237 > Date: Sat, 12 Dec 2020 12:45:17 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: 24237@debbugs.gnu.org > > IF the guess is correct that this caveat does NOT > in fact apply to this use case then no, it is > NOT the case that "You should always write these > filter functions as if they are called at any time." > If that guess is correct then what you say as the > reason for not fixing this doc bug simply isn't > relevant. I don't think I understand what "this case" is, but in general menu functions could be called whenever the display engine needs to recalculate the contents and the dimensions of the menu, and that could basically be every redisplay cycle, depending on circumstances. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-12-20 1:23 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default> [not found] ` <<<<87v9d67ox6.fsf@gnus.org> [not found] ` <<<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default> [not found] ` <<<<83blexeod5.fsf@gnu.org> [not found] ` <<<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default> [not found] ` <<<83v9d5d1yd.fsf@gnu.org> [not found] ` <<846fcdf8-9b51-4246-8200-b067e7006e24@default> [not found] ` <<83y2hut6m7.fsf@gnu.org> 2020-12-19 18:54 ` bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning Drew Adams 2020-12-19 19:17 ` Eli Zaretskii [not found] <<<<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default> [not found] ` <<<<<87v9d67ox6.fsf@gnus.org> [not found] ` <<<<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default> [not found] ` <<<<<83blexeod5.fsf@gnu.org> [not found] ` <<<<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default> [not found] ` <<<<83v9d5d1yd.fsf@gnu.org> [not found] ` <<<846fcdf8-9b51-4246-8200-b067e7006e24@default> [not found] ` <<<83y2hut6m7.fsf@gnu.org> [not found] ` <<d15a8746-eb78-44b5-a4d6-af2285969b76@default> [not found] ` <<838s9ttxkk.fsf@gnu.org> 2020-12-19 19:35 ` Drew Adams 2020-12-20 0:05 ` Stefan Kangas 2020-12-20 1:23 ` Drew Adams [not found] <<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default> [not found] ` <<<87v9d67ox6.fsf@gnus.org> [not found] ` <<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default> [not found] ` <<<83blexeod5.fsf@gnu.org> [not found] ` <<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default> [not found] ` <<83v9d5d1yd.fsf@gnu.org> 2020-12-13 19:52 ` Drew Adams 2020-12-19 10:47 ` Eli Zaretskii [not found] <<6c4f5089-43fa-4ca1-a656-1ec1684df960@default> [not found] ` <<87v9d67ox6.fsf@gnus.org> [not found] ` <<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default> [not found] ` <<83blexeod5.fsf@gnu.org> 2020-12-13 17:24 ` Drew Adams 2020-12-13 17:56 ` Eli Zaretskii 2016-08-15 18:06 Drew Adams 2020-12-12 20:24 ` Lars Ingebrigtsen 2020-12-12 20:45 ` Drew Adams 2020-12-13 15:07 ` 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.