>> Do not use /// but // and just // FIXME. Why the \TODO ? > >Because I was assuming that the code documentation is for developers, >and if I put a "///" and a "@todo", then in the "Todo List page" >generated by Doxygen I get this item included. Now that you make me >think of this, I see I picked the wrong case: it should have been "\todo", >otherwise it doesn't work.
I don't believe anyone looks at that list. >> In the lines below it is checked whether the buffer is still loaded, >> so we already chack for that. What is the todo about ? >>> + if (buffer && theBufferList().isLoaded(buffer)) >>> buffer->undo().endUndoGroup(); > >just didn't know if it is safe to call isLoaded(buffer) with a >deallocated buffer. So, if a buffer isLoaded(), then it must also >be non-null, good. > >Now that I saw the code, I have another doubt: isLoaded() should >find() also within binternal, in addition to bstore, shouldn't it ? > It doesn't make sense to ask whether an internal buffer is loaded or not. >> This is doc_buffer, as an internal buffer doesn't have params.. well >> it has params, but you can't set them. I'd guess that you use the >> doc_buffer's params when you need params in your internal buffer. > >Everytime you (adv)search, the (search)buffer->params() should be >overwritten with (a copy of) the currentDocumentBuffer()->params, >shouldn't they ? How to do that safely ? Can we have two buffers >using the same buffer params ? I don't know why you'd want to use the params. >> This is not really correct, because we don't know whether we have to >> dispatch to buffer or doc_buffer. > >this is a heuristics: try the current buffer first, if it fails then >try the document buffer. Of course, all LFUNs should be checked in >order to check whether it makes sense or not. You must understand by now that if you're hacking the core of the dispatch mechanism, there is no room for 'heuristics'. >> We should somehow make sure that BufferView->dispatch returns false if >> it is an internal buffer and we dispatched an LFUN meant for >> doc_buffer. Now, nothing will be succesfully dispatched to doc_buffer. >seems to me that it is already working that way: if >currentBV()->dispatch() returns false, then documentBV()->dispatch() is tried. Yes, but you didn't adapt BufferView->dispatch() to make sure it returns the correct value. >While testing, I've run into this problem: clicking on the TOC issues a >LFUN_PARAGRAPH_GOTO (or smth. like that). Now, I guess this is quite a >general LFUN, used for multiple purposes within LyX (cursor movements >like up/down, Ctrl+Home/End, perhaps also clicking ?). So, when clicking >on the TOC, it should go to the doc_buffer. When performing other >movements, it should go to the curr_buffer. I don't understand what you want to say here. >Would it be meaningful to add to the LFUN a field saying if to dispatch >here or there ? It would have a value of smth. like DEFAULT for most >cases, except when the GUI wants to force dispatching of the LFUN to >the non-default buffer. No, I think I'd prefer to let BufferView decide whether it handles an LFUN or not, but other may think differently (as they already expressed). But I feel that's a bit overkill. Vincent
