Thread: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2009-04-15 18:45:03
|
Hi Klaus, As I mentioned before, I hadn't used indirect buffers. This seems interesting though in that I'm just using overlays, and reading tags out of them. I will add investigating these kinds of buffers to my todo list. I'm assuming indirect buffers are used in other specialty modes, like tar-mode or something? What would a user expect out of Semantic here? Also, you appear to not be subscribed to the cedet-devel mailing list. That would help. Thanks Eric >>> <kla...@ca...> seems to think that: >Hi, >=20 >after a little bit digging around in the semantic code i found: >=20 >(defun semantic-tag-file-name (tag) > "Return the name of the file from which TAG originated. >Return nil if that information can't be obtained. >If TAG is from a loaded buffer, then that buffer's filename is used. >If TAG is unlinked, but has a :filename property, then that is used." > (let ((buffer (semantic-tag-in-buffer-p tag))) > (if buffer > (buffer-file-name buffer) > (semantic--tag-get-property tag :filename)))) >=20 >This would return nil for a TAG of an indirect-buffer even when the = >base-buffer of this indirect-buffer is a file-buffer. This is because ' = >buffer-file-name' returnes nil for indirect-buffers....therefore ECB = >uses : >=20 >(defun ecb-buffer-file-name (&optional buffer no-indirect-buffers) > "Return filename of file represented by BUFFER. >BUFFER can also be an indirect buffer - if its base buffer points to a = >file >then this filename is returned. >BUFFER can be a buffer-object or a buffer-name. >If BUFFER is nil then current buffer is used. >If NO-INDIRECT-BUFFERS is not nil then for indirect buffers always nil = >is >returned." > (or (buffer-file-name buffer) > (and (not no-indirect-buffers) > (buffer-base-buffer buffer) > (buffer-file-name (buffer-base-buffer buffer))))) >=20 >Now i suppose that there are a lot of places in semantic which are not = >'indirect-buffer-save' - or have i something misunderstood and overseen? >=20 >Ciao, >Klaus > >________________________________ > >Von: Berndl, Klaus=20 >Gesendet: Mittwoch, 15. April 2009 17:13 >An: 'ced...@li...'; 'Eric M. Ludlam' >Betreff: AW: Is Semantic able to work with indirect buffers? - some = >findings > > >Hi Eric, >=20 >again, now after doing a simple test: >=20 >1. Open a semantic supported file, e.g. ecb-method-browser.el >2. Call M-: (semantic-tag-buffer (semantic-current-tag)) RET > This returnes the buffer ecb-method-browser.el >3. Call the command `clone-indirect-buffer' > This switches to a new indirect-buffer (base-buffer is = >ecb-method-browser.el) named "ecb-method-browser.el<2>" >4. Call M-: (semantic-tag-buffer (semantic-current-tag)) RET when this = >new indirect buffer is current > This returnes the buffer ecb-method-browser.el again - wich is = >definitely wrong because the semantic-tag-buffer should be that buffer = >from which the tag is parsed and=20 > not the underlying file >=20 >Am i doing something wrong or comes my apprehension true, that semantic = >is not able to deal correctly with indirect buffers?! >=20 >Thanks for your effort! >=20 >Ciao, >Klaus > >________________________________ > >Von: Berndl, Klaus=20 >Gesendet: Mittwoch, 15. April 2009 16:43 >An: ced...@li...; 'Eric M. Ludlam' >Betreff: Is Semantic able to work with indirect buffers? > > >Hi Eric, >=20 >currently i'm preparing ECB to work with indirect buffers as well as = >with direct file-buffers.. therefore my question: Is semantic able to = >deal with indirect buffers of source-buffers - e.g. i'm thinking about = >the internal semantic caches: are they buffer(name) or filename-centric? >=20 >Ciao, >Klaus [ ... ] -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: <kla...@ca...> - 2009-04-16 08:29:34
|
Hi Eric, Tonight i substantiated my suspicion, that currently semantic is not ready for usage in indirect-buffers - independ of ECB: Test: 1. Open in emacs any elisp-file X, e.g. one of semantic: 2. Call clone-indirect-buffer for the buffer X, you will get a new indirect buffer named X<2> (or similiar) 3. Ensure that indirect buffer X<2> is the current buffer displayed 4. Now call [C-c , J] (semantic-complete-jump) when point stays on a symbol which is defined in X<2> itself(!!), e.g. any function-symbol 5. semantic-complete-jump will find this symbol but it will go to it in the base buffer X, not in the current indirect-buffer X<2> This is defintely not what the users expect! IMHO a bug but unfortunatelly one of them which could cause huge effort to fix it - can not estimate what are the costs for reworking semantic so it also works for indirect-buffers....? But maybe it is not all that bad, see below my ideas: In our example the problem is in this function: (defun semantic-complete-jump () "Jump to a semantic symbol." (interactive) (let* ((tag (semantic-complete-read-tag-project "Symbol: "))) (when (semantic-tag-p tag) (push-mark) (semantic-go-to-tag tag) (switch-to-buffer (current-buffer)) (semantic-momentary-highlight-tag tag) (working-message "%S: %s " (semantic-tag-class tag) (semantic-tag-name tag))))) The usage of semantic-go-to-tag which takes the buffer stored in the tag and makes this buffer current - but i have tested that all the tags of an indirect-buffer store the buffer-objects of the related base-buffer! But now lets become more constructive ;-) But first an excurs - from the emacs -manual: ---------- An "indirect buffer" shares the text of some other buffer, which is called the "base buffer" of the indirect buffer. In some ways it is the analogue, for buffers, of a symbolic link among files. The base buffer may not itself be an indirect buffer. The text of the indirect buffer is always identical to the text of its base buffer; changes made by editing either one are visible immediately in the other. This includes the text properties as well as the characters themselves. In all other respects, the indirect buffer and its base buffer are completely separate. They have different names, independent values of point, independent narrowing, independent markers and overlays (though inserting or deleting text in either buffer relocates the markers and overlays for both), independent major modes, and independent buffer-local variable bindings. An indirect buffer cannot visit a file, but its base buffer can. If you try to save the indirect buffer, that actually saves the base buffer. Killing an indirect buffer has no effect on its base buffer. Killing the base buffer effectively kills the indirect buffer in that it cannot ever again be the current buffer. --------- There is one good thing: indirect-buffers have separate overlays which is definitely good for semantic ;-) But my suspicion is, that all overlays of the base-buffer are copied to the indirect-buffers...maybe therefore the wrong-buffer-object is stored in the semantic-tags??!! AFAIK semantic uses overlay-buffer to get the buffer of an overlay, right? So, could this be an Emacs bug? IMHO the new overlays of the indirect-buffers should automatically return the correct buffer when calling overlay-buffer for an indirect-buffer... SO IMHO the key to an indirect-buffer-able semantic could be: A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... B) use something like (ecb-buffer-file-name) (see ecb-utils.el) instead of plain (buffer-file-name) when you (semantic)need the underlying file of a buffer...because this also works for indirect buffers... Could be that implementing A and B is quite easy but running all necessary tests, that all is working fine afterwars, could be a pain.... ;-) Summary: IMHO semantic should be able to deal with indirect buffers because otherwise there could be really unwished, unexpected and also unknown sideeffects, which should be avoided with every software... In the meanwhile i think i can add a small workaround to ECB so it is able to uses current semantic also for indirect buffers, at least to the needs of ECB. Your thoughts? Ciao, Klaus P.S. Some weeks before i was in the same situation as you as i detected that ECB was too file-focussed in its internals... Now i have rewritten the source-handling backbone and now the source can either be a real filebuffer or an indirect-buffer if ist base-buffer is a file-buffer.... Dealing with completely file-unrelated buffers makes no sense for a code-browser, but indirect buffer can be senseful, see one of the news of next ECB-release: ** Complete reworked history-buffer *** The history is able to deal with indirect-buffer entries. See new option `ecb-history-stick-indirect-buffers-to-basebuffer'. *** The history can now be bucketized, see new `ecb-history-make-buckets'. This option allows to define several criterias for building buckets in the history-buffer all the history entries are sorted in (e.g. by major-mode, directory, file-extension or regular expressions). The latter one allows in combination with the indirect-buffer ability to work with something like "virtual folders" (well, "virtual folders" light). For example, there is a large project with a huge number of files, and there are various tasks in this project. So it could be convenient to group buffers according to various tasks. It could be fulfiled through using indirect buffers, for example like this task_1-aaa.pl task_1-bbb.c task_1-ccc.sh ... task_N-xxx.java task_N-ccc.sh This means create indirect buffers with a name-part which can be used for grouping together buffers with same name-part (here e.g. task_1- ... task_N-). In the example above you would create two indirect buffers for the filebuffer ccc.sh, one named task_1-ccc.sh, the other named task_N-ccc.sh). Then use the new option `ecb-history-make-buckets' to define regexps for bucketizing all (indirect) buffers according their task-part in the buffer-name. This "virual folders" were a suggestion of a user and it sounded senseful in my ears ;-) |
From: Lennart B. <len...@gm...> - 2009-04-16 10:32:46
|
On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: > A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... I have no idea how this work, but it sounds that there are some properties on the overlays that points to position in a buffer. I guess these are markers. Then maybe a check if the marker points to the base buffer could be made just before use? Or perhaps that will be too slow? |
From: Eric M. L. <er...@si...> - 2009-04-16 11:21:36
|
>>> Lennart Borgman <len...@gm...> seems to think that: >On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: >> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... > >I have no idea how this work, but it sounds that there are some >properties on the overlays that points to position in a buffer. I >guess these are markers. Then maybe a check if the marker points to >the base buffer could be made just before use? Or perhaps that will be >too slow? [ ... ] I did an experiment. I pulled up a simple C++ file, and cloned it. I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer. I then ran: C-u M-x bovinate RET to reparse. Now this throws away all the tag information, and reparses. The new tag was not `eq', and also did not have buffer file names associated with it. I suspect the "fix" is going to be easy. First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse. Semantic will take care of the rest later, and have all the tags marked correctly. I don't think an unlink/link pass would work since the raw tag data is shared at first. There is a spiffy keybinding in senator: C-c , / which will show you details of the tag under point in the data-debugger so you can navigate the structure. It is very helpful for stuff like this. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: <kla...@ca...> - 2009-04-16 12:09:58
|
Hi Eric, Hmm, sound senseful - al least at first glance... On a second glance i want to point to the most recent posting i sent to you - this one, where i describe what happens after editing tags in the *indirect-buffer*... How does this behavior match your findings you describe below?! But maybe you are right and fixing one small underlying problem-source in semantic fixes all other misbehaviors too.. But currently i'm slightly pessimistic ;-) Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Donnerstag, 16. April 2009 13:21 An: Lennart Borgman Cc: Berndl, Klaus; ced...@li... Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea >>> Lennart Borgman <len...@gm...> seems to think that: >On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: >> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... > >I have no idea how this work, but it sounds that there are some >properties on the overlays that points to position in a buffer. I guess >these are markers. Then maybe a check if the marker points to the base >buffer could be made just before use? Or perhaps that will be too slow? [ ... ] I did an experiment. I pulled up a simple C++ file, and cloned it. I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer. I then ran: C-u M-x bovinate RET to reparse. Now this throws away all the tag information, and reparses. The new tag was not `eq', and also did not have buffer file names associated with it. I suspect the "fix" is going to be easy. First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse. Semantic will take care of the rest later, and have all the tags marked correctly. I don't think an unlink/link pass would work since the raw tag data is shared at first. There is a spiffy keybinding in senator: C-c , / which will show you details of the tag under point in the data-debugger so you can navigate the structure. It is very helpful for stuff like this. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2009-04-16 12:32:35
|
When you edit a buffer, Semantic will reparse only the local area. It will recycle the overlay, and splice the new tags into the existing tags list. Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed. I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent. Here is a patch you can try: *** semantic.el.~1.212.~ 2009-03-18 20:46:39.000000000 -0400 --- semantic.el 2009-04-16 08:29:37.000000000 -0400 *************** *** 299,304 **** --- 299,309 ---- (not (semantic-active-p)) (not (run-hook-with-args-until-success 'semantic-inhibit-functions))) + ;; Make sure that if this buffer is cloned, our tags and overlays + ;; don't go along for the ride. + (add-hook 'clone-indirect-buffer-hook + 'semantic-clear-toplevel-cache + nil t) ;; Specify that this function has done it's work. At this point ;; we can consider that semantic is active in this buffer. (setq semantic-new-buffer-fcn-was-run t) ---------- This adds a hook to clear the cache when something is cloned. Please give it a try and let me know how it works. I don't know if this is really the right thing or not. Thanks! Eric >>> <kla...@ca...> seems to think that: >Hi Eric, > >Hmm, sound senseful - al least at first glance... > >On a second glance i want to point to the most recent posting i sent >to you - this one, where i describe what happens after editing tags >in the *indirect-buffer*... How does this behavior match your >findings you describe below?! > >But maybe you are right and fixing one small underlying >problem-source in semantic fixes all other misbehaviors too.. But >currently i'm slightly pessimistic ;-) > >Ciao, >Klaus > >-----Ursprüngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Donnerstag, 16. April 2009 13:21 >An: Lennart Borgman >Cc: Berndl, Klaus; ced...@li... >Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea > >>>> Lennart Borgman <len...@gm...> seems to think that: >>On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: >>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... >> >>I have no idea how this work, but it sounds that there are some >>properties on the overlays that points to position in a buffer. I guess >>these are markers. Then maybe a check if the marker points to the base >>buffer could be made just before use? Or perhaps that will be too slow? > [ ... ] > > >I did an experiment. I pulled up a simple C++ file, and cloned it. I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer. > >I then ran: > >C-u M-x bovinate RET > >to reparse. Now this throws away all the tag information, and reparses. The new tag was not `eq', and also did not have buffer file names associated with it. > >I suspect the "fix" is going to be easy. First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse. Semantic will take care of the rest later, and have all the tags marked correctly. I don't think an unlink/link pass would work since the raw tag data is shared at first. > >There is a spiffy keybinding in senator: > >C-c , / > >which will show you details of the tag under point in the data-debugger so you can navigate the structure. It is very helpful for stuff like this. > >Eric > -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: <kla...@ca...> - 2009-04-16 13:04:43
|
Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)! Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Donnerstag, 16. April 2009 14:32 An: Berndl, Klaus Cc: len...@gm...; ced...@li... Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea When you edit a buffer, Semantic will reparse only the local area. It will recycle the overlay, and splice the new tags into the existing tags list. Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed. I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent. Here is a patch you can try: *** semantic.el.~1.212.~ 2009-03-18 20:46:39.000000000 -0400 --- semantic.el 2009-04-16 08:29:37.000000000 -0400 *************** *** 299,304 **** --- 299,309 ---- (not (semantic-active-p)) (not (run-hook-with-args-until-success 'semantic-inhibit-functions))) + ;; Make sure that if this buffer is cloned, our tags and overlays + ;; don't go along for the ride. + (add-hook 'clone-indirect-buffer-hook + 'semantic-clear-toplevel-cache + nil t) ;; Specify that this function has done it's work. At this point ;; we can consider that semantic is active in this buffer. (setq semantic-new-buffer-fcn-was-run t) ---------- This adds a hook to clear the cache when something is cloned. Please give it a try and let me know how it works. I don't know if this is really the right thing or not. Thanks! Eric >>> <kla...@ca...> seems to think that: >Hi Eric, > >Hmm, sound senseful - al least at first glance... > >On a second glance i want to point to the most recent posting i sent to >you - this one, where i describe what happens after editing tags in the >*indirect-buffer*... How does this behavior match your findings you >describe below?! > >But maybe you are right and fixing one small underlying problem-source >in semantic fixes all other misbehaviors too.. But currently i'm >slightly pessimistic ;-) > >Ciao, >Klaus > >-----Ursprüngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Donnerstag, 16. April 2009 13:21 >An: Lennart Borgman >Cc: Berndl, Klaus; ced...@li... >Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect >buffers? -some more findings and a solution idea > >>>> Lennart Borgman <len...@gm...> seems to think that: >>On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: >>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... >> >>I have no idea how this work, but it sounds that there are some >>properties on the overlays that points to position in a buffer. I >>guess these are markers. Then maybe a check if the marker points to >>the base buffer could be made just before use? Or perhaps that will be too slow? > [ ... ] > > >I did an experiment. I pulled up a simple C++ file, and cloned it. I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer. > >I then ran: > >C-u M-x bovinate RET > >to reparse. Now this throws away all the tag information, and reparses. The new tag was not `eq', and also did not have buffer file names associated with it. > >I suspect the "fix" is going to be easy. First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse. Semantic will take care of the rest later, and have all the tags marked correctly. I don't think an unlink/link pass would work since the raw tag data is shared at first. > >There is a spiffy keybinding in senator: > >C-c , / > >which will show you details of the tag under point in the data-debugger so you can navigate the structure. It is very helpful for stuff like this. > >Eric > -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Lennart B. <len...@gm...> - 2009-04-16 13:27:48
|
On Thu, Apr 16, 2009 at 3:04 PM, <kla...@ca...> wrote: > Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)! 2008-02-12 Stefan Monnier <mo...@ir...> * simple.el (clone-indirect-buffer-hook): New hook. |
From: <kla...@ca...> - 2009-04-16 13:44:38
|
Hmm, IMHO cedet should be based on features of Emacs not contained in the official release! AFAIK Emacs 22.3.1 is still the official release and this one doesn't have this new hook! BTW: XEmacs doesn't have any clone-indirect-stuff - just make-indirect-buffer ... So what about the compatibility of cedet?! IMHO the importance of XEmacs goes south...... ;-) but cedet should be compatible at least with official releases of Gnu Emacs... Klaus -----Ursprüngliche Nachricht----- Von: Lennart Borgman [mailto:len...@gm...] Gesendet: Donnerstag, 16. April 2009 15:28 An: Berndl, Klaus Cc: er...@si...; ced...@li... Betreff: Re: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea On Thu, Apr 16, 2009 at 3:04 PM, <kla...@ca...> wrote: > Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)! 2008-02-12 Stefan Monnier <mo...@ir...> * simple.el (clone-indirect-buffer-hook): New hook. |
From: <kla...@ca...> - 2009-04-16 13:48:15
|
Should be: "... IMHO cedet should NOT be based on..." -----Ursprüngliche Nachricht----- Von: kla...@ca... [mailto:kla...@ca...] Gesendet: Donnerstag, 16. April 2009 15:42 An: len...@gm... Cc: ced...@li...; er...@si... Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea Hmm, IMHO cedet should be based on features of Emacs not contained in the official release! AFAIK Emacs 22.3.1 is still the official release and this one doesn't have this new hook! BTW: XEmacs doesn't have any clone-indirect-stuff - just make-indirect-buffer ... So what about the compatibility of cedet?! IMHO the importance of XEmacs goes south...... ;-) but cedet should be compatible at least with official releases of Gnu Emacs... Klaus -----Ursprüngliche Nachricht----- Von: Lennart Borgman [mailto:len...@gm...] Gesendet: Donnerstag, 16. April 2009 15:28 An: Berndl, Klaus Cc: er...@si...; ced...@li... Betreff: Re: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea On Thu, Apr 16, 2009 at 3:04 PM, <kla...@ca...> wrote: > Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)! 2008-02-12 Stefan Monnier <mo...@ir...> * simple.el (clone-indirect-buffer-hook): New hook. ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Cedet-devel mailing list Ced...@li... https://lists.sourceforge.net/lists/listinfo/cedet-devel |
From: <kla...@ca...> - 2009-04-16 12:10:25
|
After playing a little bit i found other very mysterious behaviors: 1. Start Emacs with semantic activated and load a elisp file X 2. Go to a tag T (e.g. a defun) 3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X 4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> 5. Go to the same tag T as in step 2 6. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X well, we know already this failure, but now lets go further 7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument to the defun, if T is a defun) 8. Do M-: (semantic-current-tag) --> semantic returns the repares tag T with the new informations, fine! 9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the reparsed tag T with new informations but still the wrong buffer X Well, same failure as after 6, but now it gets crazy 10. Now edit tag T in the indirect-buffer X<2>!! (e.g. remove the newly added argument from step 7) - do not save! 11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations but still the wrong buffer X 12. Switch back to buffer X (the base buffer) and move point to tag T 13: do M-: (semantic-current-tag) --> you get.................................... nil!! No tag T anymore in the base buffer after editing tag T in the indirect buffer..... Again: With current semantic working with indirect buffers yields to unpredictable side-effects. So either the users should get a warning not to work with indirect buffers and semantic or semantic should be fixed with that respect... Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Lennart Borgman [mailto:len...@gm...] Gesendet: Donnerstag, 16. April 2009 12:33 An: Berndl, Klaus Cc: er...@si...; ced...@li... Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings and a solution idea On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: > A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... I have no idea how this work, but it sounds that there are some properties on the overlays that points to position in a buffer. I guess these are markers. Then maybe a check if the marker points to the base buffer could be made just before use? Or perhaps that will be too slow? |
From: <kla...@ca...> - 2009-04-16 15:33:40
|
Hi all, Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results: 1. Start Emacs with semantic activated and load a elisp file X 2. Go to a tag T (e.g. a defun) 3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X 4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> 5. Go to the same tag T as in step 2 6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine! 7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun) 8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine! 9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2> 10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save! 11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer X<2> 12. Switch back to buffer X (the base buffer) and move point to tag T 13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X Summary: With this patch the indirect-buffer has the right buffer-information, which is good. Then the tag-lists seems to be completely independent, so editing one buffer does not influence not the other one - which is also good! What i'm wondering why running semantic-current-tag does not automatically return the newly reparsed tag but the old one (i assume from the semantic tag-cache) - see steps 9. and 13. above... Is this a correct behavior? The charme of indirect buffers is that editing takes effect in the base-buffer an all related indirect buffers: so if i edit (en edition which triggers a reparse!) a tag e.g. the base-buffer then the changes are also in the indirect-buffer so i would expect that when switching to the indirect-buffer (as in step 9) then semantic should recognize that also this buffer has been changed and therefore automatically reparse when i call semantic-curre3nt-tag (as is done in step 8 above)... Why does this not work? Is this because the tag-cache of semantic is file-centric? Or have i misunderstood something?? Conclusion: Eric's patch seems to be a great step forward but not perfect... ;-) Thansk for your help! Klaus -----Ursprüngliche Nachricht----- Von: kla...@ca... [mailto:kla...@ca...] Gesendet: Donnerstag, 16. April 2009 14:10 An: len...@gm... Cc: ced...@li...; er...@si... Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea After playing a little bit i found other very mysterious behaviors: 1. Start Emacs with semantic activated and load a elisp file X 2. Go to a tag T (e.g. a defun) 3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X 4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> 5. Go to the same tag T as in step 2 6. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X well, we know already this failure, but now lets go further 7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument to the defun, if T is a defun) 8. Do M-: (semantic-current-tag) --> semantic returns the repares tag T with the new informations, fine! 9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the reparsed tag T with new informations but still the wrong buffer X Well, same failure as after 6, but now it gets crazy 10. Now edit tag T in the indirect-buffer X<2>!! (e.g. remove the newly added argument from step 7) - do not save! 11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations but still the wrong buffer X 12. Switch back to buffer X (the base buffer) and move point to tag T 13: do M-: (semantic-current-tag) --> you get.................................... nil!! No tag T anymore in the base buffer after editing tag T in the indirect buffer..... Again: With current semantic working with indirect buffers yields to unpredictable side-effects. So either the users should get a warning not to work with indirect buffers and semantic or semantic should be fixed with that respect... Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Lennart Borgman [mailto:len...@gm...] Gesendet: Donnerstag, 16. April 2009 12:33 An: Berndl, Klaus Cc: er...@si...; ced...@li... Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings and a solution idea On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: > A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... I have no idea how this work, but it sounds that there are some properties on the overlays that points to position in a buffer. I guess these are markers. Then maybe a check if the marker points to the base buffer could be made just before use? Or perhaps that will be too slow? ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Cedet-devel mailing list Ced...@li... https://lists.sourceforge.net/lists/listinfo/cedet-devel |
From: Eric M. L. <er...@si...> - 2009-04-16 15:47:32
|
>>> <kla...@ca...> seems to think that: >Hi all, > >Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results: > >1. Start Emacs with semantic activated and load a elisp file X >2. Go to a tag T (e.g. a defun) >3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X >4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> >5. Go to the same tag T as in step 2 >6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine! > >7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun) >8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine! >9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2> > >10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save! >11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer X<2> >12. Switch back to buffer X (the base buffer) and move point to tag T >13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X > >Summary: With this patch the indirect-buffer has the right >buffer-information, which is good. Then the tag-lists seems to be >completely independent, so editing one buffer does not influence not >the other one - which is also good! > >What i'm wondering why running semantic-current-tag does not >automatically return the newly reparsed tag but the old one (i assume >from the semantic tag-cache) - see steps 9. and 13. above... Is this >a correct behavior? The charme of indirect buffers is that editing >takes effect in the base-buffer an all related indirect buffers: so >if i edit (en edition which triggers a reparse!) a tag e.g. the >base-buffer then the changes are also in the indirect-buffer so i >would expect that when switching to the indirect-buffer (as in step >9) then semantic should recognize that also this buffer has been >changed and therefore automatically reparse when i call >semantic-curre3nt-tag (as is done in step 8 above)... > >Why does this not work? Is this because the tag-cache of semantic is >file-centric? Or have i misunderstood something?? The command `semantic-current-tag', like many very basic commands, do not request a reparse. Reparses are requested by top-level commands before they call utility functions. This saves time since a single top-level command might call hundreds of low-level commands. Each one does not need to do the reparse duties. In particular, utilities like SRecode which edits buffers wants to be in control of when a buffer is reparsed, in case it is only part-way through a code-creation function when it needs to call some utility. Use the senator command `senator-adebug-tag' which will do the reparse for you. Or you can wait 3 seconds, and the idle timer will clean everything up for you. Does that help? Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: <kla...@ca...> - 2009-04-16 16:50:16
|
Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not? To be clear: If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag. Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-) Is this ok too for you? Why? Thanks Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Donnerstag, 16. April 2009 17:47 An: Berndl, Klaus Cc: Berndl, Klaus; len...@gm...; ced...@li... Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea >>> <kla...@ca...> seems to think that: >Hi all, > >Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results: > >1. Start Emacs with semantic activated and load a elisp file X >2. Go to a tag T (e.g. a defun) >3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X >4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> >5. Go to the same tag T as in step 2 >6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine! > >7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun) >8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine! >9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2> > >10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save! >11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer X<2> >12. Switch back to buffer X (the base buffer) and move point to tag T >13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X > >Summary: With this patch the indirect-buffer has the right >buffer-information, which is good. Then the tag-lists seems to be >completely independent, so editing one buffer does not influence not >the other one - which is also good! > >What i'm wondering why running semantic-current-tag does not >automatically return the newly reparsed tag but the old one (i assume >from the semantic tag-cache) - see steps 9. and 13. above... Is this >a correct behavior? The charme of indirect buffers is that editing >takes effect in the base-buffer an all related indirect buffers: so >if i edit (en edition which triggers a reparse!) a tag e.g. the >base-buffer then the changes are also in the indirect-buffer so i >would expect that when switching to the indirect-buffer (as in step >9) then semantic should recognize that also this buffer has been >changed and therefore automatically reparse when i call >semantic-curre3nt-tag (as is done in step 8 above)... > >Why does this not work? Is this because the tag-cache of semantic is >file-centric? Or have i misunderstood something?? The command `semantic-current-tag', like many very basic commands, do not request a reparse. Reparses are requested by top-level commands before they call utility functions. This saves time since a single top-level command might call hundreds of low-level commands. Each one does not need to do the reparse duties. In particular, utilities like SRecode which edits buffers wants to be in control of when a buffer is reparsed, in case it is only part-way through a code-creation function when it needs to call some utility. Use the senator command `senator-adebug-tag' which will do the reparse for you. Or you can wait 3 seconds, and the idle timer will clean everything up for you. Does that help? Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2009-04-16 17:50:08
|
Ah, I think I understand better. It appears that the hooks I use to track edits don't work in linked buffers. If you enable global-semantic-highlight-edits-mode, you will see that it finds things you edit, but the mirror edits in the other linked buffers do not get their change hooks run, and thus you don't see the highlight. I suppose I could look for all buffers that are linked together and propagate the change. That seems kind of unpleasant as I can find no function to get that info. I don't think an after-change-function should be looping over every buffer looking for indirect buffers associated with it. That sounds painfully slow. Eric >>> <kla...@ca...> seems to think that: >Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not? > >To be clear: >If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag. >Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-) > >Is this ok too for you? Why? > >Thanks >Klaus > >-----Ursprüngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Donnerstag, 16. April 2009 17:47 >An: Berndl, Klaus >Cc: Berndl, Klaus; len...@gm...; ced...@li... >Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea > >>>> <kla...@ca...> seems to think that: >>Hi all, >> >>Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results: >> >>1. Start Emacs with semantic activated and load a elisp file X >>2. Go to a tag T (e.g. a defun) >>3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X >>4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> >>5. Go to the same tag T as in step 2 >>6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine! >> >>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun) >>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine! >>9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffeer X<2> >> >>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save! >>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer X<2> >>12. Switch back to buffer X (the base buffer) and move point to tag T >>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X >> >>Summary: With this patch the indirect-buffer has the right >>buffer-information, which is good. Then the tag-lists seems to be >>completely independent, so editing one buffer does not influence not >>the other one - which is also good! >> >>What i'm wondering why running semantic-current-tag does not >>automatically return the newly reparsed tag but the old one (i assume >>from the semantic tag-cache) - see steps 9. and 13. above... Is this >>a correct behavior? The charme of indirect buffers is that editing >>takes effect in the base-buffer an all related indirect buffers: so >>if i edit (en edition which triggers a reparse!) a tag e.g. the >>base-buffer then the changes are also in the indirect-buffer so i >>would expect that when switching to the indirect-buffer (as in step >>9) then semantic should recognize that also this buffer has been >>changed and therefore automatically reparse when i call >>semantic-curre3nt-tag (as is done in step 8 above)... >> >>Why does this not work? Is this because the tag-cache of semantic is >>file-centric? Or have i misunderstood something?? > >The command `semantic-current-tag', like many very basic commands, do >not request a reparse. Reparses are requested by top-level commands >before they call utility functions. This saves time since a single >top-level command might call hundreds of low-level commands. Each one >does not need to do the reparse duties. In particular, utilities like >SRecode which edits buffers wants to be in control of when a buffer is >reparsed, in case it is only part-way through a code-creation function >when it needs to call some utility. > >Use the senator command `senator-adebug-tag' which will do the reparse >for you. Or you can wait 3 seconds, and the idle timer will clean >everything up for you. > >Does that help? > >Eric > |
From: <kla...@ca...> - 2009-04-16 20:36:36
|
Yep, i agree - this is nothing which should be added to a after-change-function... The logic is easy, ECB has already somehting: (defun ecb-indirect-buffers-of-buffer (&optional buffer-or-name) (let ((buffer (if (null buffer-or-name) (current-buffer) (if (and (bufferp buffer-or-name) (buffer-live-p buffer-or-name)) buffer-or-name (if (stringp buffer-or-name) (get-buffer buffer-or-name)))))) (delq nil (mapcar (function (lambda (buf) (if (equal buffer (buffer-base-buffer buf)) buf))) (buffer-list))))) but within ECB this is only used on demand and then run only once... Hmm, currently i'm at a loss with this... do not good enough the internal mechanisms of semantic... maybe this is something to be ask the Emacs-gurus - in general Emacs must already have a linkage between all these related buffers because if you kill the base-buffer then all indirect-buffers of it are killed automatically too... IMHO this propagation of hooks-running should be done internally be Emacs...what do you think? Should we file a problem-report to the emacs-devel-group? Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Do 16.04.2009 19:49 An: Berndl, Klaus Cc: ced...@li... Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea Ah, I think I understand better. It appears that the hooks I use to track edits don't work in linked buffers. If you enable global-semantic-highlight-edits-mode, you will see that it finds things you edit, but the mirror edits in the other linked buffers do not get their change hooks run, and thus you don't see the highlight. I suppose I could look for all buffers that are linked together and propagate the change. That seems kind of unpleasant as I can find no function to get that info. I don't think an after-change-function should be looping over every buffer looking for indirect buffers associated with it. That sounds painfully slow. Eric >>> <kla...@ca...> seems to think that: >Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not? > >To be clear: >If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag. >Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-) > >Is this ok too for you? Why? > >Thanks >Klaus > >-----Ursprüngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Donnerstag, 16. April 2009 17:47 >An: Berndl, Klaus >Cc: Berndl, Klaus; len...@gm...; ced...@li... >Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea > >>>> <kla...@ca...> seems to think that: >>Hi all, >> >>Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results: >> >>1. Start Emacs with semantic activated and load a elisp file X >>2. Go to a tag T (e.g. a defun) >>3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X >>4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> >>5. Go to the same tag T as in step 2 >>6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine! >> >>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun) >>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine! >>9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2> >> >>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save! >>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer X<2> >>12. Switch back to buffer X (the base buffer) and move point to tag T >>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X >> >>Summary: With this patch the indirect-buffer has the right >>buffer-information, which is good. Then the tag-lists seems to be >>completely independent, so editing one buffer does not influence not >>the other one - which is also good! >> >>What i'm wondering why running semantic-current-tag does not >>automatically return the newly reparsed tag but the old one (i assume >>from the semantic tag-cache) - see steps 9. and 13. above... Is this >>a correct behavior? The charme of indirect buffers is that editing >>takes effect in the base-buffer an all related indirect buffers: so >>if i edit (en edition which triggers a reparse!) a tag e.g. the >>base-buffer then the changes are also in the indirect-buffer so i >>would expect that when switching to the indirect-buffer (as in step >>9) then semantic should recognize that also this buffer has been >>changed and therefore automatically reparse when i call >>semantic-curre3nt-tag (as is done in step 8 above)... >> >>Why does this not work? Is this because the tag-cache of semantic is >>file-centric? Or have i misunderstood something?? > >The command `semantic-current-tag', like many very basic commands, do >not request a reparse. Reparses are requested by top-level commands >before they call utility functions. This saves time since a single >top-level command might call hundreds of low-level commands. Each one >does not need to do the reparse duties. In particular, utilities like >SRecode which edits buffers wants to be in control of when a buffer is >reparsed, in case it is only part-way through a code-creation function >when it needs to call some utility. > >Use the senator command `senator-adebug-tag' which will do the reparse >for you. Or you can wait 3 seconds, and the idle timer will clean >everything up for you. > >Does that help? > >Eric > |
From: Eric M. L. <er...@si...> - 2009-04-16 21:36:40
|
It is unclear to me exactly what the rules might be for such a thing. For semantic, the minimum would be as you suggest below for finding all the indirect buffers in a fast way. (I think you can use 'eq' instead of 'equal' BTW.) At a minimum, a super-fast way of knowing if a particular buffer has at least one indirect buffer would be ok too. It's the no-indirects anywhere problem that needs to be resolved. I could certainly build a framework and do all the tracking myself, but I'd need that hook fcn since the system I put together for the patch will have a potential 3 second delay before it takes effect. Propagating change-hook calling as a part of Emacs could be a bit hazardous. Many change hooks might be redisplaying interactive things, and assume that they are called in the current buffer the focus is in. That could get a bit wacky. Eric >>> <kla...@ca...> seems to think that: >Yep, i agree - this is nothing which should be added to a = >after-change-function... > >The logic is easy, ECB has already somehting: > >(defun ecb-indirect-buffers-of-buffer (&optional buffer-or-name) > (let ((buffer (if (null buffer-or-name) > (current-buffer) > (if (and (bufferp buffer-or-name) > (buffer-live-p buffer-or-name)) > buffer-or-name > (if (stringp buffer-or-name) > (get-buffer buffer-or-name)))))) > (delq nil (mapcar (function > (lambda (buf) > (if (equal buffer (buffer-base-buffer buf)) > buf))) > (buffer-list))))) > >but within ECB this is only used on demand and then run only once... > >Hmm, currently i'm at a loss with this... do not good enough the = >internal mechanisms of semantic... maybe this is something to be ask the = >Emacs-gurus - in general Emacs must already have a linkage between all = >these related buffers because if you kill the base-buffer then all = >indirect-buffers of it are killed automatically too... > >IMHO this propagation of hooks-running should be done internally be = >Emacs...what do you think? Should we file a problem-report to the = >emacs-devel-group? > >Ciao, >Klaus > >-----Urspr=FCngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Do 16.04.2009 19:49 >An: Berndl, Klaus >Cc: ced...@li... >Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with = >indirectbuffers?-some more findings and a solution idea >=20 >Ah, I think I understand better. > >It appears that the hooks I use to track edits don't work in linked >buffers. If you enable global-semantic-highlight-edits-mode, you will >see that it finds things you edit, but the mirror edits in the other >linked buffers do not get their change hooks run, and thus you don't >see the highlight. > >I suppose I could look for all buffers that are linked together and >propagate the change. That seems kind of unpleasant as I can find no >function to get that info. I don't think an after-change-function >should be looping over every buffer looking for indirect buffers >associated with it. That sounds painfully slow. > >Eric > >>>> <kla...@ca...> seems to think that: >>Hmm, i know all this you explained to me - i.e. i know that = >semantic-current-tag does not trigger a parse-run - but nevertheless the = >indirect changed indirectbuffer (means changes has been done via the = >base-buffer) is not parsed - the idle-triggered reparse takes not place = >- this is what i'm wondering, why not? >> >>To be clear: >>If i change a tag in a base-buffer, than here the buffer is reparsed = >after 3 seconds and semantic-current-tag returns the modified tag. >>Such a change influences all indirect-buffers of the base buffer - but = >when i switch to one of these indirect buffers then no reparse takes = >place, not after 3 sec and not after 3000 sec ;-)=20 >> >>Is this ok too for you? Why? >> >>Thanks >>Klaus >> >>-----Urspr=FCngliche Nachricht----- >>Von: Eric M. Ludlam [mailto:er...@si...]=20 >>Gesendet: Donnerstag, 16. April 2009 17:47 >>An: Berndl, Klaus >>Cc: Berndl, Klaus; len...@gm...; ced...@li... >>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect = >buffers?-some more findings and a solution idea >> >>>>> <kla...@ca...> seems to think that: >>>Hi all, >>> >>>Well, i have just modified the clone-indirect-buffer - command in my = >Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i = >have applied Eric's patch which uses this new hook and then tested the = >scenario below - here are the results: >>> >>>1. Start Emacs with semantic activated and load a elisp file X >>>2. Go to a tag T (e.g. a defun) >>>3. Do M-: (semantic-current-tag) --> this will return the tag T with = >buffer object X >>>4. Call M-x clone-indirect-buffer RET --> this will popup a new = >indirect buffer X<2> >>>5. Go to the same tag T as in step 2 >>>6. Do M-: (semantic-current-tag) --> this will now return the tag T = >with correct buffer X<2> and not - as before the patch - buffer object X = >--> fine! >>> >>>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add = >a new argument iii to the defun, if T is a defun) >>>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag = >T with the new informations (here iii as new argument, fine! >>>9. Switch to buffer X<2> (the indirect buffer) and do M-: = >(semantic-current-tag) --> you get the NOT(!) reparsed tag T with old = >informations (here without the new argument iii) but now with the = >correct buffer X<2> >>> >>>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another = >argument jjj) - do not save! >>>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with = >again new informations and still the correct buffer X<2> >>>12. Switch back to buffer X (the base buffer) and move point to tag T >>>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T = >with old informations (ie. Without new argument jjj) but with correct = >buffer X >>> >>>Summary: With this patch the indirect-buffer has the right >>>buffer-information, which is good. Then the tag-lists seems to be >>>completely independent, so editing one buffer does not influence not >>>the other one - which is also good! >>> >>>What i'm wondering why running semantic-current-tag does not >>>automatically return the newly reparsed tag but the old one (i assume >>>from the semantic tag-cache) - see steps 9. and 13. above... Is this >>>a correct behavior? The charme of indirect buffers is that editing >>>takes effect in the base-buffer an all related indirect buffers: so >>>if i edit (en edition which triggers a reparse!) a tag e.g. the >>>base-buffer then the changes are also in the indirect-buffer so i >>>would expect that when switching to the indirect-buffer (as in step >>>9) then semantic should recognize that also this buffer has been >>>changed and therefore automatically reparse when i call >>>semantic-curre3nt-tag (as is done in step 8 above)... >>> >>>Why does this not work? Is this because the tag-cache of semantic is >>>file-centric? Or have i misunderstood something?? >> >>The command `semantic-current-tag', like many very basic commands, do >>not request a reparse. Reparses are requested by top-level commands >>before they call utility functions. This saves time since a single >>top-level command might call hundreds of low-level commands. Each one >>does not need to do the reparse duties. In particular, utilities like >>SRecode which edits buffers wants to be in control of when a buffer is >>reparsed, in case it is only part-way through a code-creation function >>when it needs to call some utility. >> >>Use the senator command `senator-adebug-tag' which will do the reparse >>for you. Or you can wait 3 seconds, and the idle timer will clean >>everything up for you. >> >>Does that help? >> >>Eric >> > > |
From: Lennart B. <len...@gm...> - 2009-04-16 23:22:27
|
On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <er...@si...> wrote: > Propagating change-hook calling as a part of Emacs could be a bit > hazardous. Many change hooks might be redisplaying interactive > things, and assume that they are called in the current buffer the > focus is in. That could get a bit wacky. Aren't the change hooks run in the indirect buffers too? |
From: <kla...@ca...> - 2009-04-17 05:25:46
|
Hi guys, first a definition: let us name all buffers having an indirect-buffer-relationship among each other as a 'indirect buffer set' - this includes exactly one file-based base-buffer and an arbitrary number of indirect-buffers to this base-buffer... after fixing a very small bug in ECB i found that it could be sufficient to detect: a) has the current active buffer switched by the user (e.g. by switching window, buffer etc...), i.e. is now another buffer current compared to the last run of this check b) is the buffer switch within a 'indirect-buffer-set (hmm, have not thinked in depth about this...maybe this check is not necessary or even forbidden?! c) has been one of the buffers of the indirect-buffer-set changed / reparsed etc... If a, b and c are all true then clear the toplevel cache of semantic and fetch the tags ==> this will return the right tag-set containing all changes previously made in another buffer of the indirect-buffer-set. Encapsulate this in an idle-function which runs e.e. each second and checks a - c (s.a.) - at least a is very fast checkable (ECB does this already for its own sake) - so when editing in a buffer a) always fails and therefore no checks for b and c are necessary ==> no performance lack... E.g. see `ecb-basic-buffer-sync' - search for "(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in ecb-file-browser.el (CVS-version) which already checks condition a. Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i sent to you). Condition c: Hmm, do not know exactly what is here necessary - maybe it is already enough to check if that buffer has changed which was previous before switching to the current one [a) compares already these two]?! Eric. Lennart, you are the semantic guys, i'm sure you know a solution for c) ;-) Summary: With such a mechanism no realtime-propagation is needed during editing a buffer etc.. the only thing a user wants is, that when he edits a buffer of a indirect-buffer-set (see definition at beginning) and he later switch to another buffer of this set then this other buffer should be automatically be reparsed to reflect (e.g. this means in ECB: display) the correct tag-set (including the changes made in the other buffer of the indirect-buffer-set)... For a user it's equal if the tag-info-changes in one buffer of an indirect-buffer-set are immediately propagated to all other buffers of such a buffer-set, he only wants to get the right tag-set when he *activate* another buffer of the buffer-set! Well, now a short question: Was my description understandable for you? Sometimes it's not easy for me being as precise and clear as necessary when writing in english ;-) In general I'm now quite optimistic that there can be found a solution for the problem without performance-issues.... and without two much effort to implement ;-) Thoughts? Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Fr 17.04.2009 05:41 An: Lennart Borgman Cc: Berndl, Klaus; ced...@li... Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea >>> Lennart Borgman <len...@gm...> seems to think that: >On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <er...@si...> wrote: >> Propagating change-hook calling as a part of Emacs could be a bit >> hazardous. Many change hooks might be redisplaying interactive >> things, and assume that they are called in the current buffer the >> focus is in. That could get a bit wacky. > >Aren't the change hooks run in the indirect buffers too? Yes, but only when the indirect buffer is the current buffer. Or so it seems the way I'm using it. An edit in one buffer does not trigger my hooks in the other buffers to run. I've only been able to run some simple experiments, so I don't know in any great detail hat is going on. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2009-04-17 12:11:24
|
CEDET/Semantic will track tiny changes in a buffer based on the after-change-functions. Those changes are just noted with overlays. Once Semantic goes to update the tags in the buffer, it takes these overlays, and merges them together to find out which tags changed. It will then reparse those text units, and splices the results into the original list, attempting to keep as much of the old structure as possible. As the indirect buffer might be in a different mode, and have a completely different parser, all changes in it must be tracked as completely separate and reparsed completely separately. So long as Emacs doesn't propagate the calls to the change function, we'd need to do that propagation of change ourselves. If, as you suggest, you can quickly get the list of linked buffers, this should be ok to do in the change hook. I don't know if propagating the changes later will help in this case. Just the notification is not enough since I need all the data of location as well. Eric >>> <kla...@ca...> seems to think that: >Hi guys, > >first a definition: let us name all buffers having an = >indirect-buffer-relationship among each other as a 'indirect buffer set' = >- this includes exactly one file-based base-buffer and an arbitrary = >number of indirect-buffers to this base-buffer... > >after fixing a very small bug in ECB i found that it could be sufficient = >to detect: >a) has the current active buffer switched by the user (e.g. by switching = >window, buffer etc...), i.e. is now another buffer current compared to = >the last run of this check >b) is the buffer switch within a 'indirect-buffer-set (hmm, have not = >thinked in depth about this...maybe this check is not necessary or even = >forbidden?! >c) has been one of the buffers of the indirect-buffer-set changed / = >reparsed etc... > >If a, b and c are all true then clear the toplevel cache of semantic and = >fetch the tags =3D=3D> this will return the right tag-set containing all = >changes previously made in another buffer of the indirect-buffer-set. > >Encapsulate this in an idle-function which runs e.e. each second and = >checks a - c (s.a.) - at least a is very fast checkable (ECB does this = >already for its own sake) - so when editing in a buffer a) always fails = >and therefore no checks for b and c are necessary =3D=3D> no performance = >lack... > >E.g. see `ecb-basic-buffer-sync' - search for = >"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in = >ecb-file-browser.el (CVS-version) which already checks condition a. >Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i = >sent to you). >Condition c: Hmm, do not know exactly what is here necessary - maybe it = >is already enough to check if that buffer has changed which was previous = >before switching to the current one [a) compares already these two]?! = >Eric. Lennart, you are the semantic guys, i'm sure you know a solution = >for c) ;-) > >Summary: With such a mechanism no realtime-propagation is needed during = >editing a buffer etc.. the only thing a user wants is, that when he = >edits a buffer of a indirect-buffer-set (see definition at beginning) = >and he later switch to another buffer of this set then this other buffer = >should be automatically be reparsed to reflect (e.g. this means in ECB: = >display) the correct tag-set (including the changes made in the other = >buffer of the indirect-buffer-set)... For a user it's equal if the = >tag-info-changes in one buffer of an indirect-buffer-set are immediately = >propagated to all other buffers of such a buffer-set, he only wants to = >get the right tag-set when he *activate* another buffer of the = >buffer-set! > >Well, now a short question: Was my description understandable for you? = >Sometimes it's not easy for me being as precise and clear as necessary = >when writing in english ;-) > >In general I'm now quite optimistic that there can be found a solution = >for the problem without performance-issues.... and without two much = >effort to implement ;-) > >Thoughts? >Klaus > > >-----Urspr=FCngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Fr 17.04.2009 05:41 >An: Lennart Borgman >Cc: Berndl, Klaus; ced...@li... >Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with = >indirectbuffers?-some more findings and a solution idea >=20 >>>> Lennart Borgman <len...@gm...> seems to think that: >>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam = ><er...@si...> wrote: >>> Propagating change-hook calling as a part of Emacs could be a bit >>> hazardous. =A0Many change hooks might be redisplaying interactive >>> things, and assume that they are called in the current buffer the >>> focus is in. =A0That could get a bit wacky. >> >>Aren't the change hooks run in the indirect buffers too? > >Yes, but only when the indirect buffer is the current buffer. Or so >it seems the way I'm using it. An edit in one buffer does not trigger >my hooks in the other buffers to run. > >I've only been able to run some simple experiments, so I don't know >in any great detail hat is going on. > >Eric > >--=20 > Eric Ludlam: er...@si... > Siege: www.siege-engine.com Emacs: = >http://cedet.sourceforge.net > > |
From: <kla...@ca...> - 2009-04-17 13:41:34
|
Yes, of course - the "full"-featured solution should do what you describe... BUT my suggestion was another one: at least we should ensure that an "indirectly" changed buffer (ie. changed via editing another buffer in the indirect-buffer-set) will be reparsed when this buffer becomes current for the user(!). IMHO for a first solution it would be sufficient to completely clear the tag-cache, so afterwards the buffer will be automatically fully reparsed ad all tags are uptodate... This can of course not use your incremental parsing mechanism you described. But better some full parse-runs as no parsing at all though it would be necessary... Maybe not the gold-medal, but sometimes bronze medal is also not bad - aftre that we can try to reach the gold-medal... Thoughts? Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Freitag, 17. April 2009 14:11 An: Berndl, Klaus Cc: len...@gm...; ced...@li... Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea CEDET/Semantic will track tiny changes in a buffer based on the after-change-functions. Those changes are just noted with overlays. Once Semantic goes to update the tags in the buffer, it takes these overlays, and merges them together to find out which tags changed. It will then reparse those text units, and splices the results into the original list, attempting to keep as much of the old structure as possible. As the indirect buffer might be in a different mode, and have a completely different parser, all changes in it must be tracked as completely separate and reparsed completely separately. So long as Emacs doesn't propagate the calls to the change function, we'd need to do that propagation of change ourselves. If, as you suggest, you can quickly get the list of linked buffers, this should be ok to do in the change hook. I don't know if propagating the changes later will help in this case. Just the notification is not enough since I need all the data of location as well. Eric >>> <kla...@ca...> seems to think that: >Hi guys, > >first a definition: let us name all buffers having an = >indirect-buffer-relationship among each other as a 'indirect buffer >set' = >- this includes exactly one file-based base-buffer and an arbitrary = >number of indirect-buffers to this base-buffer... > >after fixing a very small bug in ECB i found that it could be >sufficient = to detect: >a) has the current active buffer switched by the user (e.g. by >switching = window, buffer etc...), i.e. is now another buffer current >compared to = the last run of this check >b) is the buffer switch within a 'indirect-buffer-set (hmm, have not = >thinked in depth about this...maybe this check is not necessary or even >= forbidden?! >c) has been one of the buffers of the indirect-buffer-set changed / = >reparsed etc... > >If a, b and c are all true then clear the toplevel cache of semantic >and = fetch the tags =3D=3D> this will return the right tag-set >containing all = changes previously made in another buffer of the indirect-buffer-set. > >Encapsulate this in an idle-function which runs e.e. each second and = >checks a - c (s.a.) - at least a is very fast checkable (ECB does this >= already for its own sake) - so when editing in a buffer a) always >fails = and therefore no checks for b and c are necessary =3D=3D> no >performance = lack... > >E.g. see `ecb-basic-buffer-sync' - search for = >"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in = >ecb-file-browser.el (CVS-version) which already checks condition a. >Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i >= sent to you). >Condition c: Hmm, do not know exactly what is here necessary - maybe it >= is already enough to check if that buffer has changed which was >previous = before switching to the current one [a) compares already >these two]?! = Eric. Lennart, you are the semantic guys, i'm sure you >know a solution = for c) ;-) > >Summary: With such a mechanism no realtime-propagation is needed during >= editing a buffer etc.. the only thing a user wants is, that when he = >edits a buffer of a indirect-buffer-set (see definition at beginning) = >and he later switch to another buffer of this set then this other >buffer = should be automatically be reparsed to reflect (e.g. this >means in ECB: = >display) the correct tag-set (including the changes made in the other = >buffer of the indirect-buffer-set)... For a user it's equal if the = >tag-info-changes in one buffer of an indirect-buffer-set are >immediately = propagated to all other buffers of such a buffer-set, he >only wants to = get the right tag-set when he *activate* another buffer >of the = buffer-set! > >Well, now a short question: Was my description understandable for you? >= Sometimes it's not easy for me being as precise and clear as >necessary = when writing in english ;-) > >In general I'm now quite optimistic that there can be found a solution >= for the problem without performance-issues.... and without two much = >effort to implement ;-) > >Thoughts? >Klaus > > >-----Urspr=FCngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Fr 17.04.2009 05:41 >An: Lennart Borgman >Cc: Berndl, Klaus; ced...@li... >Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with = >indirectbuffers?-some more findings and a solution idea =20 >>>> Lennart Borgman <len...@gm...> seems to think that: >>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam = ><er...@si...> wrote: >>> Propagating change-hook calling as a part of Emacs could be a bit >>> hazardous. =A0Many change hooks might be redisplaying interactive >>> things, and assume that they are called in the current buffer the >>> focus is in. =A0That could get a bit wacky. >> >>Aren't the change hooks run in the indirect buffers too? > >Yes, but only when the indirect buffer is the current buffer. Or so it >seems the way I'm using it. An edit in one buffer does not trigger my >hooks in the other buffers to run. > >I've only been able to run some simple experiments, so I don't know in >any great detail hat is going on. > >Eric > >--=20 > Eric Ludlam: er...@si... > Siege: www.siege-engine.com Emacs: = >http://cedet.sourceforge.net > > |
From: <kla...@ca...> - 2009-04-18 09:01:55
|
Well, two points: 1) Now i'm convinced that we should use an advice if there is no hook which runs with BOTH(!) of clone-indirect-buffer and make-indirect-buffer (alos with XEmacs which have only the later one): I have written a small test-avice for make-indirect-buffer which only contains the following code: (save-excursion (set-buffer ad-return-value) (message "return-value: %s, Cur-buffer: %s, base-buffer: %s" ad-return-value (buffer-name) (buffer-base-buffer))) This works well and we see how it works...just replace the message-call with the cache clearing and we are fine... this after advice is save and can not fail so we can do it ... if we are paranoid we could encapsulate in a call to condition-case nil...... ;-) 2) I think i have found a way how to detect very fast the indirect-buffer-set of a buffer without looping each time over the whole buffer list: we do this via the advice above and within kill-buffer-hook! :-) We write a small framework which makes a smart storage of the current indirect-buffer-list of each opened base-buffer, e.g. an alist with key is a base-buffer and value is the list of all related indirect-buffers to the base-buffer... This storage we administrate with the advice of make-indirect-buffer and with kill-buffer-hook so this storage is always up-to-date... Then you can use in your after-change-function this indirect-buffer-storage to propagate... shouldbe fast because we can use `eq' and buffer-objects... if still to slow we could add a further alist which contains an entry for each(!) current opened file-buffer (regardless if a base- or an indirect one), and car is a buffer-object and cdr is the base-buffer for this buffer - so we have a two step storage... Thoughts? Ciao, Klaus P.S. see the answer to my emacs-bug-report.... -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Fr 17.04.2009 14:11 An: Berndl, Klaus Cc: len...@gm...; ced...@li... Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea CEDET/Semantic will track tiny changes in a buffer based on the after-change-functions. Those changes are just noted with overlays. Once Semantic goes to update the tags in the buffer, it takes these overlays, and merges them together to find out which tags changed. It will then reparse those text units, and splices the results into the original list, attempting to keep as much of the old structure as possible. As the indirect buffer might be in a different mode, and have a completely different parser, all changes in it must be tracked as completely separate and reparsed completely separately. So long as Emacs doesn't propagate the calls to the change function, we'd need to do that propagation of change ourselves. If, as you suggest, you can quickly get the list of linked buffers, this should be ok to do in the change hook. I don't know if propagating the changes later will help in this case. Just the notification is not enough since I need all the data of location as well. Eric >>> <kla...@ca...> seems to think that: >Hi guys, > >first a definition: let us name all buffers having an = >indirect-buffer-relationship among each other as a 'indirect buffer set' = >- this includes exactly one file-based base-buffer and an arbitrary = >number of indirect-buffers to this base-buffer... > >after fixing a very small bug in ECB i found that it could be sufficient = >to detect: >a) has the current active buffer switched by the user (e.g. by switching = >window, buffer etc...), i.e. is now another buffer current compared to = >the last run of this check >b) is the buffer switch within a 'indirect-buffer-set (hmm, have not = >thinked in depth about this...maybe this check is not necessary or even = >forbidden?! >c) has been one of the buffers of the indirect-buffer-set changed / = >reparsed etc... > >If a, b and c are all true then clear the toplevel cache of semantic and = >fetch the tags =3D=3D> this will return the right tag-set containing all = >changes previously made in another buffer of the indirect-buffer-set. > >Encapsulate this in an idle-function which runs e.e. each second and = >checks a - c (s.a.) - at least a is very fast checkable (ECB does this = >already for its own sake) - so when editing in a buffer a) always fails = >and therefore no checks for b and c are necessary =3D=3D> no performance = >lack... > >E.g. see `ecb-basic-buffer-sync' - search for = >"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in = >ecb-file-browser.el (CVS-version) which already checks condition a. >Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i = >sent to you). >Condition c: Hmm, do not know exactly what is here necessary - maybe it = >is already enough to check if that buffer has changed which was previous = >before switching to the current one [a) compares already these two]?! = >Eric. Lennart, you are the semantic guys, i'm sure you know a solution = >for c) ;-) > >Summary: With such a mechanism no realtime-propagation is needed during = >editing a buffer etc.. the only thing a user wants is, that when he = >edits a buffer of a indirect-buffer-set (see definition at beginning) = >and he later switch to another buffer of this set then this other buffer = >should be automatically be reparsed to reflect (e.g. this means in ECB: = >display) the correct tag-set (including the changes made in the other = >buffer of the indirect-buffer-set)... For a user it's equal if the = >tag-info-changes in one buffer of an indirect-buffer-set are immediately = >propagated to all other buffers of such a buffer-set, he only wants to = >get the right tag-set when he *activate* another buffer of the = >buffer-set! > >Well, now a short question: Was my description understandable for you? = >Sometimes it's not easy for me being as precise and clear as necessary = >when writing in english ;-) > >In general I'm now quite optimistic that there can be found a solution = >for the problem without performance-issues.... and without two much = >effort to implement ;-) > >Thoughts? >Klaus > > >-----Urspr=FCngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Fr 17.04.2009 05:41 >An: Lennart Borgman >Cc: Berndl, Klaus; ced...@li... >Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with = >indirectbuffers?-some more findings and a solution idea >=20 >>>> Lennart Borgman <len...@gm...> seems to think that: >>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam = ><er...@si...> wrote: >>> Propagating change-hook calling as a part of Emacs could be a bit >>> hazardous. =A0Many change hooks might be redisplaying interactive >>> things, and assume that they are called in the current buffer the >>> focus is in. =A0That could get a bit wacky. >> >>Aren't the change hooks run in the indirect buffers too? > >Yes, but only when the indirect buffer is the current buffer. Or so >it seems the way I'm using it. An edit in one buffer does not trigger >my hooks in the other buffers to run. > >I've only been able to run some simple experiments, so I don't know >in any great detail hat is going on. > >Eric > >--=20 > Eric Ludlam: er...@si... > Siege: www.siege-engine.com Emacs: = >http://cedet.sourceforge.net > > |
From: Eric M. L. <er...@si...> - 2009-04-18 12:44:44
|
Hi Klaus, If you replace the message with something that calls the hook we'd like to have, then we won't need to change any code in semantic once the hook is generally available (if ever.) You're other idea is good too with indirect buffer tracking. I will attempt to explain the after-change-function issue as a reply to the other email. Eric >>> <kla...@ca...> seems to think that: >Well, two points: > >1) Now i'm convinced that we should use an advice if there is no hook = >which runs with BOTH(!) of clone-indirect-buffer and = >make-indirect-buffer (alos with XEmacs which have only the later one): > >I have written a small test-avice for make-indirect-buffer which only = >contains the following code: > >(save-excursion > (set-buffer ad-return-value) > (message "return-value: %s, Cur-buffer: %s, base-buffer: %s" > ad-return-value (buffer-name) (buffer-base-buffer))) > >This works well and we see how it works...just replace the message-call = >with the cache clearing and we are fine... this after advice is save and = >can not fail so we can do it ... if we are paranoid we could encapsulate = >in a call to condition-case nil...... ;-) > >2) I think i have found a way how to detect very fast the = >indirect-buffer-set of a buffer without looping each time over the whole = >buffer list: we do this via the advice above and within = >kill-buffer-hook! :-) > >We write a small framework which makes a smart storage of the current = >indirect-buffer-list of each opened base-buffer, e.g. an alist with key = >is a base-buffer and value is the list of all related indirect-buffers = >to the base-buffer... This storage we administrate with the advice of = >make-indirect-buffer and with kill-buffer-hook so this storage is always = >up-to-date... > >Then you can use in your after-change-function this = >indirect-buffer-storage to propagate... shouldbe fast because we can use = >`eq' and buffer-objects... if still to slow we could add a further alist = >which contains an entry for each(!) current opened file-buffer = >(regardless if a base- or an indirect one), and car is a buffer-object = >and cdr is the base-buffer for this buffer - so we have a two step = >storage... > >Thoughts? > >Ciao, >Klaus > >P.S. >see the answer to my emacs-bug-report.... >-----Urspr=FCngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Fr 17.04.2009 14:11 >An: Berndl, Klaus >Cc: len...@gm...; ced...@li... >Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with = >indirectbuffers?-some more findings and a solution idea >=20 >CEDET/Semantic will track tiny changes in a buffer based on the >after-change-functions. Those changes are just noted with overlays. >Once Semantic goes to update the tags in the buffer, it takes these >overlays, and merges them together to find out which tags changed. It >will then reparse those text units, and splices the results into the >original list, attempting to keep as much of the old structure as >possible. > >As the indirect buffer might be in a different mode, and have a >completely different parser, all changes in it must be tracked as >completely separate and reparsed completely separately. > >So long as Emacs doesn't propagate the calls to the change function, >we'd need to do that propagation of change ourselves. If, as you >suggest, you can quickly get the list of linked buffers, this should >be ok to do in the change hook. I don't know if propagating the >changes later will help in this case. Just the notification is not >enough since I need all the data of location as well. > >Eric > > >>>> <kla...@ca...> seems to think that: >>Hi guys, >> >>first a definition: let us name all buffers having an =3D >>indirect-buffer-relationship among each other as a 'indirect buffer = >set' =3D >>- this includes exactly one file-based base-buffer and an arbitrary =3D >>number of indirect-buffers to this base-buffer... >> >>after fixing a very small bug in ECB i found that it could be = >sufficient =3D >>to detect: >>a) has the current active buffer switched by the user (e.g. by = >switching =3D >>window, buffer etc...), i.e. is now another buffer current compared to = >=3D >>the last run of this check >>b) is the buffer switch within a 'indirect-buffer-set (hmm, have not = >=3D >>thinked in depth about this...maybe this check is not necessary or even = >=3D >>forbidden?! >>c) has been one of the buffers of the indirect-buffer-set changed / =3D >>reparsed etc... >> >>If a, b and c are all true then clear the toplevel cache of semantic = >and =3D >>fetch the tags =3D3D=3D3D> this will return the right tag-set = >containing all =3D >>changes previously made in another buffer of the indirect-buffer-set. >> >>Encapsulate this in an idle-function which runs e.e. each second and = >=3D >>checks a - c (s.a.) - at least a is very fast checkable (ECB does this = >=3D >>already for its own sake) - so when editing in a buffer a) always fails = >=3D >>and therefore no checks for b and c are necessary =3D3D=3D3D> no = >performance =3D >>lack... >> >>E.g. see `ecb-basic-buffer-sync' - search for =3D >>"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in =3D >>ecb-file-browser.el (CVS-version) which already checks condition a. >>Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i = >=3D >>sent to you). >>Condition c: Hmm, do not know exactly what is here necessary - maybe it = >=3D >>is already enough to check if that buffer has changed which was = >previous =3D >>before switching to the current one [a) compares already these two]?! = >=3D >>Eric. Lennart, you are the semantic guys, i'm sure you know a solution = >=3D >>for c) ;-) >> >>Summary: With such a mechanism no realtime-propagation is needed during = >=3D >>editing a buffer etc.. the only thing a user wants is, that when he =3D >>edits a buffer of a indirect-buffer-set (see definition at beginning) = >=3D >>and he later switch to another buffer of this set then this other = >buffer =3D >>should be automatically be reparsed to reflect (e.g. this means in ECB: = >=3D >>display) the correct tag-set (including the changes made in the other = >=3D >>buffer of the indirect-buffer-set)... For a user it's equal if the =3D >>tag-info-changes in one buffer of an indirect-buffer-set are = >immediately =3D >>propagated to all other buffers of such a buffer-set, he only wants to = >=3D >>get the right tag-set when he *activate* another buffer of the =3D >>buffer-set! >> >>Well, now a short question: Was my description understandable for you? = >=3D >>Sometimes it's not easy for me being as precise and clear as necessary = >=3D >>when writing in english ;-) >> >>In general I'm now quite optimistic that there can be found a solution = >=3D >>for the problem without performance-issues.... and without two much =3D >>effort to implement ;-) >> >>Thoughts? >>Klaus >> >> >>-----Urspr=3DFCngliche Nachricht----- >>Von: Eric M. Ludlam [mailto:er...@si...] >>Gesendet: Fr 17.04.2009 05:41 >>An: Lennart Borgman >>Cc: Berndl, Klaus; ced...@li... >>Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with =3D >>indirectbuffers?-some more findings and a solution idea >>=3D20 >>>>> Lennart Borgman <len...@gm...> seems to think that: >>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam =3D >><er...@si...> wrote: >>>> Propagating change-hook calling as a part of Emacs could be a bit >>>> hazardous. =3DA0Many change hooks might be redisplaying interactive >>>> things, and assume that they are called in the current buffer the >>>> focus is in. =3DA0That could get a bit wacky. >>> >>>Aren't the change hooks run in the indirect buffers too? >> >>Yes, but only when the indirect buffer is the current buffer. Or so >>it seems the way I'm using it. An edit in one buffer does not trigger >>my hooks in the other buffers to run. >> >>I've only been able to run some simple experiments, so I don't know >>in any great detail hat is going on. >> >>Eric >> >>--=3D20 >> Eric Ludlam: er...@si... >> Siege: www.siege-engine.com Emacs: =3D >>http://cedet.sourceforge.net >> >> > > > -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2009-04-16 13:55:41
|
Ah. I'm using Emacs 23 from CVS. I guess that hook doesn't exist everywhere. Is there a way to do something similar in Emacs 22? (I don't have a copy.) Eric >>> <kla...@ca...> seems to think that: >Hmmmm, thanks for a patch but what is >`clone-indirect-buffer-hook'???? My Emacs doesn't have anything like >this (Gnu Emacs 22.3.1)! > >Ciao, >Klaus > >-----Ursprüngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Donnerstag, 16. April 2009 14:32 >An: Berndl, Klaus >Cc: len...@gm...; ced...@li... >Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea > >When you edit a buffer, Semantic will reparse only the local area. It will recycle the overlay, and splice the new tags into the existing tags list. Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed. > >I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent. > >Here is a patch you can try: > >*** semantic.el.~1.212.~ 2009-03-18 20:46:39.000000000 -0400 >--- semantic.el 2009-04-16 08:29:37.000000000 -0400 >*************** >*** 299,304 **** >--- 299,309 ---- > (not (semantic-active-p)) > (not (run-hook-with-args-until-success > 'semantic-inhibit-functions))) >+ ;; Make sure that if this buffer is cloned, our tags and overlays >+ ;; don't go along for the ride. >+ (add-hook 'clone-indirect-buffer-hook >+ 'semantic-clear-toplevel-cache >+ nil t) > ;; Specify that this function has done it's work. At this point > ;; we can consider that semantic is active in this buffer. > (setq semantic-new-buffer-fcn-was-run t) > > >---------- >This adds a hook to clear the cache when something is cloned. Please give it a try and let me know how it works. I don't know if this is really the right thing or not. > >Thanks! >Eric > >>>> <kla...@ca...> seems to think that: >>Hi Eric, >> >>Hmm, sound senseful - al least at first glance... >> >>On a second glance i want to point to the most recent posting i sent to >>you - this one, where i describe what happens after editing tags in the >>*indirect-buffer*... How does this behavior match your findings you >>describe below?! >> >>But maybe you are right and fixing one small underlying problem-source >>in semantic fixes all other misbehaviors too.. But currently i'm >>slightly pessimistic ;-) >> >>Ciao, >>Klaus >> >>-----Ursprüngliche Nachricht----- >>Von: Eric M. Ludlam [mailto:er...@si...] >>Gesendet: Donnerstag, 16. April 2009 13:21 >>An: Lennart Borgman >>Cc: Berndl, Klaus; ced...@li... >>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect >>buffers? -some more findings and a solution idea >> >>>>> Lennart Borgman <len...@gm...> seems to think that: >>>On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: >>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... >>> >>>I have no idea how this work, but it sounds that there are some >>>properties on the overlays that points to position in a buffer. I >>>guess these are markers. Then maybe a check if the marker points to >>>the base buffer could be made just before use? Or perhaps that will be too slow? >> [ ... ] >> >> >>I did an experiment. I pulled up a simple C++ file, and cloned it. I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer. >> >>I then ran: >> >>C-u M-x bovinate RET >> >>to reparse. Now this throws away all the tag information, and reparses. The new tag was not `eq', and also did not have buffer file names associated with it. >> >>I suspect the "fix" is going to be easy. First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse. Semantic will take care of the rest later, and have all the tags marked correctly. I don't think an unlink/link pass would work since the raw tag data is shared at first. >> >>There is a spiffy keybinding in senator: >> >>C-c , / >> >>which will show you details of the tag under point in the data-debugger so you can navigate the structure. It is very helpful for stuff like this. >> >>Eric >> > |
From: Lennart B. <len...@gm...> - 2009-04-16 14:02:18
|
There is no easy way (except to advice clone-indirect-buffer), but isn't it good enough that it will work in Emacs 23 (which is in pretest currently)? On Thu, Apr 16, 2009 at 3:55 PM, Eric M. Ludlam <er...@si...> wrote: > Ah. I'm using Emacs 23 from CVS. I guess that hook doesn't exist > everywhere. > > Is there a way to do something similar in Emacs 22? (I don't have a > copy.) > > Eric > >>>> <kla...@ca...> seems to think that: >>Hmmmm, thanks for a patch but what is >>`clone-indirect-buffer-hook'???? My Emacs doesn't have anything like >>this (Gnu Emacs 22.3.1)! >> >>Ciao, >>Klaus >> >>-----Ursprüngliche Nachricht----- >>Von: Eric M. Ludlam [mailto:er...@si...] >>Gesendet: Donnerstag, 16. April 2009 14:32 >>An: Berndl, Klaus >>Cc: len...@gm...; ced...@li... >>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea >> >>When you edit a buffer, Semantic will reparse only the local area. It will recycle the overlay, and splice the new tags into the existing tags list. Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed. >> >>I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent. >> >>Here is a patch you can try: >> >>*** semantic.el.~1.212.~ 2009-03-18 20:46:39.000000000 -0400 >>--- semantic.el 2009-04-16 08:29:37.000000000 -0400 >>*************** >>*** 299,304 **** >>--- 299,309 ---- >> (not (semantic-active-p)) >> (not (run-hook-with-args-until-success >> 'semantic-inhibit-functions))) >>+ ;; Make sure that if this buffer is cloned, our tags and overlays >>+ ;; don't go along for the ride. >>+ (add-hook 'clone-indirect-buffer-hook >>+ 'semantic-clear-toplevel-cache >>+ nil t) >> ;; Specify that this function has done it's work. At this point >> ;; we can consider that semantic is active in this buffer. >> (setq semantic-new-buffer-fcn-was-run t) >> >> >>---------- >>This adds a hook to clear the cache when something is cloned. Please give it a try and let me know how it works. I don't know if this is really the right thing or not. >> >>Thanks! >>Eric >> >>>>> <kla...@ca...> seems to think that: >>>Hi Eric, >>> >>>Hmm, sound senseful - al least at first glance... >>> >>>On a second glance i want to point to the most recent posting i sent to >>>you - this one, where i describe what happens after editing tags in the >>>*indirect-buffer*... How does this behavior match your findings you >>>describe below?! >>> >>>But maybe you are right and fixing one small underlying problem-source >>>in semantic fixes all other misbehaviors too.. But currently i'm >>>slightly pessimistic ;-) >>> >>>Ciao, >>>Klaus >>> >>>-----Ursprüngliche Nachricht----- >>>Von: Eric M. Ludlam [mailto:er...@si...] >>>Gesendet: Donnerstag, 16. April 2009 13:21 >>>An: Lennart Borgman >>>Cc: Berndl, Klaus; ced...@li... >>>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect >>>buffers? -some more findings and a solution idea >>> >>>>>> Lennart Borgman <len...@gm...> seems to think that: >>>>On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: >>>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... >>>> >>>>I have no idea how this work, but it sounds that there are some >>>>properties on the overlays that points to position in a buffer. I >>>>guess these are markers. Then maybe a check if the marker points to >>>>the base buffer could be made just before use? Or perhaps that will be too slow? >>> [ ... ] >>> >>> >>>I did an experiment. I pulled up a simple C++ file, and cloned it. I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer. >>> >>>I then ran: >>> >>>C-u M-x bovinate RET >>> >>>to reparse. Now this throws away all the tag information, and reparses. The new tag was not `eq', and also did not have buffer file names associated with it. >>> >>>I suspect the "fix" is going to be easy. First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse. Semantic will take care of the rest later, and have all the tags marked correctly. I don't think an unlink/link pass would work since the raw tag data is shared at first. >>> >>>There is a spiffy keybinding in senator: >>> >>>C-c , / >>> >>>which will show you details of the tag under point in the data-debugger so you can navigate the structure. It is very helpful for stuff like this. >>> >>>Eric >>> >> > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |