On Sat, Oct 11, 2003 at 02:43:39PM +0200, Lars Gullik Bjønnes wrote:
>
> Please have a look.
Fine with me with exception of the
- virtual dispatch_result localDispatch(FuncRequest const & cmd);
- ///
/// Get the inset parameters, used by the GUIndependent dialog.
Inse
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, Oct 11, 2003 at 02:43:39PM +0200, Lars Gullik Bjønnes wrote:
>>
>> Please have a look.
>
| Fine with me with exception of the
>
| - virtual dispatch_result localDispatch(FuncRequest const & cmd);
| - ///
| /// Get the inset p
Lars Gullik Bjønnes wrote:
> I even think boost::optional should be used for the Cached vars
> type, then you can easily know if the cached var is set or not.
>
> template
> class CachedVar {
> public:
> CachedVar(CachedVar const &) { var_.reset(); }
> void operator=(CachedVar con
On Sun, Oct 12, 2003 at 08:56:59PM +, Angus Leeming wrote:
> Cached variables are a royal pain in the butt.
>
> Writing explicit copy constructors simply so that we don't copy
> mutable int xo_;
> is a real bore. I'm sure that the author of formulabase.[Ch] would
> agree with me ther
Milton Woods wrote:
> The linker doesn't seem to be the problem.
>
> Consider as an example the file src/TextCache.C which declares a
> global method 'findFit'. When compiled using gcc-3.2 on Redhat 9,
> the 'nm' program shows that the object file includes two 'findFit'
> symbols:
>
> 0366 t
On Sun, Oct 12, 2003 at 11:53:16PM +0200, Lars Gullik Bjønnes wrote:
> Are there a standard way? If there are a standard way it would be to
> call the public interface "pubdispatch" and the private one
> "dispatch".
Boys, may I ask you not to introduce new programming tenets to LyX
(right now at l
On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
> I even think boost::optional should be used for the Cached vars type,
> then you can easily know if the cached var is set or not.
We'd never, ever need to know whether this is set or not. You can put in
arbitrary values in this
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> I even think boost::optional should be used for the Cached vars
>> type, then you can easily know if the cached var is set or not.
>>
>> template
>> class CachedVar {
>> public:
>> CachedVar(CachedVar const &) { va
Andre Poenitz wrote:
>> Cached variables are a royal pain in the butt.
>>
>> Writing explicit copy constructors simply so that we don't copy
>> mutable int xo_;
>> is a real bore. I'm sure that the author of formulabase.[Ch] would
>> agree with me there ;-)
> So just copy it.
>
>> Why don
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
>> I even think boost::optional should be used for the Cached vars type,
>> then you can easily know if the cached var is set or not.
>
| We'd never, ever need to know whether this is s
On Mon, Oct 13, 2003 at 10:00:10AM +0200, Lars Gullik Bjønnes wrote:
> | with FuncResult being
> >
> | struct FuncResult {
> | dispatch_result res;
> | idx_type idx;
> | pos_type pos;
> | };
>
> Are you sure that no dispatch ever uses the idx and pos pas
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Oct 12, 2003 at 11:53:16PM +0200, Lars Gullik Bjønnes wrote:
>> Are there a standard way? If there are a standard way it would be to
>> call the public interface "pubdispatch" and the private one
>> "dispatch".
>
| Boys, may I ask you not to intr
Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
>> I even think boost::optional should be used for the Cached vars
>> type, then you can easily know if the cached var is set or not.
>
> We'd never, ever need to know whether this is set or not. You can
>
On Mon, Oct 13, 2003 at 10:18:26AM +0200, Lars Gullik Bjønnes wrote:
> | I'm not so sure. Apart from the fact that I don't know what the result
> | of '*var_' is when the variable is not set, I think it is always true
> | that 'T()' is a perfectly valid result here. See how we use cached
> | var
On Mon, Oct 13, 2003 at 09:22:55AM +, Angus Leeming wrote:
> There are several examples of places where we do not want these
> variables to be copied. Indeed, there are examples where the default
> copy constructor fails to compile. For example, any class holding a
> boost::signal. These der
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 10:00:10AM +0200, Lars Gullik Bjønnes wrote:
>> | with FuncResult being
>> >
>> |struct FuncResult {
>> |dispatch_result res;
>> |idx_type idx;
>> |pos_type pos;
>> |};
>>
>> Are you su
Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 09:22:55AM +, Angus Leeming wrote:
>> There are several examples of places where we do not want these
>> variables to be copied. Indeed, there are examples where the
>> default copy constructor fails to compile. For example, any class
>> holding a
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>>> Cached variables are a royal pain in the butt.
>>>
>>> Writing explicit copy constructors simply so that we don't copy
>>> mutable int xo_;
>>> is a real bore. I'm sure that the author of formulabase.[Ch] would
>>> agree
Andre Poenitz wrote:
> On Sun, Oct 12, 2003 at 11:53:16PM +0200, Lars Gullik Bjønnes wrote:
>> Are there a standard way? If there are a standard way it would be
>> to call the public interface "pubdispatch" and the private one
>> "dispatch".
>
> Boys, may I ask you not to introduce new programmin
On Mon, Oct 13, 2003 at 10:24:10AM +0200, Lars Gullik Bjønnes wrote:
> | We'd never, ever need to know whether this is set or not. You can put in
> | arbitrary values in this variable at any point of time _except_ at the
> | end of 'metrics'.
>
> The you need to be pretty sure that is it never use
On Mon, Oct 13, 2003 at 09:27:03AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
> >> I even think boost::optional should be used for the Cached vars
> >> type, then you can easily know if the cached var is set or not.
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> On Mon, Oct 13, 2003 at 09:22:55AM +, Angus Leeming wrote:
>>> There are several examples of places where we do not want these
>>> variables to be copied. Indeed, there are examples where the
>>> default copy constructor fai
On Mon, Oct 13, 2003 at 10:21:43AM +0200, Lars Gullik Bjønnes wrote:
> | LyX has much more serious problems than not following the latest
> | ideas of the greatest gurus.
>
> Your are off to ranting again. (why is it only your problems that are
> real?)
My real problem is that I probably won't be
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 10:24:10AM +0200, Lars Gullik Bjønnes wrote:
>> | We'd never, ever need to know whether this is set or not. You can put in
>> | arbitrary values in this variable at any point of time _except_ at the
>> | end of 'metrics'.
>>
>> T
On Mon, Oct 13, 2003 at 09:38:02AM +, Angus Leeming wrote:
> > So please use whatever is needed there and leave the xo_, yo_ cache
> > as-is.
>
> I'll certainly remember not to use examples of mathed code to
> illustrate my point in the future.
I thought your reason for your code was some ma
On Mon, Oct 13, 2003 at 09:32:18AM +, Angus Leeming wrote:
> > Boys, may I ask you not to introduce new programming tenets to LyX
> > (right now at least)?
>
> Speaking for myself, I have been getting LyX's interaction with
> outside files to just work. I have no idea how many 'official' bugs
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 10:18:26AM +0200, Lars Gullik Bjønnes wrote:
>> | I'm not so sure. Apart from the fact that I don't know what the result
>> | of '*var_' is when the variable is not set, I think it is always true
>> | that 'T()' is a perfectly v
Andre Poenitz wrote:
>> Slightly miffed.
> Sorry.
Apology accepted. And I'll try and get a thicker skin ;-)
--
Angus
On Mon, Oct 13, 2003 at 10:56:41AM +0200, Lars Gullik Bjønnes wrote:
> | But it is not. You are fending against problems that are obvious to
> | solve once they occur. A broken xy cache would mean the cursor is
> | completely off after clicking in a formula.
>
> Not everything is about mathed and
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 10:21:43AM +0200, Lars Gullik Bjønnes wrote:
>> | LyX has much more serious problems than not following the latest
>> | ideas of the greatest gurus.
>>
>> Your are off to ranting again. (why is it only your problems that are
>> r
On Mon, Oct 13, 2003 at 10:42:56AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Oct 13, 2003 at 10:18:26AM +0200, Lars Gullik Bjønnes wrote:
> >> | I'm not so sure. Apart from the fact that I don't know what the result
> >> | of '*var_' is when the v
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Yes. The LyX core is the domain of a few people right now when it comes
| to contributions. Even worse, most are 'retired' (at least
| de-facto...) and the situation is not improving. The only solution I see
| is to lower the bar as much as possible, and
Joao Luis Meloni Assirati wrote:
> On Wed, 8 Oct 2003, Angus Leeming wrote:
>
>> Of course, there are lots of small coding points,
>
> It is not a surprise :). If there is a chance of my patch being
> accepted, I would be glad to correct them. Note also that
> lyxclient.C is still sort of prelimi
Joao Luis Meloni Assirati wrote:
> Hello again,
>
> This patch implements Inverse DVI search for lyx. It needs my
> previous patch for the socket lyxserver. To use it, define
>
> xdvi -editor 'lyxclient -a $$s -g %f %l'
>
> as the viewer for the DVI format and
>
> latex --src-specials
>
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Joao Luis Meloni Assirati wrote:
>> On Wed, 8 Oct 2003, Angus Leeming wrote:
>>
>>> Of course, there are lots of small coding points,
>>
>> It is not a surprise :). If there is a chance of my patch being
>> accepted, I would be glad to correct them. No
On Mon, Oct 13, 2003 at 11:03:50AM +0200, Lars Gullik Bjønnes wrote:
> | And given a choice of implementing Yet Another Feature or
> | fixing Yet Another Bug
... or ranting a bit...
> but you did neither...
>
> | I thought it was more prudent to point to a few
> | issues which hamper LyX devel
Lars Gullik Bjønnes wrote:
> | Joao Luis Meloni Assirati wrote:
>>> On Wed, 8 Oct 2003, Angus Leeming wrote:
>>>
Of course, there are lots of small coding points,
>>>
>>> It is not a surprise :). If there is a chance of my patch being
>>> accepted, I would be glad to correct them. Note also
Angus Leeming <[EMAIL PROTECTED]> writes:
| Joao Luis Meloni Assirati wrote:
>> Hello again,
>>
>> This patch implements Inverse DVI search for lyx. It needs my
>> previous patch for the socket lyxserver. To use it, define
>>
>> xdvi -editor 'lyxclient -a $$s -g %f %l'
>>
>> as the viewer for
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 11:03:50AM +0200, Lars Gullik Bjønnes wrote:
>> | And given a choice of implementing Yet Another Feature or
>> | fixing Yet Another Bug
>
| ... or ranting a bit...
>
>> but you did neither...
>>
>> | I thought it was more prude
Lars Gullik Bjønnes wrote:
> | I am going to commit this patch as-is unless someone speaks up
> | soon.
>
> Is it tested?
It will be by the time I commit it.
--
Angus
On Mon, Oct 13, 2003 at 11:24:05AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Yes. The LyX core is the domain of a few people right now when it comes
> | to contributions. Even worse, most are 'retired' (at least
> | de-facto...) and the situation is not im
On Mon, Oct 13, 2003 at 10:26:46AM +, Angus Leeming wrote:
> Joao Luis Meloni Assirati wrote:
> > On Wed, 8 Oct 2003, Angus Leeming wrote:
> >
> >> Of course, there are lots of small coding points,
> >
> > It is not a surprise :). If there is a chance of my patch being
> > accepted, I would b
It appears the attached is needed to compile. Seems to be on your turf
;-) and I am not sure that this is the right/best way to fix it. But
it works.
- Martin
? err.txt
? x.diff
Index: formula.C
===
RCS file: /usr/local/lyx/cvsroot/l
On Mon, Oct 13, 2003 at 11:41:14AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Oct 13, 2003 at 11:03:50AM +0200, Lars Gullik Bjønnes wrote:
> >> | And given a choice of implementing Yet Another Feature or
> >> | fixing Yet Another Bug
> >
> | ... o
On Mon, Oct 13, 2003 at 11:53:40AM +0200, Andre' Poenitz wrote:
> I was about asking
'about to ask' I suppose...
Andre'
On Mon, Oct 13, 2003 at 01:10:59PM +0300, Martin Vermeer wrote:
> It appears the attached is needed to compile.
Not in Standard-C++ IIRC.
> ;-) and I am not sure that this is the right/best way to fix it. But
> it works.
I'd rather add the const on the other operand.
>
> // The previews
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Still there are drawing bugs, cursor placement bugs, undo bugs, C&P
>> bugs. I am sure all of them can be fixed, but is it easy?
>
| I am not talking about the core stuff.
I am.
And where do we have all the regressions? Where did they come from?
--
On Monday 13 October 2003 10:10 am, Martin Vermeer wrote:
> It appears the attached is needed to compile. Seems to be on your turf
> ;-) and I am not sure that this is the right/best way to fix it. But
> it works.
Should be Ok now.
A
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
>>> Still there are drawing bugs, cursor placement bugs, undo bugs,
>>> C&P bugs. I am sure all of them can be fixed, but is it easy?
>>
> | I am not talking about the core stuff.
>
> I am.
>
> And where do we have all the
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Baby steps, never allow a patch that introduces regressions, stay
>> stable at all times. Better to move slow than to fall.
>
| Ok...
>
| So what's next now?
Well since we did a giant step instead of a baby step, we must fix the
problems resulting from
Angus Leeming <[EMAIL PROTECTED]> writes:
| Stop this point scoring and fix a bug!
Can't code. Eating.
When finished... I'll try to do one bug at a time, problem is of
course that I do not _really_ grasp the metrics/update stuff. And it
is the update stuff that I'd like to focus on first, curren
This appears to be related with Lars dispatch patch:
make[5]: Entering directory `/home/jamatos/lyx/lyx-devel/src/frontends/gtk'
source='lyx_gui.C' object='lyx_gui.lo' libtool=yes \
depfile='.deps/lyx_gui.Plo' tmpdepfile='.deps/lyx_gui.TPlo' \
depmode=gcc3 /bin/sh ../../../config/depcomp \
/bin/sh
"Jose' Matos" <[EMAIL PROTECTED]> writes:
|std::vector >&)':
| lyx_gui.C:339: no matching function for call to `LyXFunc::dispatch(const
|std::basic_string, std::allocator >&)'
| ../../../src/lyxfunc.h:46: candidates are: void LyXFunc::dispatch(const
|FuncRequest&, bool = false)
>
| rh
Joao Luis Meloni Assirati wrote:
> I wrote a simple local socket interface for lyx that compiles and
> runs well in Linux with gcc 3.3 (Debian unstable) with the purpose
> of getting inverse dvi search working, for witch I will send a patch
> in my next e-mail.
Dear Joao, I attach the patch that I
Angus Leeming <[EMAIL PROTECTED]> writes:
| Joao Luis Meloni Assirati wrote:
>> I wrote a simple local socket interface for lyx that compiles and
>> runs well in Linux with gcc 3.3 (Debian unstable) with the purpose
>> of getting inverse dvi search working, for witch I will send a patch
>> in my n
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Joao Luis Meloni Assirati wrote:
>>> I wrote a simple local socket interface for lyx that compiles and
>>> runs well in Linux with gcc 3.3 (Debian unstable) with the purpose
>>> of getting inverse dvi search working, for
Joao Luis Meloni Assirati wrote:
>
> Hello again,
>
> This patch implements Inverse DVI search for lyx. It needs my
> previous patch for the socket lyxserver. To use it, define
>
> xdvi -editor 'lyxclient -a $$s -g %f %l'
>
> as the viewer for the DVI format and
>
> latex --src-specials
>
At least this fixes one of them. (It took the cursor position inside
the inset and compared it with the length of the paragraph containing
the inset. Works OK as long as the inset content is longer than the
containing paragraph :-( )
- Martin
PS I'm on my way travelling the rest of the week... Wa
Angus wrote :
>Alain Castera wrote:
>> To make it short, I reported the changes I've made to my copy of
>> 1.3.0pre1, changes that I would like to become persistent across the
>> versions :
>> - bad handling of "default alignment" (LYX_ALIGN_LAYOUT is changed
>> by the paragraph pop-up)
>> - def
Alain Castera wrote:
> Can you please have a look ?
It looks good to me, but I'd be grateful if you could get Jean-Marc to
look at it too perhaps. He seems to understand this stuff better than
most.
--
Angus
Hello,
It is good to hear about my patch...
On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
> | Run lyx-xforms (the patch will be in cvs in 5 mins). You'll find a
> | special file, eg /tmp/lyx_tmpdir222460OMx2d/lyxsocket
>
> Is this a good place to put the file?
> It should be placed in .lyx an
Hello Angus!
On Mon, 13 Oct 2003, Angus Leeming wrote:
> João, I am not going to commit this patch as it stands.
> I think that you should think about Lars' suggestion to place the
> socket files in ~/.lyx/socket.#pid. Doing so would mean you changing
> getBufferFromTmp to getBufferFromPID or si
On Mon, 13 Oct 2003, Angus Leeming wrote:
> Pass commands to lyx:
> ./lyxclient -a /tmp/lyx_tmpdir222460OMx2d/lyxsocket -c
> 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
Or simply
./lyxclient 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
if you have only one lyx runing, as the
On Monday 13 October 2003 12:10, Lars Gullik Bjønnes wrote:
>
> Patch is welcome.
Is this ok?
--
José Abílio
LyX and docbook, a perfect match. :-)
Index: lyx_gui.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/gtk/ly
Joao Luis Meloni Assirati wrote:
>
> Hello Angus!
>
> On Mon, 13 Oct 2003, Angus Leeming wrote:
>
>> João, I am not going to commit this patch as it stands.
>> I think that you should think about Lars' suggestion to place the
>> socket files in ~/.lyx/socket.#pid. Doing so would mean you
>> cha
> "Joao" == Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
Joao> For me it is no problem, but I remember people saying that /home
Joao> is not a good place to put fifos and sockets because it can be
Joao> an afs or other restrictive filesystem mount. So, looking at all
Joao> other progr
On Mon, Oct 13, 2003 at 03:29:08PM +0100, Jose' Matos wrote:
> On Monday 13 October 2003 12:10, Lars Gullik Bjønnes wrote:
> >
> > Patch is welcome.
>
> Is this ok?
Looks similar to what Lars did in similar places. So if it works it
should be ok.
Andre'
--
Those who desire to give up Freedom i
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Baby steps, never allow a patch that introduces regressions,
Lars> stay stable at all times. Better to move slow than to fall.
When was the last time you saw a baby walking?
JMarc
PS: OK, OK...
On Mon, 13 Oct 2003, Angus Leeming wrote:
> Joao Luis Meloni Assirati wrote:
>
> > See the last email in the thread on the lyxsocket. I have arguments
> > in favour of my choice, but if people thint that it must change,
> > I'll do it.
>
> No, I think your points about afs are enough. I didn't r
Joao Luis Meloni Assirati wrote:
> So if lyxclient is to be parsing user configuration, the
> --with-version-suffix must also modify lyxclient configuration. Not
> difficult to do, but we may postpone, don't you think?
Sure.
--
Angus
Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
| On Mon, 13 Oct 2003, Angus Leeming wrote:
>
>> Pass commands to lyx:
>> ./lyxclient -a /tmp/lyx_tmpdir222460OMx2d/lyxsocket -c
>> 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
>
| Or simply
>
| ./lyxclient 'LYXCMD:file-open /home/angus
On Mon, Oct 13, 2003 at 04:44:26PM +0200, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Baby steps, never allow a patch that introduces regressions,
> Lars> stay stable at all times. Better to move slow than to fall.
>
> When was the last
On Monday 13 October 2003 15:39, Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 03:29:08PM +0100, Jose' Matos wrote:
> > On Monday 13 October 2003 12:10, Lars Gullik Bjønnes wrote:
> > > Patch is welcome.
> >
> > Is this ok?
>
> Looks similar to what Lars did in similar places. So if it works it
>
Jose' Matos wrote:
> Any clue?
> That socket thing look suspicious there, I know. :-)
>
> This is for the gtk frontend, I do not have any problem with
> xforms or qt.
You should have empty functions defined in gtk/lyx_gui.C...
Ahhh. My bad. Could you please prepend each with 'lyx_gui::'.
On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
> Is the check clever enough? What about multiuser boxes?
It relies only in permission bits. That is, it tries all lyx_tmpdir...,
and stays with the first it can connect. Of course it cannot connet to a
socket that is under a closed directory. The
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Baby steps, never allow a patch that introduces regressions,
| Lars> stay stable at all times. Better to move slow than to fall.
>
| When was the last time you saw a baby wal
How do I get the 'innermost' LyXText given a ParIterator?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
| On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
>
>> Is the check clever enough? What about multiuser boxes?
>
| It relies only in permission bits. That is, it tries all lyx_tmpdir...,
| and stays with the first it can connect. Of course it c
On Monday 13 October 2003 16:59, Angus Leeming wrote:
>
> You should have empty functions defined in gtk/lyx_gui.C...
>
> Ahhh. My bad. Could you please prepend each with 'lyx_gui::'.
Done, it works. I will commit the fixes.
--
José Abílio
LyX and docbook, a perfect match. :-)
Andre Poenitz <[EMAIL PROTECTED]> writes:
| How do I get the 'innermost' LyXText given a ParIterator?
In the whole docuement? the deepest LyXText?
I do not think I understand the question properly...
--
Lgb
On Mon, Oct 13, 2003 at 05:14:42PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | How do I get the 'innermost' LyXText given a ParIterator?
>
> In the whole docuement? the deepest LyXText?
> I do not think I understand the question properly...
I have a ParIte
On Mon, Oct 13, 2003 at 12:51:42PM +0200, Lars Gullik Bj?nnes wrote:
> Would be good if someone could go through bugzilla and check all the
> bugs marked with "crash" and see if it is relevant for current CVS.
> All that is relevant and all new crashing bugs should get 1.4.0CVS as
> Target.
I did
Attempting to get rid of the BufferView cache stuff, I've had a look
at class LyX. It is simple enough to turn it into a singleton class
class LyX : boost::noncopyable {
static void init(int & argc, char * argv[]);
static LyX const & get();
private:
LyX(int & argc, char *
On Mon, Oct 13, 2003 at 11:24:05AM +0200, Lars Gullik Bj?nnes wrote:
> Because the core still stinks, are close to impossible to understand
> etc. Millions of hidden dependencies, not to mention all the new and
> old bugs, that makes non-guru visits to this part of the code _very_
> hard.
Besides
"Jose' Matos" <[EMAIL PROTECTED]> writes:
| On Monday 13 October 2003 12:10, Lars Gullik Bjønnes wrote:
>>
>> Patch is welcome.
>
| Is this ok?
yes.
--
Lgb
On Mon, Oct 13, 2003 at 04:27:09PM +, Angus Leeming wrote:
> Attempting to get rid of the BufferView cache stuff, I've had a look
> at class LyX. It is simple enough to turn it into a singleton class
If so it could be turned to a namespace as well...
Andre'
On Mon, Oct 13, 2003 at 04:29:06PM +0100, John Levon wrote:
> On Mon, Oct 13, 2003 at 11:24:05AM +0200, Lars Gullik Bj?nnes wrote:
>
> > Because the core still stinks, are close to impossible to understand
> > etc. Millions of hidden dependencies, not to mention all the new and
> > old bugs, that
Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 04:27:09PM +, Angus Leeming wrote:
>> Attempting to get rid of the BufferView cache stuff, I've had a
>> look at class LyX. It is simple enough to turn it into a singleton
>> class
>
> If so it could be turned to a namespace as well...
I'd like
On Mon, Oct 13, 2003 at 05:33:50PM +0200, Andre Poenitz wrote:
> I don't see all the black shadows you see. There is no need to abandon
> anything.
Who are the people who are going to fix all the nasty problems ?
I can see one candidate now: Lars. Is it really likely he'll be able to
sort out th
Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
| Hello Angus!
>
| On Mon, 13 Oct 2003, Angus Leeming wrote:
>
>> João, I am not going to commit this patch as it stands.
>> I think that you should think about Lars' suggestion to place the
>> socket files in ~/.lyx/socket.#pid. Doing so would
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 05:33:50PM +0200, Andre Poenitz wrote:
>
>> I don't see all the black shadows you see. There is no need to abandon
>> anything.
>
| Who are the people who are going to fix all the nasty problems ?
>
| I can see one candidate now: Lar
On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
> | It relies only in permission bits. That is, it tries all lyx_tmpdir...,
> | and stays with the first it can connect. Of course it cannot connet to a
> | socket that is under a closed directory. The socket itself is created
> | closed for other
On Mon, 13 Oct 2003, Joao Luis Meloni Assirati wrote:
> Or simply
>
> ./lyxclient 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
>
> if you have only one lyx runing, as the client will search for a running
> lyx.
Ooops... I mean
./lyxclient -c 'file-open /home/angus/docs/transform_v2.lyx
On Solaris:
g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src
-I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include
-I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT socktools.lo -MD -MP -MF
.deps/socktools.Tpo -c ../../../lyx/src/support/socktools.C
../../
On Mon, 13 Oct 2003, Kayvan A. Sylvan wrote:
> On Solaris:
>
> g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src
> -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include
> -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT socktools.lo -MD -MP -MF
> .deps/s
This patch fixes it:
--
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)
Index: src/support/socktools.C
==
The minipage inset has the parameters height and inner_position, but they
are not visible from the GUI and not written to the latex file. Is there
any reason for that?
I am converting some latex files to lyx. tex2lyx converts the parameters,
but when I export the file again from lyx they are lost.
On Mon, 13 Oct 2003, Jean-Marc Lasgouttes wrote:
> > "Joao" == Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
>
> Joao> For me it is no problem, but I remember people saying that /home
> Joao> is not a good place to put fifos and sockets because it can be
> Joao> an afs or other restri
On Mon, 13 Oct 2003, Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 04:44:26PM +0200, Jean-Marc Lasgouttes wrote:
> > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> >
> > Lars> Baby steps, never allow a patch that introduces regressions,
> > Lars> stay stable at all times. Bett
Georg Baum wrote:
> The minipage inset has the parameters height and inner_position, but
> they are not visible from the GUI and not written to the latex file.
> Is there any reason for that?
Laziness.
Note, however, that Martin Vermeer has written an InsetBox that
swallows up the minipage dial
1 - 100 of 103 matches
Mail list logo
