On 05/02/2011 02:11 PM, Richard Heck wrote:
> On 05/02/2011 01:18 PM, Tommaso Cucinotta wrote:
>> Il 02/05/2011 18:49, Richard Heck ha scritto:
>>> I have a book consisting of several documents. They have a default
>>> master set. When I use Adv F&R to do any kind of replacemean, I get a
>>> dialog with the message:
>>>      /home/rgheck/FregesTheorem.lyx does not exist. Do you want to
>>> create
>>> a new document?
>>> That's the right master, but in the wrong directory: The files are
>>> actually three subdirectories down.
>>>
>>> I can't seem to reproduce with a simple test case, though. Why might
>>> this happen?
>> I guess you're trying to use the Settings->"Master Document" scope.
>>
>> In such a case, in FindAndReplace.cpp the buffers are iterated via:
>>
>> static bool nextDocumentBuffer(Buffer * & buf)
>> {
>>     ListOfBuffers const children = buf->allRelatives();
>>     [...]
>>     buf = *it;
>> }
>>
>> Later (same file), the buffer is actually switched via:
>>
>>         if (buf != &view_.documentBufferView()->buffer())
>>             lyx::dispatch(FuncRequest(LFUN_BUFFER_SWITCH,
>>                           buf->absFileName()));
>>
>> My guess is that either the allRelatives() call above, or the
>> BUFFER_SWITCH dispatch here, are actually trying to create a new file
>> instead of opening the correct one, due to some pathname problem
>> (again, let me guess: the folder from where you launched LyX is not
>> the same as the one where the lyx document with a relative path
>> resides ?).
>>
> Well, I wouldn't know why this is happening, but the two files attached
> constitute a simple test case. Open math-c.lyx and use F&R to do
> whatever. Then I get the warning.
>
> Backtrace:
>
> 0    lyx::checkAndLoadLyXFile    buffer_funcs.cpp    109    0x4f9a3d   
> 1    lyx::Buffer::readDocument    Buffer.cpp    792    0x4c1e3b   
> 2    lyx::Buffer::readString    Buffer.cpp    861    0x4c3f83   
> 3    lyx::findAdvReplace    lyxfind.cpp    1299    0x819af5   
> 4    lyx::findAdv    lyxfind.cpp    1359    0x81cfaa   
> 5    lyx::BufferView::dispatch    BufferView.cpp    1544    0x769179   
>
> At (3), we are doing:
>       LASSERT(repl_buffer.readString(lyx), /**/);
> and the problem here is that the lyx string is:
>
> "#LyX 2.0 created this file. For more info see
> http://www.lyx.org/\n\lyxformat
> 413\n\begin_document\n\begin_header\n\textclass
> article\n\use_default_options true\n\master
> math-m.lyx\n\maintain_unincluded_children false\n\language
> english\n\language_package default\n\inputencoding auto\n\fontencoding
> global\n\font_roman default\n\font_sans default\n\font_typewriter
> default\n\font_default_family default\n\use_non_tex_fonts
> false\n\font_sc false\n\font_osf false\n\font_sf_scale
> 100\n\font_tt_scale 100\n\n\grap..."
>
> Note that it has a master set. I have no idea why that would be.
>
The problem turns out to be simple. In ApplyParams(), in
FindAndReplace.cpp, we apply the document params to the find and replace
buffers. This includes the master. So the replace buffer thinks it has a
master document, which it promptly tries to open. I'm much less sure how
to resolve this. I guess you can reset the master directly, but whether
there are other things we don't really want is less clear.

If you did happen to be in the right directory, it would find it. But I
am not sure you really want these internal buffers to think they have
parents.

So here's a way to get the bug: Open any document set with a child that
has a default master. When in the child, and with the F&R dialog closed,
hit Ctrl-Shift-F. This will trigger a ShowEvent and so ApplyParams.

Along these same lines, shouldn't switching documents with the advanced
F&R dialog open cause a call to ApplyParams? I still get asked about the
same master if I switch buffers or even create a new buffer. There may
be other bugs hiding there (e.g., the language won't be changed either).

One other thought. Instead of ApplyParams, what about a
Buffer::setParams(BufferParams const & bp) that would basically do:
    d->params_ = bp;
?? This might be more natural if we had a subclass of Buffer called
InternalBuffer. Just an idea....

Richard

Reply via email to