Re: Pasting the wrong inset.
On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote: // A 'paste' operation creates a new inset with the correct filepath, // but then the 'old' inset stored in the 'copy' operation is actually // added to the buffer. I don't see how this can happen. We clone the inset used in cut_clone. Can you explain further? regards john
Re: Pasting the wrong inset.
Angus Leeming [EMAIL PROTECTED] writes:
| Sometime ago I put the following message into InsetGraphic::draw
|
| // MakeAbsPath returns filename_ unchanged if it is absolute
| // already.
| string const file_with_path =
| MakeAbsPath(params_.filename, bv-buffer()-filePath());
|
| // A 'paste' operation creates a new inset with the correct filepath,
| // but then the 'old' inset stored in the 'copy' operation is actually
| // added to the buffer.
| // Thus, we should ensure that the filepath is correct.
| if (file_with_path != loader_.filename()) {
| params_.filename = file_with_path;
| update(params_);
| }
|
| I suspect that John's changes to store the absolute path name internally
| will have cured the symptoms of this problem, but it would be nice if paste
| used the correct inset...
I do not quite get what you are at? Can you elaborate a bit?
--
Lgb
Re: Pasting the wrong inset.
John Levon [EMAIL PROTECTED] writes: | On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote: | | // A 'paste' operation creates a new inset with the correct filepath, | // but then the 'old' inset stored in the 'copy' operation is actually | // added to the buffer. | | I don't see how this can happen. We clone the inset used in cut_clone. Note that some of the implementation changed as part of the CutAndPaste work some weeks ago. -- Lgb
Re: Pasting the wrong inset.
Lars Gullik Bjnnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Sometime ago I put the following message into InsetGraphic::draw
|
| // MakeAbsPath returns filename_ unchanged if it is absolute
| // already.
| string const file_with_path =
| MakeAbsPath(params_.filename, bv-buffer()-filePath());
|
| // A 'paste' operation creates a new inset with the correct
| filepath, // but then the 'old' inset stored in the 'copy'
| operation is actually // added to the buffer.
| // Thus, we should ensure that the filepath is correct.
| if (file_with_path != loader_.filename()) {
| params_.filename = file_with_path;
| update(params_);
| }
|
| I suspect that John's changes to store the absolute path name internally
| will have cured the symptoms of this problem, but it would be nice if
| paste used the correct inset...
I do not quite get what you are at? Can you elaborate a bit?
Sure. Sometime _last year_ I put this message into the method.
Until John's clone patch, we stored the file internally sometimes with a
relative path to the buffer and sometimes with an absolute path.
If it were stored with a relative path in subdir/file.eps and I _cut_ it and
pasted it into a new buffer with a different buffer-filePath(), we failed
to find the graphics file.
It turned out --- lots of digging --- that we were doing what I describe
above.
I don't know if this is still the case and suspect that the problem will be
hidden if it is (because the absolute file path is now stored internally).
Nonetheless it would appear to be a bug waiting to bite again.
--
Angus
Re: Pasting the wrong inset.
Angus Leeming wrote: If it were stored with a relative path in subdir/file.eps and I cut it and pasted it into a new buffer with a different buffer-filePath(), we failed to find the graphics file. Actually, this description is exactly wrong ;-) If the file is stored with a relative path and I either cut it or copy it and then paste it into a buffer with a different buffer-filePath(), then LyX _finds_ and displays it. Of course, no file exists at this absolute (new buffer) + (relative path to graphic file) location, so we should fail to find it and display nothing. And yes, the bug still exists. Ie, paste is shoving in the wrong inset. -- Angus
Re: Pasting the wrong inset.
On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote: If the file is stored with a relative path and I either cut it or copy it and then paste it into a buffer with a different buffer-filePath(), then LyX _finds_ and displays it. Of course, no file exists at this absolute (new buffer) + (relative path to graphic file) location, so we should fail to find it and display nothing. If I'm understanding you correctly then I strongly disagree. The computer shouldn't act like a moron. If it knows where the file is (and it does), then when I paste it into another document, it should get added there. We should handle all the relative path stuff automatically ... and we do now. Previously (storing relative path in the params) it would break even if the user did Save As. That's obviously not too clever. Example: I have two docs /foo/a.lyx and /bar/b.lyx, and a graphics file /foo/a.eps a.lyx when loaded contains a graphics inset with a graphics path /foo/a.eps. I cut and paste that into b.lyx. Now that contains /foo/a.eps. All works as is. The former is *saved* as a.eps and the latter as /foo/a.eps, and that's what we show the user, but that's all. The only corner case I'm aware of is if the user does mv /foo /baz Then in the current code we'll not be able to find the image unless the user reloads the document as /baz/a.lyx. But I don't see a smart way around that. And yes, the bug still exists. Ie, paste is shoving in the wrong inset. I totally don't get this sorry :/ john
Re: Pasting the wrong inset.
John Levon wrote: On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote: If the file is stored with a relative path and I either cut it or copy it and then paste it into a buffer with a different buffer-filePath(), then LyX _finds_ and displays it. Of course, no file exists at this absolute (new buffer) + (relative path to graphic file) location, so we should fail to find it and display nothing. If I'm understanding you correctly then I strongly disagree. The computer shouldn't act like a moron. If it knows where the file is (and it does), then when I paste it into another document, it should get added there. We should handle all the relative path stuff automatically ... and we do now. Then it should also display the correct path (presumably now absolute) when I open the dialog. And here, where I have removed the fudge I describe, it does not. I totally don't get this sorry :/ Because the fudge I pointed out in draw still exists in your tree. -- Angus
Re: Pasting the wrong inset.
On Tue, Jun 03, 2003 at 05:21:56PM +, Angus Leeming wrote: Then it should also display the correct path (presumably now absolute) when I open the dialog. And here, where I have removed the fudge I describe, it does not. Why ? The document is saved with relative paths. The absolute path thing is basically an implementation detail. Because the fudge I pointed out in draw still exists in your tree. InsetGraphics::draw ? Where ? I thought I'd removed it regards john
Re: Pasting the "wrong" inset.
On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote: > // A 'paste' operation creates a new inset with the correct filepath, > // but then the 'old' inset stored in the 'copy' operation is actually > // added to the buffer. I don't see how this can happen. We clone the inset used in cut_clone. Can you explain further? regards john
Re: Pasting the "wrong" inset.
Angus Leeming <[EMAIL PROTECTED]> writes:
| Sometime ago I put the following message into InsetGraphic::draw
|
| // MakeAbsPath returns filename_ unchanged if it is absolute
| // already.
| string const file_with_path =
| MakeAbsPath(params_.filename, bv->buffer()->filePath());
|
| // A 'paste' operation creates a new inset with the correct filepath,
| // but then the 'old' inset stored in the 'copy' operation is actually
| // added to the buffer.
| // Thus, we should ensure that the filepath is correct.
| if (file_with_path != loader_.filename()) {
| params_.filename = file_with_path;
| update(params_);
| }
|
| I suspect that John's changes to store the absolute path name internally
| will have cured the symptoms of this problem, but it would be nice if paste
| used the correct inset...
I do not quite get what you are at? Can you elaborate a bit?
--
Lgb
Re: Pasting the "wrong" inset.
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote: | | > // A 'paste' operation creates a new inset with the correct filepath, | > // but then the 'old' inset stored in the 'copy' operation is actually | > // added to the buffer. | | I don't see how this can happen. We clone the inset used in cut_clone. Note that some of the implementation changed as part of the CutAndPaste work some weeks ago. -- Lgb
Re: Pasting the "wrong" inset.
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Sometime ago I put the following message into InsetGraphic::draw
> |
> | // MakeAbsPath returns filename_ unchanged if it is absolute
> | // already.
> | string const file_with_path =
> | MakeAbsPath(params_.filename, bv->buffer()->filePath());
> |
> | // A 'paste' operation creates a new inset with the correct
> | filepath, // but then the 'old' inset stored in the 'copy'
> | operation is actually // added to the buffer.
> | // Thus, we should ensure that the filepath is correct.
> | if (file_with_path != loader_.filename()) {
> | params_.filename = file_with_path;
> | update(params_);
> | }
> |
> | I suspect that John's changes to store the absolute path name internally
> | will have cured the symptoms of this problem, but it would be nice if
> | paste used the correct inset...
>
> I do not quite get what you are at? Can you elaborate a bit?
Sure. Sometime _last year_ I put this message into the method.
Until John's clone patch, we stored the file internally sometimes with a
relative path to the buffer and sometimes with an absolute path.
If it were stored with a relative path in subdir/file.eps and I _cut_ it and
pasted it into a new buffer with a different buffer->filePath(), we failed
to find the graphics file.
It turned out --- lots of digging --- that we were doing what I describe
above.
I don't know if this is still the case and suspect that the problem will be
hidden if it is (because the absolute file path is now stored internally).
Nonetheless it would appear to be a bug waiting to bite again.
--
Angus
Re: Pasting the "wrong" inset.
Angus Leeming wrote: > If it were stored with a relative path in subdir/file.eps and I cut it and > pasted it into a new buffer with a different buffer->filePath(), we failed > to find the graphics file. Actually, this description is exactly wrong ;-) If the file is stored with a relative path and I either cut it or copy it and then paste it into a buffer with a different buffer->filePath(), then LyX _finds_ and displays it. Of course, no file exists at this absolute (new buffer) + (relative path to graphic file) location, so we should fail to find it and display nothing. And yes, the bug still exists. Ie, paste is shoving in the "wrong" inset. -- Angus
Re: Pasting the "wrong" inset.
On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote: > If the file is stored with a relative path and I either cut it or copy it > and then paste it into a buffer with a different buffer->filePath(), then > LyX _finds_ and displays it. Of course, no file exists at this absolute > (new buffer) + (relative path to graphic file) location, so we should fail > to find it and display nothing. If I'm understanding you correctly then I strongly disagree. The computer shouldn't act like a moron. If it knows where the file is (and it does), then when I paste it into another document, it should get added there. We should handle all the relative path stuff automatically ... and we do now. Previously (storing relative path in the params) it would break even if the user did Save As. That's obviously not too clever. Example: I have two docs /foo/a.lyx and /bar/b.lyx, and a graphics file /foo/a.eps a.lyx when loaded contains a graphics inset with a graphics path "/foo/a.eps". I cut and paste that into b.lyx. Now that contains "/foo/a.eps". All works as is. The former is *saved* as "a.eps" and the latter as "/foo/a.eps", and that's what we show the user, but that's all. The only corner case I'm aware of is if the user does mv /foo /baz Then in the current code we'll not be able to find the image unless the user reloads the document as /baz/a.lyx. But I don't see a "smart" way around that. > And yes, the bug still exists. Ie, paste is shoving in the "wrong" inset. I totally don't get this sorry :/ john
Re: Pasting the "wrong" inset.
John Levon wrote: > On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote: > >> If the file is stored with a relative path and I either cut it or copy it >> and then paste it into a buffer with a different buffer->filePath(), then >> LyX _finds_ and displays it. Of course, no file exists at this absolute >> (new buffer) + (relative path to graphic file) location, so we should >> fail to find it and display nothing. > > If I'm understanding you correctly then I strongly disagree. The > computer shouldn't act like a moron. If it knows where the file is (and > it does), then when I paste it into another document, it should get > added there. We should handle all the relative path stuff automatically > ... and we do now. Then it should also display the correct path (presumably now absolute) when I open the dialog. And here, where I have removed the fudge I describe, it does not. > I totally don't get this sorry :/ Because the fudge I pointed out in draw still exists in your tree. -- Angus
Re: Pasting the "wrong" inset.
On Tue, Jun 03, 2003 at 05:21:56PM +, Angus Leeming wrote: > Then it should also display the correct path (presumably now absolute) when > I open the dialog. And here, where I have removed the fudge I describe, it > does not. Why ? The document is saved with relative paths. The absolute path thing is basically an implementation detail. > Because the fudge I pointed out in draw still exists in your tree. InsetGraphics::draw ? Where ? I thought I'd removed it regards john
