* bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook @ 2009-04-16 15:46 klaus.berndl 2009-04-17 9:53 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: klaus.berndl @ 2009-04-16 15:46 UTC (permalink / raw) To: bug-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 456 bytes --] Hi all, AFAICS the new hook `clone-indirect-buffer-hook' of Emacs 23 is not used by the command `make-indirect-buffer-hook' or is it? If not: why not? IMHO a bug in Emacs 23 because if there is such a hook, then it should be used by both of them - at ist best only by make-indirect-buffer (because this command is called by clone-indirect-buffer) and then the new hook should be named make-indirect-buffer-hook... Thoughts? Regards Klaus [-- Attachment #2: Type: text/html, Size: 1277 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook 2009-04-16 15:46 bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook klaus.berndl @ 2009-04-17 9:53 ` Lennart Borgman 2009-04-17 20:26 ` Stefan Monnier 2022-05-01 10:00 ` bug#3018: bug#3038: 23.0.91; after-change-functions and indirect buffers Lars Ingebrigtsen 2 siblings, 0 replies; 8+ messages in thread From: Lennart Borgman @ 2009-04-17 9:53 UTC (permalink / raw) To: klaus.berndl, 3018 Hi Klaus, you never sent a bug report, or? Hope someone still answers, but this might be forgotten if it does not get into the bug system. Please wait a couple of days and see if someone answers. On Thu, Apr 16, 2009 at 5:46 PM, <klaus.berndl@capgemini-sdm.com> wrote: > Hi all, > > AFAICS the new hook `clone-indirect-buffer-hook' of Emacs 23 is not used by > the command `make-indirect-buffer-hook' or is it? If not: why not? > > IMHO a bug in Emacs 23 because if there is such a hook, then it should be > used by both of them - at ist best only by make-indirect-buffer (because > this command is called by clone-indirect-buffer) and then the new hook > should be named make-indirect-buffer-hook... > > Thoughts? > > Regards > > Klaus ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook 2009-04-16 15:46 bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook klaus.berndl 2009-04-17 9:53 ` Lennart Borgman @ 2009-04-17 20:26 ` Stefan Monnier 2009-04-18 8:49 ` bug#3018: AW: " klaus.berndl 2022-05-01 10:00 ` bug#3018: bug#3038: 23.0.91; after-change-functions and indirect buffers Lars Ingebrigtsen 2 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2009-04-17 20:26 UTC (permalink / raw) To: klaus.berndl; +Cc: 3018 > IMHO a bug in Emacs 23 because if there is such a hook, then it should > be used by both of them - at ist best only by make-indirect-buffer > (because this command is called by clone-indirect-buffer) and then the > new hook should be named make-indirect-buffer-hook... If `make-indirect-buffer' is called with a nil argument for `clone', then it shouldn't run any buffer-local part of clone-indirect-buffer-hook (which is typically used by major modes). So maybe you're right, but as long as nobody uses the global part of clone-indirect-buffer-hook, or calls `make-indirect-buffer' with a non-nil `clone' argument (rather than calling clone-indirect-buffer), it shouldn't matter. Care to explain the context in which you bumped into this? It might help us understand what needs to be done. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook 2009-04-17 20:26 ` Stefan Monnier @ 2009-04-18 8:49 ` klaus.berndl 2009-04-18 12:56 ` bug#3018: Re[1]: " Eric M. Ludlam 0 siblings, 1 reply; 8+ messages in thread From: klaus.berndl @ 2009-04-18 8:49 UTC (permalink / raw) To: monnier, eric; +Cc: 3018 [-- Attachment #1: Type: text/plain, Size: 3048 bytes --] Hi Stefan, probably Eric could explain this better, but i will make a try: Currently we try to make ECB and CEDET (semantic) ready for usage with indirect-buffers too... For ECB the part is done but for semantic we detected that there are really ugly and unpredictable side-effects when cloning a buffer which is supported by semantic - simplified reason: all the semantic-overlays are cloned too and it seems that the buffer-object of such a semantic-overlay in the new clone points still to the base-buffer which confuses semantic and all tools using semantic (e.g. ECB) a lot... Therefore we came to the solution that semantic clears its cache for the new clone when the new clone is created, so the new clone is completely reparsed next time and therefore the new clone gets new semantic overleys completely different from these of the base-buffer... A first and working solution was to do this with clone-indirect-buffer-hook.. but this is an unsave solution because tere is the command make-indirect-buffer which can also be used to create a clone and when done this way, the hook doesn't run, therefore the semantic-cache is not cleared and therefore ugly sideeffets came up which makes semantic quite unusable with indirect buffers... so in this case the usage of the hook is not related to a certain major-mode but we need an entry-point in indirect-buffer-creation to prepare some things needed by semantic and ECB... Without such a common hook as suggested by me i see only one chance: writing a small after advice for make-indirect-buffer - i have tested this already and it would work but IMHO a hook-solution would be preferable. Therefore the suggestion to make a hook, which runs also with make-indirect-buffer... Eric, is this understandable or would you like to add some remarks? BTW: there is another problem related to indirect-buffer but this one has to be explained by Eric... best regards Klaus -----Ursprüngliche Nachricht----- Von: Stefan Monnier [mailto:monnier@IRO.UMontreal.CA] Gesendet: Fr 17.04.2009 22:26 An: Berndl, Klaus Cc: 3018@emacsbugs.donarmstrong.com Betreff: Re: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook > IMHO a bug in Emacs 23 because if there is such a hook, then it should > be used by both of them - at ist best only by make-indirect-buffer > (because this command is called by clone-indirect-buffer) and then the > new hook should be named make-indirect-buffer-hook... If `make-indirect-buffer' is called with a nil argument for `clone', then it shouldn't run any buffer-local part of clone-indirect-buffer-hook (which is typically used by major modes). So maybe you're right, but as long as nobody uses the global part of clone-indirect-buffer-hook, or calls `make-indirect-buffer' with a non-nil `clone' argument (rather than calling clone-indirect-buffer), it shouldn't matter. Care to explain the context in which you bumped into this? It might help us understand what needs to be done. Stefan [-- Attachment #2: Type: text/html, Size: 3749 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: Re[1]: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook 2009-04-18 8:49 ` bug#3018: AW: " klaus.berndl @ 2009-04-18 12:56 ` Eric M. Ludlam 2009-04-18 17:54 ` bug#3018: " Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Eric M. Ludlam @ 2009-04-18 12:56 UTC (permalink / raw) To: klaus.berndl; +Cc: 3018, monnier Hi, Klaus' explanation is accurate. Semantic's parsing engine needs to have separate tag streams (tracked by overlays) for each buffer. When the clone replicates the overlays and local variables, they share the same cons cells in Semantic's tag data structure. When Semantic then incrementally parses the buffer, and splices new tags in, things get a bit unreliable. If the two buffers were in two different modes (ie, one of the multi-modes?) with different parsers, I can imagine things being even stranger. The second issue Klaus alludes two is with the after-change function. Semantic tracks all the little changes, then the next time the tag stream needs to be updated for Semantic, it combines those changes to determine what subset of the buffer to reparse. This makes the reparsing step very fast. The after-change function does not seem to be called for all linked buffers. Changing a base buffer doesn't call the same hooks in the indirect buffer, and vice-versa. This means that changes get lost, as each buffer appears to need Semantic to track the changes separately. I can imagine calling the after-change-function for every linked buffer might be a bad idea, but there is also no way to get a list of all such linked buffers. If there were, I could propagate the change tracking myself quite easily. I don't think having something looping over all buffers to generate said list myself would be a good idea in the after-change-function though, especially in the general case where there aren't any, that would be a waste. If you need any additional information, let me know. Eric >>> <klaus.berndl@capgemini-sdm.com> seems to think that: >Hi Stefan, > >probably Eric could explain this better, but i will make a try: > >Currently we try to make ECB and CEDET (semantic) ready for usage with = >indirect-buffers too... For ECB the part is done but for semantic we = >detected that there are really ugly and unpredictable side-effects when = >cloning a buffer which is supported by semantic - simplified reason: all = >the semantic-overlays are cloned too and it seems that the buffer-object = >of such a semantic-overlay in the new clone points still to the = >base-buffer which confuses semantic and all tools using semantic (e.g. = >ECB) a lot... Therefore we came to the solution that semantic clears = >its cache for the new clone when the new clone is created, so the new = >clone is completely reparsed next time and therefore the new clone gets = >new semantic overleys completely different from these of the = >base-buffer... A first and working solution was to do this with = >clone-indirect-buffer-hook.. but this is an unsave solution because tere = >is the command make-indirect-buffer which can also be used to create a = >clone and when done this way, the hook doesn't run, therefore the = >semantic-cache is not cleared and therefore ugly sideeffets came up = >which makes semantic quite unusable with indirect buffers... so in this = >case the usage of the hook is not related to a certain major-mode but we = >need an entry-point in indirect-buffer-creation to prepare some things = >needed by semantic and ECB... > >Without such a common hook as suggested by me i see only one chance: = >writing a small after advice for make-indirect-buffer - i have tested = >this already and it would work but IMHO a hook-solution would be = >preferable. > >Therefore the suggestion to make a hook, which runs also with = >make-indirect-buffer... > >Eric, is this understandable or would you like to add some remarks? > >BTW: there is another problem related to indirect-buffer but this one = >has to be explained by Eric... > >best regards >Klaus > >-----Urspr=FCngliche Nachricht----- >Von: Stefan Monnier [mailto:monnier@IRO.UMontreal.CA] >Gesendet: Fr 17.04.2009 22:26 >An: Berndl, Klaus >Cc: 3018@emacsbugs.donarmstrong.com >Betreff: Re: bug#3018: clone-indirect-buffer-hook should be = >make-indirect-buffer-hook >=20 >> IMHO a bug in Emacs 23 because if there is such a hook, then it should >> be used by both of them - at ist best only by make-indirect-buffer >> (because this command is called by clone-indirect-buffer) and then the >> new hook should be named make-indirect-buffer-hook... > >If `make-indirect-buffer' is called with a nil argument for `clone', >then it shouldn't run any buffer-local part of >clone-indirect-buffer-hook (which is typically used by major modes). > >So maybe you're right, but as long as nobody uses the global part of >clone-indirect-buffer-hook, or calls `make-indirect-buffer' with >a non-nil `clone' argument (rather than calling clone-indirect-buffer), >it shouldn't matter. > >Care to explain the context in which you bumped into this? It might >help us understand what needs to be done. > > > Stefan > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook 2009-04-18 12:56 ` bug#3018: Re[1]: " Eric M. Ludlam @ 2009-04-18 17:54 ` Stefan Monnier 2009-04-19 4:55 ` bug#3018: AW: " klaus.berndl 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2009-04-18 17:54 UTC (permalink / raw) To: Eric M. Ludlam; +Cc: klaus.berndl, 3018 > Klaus' explanation is accurate. Semantic's parsing engine needs to > have separate tag streams (tracked by overlays) for each buffer. When > the clone replicates the overlays and local variables, they share the > same cons cells in Semantic's tag data structure. When Semantic then > incrementally parses the buffer, and splices new tags in, things get a > bit unreliable. If the two buffers were in two different modes (ie, > one of the multi-modes?) with different parsers, I can imagine things > being even stranger. Yes, this is a "common" problem, and is the reason why clone-indirect-buffer-hook was introduced. If `make-indirect-buffer' is called with a nil `clone' argument this problem shouldn't show up (because such a call shouldn't copy the overlays). So the problem might only show up when calling `make-indirect-buffer' with a non-nil `clone' argument without going through clone-indirect-buffer. When did you come across such a situation? > The after-change function does not seem to be called for all linked > buffers. Changing a base buffer doesn't call the same hooks in the > indirect buffer, and vice-versa. This means that changes get lost, as > each buffer appears to need Semantic to track the changes separately. Indeed, it might be that *-change-functions only get called in the buffer from which they are performed, which is probably a bug. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: AW: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook 2009-04-18 17:54 ` bug#3018: " Stefan Monnier @ 2009-04-19 4:55 ` klaus.berndl 0 siblings, 0 replies; 8+ messages in thread From: klaus.berndl @ 2009-04-19 4:55 UTC (permalink / raw) To: monnier, eric; +Cc: 3018 [-- Attachment #1: Type: text/plain, Size: 2756 bytes --] Ah, now i understand - when calling make-indirect-buffer interactively the clone-arg is always nil... major-mode is fundamental-mode (e.g.), no overlays are copied ==> the buffer is not setup for semantic... Just tested - with respect to semantic indirect-buffers made by make-indirect-buffer are quite useless, because not even the major-mode is copied, so semantic is in consequence not active for such a non-clone. Well, so if a user wants a real clone then he must use clone-indirect-buffer. I have misunderstood this...thanks for explanation. Well, then it might be ok, only having the clone-indirect-buffer hook because semantic has only to deal with indirect-buffers which are real clones not with that ones created by make-indirect-buffer... Eric: Now for me the clone-indirect-buffer-hook solution is ok and save. Topic after-change-function: Stefan, what do you think? Are there chances that this bug will be fixed in the near future or do have any idea for a practicable work- around? Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Stefan Monnier [mailto:monnier@iro.umontreal.ca] Gesendet: Sa 18.04.2009 19:54 An: Eric M. Ludlam Cc: Berndl, Klaus; 3018@emacsbugs.donarmstrong.com Betreff: Re: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook > Klaus' explanation is accurate. Semantic's parsing engine needs to > have separate tag streams (tracked by overlays) for each buffer. When > the clone replicates the overlays and local variables, they share the > same cons cells in Semantic's tag data structure. When Semantic then > incrementally parses the buffer, and splices new tags in, things get a > bit unreliable. If the two buffers were in two different modes (ie, > one of the multi-modes?) with different parsers, I can imagine things > being even stranger. Yes, this is a "common" problem, and is the reason why clone-indirect-buffer-hook was introduced. If `make-indirect-buffer' is called with a nil `clone' argument this problem shouldn't show up (because such a call shouldn't copy the overlays). So the problem might only show up when calling `make-indirect-buffer' with a non-nil `clone' argument without going through clone-indirect-buffer. When did you come across such a situation? > The after-change function does not seem to be called for all linked > buffers. Changing a base buffer doesn't call the same hooks in the > indirect buffer, and vice-versa. This means that changes get lost, as > each buffer appears to need Semantic to track the changes separately. Indeed, it might be that *-change-functions only get called in the buffer from which they are performed, which is probably a bug. Stefan [-- Attachment #2: Type: text/html, Size: 3604 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3018: bug#3038: 23.0.91; after-change-functions and indirect buffers 2009-04-16 15:46 bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook klaus.berndl 2009-04-17 9:53 ` Lennart Borgman 2009-04-17 20:26 ` Stefan Monnier @ 2022-05-01 10:00 ` Lars Ingebrigtsen 2 siblings, 0 replies; 8+ messages in thread From: Lars Ingebrigtsen @ 2022-05-01 10:00 UTC (permalink / raw) To: klaus.berndl; +Cc: 3018, 3038 <klaus.berndl@capgemini-sdm.com> writes: > AFAICS the new hook `clone-indirect-buffer-hook' of Emacs 23 is not > used by the command `make-indirect-buffer-hook' or is it? If not: why > not? (I'm going through old bug reports that unfortunately weren't resolved at the time.) Skimming this bug report, it seems like it was agreed that this works as designed. There was then some discussion about after-change-functions, but this bug report doesn't seem actionable, so I'm closing it. If there is something that should be done in this area, opening a new bug report and restating the issue would be the way forward. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-05-01 10:00 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-16 15:46 bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook klaus.berndl 2009-04-17 9:53 ` Lennart Borgman 2009-04-17 20:26 ` Stefan Monnier 2009-04-18 8:49 ` bug#3018: AW: " klaus.berndl 2009-04-18 12:56 ` bug#3018: Re[1]: " Eric M. Ludlam 2009-04-18 17:54 ` bug#3018: " Stefan Monnier 2009-04-19 4:55 ` bug#3018: AW: " klaus.berndl 2022-05-01 10:00 ` bug#3018: bug#3038: 23.0.91; after-change-functions and indirect buffers Lars Ingebrigtsen
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.