This is wrong. Because buffer_-embeddedFiles(), unless an update() is
called,
updateBibfilesCache() calls EmbeddedFileList::enable(), which calls
update(). This is what the other question was about, really.
+}
The vectorFileName tells us what files we have, and
I don't really understand this. The registered file will get its enabled
status when it's constructed:
EmbeddedFile::EmbeddedFile(std::string const file,
std::string const inzipName, bool embed, Buffer const buf)
: DocFileName(, false), inzip_name_(inzipName), inset_list_()
I hate to be a pain the ... about this, but I am morally certain that
this will not work, at least in the long term. The problem isn't just
the lack of meta-info. It's the fact that this way of doing things is
completely contrary to how the InsetCommand hierarchy is supposed to
work. (I
If you're agreed, I can change the patch this way. The only task is to
write the update() method, really---we could just take over the old
createBibFiles, but that seems like overkill---and for me to undo some
other bits, like registerEmbeddedFile(). OK?
I knew we'd figure this out
Allow me to answer this critical question first:
Why does it need to happen then? (I understand that this is a high-level
design question.) This seems like something that needs to happen only
when there are certain buffer-level events: Export, saving, etc.
For example, when you insert a
OK. I can see this then, and can adjust for it. That said, however,
speaking as a potential user of this feature, I find this very
counterintuitive. I select a bibliography file, choose Embed (let's
say the document is already in embedded status), and now the edits I
make the file have
> I do not think that even a InsetGraphics object has to be a valid
> file. If I have Logo_INRIA.pdf in my TeX path at work, I want to be
> able to use it. Currently, LyX does not find graphics through
> kpsewhich, but there has been a request for that (and I think we
> should do it).
> OK, that's helpful by way of explanation. But here's where I was getting
> the crash: You have an existing InsetBibtex, embedded, and then you
> change the bibfiles. Now you try to save. Boom, because the newly chosen
> bibfiles haven't been copied and, when the exception is thrown, LyX
>
> > This is wrong. Because buffer_->embeddedFiles(), unless an update() is
> > called,
> >
> updateBibfilesCache() calls EmbeddedFileList::enable(), which calls
> update(). This is what the other question was about, really.
>
> +}
> The vector tells us what files we have,
> I don't really understand this. The registered file will get its enabled
> status when it's constructed:
> EmbeddedFile::EmbeddedFile(std::string const & file,
> std::string const & inzipName, bool embed, Buffer const & buf)
> : DocFileName("", false), inzip_name_(inzipName),
> I hate to be a pain the ... about this, but I am morally certain that
> this will not work, at least in the long term. The problem isn't just
> the lack of meta-info. It's the fact that this way of doing things is
> completely contrary to how the InsetCommand hierarchy is supposed to
>
> If you're agreed, I can change the patch this way. The only task is to
> write the update() method, really---we could just take over the old
> createBibFiles, but that seems like overkill---and for me to undo some
> other bits, like registerEmbeddedFile(). OK?
>
> I knew we'd figure this
Allow me to answer this critical question first:
> Why does it need to happen then? (I understand that this is a high-level
> design question.) This seems like something that needs to happen only
> when there are certain buffer-level events: Export, saving, etc.
For example, when you insert a
> OK. I can see this then, and can adjust for it. That said, however,
> speaking as a potential user of this feature, I find this very
> counterintuitive. I select a bibliography file, choose "Embed" (let's
> say the document is already in embedded status), and now the edits I
> make the file
Comments welcome.
This is pretty radical. You basically have a relative-path version of
EmbeddedFile in InsetBibtex and convert to EmbeddedFile if needed.
How about making EmbeddedFile a standard-alone class that does not
derive from DocFileName? We simply save whatever path, relative or
Well, we need some general solution, because there are similar problems
elsewhere. If you have a file that contains a path to an included file,
for example, it can be changed simply by opening and saving the file. In
particular, it will always be converted from an absolute to a relative
At least my most recent bit encapsulates that.
I have not looked at the svn, have your committed your patch? Will you
be able to wait for me to make EmbeddedFile relative-path friendly?
Cheers,
Bo
In a way, but there's no EmbeddedFile object stored there at all. Just
the old parameter info. We build EmbeddedFile objects when necessary
mostly so they will tell us about the inzip path and, of course, so we
can use the copyTo() function. If there were a static
I'm fairly convinced that we should not be using the
EmbeddedFiles stuff to represent the parameters here. That just seems
like mixing up the wrong things.
Why not? We need to store filenames (I know I need to keep the
original filenames), and the embedding status. Using a EmbeddedFiles
I'm skeptical that this will solve the problems. The issue doesn't
really have anything to do with relative versus absolute paths. If I
choose biblio as my BibTeX file, that is NOT a pathname.
I see your point now. Unlike InsetInclude and InsetGraphics where a
file must be a file, this
On Thu, Mar 27, 2008 at 1:55 PM, Andre Poenitz
[EMAIL PROTECTED] wrote:
Why is is called InsetListing_s_ (plural)?
That's out-of-sync with the rest of them...
Because the package is named listings.
Bo
I think the approach in my patch can be made to work. I can embed the
file just fine, and it gets extracted just fine. But I have seen some
issues with latex output. Sometimes it works, sometimes it doesn't. But
I'm thinking this can be made to work. At the very least, we can give a
It seems to me that it would be a good idea, in general, if we were to
do that after, say, InsetInclude's parameters were changed. I saw some
crashes with InsetBibtex that were related to my not updating this
structure. E.g., I changed the bibfiles and then tried to save, but they
hadn't
I am reading your patch and hopefully can make it
work.
+ // Make sure we are up to date.
+ buffer_-updateBibfilesCache();
+ EmbeddedFileList efl = buffer_-embeddedFiles();
+ vectorFileName const files = getFiles();
+
On Thu, Mar 27, 2008 at 9:47 PM, Bo Peng [EMAIL PROTECTED] wrote:
I am reading your patch and hopefully can make it
work.
void InsetBibtex::registerEmbeddedFiles(EmbeddedFileList files) const
{
- if (bibfiles_.empty())
- createBibFiles(params()[bibfiles], params
On Thu, Mar 27, 2008 at 9:59 PM, Bo Peng [EMAIL PROTECTED] wrote:
On Thu, Mar 27, 2008 at 9:47 PM, Bo Peng [EMAIL PROTECTED] wrote:
I am reading your patch and hopefully can make it
work.
+EmbeddedFile const * EmbeddedFileList::findFile(std::string const
filename) const
Hi, Richard,
I think most of your problems can be solved in a less-radical way, by
saving relative path, or something like that, so that you can recover
user input.
The attached patch tries to do exactly this. It adds meta_ to
EmbeddedFile and allow InsetBibtex to add 'biblio' to an
> Comments welcome.
This is pretty radical. You basically have a relative-path version of
EmbeddedFile in InsetBibtex and convert to EmbeddedFile if needed.
How about making EmbeddedFile a standard-alone class that does not
derive from DocFileName? We simply save whatever path, relative or
> Well, we need some general solution, because there are similar problems
> elsewhere. If you have a file that contains a path to an included file,
> for example, it can be changed simply by opening and saving the file. In
> particular, it will always be converted from an absolute to a
> >
> At least my most recent bit encapsulates that.
I have not looked at the svn, have your committed your patch? Will you
be able to wait for me to make EmbeddedFile relative-path friendly?
Cheers,
Bo
> In a way, but there's no EmbeddedFile object stored there at all. Just
> the old parameter info. We build EmbeddedFile objects when necessary
> mostly so they will tell us about the inzip path and, of course, so we
> can use the copyTo() function. If there were a static
>
> I'm fairly convinced that we should not be using the
> EmbeddedFiles stuff to represent the parameters here. That just seems
> like mixing up the wrong things.
Why not? We need to store filenames (I know I need to keep the
original filenames), and the embedding status. Using a EmbeddedFiles
> I'm skeptical that this will solve the problems. The issue doesn't
> really have anything to do with relative versus absolute paths. If I
> choose "biblio" as my BibTeX file, that is NOT a pathname.
I see your point now. Unlike InsetInclude and InsetGraphics where a
file must be a file, this
On Thu, Mar 27, 2008 at 1:55 PM, Andre Poenitz
<[EMAIL PROTECTED]> wrote:
>
> Why is is called InsetListing_s_ (plural)?
>
> That's out-of-sync with the rest of them...
Because the package is named listings.
Bo
> I think the approach in my patch can be made to work. I can embed the
> file just fine, and it gets extracted just fine. But I have seen some
> issues with latex output. Sometimes it works, sometimes it doesn't. But
> I'm thinking this can be made to work. At the very least, we can give a
>
> It seems to me that it would be a good idea, in general, if we were to
> do that after, say, InsetInclude's parameters were changed. I saw some
> crashes with InsetBibtex that were related to my not updating this
> structure. E.g., I changed the bibfiles and then tried to save, but they
>
> I am reading your patch and hopefully can make it
> work.
+ // Make sure we are up to date.
+ buffer_->updateBibfilesCache();
+ EmbeddedFileList & efl = buffer_->embeddedFiles();
+ vector const files = getFiles();
+
On Thu, Mar 27, 2008 at 9:47 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > I am reading your patch and hopefully can make it
> > work.
>
void InsetBibtex::registerEmbeddedFiles(EmbeddedFileList & files) const
{
- if (bibfiles_.empty())
- createBi
On Thu, Mar 27, 2008 at 9:59 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 9:47 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > > I am reading your patch and hopefully can make it
> > > work.
> >
+EmbeddedFile const * EmbeddedFileList
Hi, Richard,
I think most of your problems can be solved in a less-radical way, by
saving relative path, or something like that, so that you can recover
user input.
The attached patch tries to do exactly this. It adds meta_ to
EmbeddedFile and allow InsetBibtex to add 'biblio' to an
Is there any progress on this? Is it a problem by design of the new
file handling? Or just a bug? What does There are a lot of work in
this area. mean? Is anybody actively working on this?
These files are now EmbeddedFiles and their latex output names are
currently wrong. I am supposed to
I have to say that it seems messy to me that we're effectively storing
two sets of things that have the same significance: params[bibfiles],
on the one hand, and the embedded file list, on the other. This makes
the logic in InsetBibtex, on which I worked a fair bit and would have
thought
Can you explain to me what the embed parameter here is supposed to mean?
I have e.g.
\begin_inset CommandInset bibtex
LatexCommand bibtex
bibfiles /home/rgheck/files/bibtex/biblio
embed ./LyX.Embed.Dir.Abs//home/rgheck/files/bibtex/biblio.bib
options plain
The bib file is an
This should be fixed now. whateverCO-currentIndex() is returning -1
if there's no current index yet. this can't be used to access an
array...
Thank you very much! I was confused because lyx did not always crash.
Bo
Comments welcome. And see the long FIXME about remaining issues.
Why do you remove updateParam and manipulate (in add/remove database
etc) these parameter strings again and again? The original idea was to
change EmbeddedFiles, and write these strings from the file list each
time.
Bo
I tried using updateParam() after introducing getTeXFile, but that
didn't work. The problem is that there's no way to tell when you get
back from EmbeddedFiles what the ORIGINAL path was. Things like: biblio,
../biblio, /home/me/biblio, etc, all look the same to EmbeddedFiles at
that
I agree, I like all of them!
I like the first and third the most, but I will not vote against other
two either.
Bo
> Is there any progress on this? Is it a problem by design of the new
> file handling? Or just a bug? What does "There are a lot of work in
> this area." mean? Is anybody actively working on this?
These files are now EmbeddedFiles and their latex output names are
currently wrong. I am supposed
> I have to say that it seems messy to me that we're effectively storing
> two sets of things that have the same significance: params["bibfiles"],
> on the one hand, and the embedded file list, on the other. This makes
> the logic in InsetBibtex, on which I worked a fair bit and would have
>
> Can you explain to me what the embed parameter here is supposed to mean?
> I have e.g.
> \begin_inset CommandInset bibtex
> LatexCommand bibtex
> bibfiles "/home/rgheck/files/bibtex/biblio"
> embed "./LyX.Embed.Dir.Abs//home/rgheck/files/bibtex/biblio.bib"
> options "plain"
The bib file
> This should be fixed now. "whateverCO->currentIndex()" is returning -1
> if there's no current index yet. this can't be used to access an
> array...
Thank you very much! I was confused because lyx did not always crash.
Bo
> Comments welcome. And see the long FIXME about remaining issues.
Why do you remove updateParam and manipulate (in add/remove database
etc) these parameter strings again and again? The original idea was to
change EmbeddedFiles, and write these strings from the file list each
time.
Bo
> I tried using updateParam() after introducing getTeXFile, but that
> didn't work. The problem is that there's no way to tell when you get
> back from EmbeddedFiles what the ORIGINAL path was. Things like: biblio,
> ../biblio, /home/me/biblio, etc, all look the same to EmbeddedFiles at
>
> I agree, I like all of them!
I like the first and third the most, but I will not vote against other
two either.
Bo
On Tue, Mar 25, 2008 at 11:57 AM, rgheck [EMAIL PROTECTED] wrote:
Or are there some that don't need it? or want it?
I do not have the answer but I think simple insets such as
InsetNewline does not really need a buffer pointer, whereas more
complicated ones should have one. For example,
On Tue, Mar 25, 2008 at 11:57 AM, rgheck <[EMAIL PROTECTED]> wrote:
>
> Or are there some that don't need it? or want it?
I do not have the answer but I think simple insets such as
InsetNewline does not really need a buffer pointer, whereas more
complicated ones should have one. For example,
On Mon, Mar 24, 2008 at 7:21 AM, rgheck [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Note that the mysterious listings setting crash is still there
Can you remind me how to reproduce this?
Open a document with a listings inset, right click, settings. Most of
the time, lyx will crash
On Mon, Mar 24, 2008 at 9:13 AM, Jürgen Spitzmüller
[EMAIL PROTECTED] wrote:
rgheck wrote:
Open a document with a listings inset, right click, settings. Most of
the time, lyx will crash here (Linux, RHEL4, gcc 4.1, qt 4.22)
FWIW, I see this too:
On Mon, Mar 24, 2008 at 9:12 AM, [EMAIL PROTECTED] wrote:
Author: spitz
Date: Mon Mar 24 15:12:19 2008
New Revision: 23923
URL: http://www.lyx.org/trac/changeset/23923
Log:
* src/BufferView.cpp:
* src/Text3.cpp:
- fix LFUN_INSET_SETTINGS so that it also works at cursor
When I traced it, gdb reported it elsewhere, in a totally unhelpful way.
Could it be some initialization problem with qt_() itself?
I also suspected this, maybe we can change qt_() (no translation, for
example) and test.
Bo
Bo Peng wrote:
Do we really need this
Yes. Try to open the Listings (or any other collapsable) dialog via context
menu by pressing on the button: it is disabled (without my change). It is
only enabled if you pressed _inside_ the collapsable.
since we can use LFUN_NEXT_INSET_TOGGLE
Now some people requested that this also works for non-collapsables such as
labels. They expect that if you press C-i in front of these, that they can
edit the contents as well (i.e. that the label dialog pops up).
It does work for InsetLabel and InsetRef, right?
Bo
On Mon, Mar 24, 2008 at 7:21 AM, rgheck <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
> > Note that the mysterious listings setting crash is still there
> >
> >
> Can you remind me how to reproduce this?
>
Open a document with a listings inset, right click
On Mon, Mar 24, 2008 at 9:13 AM, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
> rgheck wrote:
> > > Open a document with a listings inset, right click, settings. Most of
> > > the time, lyx will crash here (Linux, RHEL4, gcc 4.1, qt 4.22)
>
> FWIW, I see this too:
>
On Mon, Mar 24, 2008 at 9:12 AM, <[EMAIL PROTECTED]> wrote:
> Author: spitz
> Date: Mon Mar 24 15:12:19 2008
> New Revision: 23923
>
> URL: http://www.lyx.org/trac/changeset/23923
> Log:
> * src/BufferView.cpp:
> * src/Text3.cpp:
> - fix LFUN_INSET_SETTINGS so that it also works at
> When I traced it, gdb reported it elsewhere, in a totally unhelpful way.
> Could it be some initialization problem with qt_() itself?
I also suspected this, maybe we can change qt_() (no translation, for
example) and test.
Bo
> Bo Peng wrote:
> > Do we really need this
>
> Yes. Try to open the Listings (or any other collapsable) dialog via context
> menu by pressing on the button: it is disabled (without my change). It is
> only enabled if you pressed _inside_ the collapsable.
>
> Now some people requested that this also works for non-collapsables such as
> labels. They expect that if you press C-i in front of these, that they can
> edit the contents as well (i.e. that the label dialog pops up).
It does work for InsetLabel and InsetRef, right?
Bo
Looks safe. The emory th pointer is pointig to is even static, so it
does not go suddenly out of scope.
The crash does happen there ... :-(
Bo
This patch also adds a context menu to InsetGraphics, with 'Edit' as
the first item. However, when I try to implement the 'settings' menu
using LFUN_INSET_SETTINGS, I find that cur.inset() returns InsetText
when I right click on an InsetGraphics. Even if I can enable
'settings'
I tried starting to do this, but I think we'd probably have to do it all
in one go, due to how the factory works: the inset Buffer gets set in
createInset, not at creation time in createInsetHelper. So we'd at least
have to pass the Buffer to createInsetHelper; but then most insets would
Just to make sure, did you apply my patch?
Well, I think yes. But now that you're asking I am not sure. I checked
out the latest revision from SVN (now r23907) and it's still like I
said.
I meant the patch attached to my email. It may not apply clearly now though.
Bo
It certainly feels like a
kludge that we're creating a temporary InsetGraphics just so we can call
one of its methods. But I don't know this code well enough to have any
more of an opinion than that...except to say, if we commit this, let's
do the context menu and see what Andre thinks
As shown in the attached patch, I tent to remove the use of a
temporary InsetGraphics by moving the lfun implementation to
BufferView.cpp.
I have committed this part, and this is the only part that makes
sense. All others were trying to re-implement next-inset-toggle. :-(
Bo
> Looks safe. The emory th pointer is pointig to is even static, so it
> does not go "suddenly" out of scope.
The crash does happen there ... :-(
Bo
> > This patch also adds a context menu to InsetGraphics, with 'Edit' as
> > the first item. However, when I try to implement the 'settings' menu
> > using LFUN_INSET_SETTINGS, I find that cur.inset() returns InsetText
> > when I right click on an InsetGraphics. Even if I can enable
> >
> I tried starting to do this, but I think we'd probably have to do it all
> in one go, due to how the factory works: the inset Buffer gets set in
> createInset, not at creation time in createInsetHelper. So we'd at least
> have to pass the Buffer to createInsetHelper; but then most insets
> > Just to make sure, did you apply my patch?
>
> Well, I think yes. But now that you're asking I am not sure. I checked
> out the latest revision from SVN (now r23907) and it's still like I
> said.
I meant the patch attached to my email. It may not apply clearly now though.
Bo
> It certainly feels like a
> kludge that we're creating a temporary InsetGraphics just so we can call
> one of its methods. But I don't know this code well enough to have any
> more of an opinion than that...except to say, if we commit this, let's
> do the context menu and see what Andre
> As shown in the attached patch, I tent to remove the use of a
> temporary InsetGraphics by moving the lfun implementation to
> BufferView.cpp.
>
I have committed this part, and this is the only part that makes
sense. All others were trying to re-implement next-inset-toggle. :-(
Bo
Wait, did you try inset-settings listings?
You are right, this seems to be the right lfunc to use. However, lyx
still crashes with the same error message...
Bo
In program listings, right click doesn't bring up listings dialog. Doesn't
seem to be any way to get the program listings dialog.
Abdel and I are working on it.
Bo
OK. I can certainly do this.
Should we permit inset creation without a buffer, anyway?
1.5.x uses *cur.bv().buffer(), 1.6.x changed this to plain buffer().
Bo
On Sat, Mar 22, 2008 at 10:48 PM, Bo Peng [EMAIL PROTECTED] wrote:
OK. I can certainly do this.
Should we permit inset creation without a buffer, anyway?
1.5.x uses *cur.bv().buffer(), 1.6.x changed this to plain buffer().
Fixed (r23899).
Bo
Fixed (r23899).
A proper fix, IMHO, would be moving GRAPHICS_EDIT from LyXFunc.h/cpp
to BufferView.h/cpp, and dispatch GRAPHICS_EDIT from a real inset. The
attached patch does this.
This patch also adds a context menu to InsetGraphics, with 'Edit' as
the first item. However, when I try to
On Sat, Mar 22, 2008 at 9:22 AM, Bo Peng [EMAIL PROTECTED] wrote:
Wait, did you try inset-settings listings?
You are right, this seems to be the right lfunc to use. However, lyx
still crashes with the same error message...
The exception is triggered at GuiListings.cpp, line 218 and later
> Wait, did you try "inset-settings listings"?
You are right, this seems to be the right lfunc to use. However, lyx
still crashes with the same error message...
Bo
> In program listings, right click doesn't bring up listings dialog. Doesn't
> seem to be any way to get the program listings dialog.
Abdel and I are working on it.
Bo
> OK. I can certainly do this.
>
> Should we permit inset creation without a buffer, anyway?
1.5.x uses *cur.bv().buffer(), 1.6.x changed this to plain buffer().
Bo
On Sat, Mar 22, 2008 at 10:48 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > OK. I can certainly do this.
> >
> > Should we permit inset creation without a buffer, anyway?
>
> 1.5.x uses *cur.bv().buffer(), 1.6.x changed this to plain buffer().
Fixed (r23899).
Bo
> Fixed (r23899).
A proper fix, IMHO, would be moving GRAPHICS_EDIT from LyXFunc.h/cpp
to BufferView.h/cpp, and dispatch GRAPHICS_EDIT from a real inset. The
attached patch does this.
This patch also adds a context menu to InsetGraphics, with 'Edit' as
the first item. However, when I try to
On Sat, Mar 22, 2008 at 9:22 AM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > Wait, did you try "inset-settings listings"?
>
> You are right, this seems to be the right lfunc to use. However, lyx
> still crashes with the same error message...
The exception is trigger
Obviously I am one of those 1%, exactly with regard to the case you outlined:
pageref to a given argumentation inside some longer section and paragraph.
Why should we limit ourself wrt label use compared to LaTeX?
And there are reasons to have more than one references in a paragraph,
for
Could you elaborate? To what do these labels refer?
As a recent example, I got reviewers' comments for a submitted paper
and need to write a response that refers to the revised paper. I
marked reviewers' comments as 'comment_1_1', 'comment_3_10' etc and
inserted them as labels to my
I get link errors and I can not tell whose change is responsible for
this. Any idea?
Note that boost::assertion_failed is defined in src/boost.cpp.
Bo
debug/libs/libincluded_boost_signals.a(connection.o)(.text+0x55f): In
function
On Fri, Mar 21, 2008 at 10:36 AM, Bo Peng [EMAIL PROTECTED] wrote:
I get link errors and I can not tell whose change is responsible for
this. Any idea?
Fixed by linking boost.cpp after included_boost_xxx, because
assertion_failed is required by these libraries. I do not actually
know which
I think we should be able to attach nevertheless the inset by
modifying a bit the dialog-show LFUN; this is done this way for the
label and reference dialog for example. Please have a look at
LFUN_LABEL_GOTO or something like that.
The attached might be a better solution: we simply reject
> Obviously I am one of those 1%, exactly with regard to the case you outlined:
> pageref to a given argumentation inside some longer section and paragraph.
> Why should we limit ourself wrt label use compared to LaTeX?
And there are reasons to have more than one references in a paragraph,
for
> > Could you elaborate? To what do these labels refer?
As a recent example, I got reviewers' comments for a submitted paper
and need to write a response that refers to the revised paper. I
marked reviewers' comments as 'comment_1_1', 'comment_3_10' etc and
inserted them as labels to my
I get link errors and I can not tell whose change is responsible for
this. Any idea?
Note that boost::assertion_failed is defined in src/boost.cpp.
Bo
debug/libs/libincluded_boost_signals.a(connection.o)(.text+0x55f): In
function
901 - 1000 of 8038 matches
Mail list logo
