Re: lyxconvert: version 0.0.2
On Thursday 01 August 2002 00:50, Lars Gullik Bjønnes wrote: sure... or lyx2lyx if that is agreed upon. Since Dekel does not have any preference (private message) I will set it lyx2lyx. I will start to add it to cvs later today, since university will be out of connection due to some works in a central building. The version name will be the same of the envolving lyx. The name of individual convertion modules will remain unchanged. -- José Abílio
Re: key combinations not showing up...
On Thu, Aug 01, 2002 at 03:17:15AM +0100, John Levon wrote: Is it possible that future versions have this feature back, or even better, to show possible better key-strokes, like M-m [ when you select this? It's a bug really, no sign of a fix for 1.2.x :/ For 1.3, we show the symbol name, but it doesn't work for all cases - Andre, why is this ? Hm... because no every inset displays its info yet. I usually change that as soon as I have to touch the inset but I usually don't go through every 30+ insets in one swoop. But I think that's not what Pierre was asking for, he wanted to have the shortcut displayed in the minibuffer. That's a differnt issue and never was done by mathed, so I did not break it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: mathed compile error
On Thu, Aug 01, 2002 at 04:22:09AM +0100, John Levon wrote: math_gridinset.h:22: `struct MathGridInset::CellInfo' is private math_textinset.C:141: within this context I commited a quickdirty fix. Will have a look later. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyxconvert: version 0.0.2
Dekel == Dekel Tsur [EMAIL PROTECTED] writes: Dekel How about putting the files on CVS, in lib/lyxconvert/ ? We Dekel only need to made the changes so make install will create a Dekel symbolic link /usr/bin/lyxconvert for Dekel LYXDIR/lyxconvert/lyxconvert.py Will symbolic links work under cygwin? Dekel (perhaps lyxconvert.py should be renamed to lyxconvert?) A problem we have with scripts is that the python (or perl) interpreter will not be at the same place on different systems. I'd like to avoid to create all the scripts from configure like we do for reLyX. For running scripts from inside lyx, a solution would be to rely on script extension to know how to invike it: for example, lyxconvert.py would be invoked as python lyxconvert.py Also, the calling code could arrange to define a few variables like LYX_DIR, or whatever can be useful for the script. As an example reLyXmain.pl could be invoked with LYX_DIR and PACKAGE set to the right values, so that the script reLyX is not needed. I do not know whether lyx2lyx will need to find lyx data directory in this way, though. However, this would not work from inside lyx. A solution would be to run them from lyx, like lyx --run-script reLyXmain.pl This is not a very satisfactory solution, but we need to find a way to make our scripts portable. JMarc
lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 10:49, Jean-Marc Lasgouttes wrote: Will symbolic links work under cygwin? Good question. Dekel (perhaps lyxconvert.py should be renamed to lyxconvert?) A problem we have with scripts is that the python (or perl) interpreter will not be at the same place on different systems. I'd like to avoid to create all the scripts from configure like we do for reLyX. What about the present solution: #!/usr/bin/env python Do you know any system where this fails? For running scripts from inside lyx, a solution would be to rely on script extension to know how to invike it: for example, lyxconvert.py would be invoked as python lyxconvert.py But python lyx2lyx will works as well, you don't need the extension. The knowleadge present in the extension should (could) be somewhere else. Also, the calling code could arrange to define a few variables like LYX_DIR, or whatever can be useful for the script. As an example reLyXmain.pl could be invoked with LYX_DIR and PACKAGE set to the right values, so that the script reLyX is not needed. I do not know whether lyx2lyx will need to find lyx data directory in this way, though. Since I added that code to reLyX this shouldn't ever be a problem to lyx2lyx. :-) However, this would not work from inside lyx. A solution would be to run them from lyx, like lyx --run-script reLyXmain.pl This is not a very satisfactory solution, but we need to find a way to make our scripts portable. One other question, does reLyX has internationalization? I have moved all the error, and warnings, messages to a single file to easy that possibility. I have seen also pygettext, but that seems to be only present in python 2.2 JMarc -- José Abílio
Re: Action diff - look and diss
John == John Levon [EMAIL PROTECTED] writes: John Rather than justify any of this, I'll just show it and let John people comment. It looks nice to me and I do not have many clever comments. A question though: we will be adding lots of objects with virtual methods (or lots of virtual methods to exisiting insets). What is the price we will have to pay for this in terms of bloat, link time, and startup time (remember the link-at-startup problems that kde has)? JMarc
Re: Create a new file with File open
John == John Levon [EMAIL PROTECTED] writes: John On Fri, Jun 21, 2002 at 12:09:34PM -0700, Matt Brennan wrote: As I recal, in v.1.1, you were able to create a new file by typing its name in the File-Open... popup. Now in v. 1.2 this is no longer possible. Hopefully, it should be easy to carry this feature forward to v.1.2.1 John JMarc, OK for 1.2 branch ? Questions: + Buffer * buffer = bufferlist.newFile(filename, ); I thought that the second argument to newFile was a bool. + // the user specifically chose this name. Believe them. Did you test what happens when one chooses a nonsensical file name (non-existing directory, for example) and then tries to save? Failing to save is OK, crashing lyx is not :) Othrwise, I am OK in principle for this patch in 1.2.x. JMarc
Re: lyxconvert: version 0.0.2
On Thu, Aug 01, 2002 at 11:49:15AM +0200, Jean-Marc Lasgouttes wrote: Dekel (perhaps lyxconvert.py should be renamed to lyxconvert?) A problem we have with scripts is that the python (or perl) interpreter will not be at the same place on different systems. I thought for most scripting languages there are hacks like #!/bin/sh # the next line restarts using tclsh \ exec tclsh $0 $ For running scripts from inside lyx, a solution would be to rely on script extension to know how to invike it: for example, lyxconvert.py would be invoked as python lyxconvert.py But I really don't care what language is used to implement something. So if nwe nee auto-detection we should look at the contents. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: Dekel (perhaps lyxconvert.py should be renamed to lyxconvert?) A problem we have with scripts is that the python (or perl) interpreter will not be at the same place on different systems. I'd like to avoid to create all the scripts from configure like we do for reLyX. José What about the present solution: #!/usr/bin/env python Ah. I did not notice it... Note that you should always add a space after #! José Do you know any system where this fails? I do not now, but a google search seems to propose this as a common trick. For running scripts from inside lyx, a solution would be to rely on script extension to know how to invike it: for example, lyxconvert.py would be invoked as python lyxconvert.py José But python lyx2lyx will works as well, you don't need the José extension. The knowleadge present in the extension should José (could) be somewhere else. I mean that lyx runScript (or whatever name) method could use the extension to guess the interpreter it should use. I am not sure yet it is a good idea, just a proposal. José One other question, does reLyX has internationalization? I José have moved all the error, and warnings, messages to a single José file to easy that possibility. José I have seen also pygettext, but that seems to be only present José in python 2.2 I think we can worry about that later, but gettext support would certainly be nice. JMarc
caching BufferView (again)
Lots and lots of things are caching a BufferView * or a Buffer *. To name a
few:
InsetFormulaBase (BufferView *)
InsetCite (Buffer *)
GraphicsLoader (BufferView *, cached for 2 secs then used).
Moreover, InsetGraphics and InsetInclude both are using current_view because
they don't cache but should. In the case of InsetInclude that's preview
related so it's not yet in cvs.
Clearly when we move to multiple / changing BufferViews this is going to lead
to nasty problems.
Lars has mentioned using boost::weak_ptr in just such a context and I'd like
to do so here. From the boost docs
=
http://www.boost.org/libs/smart_ptr/weak_ptr.htm
The weak_ptr class template stores a pointer to an object that's already
managed by a shared_ptr. When the object last shared_ptr to the object goes
away and the object is deleted, all weak_ptr objects have their stored
pointers set to 0.
=
I'd like, therefore, to change the LyXView store
public:
/// return the current buffer view
BufferView * view() const { return bufferview_,get(); }
+ /// weak_ptr.get() is reset to 0 automatically when bufferview_ is killed.
+ boost::weak_ptrBufferView const cachablePtr() const {
+ return boost::weak_ptrBufferView(bufferview_);
+ }
private:
/// view of a buffer. Eventually there will be several.
- boost::scoped_ptrBufferView bufferview_;
+ boost::shared_ptrBufferView bufferview_;
and to make it accessible through BufferView:
boost::weak_ptrBufferView const BufferView::cachablePtr() const
{
return pimpl_-owner_-cachablePtr();
}
Then if things want to cache a BufferView * then they can do so safely.
What do you think?
Angus
ps, when LyXView stores multiple BufferViews, we'd perhaps have
boost::weak_ptrBufferView const cachablePtr(BufferView *) const;
but that is for the future...
A
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: Clearly when we move to multiple / changing BufferViews this is going to lead to nasty problems. While we are at it: Can anybody explain me the advantages of multiple buffer views vs multiple LyX processes? Which kind of convienence would that buy us? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
On Thursday 01 August 2002 12:17 pm, Andre Poenitz wrote: On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: Clearly when we move to multiple / changing BufferViews this is going to lead to nasty problems. While we are at it: Can anybody explain me the advantages of multiple buffer views vs multiple LyX processes? Sure. A single LyXView can have multiple BufferViews. Think, in emacs terms, of C-x 2 instead of C-x 5. Angus
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 11:41, Jean-Marc Lasgouttes wrote: José What about the present solution: #!/usr/bin/env python Ah. I did not notice it... Note that you should always add a space after #! Done. José Do you know any system where this fails? I do not now, but a google search seems to propose this as a common trick. This is the usual way to deal this inside python scripts. I mean that lyx runScript (or whatever name) method could use the extension to guess the interpreter it should use. I am not sure yet it is a good idea, just a proposal. Ok. José One other question, does reLyX has internationalization? I José have moved all the error, and warnings, messages to a single José file to easy that possibility. José I have seen also pygettext, but that seems to be only present José in python 2.2 I think we can worry about that later, but gettext support would certainly be nice. Ok. Now back to fix some small issues and commit it. JMarc -- José Abílio
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: | Dekel (perhaps lyxconvert.py should be renamed to lyxconvert?) A problem we have with scripts is that the python (or perl) interpreter will not be at the same place on different systems. I'd like to avoid to create all the scripts from configure like we do for reLyX. | José What about the present solution: #!/usr/bin/env python | Ah. I did not notice it... Note that you should always add a space | after #! Why? | José One other question, does reLyX has internationalization? I | José have moved all the error, and warnings, messages to a single | José file to easy that possibility. won't that make the code harder to read? -- Lgb
lyx2lyx final touch (before commiting)
Hi, the files presents in lyx2lyx directory are: error.py lyx2lyx lyxconvert_215.py lyxconvert_218.py parser_tools.py I will add several other later, but for now this is enough. What other files do I need to add? Makefile.am? Changelog? .cvsignore? Jean-Marc? :-) -- José Abílio
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 12:41, Lars Gullik Bjønnes wrote: | José One other question, does reLyX has internationalization? I | José have moved all the error, and warnings, messages to a single | José file to easy that possibility. won't that make the code harder to read? class Error: invalid_file = Invalid LyX file\n invalid_format = Invalid LyX format\n format_not_supported = Format not supported\n same_format = No convertion because start and ending formats are the same\n newer_format = Starting format is newer than end format\n error = Error() Now in the files you use: sys.stderr.write(error.invalid_file) how is that harder to read than say: sys.stderr.write(Invalid LyX file\n) -- José Abílio
Re: caching BufferView (again)
Angus Leeming [EMAIL PROTECTED] writes:
| Lots and lots of things are caching a BufferView * or a Buffer *. To name a
| few:
| InsetFormulaBase (BufferView *)
| InsetCite (Buffer *)
| GraphicsLoader (BufferView *, cached for 2 secs then used).
| Moreover, InsetGraphics and InsetInclude both are using current_view because
| they don't cache but should. In the case of InsetInclude that's preview
| related so it's not yet in cvs.
| Clearly when we move to multiple / changing BufferViews this is going to lead
| to nasty problems.
| Lars has mentioned using boost::weak_ptr in just such a context and I'd like
| to do so here. From the boost docs
| =
| http://www.boost.org/libs/smart_ptr/weak_ptr.htm
| The weak_ptr class template stores a pointer to an object that's already
| managed by a shared_ptr. When the object last shared_ptr to the object goes
| away and the object is deleted, all weak_ptr objects have their stored
| pointers set to 0.
| =
| I'd like, therefore, to change the LyXView store
| public:
| /// return the current buffer view
| BufferView * view() const { return bufferview_,get(); }
I'd rather change this one to
a. return a shared_ptr
b. return a weak_ptr
| + /// weak_ptr.get() is reset to 0 automatically when bufferview_ is killed.
| + boost::weak_ptrBufferView const cachablePtr() const {
| + return boost::weak_ptrBufferView(bufferview_);
| + }
and not have this one at all.
| private:
| /// view of a buffer. Eventually there will be several.
| - boost::scoped_ptrBufferView bufferview_;
| + boost::shared_ptrBufferView bufferview_;
yes.
| and to make it accessible through BufferView:
| boost::weak_ptrBufferView const BufferView::cachablePtr() const
| {
| return pimpl_-owner_-cachablePtr();
| }
and you really need this?
--
Lgb
Re: caching BufferView (again)
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: Clearly when we move to multiple / changing BufferViews this is going to lead to nasty problems. | While we are at it: Can anybody explain me the advantages of multiple | buffer views vs multiple LyX processes? | Which kind of convienence would that buy us? View different parts of the same document at the same time... -- Lgb
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
José Abílio Oliveira Matos [EMAIL PROTECTED] writes: | On Thursday 01 August 2002 12:41, Lars Gullik Bjønnes wrote: | José One other question, does reLyX has internationalization? I | José have moved all the error, and warnings, messages to a single | José file to easy that possibility. won't that make the code harder to read? | class Error: | invalid_file = Invalid LyX file\n | invalid_format = Invalid LyX format\n | format_not_supported = Format not supported\n | same_format = No convertion because start and ending formats are the | same\n | newer_format = Starting format is newer than end format\n | error = Error() | Now in the files you use: | sys.stderr.write(error.invalid_file) | how is that harder to read than say: | sys.stderr.write(Invalid LyX file\n) no but... sys.stderr.write(same_format); does not exactly tell a lot... There is a reason why gettext is not using this method... -- Lgb
Re: caching BufferView (again)
On Thursday 01 August 2002 12:53 pm, Lars Gullik Bjønnes wrote:
It appears you aren't against the basic idea. Good.
| I'd like, therefore, to change the LyXView store
| public:
| /// return the current buffer view
| BufferView * view() const { return bufferview_,get(); }
I'd rather change this one to
a. return a shared_ptr
b. return a weak_ptr
Then I think it should be
boost::shared_ptrBufferView const view() const { return bufferview_; }
No more expensive than before, but may lead to more extensive changes to the
rest of the code base than I'd anticipated.
| and to make it accessible through BufferView:
| boost::weak_ptrBufferView const BufferView::cachablePtr() const
| {
| return pimpl_-owner_-cachablePtr();
| }
and you really need this?
Yes. Only now it would be
boost::shared_ptrBufferView const BufferView::cachablePtr() const
{
return pimpl_-owner_-view();
}
Think of all those times when a BufferView * (or even a BufferView ) is
passed to an inset. It makes no sense at all to pass a shared_ptr in these
cases, but if the inset wants to cache this BufferView * then it can do so as
struct Inset::Cache {
boost::weak_ptrBufferView view_;
}
Inset::Cache * cache_;
cache_-view_ = bv-cachablePtr();
This cache stuff has been bugging me for ages. I'd really like to bury it
properly.
Angus
Re: caching BufferView (again)
On Thursday 01 August 2002 12:44 pm, Angus Leeming wrote:
Yes. Only now it would be
boost::shared_ptrBufferView const BufferView::cachablePtr() const
{
return pimpl_-owner_-view();
}
Sorry. This is FUD, as André might say.
bv-owner()-view()
is sufficient.
Angus
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 11:53:09AM +0100, Angus Leeming wrote: While we are at it: Can anybody explain me the advantages of multiple buffer views vs multiple LyX processes? Sure. A single LyXView can have multiple BufferViews. Think, in emacs terms, of C-x 2 instead of C-x 5. I don't know emacs. What's C-x 2 and C-x 5 doing? [I don't even use multiple buffers in vim.] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: Clearly when we move to multiple / changing BufferViews this is going to lead to nasty problems. Andre While we are at it: Can anybody explain me the advantages of Andre multiple buffer views vs multiple LyX processes? Andre Which kind of convienence would that buy us? Cut and paste between different views JMarc
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 01:54:36PM +0200, Lars Gullik Bjønnes wrote: View different parts of the same document at the same time... In a split main LyX canvas or using several windows? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
Angus Leeming [EMAIL PROTECTED] writes:
| On Thursday 01 August 2002 12:53 pm, Lars Gullik Bjønnes wrote:
| It appears you aren't against the basic idea. Good.
| I'd like, therefore, to change the LyXView store
| public:
|/// return the current buffer view
|BufferView * view() const { return bufferview_,get(); }
I'd rather change this one to
a. return a shared_ptr
b. return a weak_ptr
| Then I think it should be
| boost::shared_ptrBufferView const view() const { return bufferview_; }
| No more expensive than before, but may lead to more extensive changes to the
| rest of the code base than I'd anticipated.
| and to make it accessible through BufferView:
| boost::weak_ptrBufferView const BufferView::cachablePtr() const
| {
|return pimpl_-owner_-cachablePtr();
| }
and you really need this?
| Yes. Only now it would be
| boost::shared_ptrBufferView const BufferView::cachablePtr() const
| {
| return pimpl_-owner_-view();
| }
| Think of all those times when a BufferView * (or even a BufferView ) is
| passed to an inset. It makes no sense at all to pass a shared_ptr in these
| cases, but if the inset wants to cache this BufferView * then it can do so as
This is where we disagree... it think it makes perfect sense to
_always_ pass a shared_ptr.
And if the caller needs to cache the BufferView it should do that with
a weak_ptr.
(And when using it could be turned back into a shared_ptr if needed.)
--
Lgb
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | Ah. I did not notice it... Note that you should always add a Lars space | after #! Lars Why? Autoconf info recommends it: Also, include a space after the exclamation point in interpreter specifications, like this: #! /usr/bin/perl If you omit the space before the path, then 4.2BSD based systems (such as Sequent DYNIX) will ignore the line, because they interpret `#! /' as a 4-byte magic number. I'm not sure we would ever suffer from this problem, but working around it never hurts. JMarc
Re: caching BufferView (again)
On Thursday 01 August 2002 1:26 pm, Andre Poenitz wrote: I don't know emacs. What's C-x 2 and C-x 5 doing? C-x 2. Split the current window horizontally into two separate work areas. C-x 5. Create a new window. [I don't even use multiple buffers in vim.] No, I find it easier to use several consoles with vi too. But then again I'm a vidiot. Angus
Re: caching BufferView (again)
On Thursday 01 August 2002 1:31 pm, Lars Gullik Bjønnes wrote:
| Think of all those times when a BufferView * (or even a BufferView ) is
| passed to an inset. It makes no sense at all to pass a shared_ptr in
| these cases, but if the inset wants to cache this BufferView * then it
| can do so as
This is where we disagree... it think it makes perfect sense to
_always_ pass a shared_ptr.
Well let's agree to differ on practical grounds then. I am /not/ going to
change 1 inset classes s/BufferView */boost::shared_ptrBufferView /
plus all associated changes when perhaps one or two things might possibly
want the shared_ptr not the thing it points to.
Maybe if André's great unification project comes off then this would be
easier since it looks like there'll be a single LyX inset that can hold any
other inset, à la mathed.
And if the caller needs to cache the BufferView it should do that with
a weak_ptr.
Yes.
Anyway you've already shown me how to do this minimally.
boost::shared_ptrBufferView const LyXView::view() const
{ return bufferview_; }
boost::weak_ptrBufferView cached_view;
cached_view = bv-owner()-view();
Angus
Re: caching BufferView (again)
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, Aug 01, 2002 at 01:54:36PM +0200, Lars Gullik Bjønnes wrote: View different parts of the same document at the same time... | In a split main LyX canvas or using several windows? Both... and you would be able to switch back and forth... editing a bit here and a bit there. You cannot do that when running two instances. -- Lgb
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 12:56, Lars Gullik Bjønnes wrote: no but... sys.stderr.write(same_format); does not exactly tell a lot... Then we change it to no_convertion_because_same_format or some name that is more expressive. There is a reason why gettext is not using this method... Notice that lyx2lyx is a just a simple converter, _all_ messages goes to standard error, and _all_ are error or warning diagnosis. gettext wasn't done with those kinds of problems in mind, or else we wouldn't need all its complexity. From pygettext: ** Many systems (Solaris, Linux, Gnu) provide extensive tools that ease the internationalization of C programs. Most of these tools are independent of the programming language and can be used from within Python programs. Martin von Loewis' work[1] helps considerably in this regard. There's one problem though; xgettext is the program that scans source code looking for message strings, but it groks only C (or C++). Python introduces a few wrinkles, such as dual quoting characters, triple quoted strings, and raw strings. xgettext understands none of this. Enter pygettext, which uses Python's standard tokenize module to scan Python source code, generating .pot files identical to what GNU xgettext[2] generates for C and C++ code. From there, the standard GNU tools can be used. ** -- José Abílio
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: José From pygettext: José ** José There's one problem though; xgettext is the program that scans José source code looking for message strings, but it groks only C (or José C++). Python introduces a few wrinkles, such as dual quoting José characters, triple quoted strings, and raw strings. xgettext José understands none of this. gettext 0.11.4 handles python, I believe. JMarc
Iterating over insets: a question
Before I dive into this caching stuff I'd like to finish the preview clean-up
that started it off.
The code below iterates over only top level insets that are owned directly
by the Buffer.
void Previews::generateBufferPreviews(Buffer const buffer) const
{
PreviewLoader ploader = loader(buffer);
Buffer::inset_iterator it = buffer.inset_const_iterator_begin();
Buffer::inset_iterator end = buffer.inset_const_iterator_end();
for (; it != end; ++it) {
(*it)-addPreview(ploader);
}
ploader.startLoading();
}
How should I loop over all insets? Do I:
1. Loop from outside
for (; it != end; ++it) {
(*it)-addPreview(ploader);
// add some sub-loop
}
2. Overload addPreview in container insets (text, tabular, collapsable any
more?)
Regards,
Angus
Incidentally, what's the preferred STL algorithm for
for (; it != end; ++it) {
(*it)-addPreview(ploader);
}
?
Re: lyx2lyx final touch (before commiting)
José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: José What other files do I need to add? José Makefile.am? Yes, probably, but Lars knows better about that José Changelog? No José .cvsignore? If you add Makefile.am, you will at least need Makefile.in in there José Jean-Marc? :-) Please do not 'cvs add' me in this directory. JMarc
Re: lyxconvert: version 0.0.2
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre But I really don't care what language is used to implement Andre something. So if nwe nee auto-detection we should look at the Andre contents. OK, it was probably a bad idea. JMarc
Re: Iterating over insets: a question
Angus Leeming [EMAIL PROTECTED] writes:
| Before I dive into this caching stuff I'd like to finish the preview clean-up
| that started it off.
| The code below iterates over only top level insets that are owned directly
| by the Buffer.
| void Previews::generateBufferPreviews(Buffer const buffer) const
| {
| PreviewLoader ploader = loader(buffer);
| Buffer::inset_iterator it = buffer.inset_const_iterator_begin();
| Buffer::inset_iterator end = buffer.inset_const_iterator_end();
| for (; it != end; ++it) {
| (*it)-addPreview(ploader);
| }
| ploader.startLoading();
| }
| How should I loop over all insets? Do I:
| 1. Loop from outside
| for (; it != end; ++it) {
| (*it)-addPreview(ploader);
| // add some sub-loop
| }
| 2. Overload addPreview in container insets (text, tabular, collapsable any
| more?)
| Regards,
| Angus
| Incidentally, what's the preferred STL algorithm for
| for (; it != end; ++it) {
| (*it)-addPreview(ploader);
| }
some variant of
for_each(begin, end, bind(Type::addPreview, ref(ploader)));
The problem iis the (*it) ... had it been just a (it) then it would
have been easy...
--
Lgb
Re: Iterating over insets: a question
On Thursday 01 August 2002 2:58 pm, Lars Gullik Bjønnes wrote:
| Incidentally, what's the preferred STL algorithm for
| for (; it != end; ++it) {
| (*it)-addPreview(ploader);
| }
some variant of
for_each(begin, end, bind(Type::addPreview, ref(ploader)));
Oh, clever! But why does this work on (*it) not (it)?
The problem iis the (*it) ... had it been just a (it) then it would
have been easy...
show me!
Could I get you to bite about the iterating over insets question too?
A
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 02:29:16PM +0200, Jean-Marc Lasgouttes wrote:
Andre While we are at it: Can anybody explain me the advantages of
Andre multiple buffer views vs multiple LyX processes?
Andre Which kind of convienence would that buy us?
Cut and paste between different views
This would be possible if we had a flawless lyx-tex-lyx round trip which
is important for a few other things too.
[Latest annoying thing I found which would be solvable by that:
If you have a 'proof' style in a home made layout which insert
\begin{proof}...\end{proof} and convert it to some common layout like
'article' which does not have these things, the \begin...\end simply
vanishes. This could be solved by a lyx(homemade)-tex-lyx(article)
roundtrip that would convert the \begin{} to ERT]
BTW: How do I define a layout 'definition' that might span several
paragraphs? And how would that work with two definitions immediately after
each other?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: Iterating over insets: a question
Angus Leeming [EMAIL PROTECTED] writes:
| On Thursday 01 August 2002 2:58 pm, Lars Gullik Bjønnes wrote:
| Incidentally, what's the preferred STL algorithm for
|for (; it != end; ++it) {
|(*it)-addPreview(ploader);
|}
some variant of
for_each(begin, end, bind(Type::addPreview, ref(ploader)));
| Oh, clever! But why does this work on (*it) not (it)?
that's the problem...
--
Lgb
Re: lyx2lyx final touch (before commiting)
On Thursday 01 August 2002 14:54, Jean-Marc Lasgouttes wrote: José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: José What other files do I need to add? José Makefile.am? Yes, probably, but Lars knows better about that Is it ok to put only the bare files? Something I saw that could be useful here (for python files) is http://www.gnu.org/manual/automake-1.6.1/html_chapter/automake_11.html José Changelog? No Ok. José .cvsignore? If you add Makefile.am, you will at least need Makefile.in in there There are several others also. José Jean-Marc? :-) Please do not 'cvs add' me in this directory. Then I will put you in .cvsignore, is that acceptable for you? JMarc -- José Abílio
Re: caching BufferView (again)
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Thu, Aug 01, 2002 at 02:29:16PM +0200, Jean-Marc Lasgouttes
Andre wrote: While we are at it: Can anybody explain me the
Andre advantages of multiple buffer views vs multiple LyX processes?
Andre Which kind of convienence would that buy us?
Cut and paste between different views
Andre This would be possible if we had a flawless lyx-tex-lyx round
Andre trip which is important for a few other things too.
I do not think this is ever going to happen. There is some information
which is _not_ written in .tex, like for example whether a float is
open or collapsed.
Andre [Latest annoying thing I found which would be solvable by that:
Andre If you have a 'proof' style in a home made layout which insert
Andre \begin{proof}...\end{proof} and convert it to some common
Andre layout like 'article' which does not have these things, the
Andre \begin...\end simply vanishes. This could be solved by a
Andre lyx(homemade)-tex-lyx(article) roundtrip that would convert
Andre the \begin{} to ERT]
Keeping \begin{proof}...\end{proof} is not possible if your article
layout does not support it, anyway... What do you propose.
I think trying to go through .tex to solve such problems is misguided,
anyway.
Andre BTW: How do I define a layout 'definition' that might span
Andre several paragraphs? And how would that work with two
Andre definitions immediately after each other?
All layouts which correspond to latex environment will span several
paragraphs. There is not clean way to split such paragraph (and this
is an old problem that drew lots of complaints) in separate
environments. A solution would be to add to paragraph layout a
checkbox 'end layout here', but this is really not an intuitive
solution. This is a real problem we have with our linear description
of layouts.
JMarc
Re: lyx2lyx final touch (before commiting)
José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: José On Thursday 01 August 2002 14:54, Jean-Marc Lasgouttes wrote: José == José Abílio Oliveira Matos [EMAIL PROTECTED] writes: José What other files do I need to add? José Makefile.am? Yes, probably, but Lars knows better about that José Is it ok to put only the bare files? Something I saw that José could be useful here (for python files) is José http://www.gnu.org/manual/automake-1.6.1/html_chapter/automake_11.html In which automake version has this been added? JMarc
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 04:29:46PM +0200, Jean-Marc Lasgouttes wrote:
Andre This would be possible if we had a flawless lyx-tex-lyx round
Andre trip which is important for a few other things too.
I do not think this is ever going to happen. There is some information
which is _not_ written in .tex, like for example whether a float is
open or collapsed.
I would not be too sure about that. We could write everything to .tex if
a certain flag is set and honour this on read-back. I was actually thinking
about using something similar to save the locked state of math insets
(i.e. write a \lyxlock 'marker' to the .lyx, but not to .tex).
Andre [Latest annoying thing I found which would be solvable by that:
Andre If you have a 'proof' style in a home made layout which insert
Andre \begin{proof}...\end{proof} and convert it to some common
Andre layout like 'article' which does not have these things, the
Andre \begin...\end simply vanishes. This could be solved by a
Andre lyx(homemade)-tex-lyx(article) roundtrip that would convert
Andre the \begin{} to ERT]
Keeping \begin{proof}...\end{proof} is not possible if your article
layout does not support it, anyway... What do you propose.
I think trying to go through .tex to solve such problems is misguided,
anyway.
Why? It's the only clean solution I can imagine. As we do not have to parse
arbitrary .tex but only things generated by ourselves I'd even think this
is feasible.
Andre BTW: How do I define a layout 'definition' that might span
Andre several paragraphs? And how would that work with two
Andre definitions immediately after each other?
All layouts which correspond to latex environment will span several
paragraphs. There is not clean way to split such paragraph (and this
is an old problem that drew lots of complaints) in separate
environments. A solution would be to add to paragraph layout a
checkbox 'end layout here', but this is really not an intuitive
solution. This is a real problem we have with our linear description
of layouts.
Ok. (Or not ok, but now I am sure I did not miss something crucial).
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx final touch (before commiting)
On Thursday 01 August 2002 15:32, Jean-Marc Lasgouttes wrote: http://www.gnu.org/manual/automake-1.6.1/html_chapter/automake_11.html In which automake version has this been added? The documentation for 1.4p5 doesn't show it. So this answers your question. :-) JMarc -- José Abílio
Re: caching BufferView (again)
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Thu, Aug 01, 2002 at 04:29:46PM +0200, Jean-Marc Lasgouttes
Andre wrote: This would be possible if we had a flawless
Andre lyx-tex-lyx round trip which is important for a few other
Andre things too.
I do not think this is ever going to happen. There is some
information which is _not_ written in .tex, like for example
whether a float is open or collapsed.
Andre I would not be too sure about that. We could write everything
Andre to .tex if a certain flag is set and honour this on read-back.
Why do you need .tex?? Just output .lyx to the clipboard and parse it
back? I just do not understand the need for an extra format.
Andre I was actually thinking about using something similar to save
Andre the locked state of math insets (i.e. write a \lyxlock
Andre 'marker' to the .lyx, but not to .tex).
What is the locked state?
I think trying to go through .tex to solve such problems is
misguided, anyway.
Andre Why? It's the only clean solution I can imagine. As we do not
Andre have to parse arbitrary .tex but only things generated by
Andre ourselves I'd even think this is feasible.
Again: what do you want to do with your \begin{proof}...\end{proof}?
Generate ERT that will not even compile?
JMarc
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 04:46:22PM +0200, Jean-Marc Lasgouttes wrote:
Andre I would not be too sure about that. We could write everything
Andre to .tex if a certain flag is set and honour this on read-back.
Why do you need .tex?? Just output .lyx to the clipboard and parse it
back? I just do not understand the need for an extra format.
Because .tex contains the \begin{proof}...\end{proof} whereas .lyx only has
\layout proof which is changed to \layout standard if read tith the wrong class
and not to a sequence ert-standard-ert.
Apart from that, .tex is not exactly an 'extra format', is it?
Andre I was actually thinking about using something similar to save
Andre the locked state of math insets (i.e. write a \lyxlock
Andre 'marker' to the .lyx, but not to .tex).
What is the locked state?
One can 'lock' insets to make them into a unit concerning 'ordinary cursor
movement'. Unfortuantely, that state is not saved (but I intend to change
that).
I think trying to go through .tex to solve such problems is
misguided, anyway.
Andre Why? It's the only clean solution I can imagine. As we do not
Andre have to parse arbitrary .tex but only things generated by
Andre ourselves I'd even think this is feasible.
Again: what do you want to do with your \begin{proof}...\end{proof}?
Generate ERT that will not even compile?
I want the proof survive the cycle mylayout-otherlayout-mylayout.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Thu, Aug 01, 2002 at 04:46:22PM +0200, Jean-Marc Lasgouttes
Andre wrote: I would not be too sure about that. We could write
Andre everything to .tex if a certain flag is set and honour this on
Andre read-back.
Why do you need .tex?? Just output .lyx to the clipboard and parse
it back? I just do not understand the need for an extra format.
Andre Because .tex contains the \begin{proof}...\end{proof} whereas
Andre .lyx only has \layout proof which is changed to \layout
Andre standard if read tith the wrong class and not to a sequence
Andre ert-standard-ert.
Andre Apart from that, .tex is not exactly an 'extra format', is it?
I really think that lyx-tex conversion cannot be one-to-one exactly.
So you are going to loose information. What about quote insets? What
you are going to propose is to add so much meta-information to .tex
that you will have invented a new hybrid fileformat---which we may
call .tyx ;)---, which will be yet another format that lyx has to
understand. And I do not see why the 'proof' environment should
survive translation, since the article document would then not be
typesetable.
An idea I had in mind some time ago was, when a layout cannot be
translated, to do as if it was 'standard', but remember the layout
name so that it does not get lost. In your case, it would look like
Standard, but be written as 'proof' in the lyx file. Certainly much
easier than what you propose.
Andre One can 'lock' insets to make them into a unit concerning
Andre 'ordinary cursor movement'. Unfortuantely, that state is not
Andre saved (but I intend to change that).
Can you give examples? Were you jealous not to have 'locking insets'
in mathed?
JMarc
Re: lyx2lyx final touch (before commiting)
On Thursday 01 August 2002 15:58, Garst R. Reese wrote: Just a tiny question. When I look in my lyxdocs directory, how do I know if a file needs conversion? Do you want an option for lyx2lyx to give you that information? That is easy to do, and we do it now, just look to the first lines of the lyx file, there you will see \lyxformat x[.,]?yz xyz is the fileformat. We already search this information, so we just need to show it. Was that your question? :-) Garst -- José Abílio
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 05:02:42PM +0200, Jean-Marc Lasgouttes wrote:
Andre Apart from that, .tex is not exactly an 'extra format', is it?
I really think that lyx-tex conversion cannot be one-to-one exactly.
I don't think this either.
So you are going to loose information. What about quote insets? What you
are going to propose is to add so much meta-information to .tex that you
will have invented a new hybrid fileformat---which we may call .tyx
;)---, which will be yet another format that lyx has to understand.
Ah... ok. So that you mean by 'new file format'. But we have that already,
it's called '.tex exported by LyX'. We put there a \def\LyX{...} in the
preamble etc.
And I do not see why the 'proof' environment should survive
translation, since the article document would then not be typesetable.
Being able to typeset something and being able to edit something are
different things. I've been writeng .tex on machines without latex
installed...
An idea I had in mind some time ago was, when a layout cannot be
translated, to do as if it was 'standard', but remember the layout name
so that it does not get lost. In your case, it would look like Standard,
but be written as 'proof' in the lyx file.
But this breaks as soon as different style define 'proof' differently.
Certainly much easier than what you propose.
I doubt that. All we need is a parser that can read the kind of .tex we
produce. [And of course the panacea is inset unification followed by
re-use the math parser, but I think you got already tired of that song]
Andre One can 'lock' insets to make them into a unit concerning Andre
'ordinary cursor movement'. Unfortuantely, that state is not Andre saved
(but I intend to change that).
Can you give examples?
You could lock a \mathbf{x} and pass over it with a single Right. If the
inset is not locked, it takes three(!) Right which is not really nice.
Were you jealous not to have 'locking insets' in mathed?
*grin*
No. The reason is really to have a means to make the additional cursor
positions that resulted from the fonts as insets change unvisible if not
needed. Of course, this is only sensible if the lock state is saved.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx final touch (before commiting)
On Thursday 01 August 2002 16:24, Garst R. Reese wrote: I guess my question is: How does an ordinary user know when to invoke lyx2lyx? It shouldn't, IMHO. By ordinary user, I mean one who may not even know how to look at a lyx file other than with lyx, and knows nothing about \lyxformat. Somebody sends them an old lyx file. They open it in their brand new lyx and it looks funny or crashes. Can (does) lyx itself provide a message guiding them to lyx2lyx or giving them the option to invoke it from lyx? It should be lyx to do that work, again IMHO. Thanks, Garst -- José Abílio
Re: caching BufferView (again)
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
So you are going to loose information. What about quote insets?
What you are going to propose is to add so much meta-information to
.tex that you will have invented a new hybrid fileformat---which we
may call .tyx ;)---, which will be yet another format that lyx has
to understand.
Andre Ah... ok. So that you mean by 'new file format'. But we have
Andre that already, it's called '.tex exported by LyX'. We put there
Andre a \def\LyX{...} in the preamble etc.
No, all things that we add to the tex files are useful to LaTeX
itself, and it parses them (just a few macros of our own). What you
propose would add some meta-information (this `` was really a quote
inset) which extends LaTeX _format_.
An idea I had in mind some time ago was, when a layout cannot be
translated, to do as if it was 'standard', but remember the layout
name so that it does not get lost. In your case, it would look like
Standard, but be written as 'proof' in the lyx file.
Andre But this breaks as soon as different style define 'proof'
Andre differently.
On contrary. If for some document class I have the latex environment
proof and on the other one prf, then what is important is that
for the two classes the layout name is the same (Proof, in this
case). So going through latex, gives the false impression that the two
styles are different and add some \begin{proof}...\end{proof} whereas
\begin{prf}...\end{prf} is the one which would be recognized.
Basically, what I propose is to rely on the fact that layouts with
same name have same meaning. I think it is much less error prone than
expecting that the latex names are the same.
Certainly much easier than what you propose.
Andre I doubt that. All we need is a parser that can read the kind of
Andre .tex we produce. [And of course the panacea is inset
Andre unification followed by re-use the math parser, but I think
Andre you got already tired of that song]
I would actually like to see 'reuse math parser' instead of using reLyX.
Andre You could lock a \mathbf{x} and pass over it with a single
Andre Right. If the inset is not locked, it takes three(!) Right
Andre which is not really nice.
And when does the locking take place?
JMarc
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 05:33:17PM +0200, Jean-Marc Lasgouttes wrote:
Andre Ah... ok. So that you mean by 'new file format'. But we have
Andre that already, it's called '.tex exported by LyX'. We put there
Andre a \def\LyX{...} in the preamble etc.
No, all things that we add to the tex files are useful to LaTeX
itself, and it parses them (just a few macros of our own). What you
propose would add some meta-information (this `` was really a quote
inset) which extends LaTeX _format_.
Hm. Maybe you are right here. But does it hurt to add a \def\lyxquote#1{}
in the preamble and \lyxquote{...} in the text?
An idea I had in mind some time ago was, when a layout cannot be
translated, to do as if it was 'standard', but remember the layout
name so that it does not get lost. In your case, it would look like
Standard, but be written as 'proof' in the lyx file.
Andre But this breaks as soon as different style define 'proof'
Andre differently.
Basically, what I propose is to rely on the fact that layouts with
same name have same meaning. I think it is much less error prone than
expecting that the latex names are the same.
[Why? - But the poitn is mood, both approaches will break in certain
circumstances]
Andre I doubt that. All we need is a parser that can read the kind of
Andre .tex we produce. [And of course the panacea is inset
Andre unification followed by re-use the math parser, but I think
Andre you got already tired of that song]
I would actually like to see 'reuse math parser' instead of using reLyX.
What else did I say?
[In case you meant it the other way round: reLyX is working but
un-maintained and I see no change soon. The math parser is working,
maintained, and about a third the size of reLyX]
And when does the locking take place?
As soon as the user invokes LFUN_INSET_TOGGLE (curetnly in front of the
inset to be locked, but I'll change theat to 'after' as the it would be
more natural to type C-e W space C-I to insert a calligraphic 'W'.
And of course things like that could be bound to command-sequences.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Hm. Maybe you are right here. But does it hurt to add a
Andre \def\lyxquote#1{} in the preamble and \lyxquote{...} in the
Andre text?
We are going to have a lot of these. But, yes, everything is possible.
I would actually like to see 'reuse math parser' instead of using
reLyX.
Andre What else did I say?
I just pointed out that I am not tired yet of this particular part of
your song.
And when does the locking take place?
Andre As soon as the user invokes LFUN_INSET_TOGGLE (curetnly in
Andre front of the inset to be locked, but I'll change theat to
Andre 'after' as the it would be more natural to type C-e W space
Andre C-I to insert a calligraphic 'W'.
It would be better to do it as the rest of lyx does :) The current
algorithm is:
- if there is an inset after cursor, toggle it
- otherwise, if we are inside an inset, close it, and place cursor
after it
- otherwise do nothing
So your example would become C-e W C-i, which is (1) simpler, and (2)
similar to what you would do with an ERT inset.
JMarc
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 06:00:31PM +0200, Jean-Marc Lasgouttes wrote: - if there is an inset after cursor, toggle it - otherwise, if we are inside an inset, close it, and place cursor after it - otherwise do nothing So your example would become C-e W C-i, which is (1) simpler, and (2) similar to what you would do with an ERT inset. It incidently works like that right now ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyxconvert: version 0.0.2
On Thu, Aug 01, 2002 at 11:49:15AM +0200, Jean-Marc Lasgouttes wrote: Dekel == Dekel Tsur [EMAIL PROTECTED] writes: Dekel How about putting the files on CVS, in lib/lyxconvert/ ? We Dekel only need to made the changes so make install will create a Dekel symbolic link /usr/bin/lyxconvert for Dekel LYXDIR/lyxconvert/lyxconvert.py Will symbolic links work under cygwin? Yes. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
André you've just swallowed my Vector!
Latest cvs. I have a macro Vector defined as:
\begin_inset FormulaMacro
\newcommand{\Vector}[1]{\boldsymbol #1}
{#1}
\end_inset
Attached is what LyX makes of it. Moreover, previews fail with
! Undefined control sequence.
recently read \Vector
l.167 $\Vector
{a}=\left(a,b\right)$
is it something to do with the additional parameter perhaps? do ya wanna
test case?
Angus
Vector.png
Description: PNG image
Re: André you've just swallowed my Vector!
On Thursday 01 August 2002 5:30 pm, Angus Leeming wrote:
\begin_inset FormulaMacro
\newcommand{\Vector}[1]{\boldsymbol #1}
{#1}
\end_inset
is it something to do with the additional parameter perhaps?
Yes, if I remove the additional parameter, all is Ok.
Angus
Re: lyxconvert: version 0.0.2
Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes: Will symbolic links work under cygwin? Kayvan Yes. Thanks. Good to know. JMarc
Re: Action diff - look and diss
On Thu, Aug 01, 2002 at 08:20:44AM +0200, Andre Poenitz wrote: Sure, but I would bet that mathed has some things easier on it compared to the requirements of insettabular/insettext. No-one (except Juergen I guess) really knows what they are though. More FUD. I think there will be a time when I can't stand it anymore. I think it's a bit unfair to call it FUD ! The requirements are theoretical exactly the same. That mathed does not implement everything (like \multicolumn for arrays) is no technical problem but a result of my limited time. You can not reasonably expect me implementing within one year what has taken six years and three or four people on average for the rest of LyX. This is exactly my point, the job you're willing to undertake is a huge one ... (again ;) How would you deal with tab inside an insettext inside a cell ? How do you make sure a keypress in the dummy cell position enters the child inset, unless it's one that needs handling differenty ? If there is no locking inset as such, how do you unlock it when I paste some text elsewhere in the owner with the mouse button ? How do you make sure asynchrnous geometry changes are propogated backwards properly ? I'm sure you've got solutions to all of these and more I don't even think of, but it doesn't mean you will necessary be able to solve them all simply. Put it this way: I expect such a rewrite to take years, regardless of the superiority of the approach regards john -- The simpler it is, the harder it is. - Tim Van Holder
Re: Action diff - look and diss
On Thu, Aug 01, 2002 at 12:08:29PM +0200, Jean-Marc Lasgouttes wrote: It looks nice to me and I do not have many clever comments. A question though: we will be adding lots of objects with virtual methods (or lots of virtual methods to exisiting insets). What is the price we will have to pay for this in terms of bloat, link time, and startup time (remember the link-at-startup problems that kde has)? Difficult to say :) Anyway, I think I will leave this one again for now. I certainly don't have the energy to deal with all the issues. It was fun playing with it... john -- The simpler it is, the harder it is. - Tim Van Holder
Re: key combinations not showing up...
On Thu, Aug 01, 2002 at 09:13:24AM +0200, Andre Poenitz wrote: Andre, why is this ? Hm... because no every inset displays its info yet. I usually change that as soon as I have to touch the inset but I usually don't go through every 30+ insets in one swoop. OK. But I think that's not what Pierre was asking for, he wanted to have the shortcut displayed in the minibuffer. That's a differnt issue and never was done by mathed, so I did not break it. He was asking for both actually, essentially regards john -- The simpler it is, the harder it is. - Tim Van Holder
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thu, Aug 01, 2002 at 12:41:23PM +0200, Jean-Marc Lasgouttes wrote: José What about the present solution: #!/usr/bin/env python Ah. I did not notice it... Note that you should always add a space after #! Is there really a system that still uses the 4-byte magic but the env trick works too ?? regards john -- The simpler it is, the harder it is. - Tim Van Holder
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: Lars has mentioned using boost::weak_ptr in just such a context and I'd like to do so here. From the boost docs = http://www.boost.org/libs/smart_ptr/weak_ptr.htm How can an inset survive the last view onto a document ? regards john -- The simpler it is, the harder it is. - Tim Van Holder
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 01:17:35PM +0200, Andre Poenitz wrote: While we are at it: Can anybody explain me the advantages of multiple buffer views vs multiple LyX processes? Drag and drop cross-document references Multiple views on a single document Resource usage LyX-content cut and paste (we could do this already with a clipboard type, but it's a lot more hassle) etc. john -- The simpler it is, the harder it is. - Tim Van Holder
Re: the patch...
On środa 31 lipiec 2002 05:15 pm, Martin Vermeer wrote: On Wed, Jul 31, 2002 at 01:26:23PM +0200, Andre Poenitz wrote: On Tue, Jul 30, 2002 at 08:59:24PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | + * configure.m4: | + * ui/default.ui: make math-extern a bit more visible in Edit-Math | + | + * bind/math.bind: remove some strange bindings for Ø and Å Empty-set and Ångstrøm. No, it was not \emptyset, it was the slashed O, which seem to be quite different. And I am not really sure why math need a Angstrom short cut as units are usually set in text mode... Andre' No, it was Oersted (the magnetic field strenghth unit and famous Danish physicist / Earth magnetic field satellite mission). A physical unit just like Å. IIRC the reason for including these was to allow people with non-danish/scand keyboards to type physics manuscripts easily (like, how would you do this on a USASCII keyboard?) Typing values + units in text mode is your choice and OK with me, I prefer mathed (is either of these formally correct?). I think that the really proper solution is SIunits package. I'm using it for everything and it mostly rocks. Some kind of support for it would be cool. Cheers, Kuba Ober
Re: caching BufferView (again)
On Thursday 01 August 2002 6:12 pm, John Levon wrote: How can an inset survive the last view onto a document ? If it caches the last BufferView * passed to draw, that BufferView is destroyed but another one still exists and then tries to use this BufferView * And that's not exactly exotic is it? Angus
Re: lyx-devel src/graphics/: ChangeLog Makefile.am PreviewLoader.C ...
Log message:
Previews for \input insets.
Refactor code common to InsetInclude and InsetFormula into a new
PreviewedInset class.
caveats and notes:
1. insets inside insets will not be converted to previews when the document
is first loaded because
void Previews::generateBufferPreviews(Buffer const buffer) const
{
PreviewLoader ploader = loader(buffer);
Buffer::inset_iterator it = buffer.inset_const_iterator_begin();
Buffer::inset_iterator end = buffer.inset_const_iterator_end();
for (; it != end; ++it) {
(*it)-addPreview(ploader);
}
ploader.startLoading();
}
loops only over top level insets. So include insets inside floats don't get
previews on start-up.
2. Edit an existing (or create a new) \input inset and a preview will be
generated successfully. However, I had to hack the code in InsetInclude:
string const InsetInclude::PreviewImpl::latexString() const
{
if (!view() || !view()-buffer())
return string();
ostringstream os;
parent().latex(view()-buffer(), os, false, false);
// This fails if the file has a relative path.
// return os.str().c_str();
// I would /really/ like not to do this...
// HELP!
string command;
string file = rtrim(split(os.str().c_str(), command, '{'), });
if (!AbsolutePath(file))
file = MakeAbsPath(file, view()-buffer()-filePath());
ostringstream out;
out command '{' file '}' endl;
return out.str().c_str();
}
3. I haven't added a bool wantPreview flag to the InsetInclude::Params yet,
nor to the Include dialog. Ie, if previews are activated, it'll try and
generate a preview for a \input inset come what may.
4. The cached BufferView thingie.
Everything else is fine ;-) Attached is a screenshot that I got by editing an
existing input inset, toggling the type to include, applied, toggled back to
input, applied, sat back and watched.
Angus
screenshot.png
Description: GIF image
Re: caching BufferView (again)
Angus Leeming [EMAIL PROTECTED] writes: On Thursday 01 August 2002 1:26 pm, Andre Poenitz wrote: I don't know emacs. What's C-x 2 and C-x 5 doing? C-x 2. Split the current window horizontally into two separate work areas. It appears you have become alien to either Emacs or the horizon. Ok, Since I can provide this info very easily: C-x 2 runs the command split-window-vertically which is an interactive compiled Lisp function in `window'. It is bound to C-x 2, menu-bar files split-window. (split-window-vertically optional ARG) Split current window into two windows, one above the other. The uppermost window gets ARG lines and the other gets the rest. Negative arg means select the size of the lowermost window instead. With no argument, split equally or close to it. Both windows display the same buffer now current. If the variable `split-window-keep-point' is non-nil, both new windows will get the same value of point as the current window. This is often more convenient for editing. Otherwise, we chose window starts so as to minimize the amount of redisplay; this is convenient on slow terminals. The new selected window is the one that the current value of point appears in. The value of point can change if the text around point is hidden by the new mode line. [back] C-x 5. Create a new window. (Emacs calls separate X windows frames): Global Bindings Starting With C-x 5: key binding --- --- C-x 5 o other-frame C-x 5 0 delete-frame C-x 5 1 delete-other-frames C-x 5 2 make-frame-command C-x 5 . find-tag-other-frame C-x 5 d dired-other-frame C-x 5 r find-file-read-only-other-frame C-x 5 C-f find-file-other-frame C-x 5 f find-file-other-frame C-x 5 b switch-to-buffer-other-frame C-x 5 m compose-mail-other-frame [back] C-x 5 2 runs the command make-frame-command which is an interactive compiled Lisp function in `frame'. It is bound to C-x 5 2, menu-bar files make-frame. (make-frame-command) Make a new frame, and select it if the terminal displays only one frame. [back] [I don't even use multiple buffers in vim.] No, I find it easier to use several consoles with vi too. But then again I'm a vidiot. What's your coefficient of viscosity? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: caching BufferView (again)
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Thu, Aug 01, 2002 at 02:29:16PM +0200, Jean-Marc Lasgouttes
Andre wrote: While we are at it: Can anybody explain me the
Andre advantages of multiple buffer views vs multiple LyX processes?
Andre Which kind of convienence would that buy us?
Cut and paste between different views
Andre This would be possible if we had a flawless lyx-tex-lyx round
Andre trip which is important for a few other things too.
I do not think this is ever going to happen. There is some information
which is _not_ written in .tex, like for example whether a float is
open or collapsed.
That would be the easiest exercise:
\begin{figure}
%LyX: collapse figure
[...]
Just define a nice syntax for LyX metacomments.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Create a new file with File open
On Thu, Aug 01, 2002 at 12:17:08PM +0200, Jean-Marc Lasgouttes wrote: + Buffer * buffer = bufferlist.newFile(filename, ); I thought that the second argument to newFile was a bool. Buffer * BufferList::newFile(string const name, string tname, bool isNamed) Though that obviously shows a little cleanup I can do :) Did you test what happens when one chooses a nonsensical file name (non-existing directory, for example) and then tries to save? Failing to save is OK, crashing lyx is not :) I didn't test, but it works (with some ugliness but that's not appropritate to fix for 1.2 because it's not a regression) Othrwise, I am OK in principle for this patch in 1.2.x. OK regards john -- The simpler it is, the harder it is. - Tim Van Holder
Re: Re: seminar.layout doesn't work as expected
On 30 Jul 2002 10:37:28 +0200 wrote Jean-Marc Lasgouttes [EMAIL PROTECTED]:
On 17 Jul 2002 11:33:15 -0400 wrote German Poo Caaman~o
Since lyx-1.1.6-fix (AFAIR) I've been having some problems with
seminar.layout. I defined frames on my slides, but now one slide
appears with frame and empty, the second one appears with text
(without frame), etc.
Guenter From the attached file I guess, that the problem arises in
Guenter LyX 1.2.0 I have written seminar.layout for 1.1.6.
I just had another look at the example file from the LyX-tips: It is for
1.2.0 and it uses a seminar.layout that is different from mine, i.e. the one
in the contributed stuff section. (I wonder, if the new layout is included
in the standard 1.2.0 distribution. Also, I wonder whether it was written
based on my layout or not knowing it (or even before)...)
The two layouts have a different philosopy in dealing with the bug 341:
environment style vs. command styles for \begin{slide}, \end{slide}
- the two are non-compatible and must not be confused! :-(
- documents writtem with my seminar.layout will not work with the
1.2.0 layout and vice versa. :-(
Guenter
--
G.Milde at physik.tu-dresden.de
autoconf 2.53 and automake 1.6.2
I just upgraded my system to use these and then I tried to build
lyx...
... close to _no_ problems...
Of course since we really want to convert to 2.53 fully some time in
the future I did some changes...
Attached is the patch that show what I did...
There are still some small problems... but nothing that hinders
building lyx.
? auto
? autom4te-2.53.cache
? build
? config.pre:config.h.in:config.post
? qtbuild
? test
? config/config.pre:config.h.in:config.post
? lib/reLyX/autom4te-2.53.cache
Index: acconfig.h
===
RCS file: acconfig.h
diff -N acconfig.h
--- acconfig.h 17 Jul 2002 21:14:03 - 1.26
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,96 +0,0 @@
-/* -*- C++ -*- */
-/* This is the compilation configuration file for LyX. It was generated by
- autoconf's configure. You might want to change some of the defaults if
- something goes wrong during the compilation
-
- * This file is part of
- * ==
- *
- * LyX, the High Level Word Processor
- *
- * Copyright 1995 Matthias Ettrich
- * Copyright 1995-2001 The LyX Team.
- *
- *==*/
-
-#ifndef _CONFIG_H
-#define _CONFIG_H
-
-@TOP@
-
-/* Define as 1 if the MKSTEMP function is declared */
-#undef HAVE_DECL_MKSTEMP
-
-/* Define if you have the function prototype for snprintf(). */
-#undef HAVE_DECL_SNPRINTF
-
-/* Define if you have the function prototype for vsnprintf(). */
-#undef HAVE_DECL_VSNPRINTF
-
-/* Define if you have the function prototype istreambuf_iterator in
- iterator */
-#undef HAVE_DECL_ISTREAMBUF_ITERATOR
-
-@BOTTOM@
-
-/
- ** You should not need to change anything beyond this point */
-
-#ifndef HAVE_STRCHR
-#define strchr(a,b) index(a,b)
-#endif
-
-#ifndef HAVE_MEMMOVE
-#define memmove(a, b, c) bcopy(b, a, c)
-#endif
-
-#ifdef HAVE_MKSTEMP
-#ifndef HAVE_DECL_MKSTEMP
-#if defined (__cplusplus)
-extern C
-#endif
-int mkstemp(char*);
-#endif
-#endif
-
-/* C++ always support the keyword `inline' */
-#if defined inline defined __cplusplus
-/**/#undef inline
-#endif
-
-/* C++ always has a good enough `const' */
-#if defined const defined __cplusplus
-/**/#undef const
-#endif
-
-/* Check on the run if we are using exceptions during this compilation.*/
-#if defined(__sgi) || defined(__GNUC__)
-# ifdef __EXCEPTIONS
-#define USING_EXCEPTIONS
-# endif
-#endif
-
-#if defined(__USLC__) || defined(__SUNPRO_CC) || defined(__COMO__) || defined(__ICL)
-# define USING_EXCEPTIONS
-#endif
-
-#ifdef __EMX__
-#include support/os2_defines.h
-#endif
-
-#if defined(__CYGWIN__) || defined( __CYGWIN32__)
-#include support/nt_defines.h
-#endif
-
-/* Some support for the boost library. */
-/*
- * #ifndef HAVE_LIMITS
- * #define BOOST_NO_LIMITS
- * #endif
- *
- * #ifndef HAVE_SSTREAM
- * #define BOOST_NO_STRINGSTREAM
- * #endif
- */
-
-#endif /* _CONFIG_H */
Index: autogen.sh
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/autogen.sh,v
retrieving revision 1.31
diff -u -p -r1.31 autogen.sh
--- autogen.sh 8 Jul 2002 15:00:54 - 1.31
+++ autogen.sh 1 Aug 2002 22:11:21 -
@@ -1,9 +1,9 @@
#!/bin/sh
ACLOCAL=aclocal
-AUTOHEADER=autoheader
+AUTOHEADER=autoheader -W none -W obsolete
AUTOMAKE=automake -a -c --foreign
-AUTOCONF=autoconf
+AUTOCONF=autoconf -W none -W obsolete
GNUM4=
ACINCLUDE_FILES=lyxinclude.m4 libtool.m4 codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 xforms.m4 qt2.m4 gtk--.m4 gnome--.m4 gnome.m4 pspell.m4 pkg.m4
Index: configure.ac
===
RCS file: configure.ac
diff -N configure.ac
--- /dev/null 1 Jan 1970 00:00:00 -
+++ configure.ac 1 Aug 2002 22:11:21 -
@@ -0,0 +1,328 @@
+dnl Process with autoconf to generate configure script -*- sh -*-
+
+AC_INIT(lyx,1.3.0cvs,[EMAIL PROTECTED])
+AC_PREREQ(2.53)
+AC_CONFIG_SRCDIR(src/main.C)
+AM_CONFIG_HEADER([src/config.h:config/config.pre:src/config.h.in:config/config.post])
+AC_CONFIG_AUX_DIR(config)
+
+PACKAGE=lyx${program_suffix}
+VERSION=1.3.0cvs
+LYX_CHECK_VERSION
+
+AC_CANONICAL_TARGET
+# AC_VALIDATE_CACHE_SYSTEM_TYPE
+
+LYX_VERSION_SUFFIX
+
+AM_INIT_AUTOMAKE($lyxname, $VERSION)
+
+# The list of languages known to LyX
+# This is needed by GNU gettext
+ALL_LINGUAS=bg ca cs da de es eu fi fr he hu it nl no pl pt ro ru sk sl sv tr wa
+
+# fix the value of the prefixes.
+test x$prefix = xNONE prefix=$ac_default_prefix
+test x$exec_prefix = xNONE exec_prefix='${prefix}'
+
+### Set the execute permissions of the various scripts correctly
+for file in config/install-sh config/mkinstalldirs lib/configure ; do
+ chmod 755 ${srcdir}/${file}
+done
+
+### Check for programs
+AC_PROG_MAKE_SET
+AC_PROG_INSTALL
+#AC_PROG_RANLIB
+AC_CHECK_PROG(KPSEWHICH,
Re: autoconf 2.53 and automake 1.6.2
On Fri, Aug 02, 2002 at 12:14:16AM +0200, Lars Gullik Bjønnes wrote: Attached is the patch that show what I did... There are still some small problems... but nothing that hinders building lyx. Did you build qt2 ? Did you try the old tools with your patch ? I'd rather not go through the nightmare again now I've got tools that (just about) work :) john -- The simpler it is, the harder it is. - Tim Van Holder
LyXCursor docs
Please check the stuff I've guessed, and fill in the FIXMEs
thanks
john
Index: lyxcursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxcursor.h,v
retrieving revision 1.25
diff -u -r1.25 lyxcursor.h
--- lyxcursor.h 16 Apr 2002 14:10:36 - 1.25
+++ lyxcursor.h 1 Aug 2002 23:51:19 -
-1,13 +1,11
// -*- C++ -*-
-/* This file is part of
- * ==
+/**
+ * \file lyxcursor.h
+ * Copyright 1995-2001 the LyX Team
+ * Read the file COPYING
*
- * LyX, The Document Processor
- *
- * Copyright 1995 Matthias Ettrich
- * Copyright 1995-2001 The LyX Team.
- *
- * == */
+ * \author Matthias Ettrich
+ */
#ifndef LYXCURSOR_H
#define LYXCURSOR_H
-21,79 +19,109
class Paragraph;
class Row;
-/** All these variables should be explained. Matthias?
+/**
+ * The cursor class describes the position of a cursor within a document.
+ * Several cursors exist within LyX; for example, when locking an inset,
+ * the position of the cursor in the containing inset is stored.
+ *
+ * FIXME: true ?
*/
class LyXCursor {
public:
- ///
LyXCursor();
- ///
+ /// set the paragraph that contains this cursor
void par(Paragraph * p);
- ///
+ /// return the paragraph this cursor is in
Paragraph * par() const;
- ///
+ /// set the position within the paragraph
void pos(lyx::pos_type p);
- ///
+ /// return the position within the paragraph
lyx::pos_type pos() const;
- ///
+ /// FIXME
void boundary(bool b);
- ///
+ /// FIXME
bool boundary() const;
- ///
+ /// set the x position in pixels
void x(int i);
- ///
+ /// return the x position in pixels
int x() const;
- ///
+ /// set the stored next-line position when at the end of a row
void ix(int i);
- ///
+ /**
+* Return the x position of the start of the next row, when this
+* cursor is at the end of the previous row, for insets that take
+* a full row.
+*
+* FIXME: explain why we need this ?
+*/
int ix() const;
- ///
+ /// set the cached x position
void x_fix(int i);
- ///
+ /**
+* Return the cached x position of the cursor. This is used for when
+* we have text like :
+*
+* blah blah blah blah| blah blah blah
+* blah blah blah
+* blah blah blah blah blah blah
+*
+* When we move onto row 3, we would like to be vertically aligned
+* with where we were in row 1, despite the fact that row 2 is
+* shorter than x()
+*/
int x_fix() const;
- ///
+ /// set the y position in pixels
void y(int i);
- ///
+ /// return the y position in pixels
int y() const;
- ///
+ /// set the stored next-line y position when at the end of a row
void iy(int i);
- ///
+ /**
+* Return the y position of the start of the next row, when this
+* cursor is at the end of the previous row, for insets that take
+* a full row.
+*
+* FIXME: explain why we need this ? especially for y...
+*/
int iy() const;
- ///
+ /// set the row of the paragraph the cursor is in
void row(Row * r);
- ///
+ /// return the row of the paragraph this cursor is in
Row * row() const;
- ///
+ /// set the stored next row
void irow(Row * r);
- ///
+ /**
+* Return the next row, when this
+* cursor is at the end of the previous row, for insets that take
+* a full row.
+*
+* FIXME: explain why we need this ? especially for y...
+*/
Row * irow() const;
private:
/// The paragraph the cursor is in.
Paragraph * par_;
/// The position inside the paragraph
lyx::pos_type pos_;
- ///
+ /// FIXME
bool boundary_;
- ///
+ /// the pixel x position
int x_;
- /// the x position of the position before the inset when we put
- /// the cursor on the end of the row before, otherwise equal to x.
+ /// the stored next-row x position
int ix_;
- ///
+ /// the cached x position
int x_fix_;
- ///
+ /// the pixel y position
int y_;
- /// the y position of the position before the inset when we put
- /// the cursor on the end of the row before, otherwise equal to y.
+ /// the stored next-row y position
int iy_;
- ///
+ /// the containing row
Row * row_;
- /// the row of the position before the inset when we put
- /// the cursor on the end of
LyXText-status
2638 // We should only go up with refreshing code so this means that if 2639 // we have a MORE refresh we should never set it to LITTLE if we still 2640 // didn't handle it (and then it will be UNCHANGED. Now as long as 2641 // we stay inside one LyXText this may work but we need to tell the 2642 // outermost LyXText that it should REALLY draw us if there is some 2643 // change in a Inset::LyXText. So you see that when we are inside a 2644 // inset's LyXText we give the LITTLE to the outermost LyXText to 2645 // tell'em that it should redraw the actual row (where the inset 2646 // resides! Capito?! What if I pass UNCHANGED into ::status() ? Given the current code this will overwrite NEED_MORE_REFRESH. Can that be right ? Furthermore, if this text's status is NEED_MORE_REFRESH, this code won't set refresh_row of the inset owner. Frankly I don't capito :) john -- The simpler it is, the harder it is. - Tim Van Holder
Re: André you've just swallowed my Vector!
On Thu, Aug 01, 2002 at 05:01:46PM +0100, Angus Leeming wrote:
On Thursday 01 August 2002 5:30 pm, Angus Leeming wrote:
\begin_inset FormulaMacro
\newcommand{\Vector}[1]{\boldsymbol #1}
{#1}
\end_inset
is it something to do with the additional parameter perhaps?
Yes, if I remove the additional parameter, all is Ok.
Hm.. I changed the handling of newlines by the parser. So I probably did
not catch all cases... I'll have a look.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
math-macro is broken
- math-macro py
- insert the pythagoras without parameter and call it py
- open a mathbox
- insert \pyspace
- nothing to see
- export to latex
-
\newcommand{\py}{c^{2}=a^{2}+b^{2}}
a macro \[
\ \]
- save and reopen the doc
- the macro is gone
Herbert
--
http://www.lyx.org/help/
Re: Action diff - look and diss
On Thu, Aug 01, 2002 at 06:04:19PM +0100, John Levon wrote:
How would you deal with tab inside an insettext inside a cell ?
I don't think that tab to go to the beginning of the net paragraph is
overly sensible. In fact, I discovered that key binding yesterday when
trying to understand what you were explaining. So I think a tab should
primarily switch table cells. I people need to kill some time, one could
implement a special case if no table wants to handle the tab. But that
kind of thing should not be hard coded, rather done more generall by
something like '\bind Tab tab-insert paragraph-forward' (i.e. try
tab-insert, if that goes unhandled, try pargraph-forward)
How do you make sure a keypress in the dummy cell position enters the
child inset, unless it's one that needs handling differenty ? If there
is no locking inset as such, how do you unlock it when I paste some
text elsewhere in the owner with the mouse button ? How do you make sure
asynchrnous geometry changes are propogated backwards properly ?
You've never had a look at mathed, have you? There are no 'dummy cell
positions'. Pasting is moving cursor there and dump the content of the
cutbuffer
// for simple stuff
void MathCursor::paste(MathArray const ar)
{
Anchor_ = Cursor_;
selection_ = true;
array().insert(pos(), ar);
pos() += ar.size();
}
The 'paste partial table' is about 25 lines fairly straight-forward
loops...
I'm sure you've got solutions to all of these and more I don't even think
of, but it doesn't mean you will necessary be able to solve them all
simply.
Put it this way: I expect such a rewrite to take years, regardless of the
superiority of the approach
I don't think the project is bigger than the mathed rewrite as I could
re-use the infrastructure. I'd guess it would take one year as a
one-man-project in an indifferent environment. With full support from the
crew I'd estimate a mere three months...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyxconvert: version 0.0.2
On Thursday 01 August 2002 00:50, Lars Gullik Bjønnes wrote: > > sure... or lyx2lyx if that is agreed upon. Since Dekel does not have any preference (private message) I will set it lyx2lyx. I will start to add it to cvs later today, since university will be out of connection due to some works in a central building. The version name will be the same of the envolving lyx. The name of individual convertion modules will remain unchanged. -- José Abílio
Re: key combinations not showing up...
On Thu, Aug 01, 2002 at 03:17:15AM +0100, John Levon wrote: > > Is it possible that future versions have this feature back, or even > > better, to show possible better key-strokes, like M-m [ when you select > > this? > > It's a bug really, no sign of a fix for 1.2.x :/ > > For 1.3, we show the symbol name, but it doesn't work for all cases - > Andre, why is this ? Hm... because no every inset displays its "info" yet. I usually change that as soon as I have to touch the inset but I usually don't go through every 30+ insets in one swoop. But I think that's not what Pierre was asking for, he wanted to have the shortcut displayed in the minibuffer. That's a differnt issue and never was done by mathed, so I did not break it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: mathed compile error
On Thu, Aug 01, 2002 at 04:22:09AM +0100, John Levon wrote: > math_gridinset.h:22: `struct MathGridInset::CellInfo' is private > math_textinset.C:141: within this context I commited a quick fix. Will have a look later. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyxconvert: version 0.0.2
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> How about putting the files on CVS, in lib/lyxconvert/ ? We Dekel> only need to made the changes so "make install" will create a Dekel> symbolic link /usr/bin/lyxconvert for Dekel> LYXDIR/lyxconvert/lyxconvert.py Will symbolic links work under cygwin? Dekel> (perhaps lyxconvert.py should be renamed to lyxconvert?) A problem we have with scripts is that the python (or perl) interpreter will not be at the same place on different systems. I'd like to avoid to create all the scripts from configure like we do for reLyX. For running scripts from inside lyx, a solution would be to rely on script extension to know how to invike it: for example, lyxconvert.py would be invoked as python lyxconvert.py Also, the calling code could arrange to define a few variables like LYX_DIR, or whatever can be useful for the script. As an example reLyXmain.pl could be invoked with LYX_DIR and PACKAGE set to the right values, so that the script reLyX is not needed. I do not know whether lyx2lyx will need to find lyx data directory in this way, though. However, this would not work from inside lyx. A solution would be to run them from lyx, like lyx --run-script reLyXmain.pl This is not a very satisfactory solution, but we need to find a way to make our scripts portable. JMarc
lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 10:49, Jean-Marc Lasgouttes wrote: > > Will symbolic links work under cygwin? Good question. > Dekel> (perhaps lyxconvert.py should be renamed to lyxconvert?) > > A problem we have with scripts is that the python (or perl) > interpreter will not be at the same place on different systems. I'd > like to avoid to create all the scripts from configure like we do for > reLyX. What about the present solution: #!/usr/bin/env python Do you know any system where this fails? > For running scripts from inside lyx, a solution would be to rely on > script extension to know how to invike it: for example, lyxconvert.py > would be invoked as > python lyxconvert.py But python lyx2lyx will works as well, you don't need the extension. The knowleadge present in the extension should (could) be somewhere else. > Also, the calling code could arrange to define a few variables like > LYX_DIR, or whatever can be useful for the script. As an example > reLyXmain.pl could be invoked with LYX_DIR and PACKAGE set to the > right values, so that the script reLyX is not needed. I do not know > whether lyx2lyx will need to find lyx data directory in this way, > though. Since I added that code to reLyX this shouldn't ever be a problem to lyx2lyx. :-) > However, this would not work from inside lyx. A solution would be to > run them from lyx, like > lyx --run-script reLyXmain.pl > > This is not a very satisfactory solution, but we need to find a way to > make our scripts portable. One other question, does reLyX has internationalization? I have moved all the error, and warnings, messages to a single file to easy that possibility. I have seen also pygettext, but that seems to be only present in python 2.2 > JMarc -- José Abílio
Re: Action diff - look and diss
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Rather than justify any of this, I'll just show it and let John> people comment. It looks nice to me and I do not have many clever comments. A question though: we will be adding lots of objects with virtual methods (or lots of virtual methods to exisiting insets). What is the price we will have to pay for this in terms of bloat, link time, and startup time (remember the link-at-startup problems that kde has)? JMarc
Re: Create a new file with "File open"
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Fri, Jun 21, 2002 at 12:09:34PM -0700, Matt Brennan wrote: >> As I recal, in v.1.1, you were able to create a new file by typing >> its name in the File->Open... popup. Now in v. 1.2 this is no >> longer possible. Hopefully, it should be easy to carry this feature >> forward to v.1.2.1 John> JMarc, OK for 1.2 branch ? Questions: + Buffer * buffer = bufferlist.newFile(filename, ""); I thought that the second argument to newFile was a bool. + // the user specifically chose this name. Believe them. Did you test what happens when one chooses a nonsensical file name (non-existing directory, for example) and then tries to save? Failing to save is OK, crashing lyx is not :) Othrwise, I am OK in principle for this patch in 1.2.x. JMarc
Re: lyxconvert: version 0.0.2
On Thu, Aug 01, 2002 at 11:49:15AM +0200, Jean-Marc Lasgouttes wrote: > Dekel> (perhaps lyxconvert.py should be renamed to lyxconvert?) > > A problem we have with scripts is that the python (or perl) > interpreter will not be at the same place on different systems. I thought for most scripting languages there are hacks like #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" > For running scripts from inside lyx, a solution would be to rely on > script extension to know how to invike it: for example, lyxconvert.py > would be invoked as > python lyxconvert.py But I really don't care what language is used to implement something. So if nwe nee auto-detection we should look at the contents. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
> "José" == José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: Dekel> (perhaps lyxconvert.py should be renamed to lyxconvert?) >> A problem we have with scripts is that the python (or perl) >> interpreter will not be at the same place on different systems. I'd >> like to avoid to create all the scripts from configure like we do >> for reLyX. José> What about the present solution: #!/usr/bin/env python Ah. I did not notice it... Note that you should always add a space after #! José> Do you know any system where this fails? I do not now, but a google search seems to propose this as a common trick. >> For running scripts from inside lyx, a solution would be to rely on >> script extension to know how to invike it: for example, >> lyxconvert.py would be invoked as python lyxconvert.py José> But python lyx2lyx will works as well, you don't need the José> extension. The knowleadge present in the extension should José> (could) be somewhere else. I mean that lyx runScript (or whatever name) method could use the extension to guess the interpreter it should use. I am not sure yet it is a good idea, just a proposal. José> One other question, does reLyX has internationalization? I José> have moved all the error, and warnings, messages to a single José> file to easy that possibility. José> I have seen also pygettext, but that seems to be only present José> in python 2.2 I think we can worry about that later, but gettext support would certainly be nice. JMarc
caching BufferView (again)
Lots and lots of things are caching a BufferView * or a Buffer *. To name a
few:
InsetFormulaBase (BufferView *)
InsetCite (Buffer *)
GraphicsLoader (BufferView *, cached for 2 secs then used).
Moreover, InsetGraphics and InsetInclude both are using current_view because
they don't cache but should. In the case of InsetInclude that's preview
related so it's not yet in cvs.
Clearly when we move to multiple / changing BufferViews this is going to lead
to nasty problems.
Lars has mentioned using boost::weak_ptr in just such a context and I'd like
to do so here. From the boost docs
=
http://www.boost.org/libs/smart_ptr/weak_ptr.htm
The weak_ptr class template stores a pointer to an object that's already
managed by a shared_ptr. When the object last shared_ptr to the object goes
away and the object is deleted, all weak_ptr objects have their stored
pointers set to 0.
=
I'd like, therefore, to change the LyXView store
public:
/// return the current buffer view
BufferView * view() const { return bufferview_,get(); }
+ /// weak_ptr.get() is reset to 0 automatically when bufferview_ is killed.
+ boost::weak_ptr const cachablePtr() const {
+ return boost::weak_ptr(bufferview_);
+ }
private:
/// view of a buffer. Eventually there will be several.
- boost::scoped_ptr bufferview_;
+ boost::shared_ptr bufferview_;
and to make it accessible through BufferView:
boost::weak_ptr const BufferView::cachablePtr() const
{
return pimpl_->owner_->cachablePtr();
}
Then if things want to cache a BufferView * then they can do so safely.
What do you think?
Angus
ps, when LyXView stores multiple BufferViews, we'd perhaps have
boost::weak_ptr const cachablePtr(BufferView *) const;
but that is for the future...
A
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: > Clearly when we move to multiple / changing BufferViews this is going to lead > to nasty problems. While we are at it: Can anybody explain me the advantages of multiple buffer views vs multiple LyX processes? Which kind of convienence would that buy us? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
On Thursday 01 August 2002 12:17 pm, Andre Poenitz wrote: > On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: > > Clearly when we move to multiple / changing BufferViews this is going to > > lead to nasty problems. > While we are at it: Can anybody explain me the advantages of multiple > buffer views vs multiple LyX processes? Sure. A single LyXView can have multiple BufferViews. Think, in emacs terms, of C-x 2 instead of C-x 5. Angus
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 11:41, Jean-Marc Lasgouttes wrote: > > José> What about the present solution: #!/usr/bin/env python > > Ah. I did not notice it... Note that you should always add a space > after #! Done. > José> Do you know any system where this fails? > > I do not now, but a google search seems to propose this as a common > trick. This is the usual way to deal this inside python scripts. > I mean that lyx runScript (or whatever name) method could use the > extension to guess the interpreter it should use. I am not sure yet it > is a good idea, just a proposal. Ok. > José> One other question, does reLyX has internationalization? I > José> have moved all the error, and warnings, messages to a single > José> file to easy that possibility. > > José> I have seen also pygettext, but that seems to be only present > José> in python 2.2 > > I think we can worry about that later, but gettext support would > certainly be nice. Ok. Now back to fix some small issues and commit it. > JMarc -- José Abílio
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "José" == José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > | Dekel> (perhaps lyxconvert.py should be renamed to lyxconvert?) >>> A problem we have with scripts is that the python (or perl) >>> interpreter will not be at the same place on different systems. I'd >>> like to avoid to create all the scripts from configure like we do >>> for reLyX. > | José> What about the present solution: #!/usr/bin/env python > | Ah. I did not notice it... Note that you should always add a space | after #! Why? | José> One other question, does reLyX has internationalization? I | José> have moved all the error, and warnings, messages to a single | José> file to easy that possibility. won't that make the code harder to read? -- Lgb
lyx2lyx final touch (before commiting)
Hi, the files presents in lyx2lyx directory are: error.py lyx2lyx lyxconvert_215.py lyxconvert_218.py parser_tools.py I will add several other later, but for now this is enough. What other files do I need to add? Makefile.am? Changelog? .cvsignore? Jean-Marc? :-) -- José Abílio
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
On Thursday 01 August 2002 12:41, Lars Gullik Bjønnes wrote:
> | José> One other question, does reLyX has internationalization? I
> | José> have moved all the error, and warnings, messages to a single
> | José> file to easy that possibility.
>
> won't that make the code harder to read?
class Error:
invalid_file = "Invalid LyX file\n"
invalid_format = "Invalid LyX format\n"
format_not_supported = "Format not supported\n"
same_format = "No convertion because start and ending formats are the
same\n"
newer_format = "Starting format is newer than end format\n"
error = Error()
Now in the files you use:
sys.stderr.write(error.invalid_file)
how is that harder to read than say:
sys.stderr.write("Invalid LyX file\n")
--
José Abílio
Re: caching BufferView (again)
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lots and lots of things are caching a BufferView * or a Buffer *. To name a
| few:
| InsetFormulaBase (BufferView *)
| InsetCite (Buffer *)
| GraphicsLoader (BufferView *, cached for 2 secs then used).
>
| Moreover, InsetGraphics and InsetInclude both are using current_view because
| they don't cache but should. In the case of InsetInclude that's preview
| related so it's not yet in cvs.
>
| Clearly when we move to multiple / changing BufferViews this is going to lead
| to nasty problems.
>
| Lars has mentioned using boost::weak_ptr in just such a context and I'd like
| to do so here. From the boost docs
>
| =
| http://www.boost.org/libs/smart_ptr/weak_ptr.htm
>
| The weak_ptr class template stores a pointer to an object that's already
| managed by a shared_ptr. When the object last shared_ptr to the object goes
| away and the object is deleted, all weak_ptr objects have their stored
| pointers set to 0.
| =
>
| I'd like, therefore, to change the LyXView store
| public:
| /// return the current buffer view
| BufferView * view() const { return bufferview_,get(); }
I'd rather change this one to
a. return a shared_ptr
b. return a weak_ptr
| + /// weak_ptr.get() is reset to 0 automatically when bufferview_ is killed.
| + boost::weak_ptr const cachablePtr() const {
| + return boost::weak_ptr(bufferview_);
| + }
and not have this one at all.
| private:
| /// view of a buffer. Eventually there will be several.
| - boost::scoped_ptr bufferview_;
| + boost::shared_ptr bufferview_;
yes.
| and to make it accessible through BufferView:
| boost::weak_ptr const BufferView::cachablePtr() const
| {
| return pimpl_->owner_->cachablePtr();
| }
and you really need this?
--
Lgb
Re: caching BufferView (again)
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: >> Clearly when we move to multiple / changing BufferViews this is going to lead >> to nasty problems. > | While we are at it: Can anybody explain me the advantages of multiple | buffer views vs multiple LyX processes? > | Which kind of convienence would that buy us? View different parts of the same document at the same time... -- Lgb
Re: lyx2lyx [It was Re: lyxconvert: version 0.0.2]
José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes:
| On Thursday 01 August 2002 12:41, Lars Gullik Bjønnes wrote:
>> | José> One other question, does reLyX has internationalization? I
>> | José> have moved all the error, and warnings, messages to a single
>> | José> file to easy that possibility.
>>
>> won't that make the code harder to read?
>
| class Error:
| invalid_file = "Invalid LyX file\n"
| invalid_format = "Invalid LyX format\n"
| format_not_supported = "Format not supported\n"
| same_format = "No convertion because start and ending formats are the
| same\n"
| newer_format = "Starting format is newer than end format\n"
>
| error = Error()
>
| Now in the files you use:
>
| sys.stderr.write(error.invalid_file)
>
| how is that harder to read than say:
>
| sys.stderr.write("Invalid LyX file\n")
no but...
sys.stderr.write(same_format);
does not exactly tell a lot...
There is a reason why gettext is not using this method...
--
Lgb
Re: caching BufferView (again)
On Thursday 01 August 2002 12:53 pm, Lars Gullik Bjønnes wrote:
It appears you aren't against the basic idea. Good.
> | I'd like, therefore, to change the LyXView store
> | public:
> | /// return the current buffer view
> | BufferView * view() const { return bufferview_,get(); }
>
> I'd rather change this one to
>
> a. return a shared_ptr
> b. return a weak_ptr
Then I think it should be
boost::shared_ptr const & view() const { return bufferview_; }
No more expensive than before, but may lead to more extensive changes to the
rest of the code base than I'd anticipated.
> | and to make it accessible through BufferView:
> | boost::weak_ptr const BufferView::cachablePtr() const
> | {
> | return pimpl_->owner_->cachablePtr();
> | }
>
> and you really need this?
Yes. Only now it would be
boost::shared_ptr const & BufferView::cachablePtr() const
{
return pimpl_->owner_->view();
}
Think of all those times when a BufferView * (or even a BufferView &) is
passed to an inset. It makes no sense at all to pass a shared_ptr in these
cases, but if the inset wants to cache this BufferView * then it can do so as
struct Inset::Cache {
boost::weak_ptr view_;
}
Inset::Cache * cache_;
cache_->view_ = bv->cachablePtr();
This cache stuff has been bugging me for ages. I'd really like to bury it
properly.
Angus
Re: caching BufferView (again)
On Thursday 01 August 2002 12:44 pm, Angus Leeming wrote:
> Yes. Only now it would be
>
> boost::shared_ptr const & BufferView::cachablePtr() const
> {
> return pimpl_->owner_->view();
> }
Sorry. This is FUD, as André might say.
bv->owner()->view()
is sufficient.
Angus
Re: caching BufferView (again)
On Thu, Aug 01, 2002 at 11:53:09AM +0100, Angus Leeming wrote: > > While we are at it: Can anybody explain me the advantages of multiple > > buffer views vs multiple LyX processes? > > Sure. A single LyXView can have multiple BufferViews. Think, in emacs terms, > of C-x 2 instead of C-x 5. I don't know emacs. What's C-x 2 and C-x 5 doing? [I don't even use multiple buffers in vim.] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: caching BufferView (again)
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Thu, Aug 01, 2002 at 11:39:13AM +0100, Angus Leeming wrote: >> Clearly when we move to multiple / changing BufferViews this is >> going to lead to nasty problems. Andre> While we are at it: Can anybody explain me the advantages of Andre> multiple buffer views vs multiple LyX processes? Andre> Which kind of convienence would that buy us? Cut and paste between different views JMarc
