I was just wondering if there's some reason why we can't include these steps
in the various auto* files? This recipe changes fairly often while greatly
appreciated is a bit of a hassle to keep up with.
cheers,
andrew
export LDFLAGS=-L/home/user/qt-3/lib -lqtmain -lqt-mt -lopengl32
I was just wondering if there's some reason why we can't include these steps
in the various auto* files? This recipe changes fairly often & while greatly
appreciated is a bit of a hassle to keep up with.
cheers,
andrew
export LDFLAGS="-L/home/user/qt-3/lib -lqtmain -lqt-mt -lopengl32
I've been waiting patiently for a windows installer
for the latest greatest LyX. Is there some technical
reason why one hasn't been posted, or is it simply that
nobody has gotten to it yet?
I've been trying to build it myself, but am getting errors
on the final link. I have been following the
I have generally followed this outline:
http://marc.theaimsgroup.com/?l=lyx-develm=113523961018129q=p3
I found that if I don't modify the environment as described
and the configure script, it fails to find the qt libraries.
Actually, it finds the library, but can't produce a working
program, so
I've been waiting patiently for a windows installer
for the latest & greatest LyX. Is there some technical
reason why one hasn't been posted, or is it simply that
nobody has gotten to it yet?
I've been trying to build it myself, but am getting errors
on the final link. I have been following the
I have generally followed this outline:
http://marc.theaimsgroup.com/?l=lyx-devel=113523961018129=p3
I found that if I don't modify the environment as described
and the configure script, it fails to find the qt libraries.
Actually, it finds the library, but can't produce a working
program, so
People have talked about preferences for a lyx namespace and/or
prefixes, but nobody has really explained why either is needed. IMHO,
Lyx is never going to be a library to be linked with some other
application - it's simply not written that way. So I don't see
what it is that we need to separate
People have talked about preferences for a lyx namespace and/or
prefixes, but nobody has really explained why either is needed. IMHO,
Lyx is never going to be a library to be linked with some other
application - it's simply not written that way. So I don't see
what it is that we need to separate
Personally I think it's madness to release something with
known critical bugs that have patches.
I think proposed patches should be in CVS. That way, when you update
you get the current patches can apply the ones you want. It
would encourage more testing through everyday use, while allowing
Personally I think it's madness to release something with
known critical bugs that have patches.
I think proposed patches should be in CVS. That way, when you update
you get the current patches & can apply the ones you want. It
would encourage more testing through everyday use, while allowing
Title: [Patch] Bugs 1391 1393
Here is my patch allowing macros to dynamically create
other macros. It also fixes bugs 1391 and 1393 regarding
renaming macros seeing/editing the number of arguments.
I've tried to encorporate previous comments.
Andrew
macros.patch
Description:
Is there a way to delete the first few lines
of that patch file? Probably too late now
andrew
Title: [Patch] Bugs 1391 & 1393
Here is my patch allowing macros to dynamically create
other macros. It also fixes bugs 1391 and 1393 regarding
renaming macros & seeing/editing the number of arguments.
I've tried to encorporate previous comments.
Andrew
macros.patch
Description:
Is there a way to delete the first few lines
of that patch file? Probably too late now
andrew
I just had a thought.
Why not give the template a fixed numerb of cells gain.
A LaTeX macro can have at most nine 'regular' arguments, so something
like eleven fixed cells should do...
Andre'
I had thought about this, but that would mean that nargs() returned 11
rather than the actual
>I just had a thought.
>
>Why not give the template a fixed numerb of cells gain.
>
>A LaTeX macro can have at most nine 'regular' arguments, so something
>like eleven fixed cells should do...
>
>Andre'
I had thought about this, but that would mean that nargs() returned 11
rather than the
There are few bugs I would like to bring to the attention of the developers:
[math-macro behavior == Big regression w.r.t. 1.3.x]
M-x; math-macro mysum 2
\sum^{#1}_{#2}
Problems:
a) the cursor is outside the box inset (flushed left)
b) type \mysum, get the #1 and #2 fields, enter something,
>
>There are few bugs I would like to bring to the attention of the developers:
>
>[math-macro behavior ==> Big regression w.r.t. 1.3.x]
>M-x; math-macro mysum 2
>\sum^{#1}_{#2}
>
>Problems:
>a) the cursor is outside the box inset (flushed left)
>
>b) type \mysum, get the #1 and #2 fields, enter
I just noticed this bug was targeted to 1.4.0. Is
the intention to get this new patch in?
andrew
Ok, I see now. Unfortunately your patch is not correct IMHO: If I click on
argument 3 I expect the cursor to appear in argument 3, not in the first
one as your patch does. In perinciple it is ok to call
Of course you tested your original patch to ensure it met this requirement?
I suspect lyx
I actually don't know anything about autoconf/automake etc, so
can't really help you. sorry.
However, I have noticed the following when linking the main executable
on mingw (this is the output from 'time make lyx-qt.exe'):
standard link time:
real3m31.984s
user0m15.507s
sys 0m11.529s
I just noticed this bug was targeted to 1.4.0. Is
the intention to get this new patch in?
andrew
>Ok, I see now. Unfortunately your patch is not correct IMHO: If I click on
>argument 3 I expect the cursor to appear in argument 3, not in the first
>one as your patch does. In perinciple it is ok to call
Of course you tested your original patch to ensure it met this requirement?
I suspect
I actually don't know anything about autoconf/automake etc, so
can't really help you. sorry.
However, I have noticed the following when linking the main executable
on mingw (this is the output from 'time make lyx-qt.exe'):
standard link time:
real3m31.984s
user0m15.507s
sys 0m11.529s
I'm working on a fix which should be available soon.
Excellent!
I just wanted to clarify the intention with this code. I tried
to follow the thread,
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg82007.html
but am none the wiser.
Is the intention of the current code to somehow work
Title: Re: crash: click on macro instantiation - bug 2060
Here is a patch to fix bug 2060 - again.
I've tested this patch in the following ways (lyx file attached)
create a macro with 0 arguments
create a macro with 1 argument
create a macro with 3 argument
use each of the above macros in
Here is a patch to fix bug 2060 - again.
It looks sensible. Are you sure that nothing needs to be done in cursorPos
and drawSelection?
Nope, I have no idea. I looked at your original patch which mentioned
fixing a potential problem, but can't see how that would eventuate.
If you can point out
>
>> I'm working on a fix which should be available soon.
>
>Excellent!
I just wanted to clarify the intention with this code. I tried
to follow the thread,
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg82007.html
but am none the wiser.
Is the intention of the current code to somehow
Title: Re: crash: click on macro instantiation - bug 2060
Here is a patch to fix bug 2060 - again.
I've tested this patch in the following ways (lyx file attached)
create a macro with 0 arguments
create a macro with 1 argument
create a macro with 3 argument
use each of the above macros in
>
>> Here is a patch to fix bug 2060 - again.
>
>It looks sensible. Are you sure that nothing needs to be done in cursorPos
>and drawSelection?
Nope, I have no idea. I looked at your original patch which mentioned
fixing a potential problem, but can't see how that would eventuate.
If you can
Title: crash: click on macro instantiation
I have replicated this bug in a recent cvs checkout.
1. Create a macro with 0 arguments.
2. Use that macro, defining the arguments
3. Leave the MathMacro inset
4. Click on the MathMacro inset
5. Reach for nearest fire extinguisher
6. Spray onto
Title: crash: click on macro instantiation
I have replicated this bug in a recent cvs checkout.
1. Create a macro with > 0 arguments.
2. Use that macro, defining the arguments
3. Leave the MathMacro inset
4. Click on the MathMacro inset
5. Reach for nearest fire extinguisher
6. Spray onto
--- text3.C 31 Dec 2005 11:40:32 - 1.323
+++ text3.C 27 Jan 2006 02:06:30 -
@@ -1254,10 +1254,10 @@
else {
string s = cmd.argument;
string const s1 = token(s, ' ', 1);
- int const
>> --- text3.C 31 Dec 2005 11:40:32 - 1.323
>> +++ text3.C 27 Jan 2006 02:06:30 -
>> @@ -1254,10 +1254,10 @@
>> else {
>> string s = cmd.argument;
>> string const s1 = token(s, ' ', 1);
>> -
Andrew I agree metrics is not the place. However, at some point you
Andrew need to go cycling through all insets to find the macro
Andrew instantiations and call changeArgs(). You need to do this on
Andrew the same kind of basis as updating the expansion - since both
Andrew reflect changes in the
Title: RE: Renaming macros
OK, here is a better formatted patch, preserving encoding etc. Thanks
for the feedback. The update is still being done in metrics() in the
same way that the macro expansion was being done previously. I have
changed it to cast away the const-ness rather than make
Andrew> I agree metrics is not the place. However, at some point you
Andrew> need to go cycling through all insets to find the macro
Andrew> instantiations and call changeArgs(). You need to do this on
Andrew> the same kind of basis as updating the expansion - since both
Andrew> reflect changes
Title: RE: Renaming macros
OK, here is a better formatted patch, preserving encoding etc. Thanks
for the feedback. The update is still being done in metrics() in the
same way that the macro expansion was being done previously. I have
changed it to cast away the const-ness rather than make
Not in metrics. metrics is only there to compute and cache the size of
an inset.
Provide some 'changeArgs' function or something like that.
Andre'
I agree metrics is not the place. However, at some point you need to go
cycling through all insets to find the macro instantiations and call
I noticed this had been done. It seems to have fixed
the bug. I've built tested on XP fedora 3. I had noticed
there was previously a big delay when creating the first
math insert in a blank document - this has been fixed also.
andrew
Title: RE: Renaming macros
Here is the patch as it stands. I'd be interested in comments.
One issue is that I've made cells_ mutable, which seems dodgy.
Another is that the name numArgs cells in macrotemplate are
just normal cells. I think they should be something that only
allows macroargs
> Not in metrics. metrics is only there to compute and cache the size of
> an inset.
>
> Provide some 'changeArgs' function or something like that.
>
> Andre'
I agree metrics is not the place. However, at some point you need to go
cycling through all insets to find the macro instantiations and
I noticed this had been done. It seems to have fixed
the bug. I've built & tested on XP & fedora 3. I had noticed
there was previously a big delay when creating the first
math insert in a blank document - this has been fixed also.
andrew
Title: RE: Renaming macros
Here is the patch as it stands. I'd be interested in comments.
One issue is that I've made cells_ mutable, which seems dodgy.
Another is that the name & numArgs cells in macrotemplate are
just normal cells. I think they should be something that only
allows
I am working on a patch for 1.4pre to allow renaming of macro templates
and modifying the number of arguments. It all works, except the case that
a macro template has already been instantiated within the text. Specifically,
I would like to grow the argument list as required. The most straight
I am working on a patch for 1.4pre to allow renaming of macro templates
and modifying the number of arguments. It all works, except the case that
a macro template has already been instantiated within the text. Specifically,
I would like to grow the argument list as required. The most straight
Title: Dynamic macros
I've ported the dynamic macro stuff to the current cvs version and
attached a diff. I've only tested this under mingw/windows. You can do:
\newcommand{\createCmd}[2]{\newcommand{#1}{#2}}
\createCmd{fName}{fDisplay}
and
\fName will display as fDisplay
This is great
Title: Dynamic macros
I've ported the dynamic macro stuff to the current cvs version and
attached a diff. I've only tested this under mingw/windows. You can do:
\newcommand{\createCmd}[2]{\newcommand{#1}{#2}}
\createCmd{fName}{fDisplay}
and
\fName will display as fDisplay
This is great
Michael Gerz
Wed, 04 Jan 2006 15:14:51 -0800
Hi Angus,
I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a
workaround, I use cygwin's automake
to generate the Makefiles. It works as expected but, of course, it isn't nice
to have to install and use
cygwin in addition to
Michael Gerz
Wed, 04 Jan 2006 15:14:51 -0800
>Hi Angus,
>
>
>I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a
>workaround, I use cygwin's automake
>to generate the Makefiles. It works as expected but, of course, it isn't nice
>to have to install and use
>cygwin in
Hi again,
So, I can now do this:
\newcommand{\createDynamicCmd}[1]{\newcommand{\fn#1}{cmdName: #1}}
\createDynamicCmd{Name}
\fnName
with
\fnName displaying as 'cmdName: Name' in the document
This makes me very happy, even if nobody else cares. The code is
at the bottom of this message. A big
Hi again,
So, I can now do this:
\newcommand{\createDynamicCmd}[1]{\newcommand{\fn#1}{cmdName: #1}}
\createDynamicCmd{Name}
\fnName
with
\fnName displaying as 'cmdName: Name' in the document
This makes me very happy, even if nobody else cares. The code is
at the bottom of this message. A big
Hi again,
Some time ago I was asking about creating macros that defined macros in
particular
having usage of the dynamically defined macro display properly. So, with the
latex
code:
\newcommand{\createDynamicCmd}[1]{\newcommand{\dynamicCmd}{cmdName: #1}}
$\createDynamicCmd{frank}$
Hi again,
Some time ago I was asking about creating macros that defined macros & in
particular
having usage of the dynamically defined macro display properly. So, with the
latex
code:
\newcommand{\createDynamicCmd}[1]{\newcommand{\dynamicCmd}{cmdName: #1}}
$\createDynamicCmd{frank}$
hi all,
I've just modified the LFUN_INSET_ERT handler so that I can have a
keyboard shortcut to create inlined ERT insets. I couldn't find any
documentation
on how to go about submitting patches etc - is there any? In any event,
I've included the code below.
I am now interested in adding support
hi all,
I've just modified the LFUN_INSET_ERT handler so that I can have a
keyboard shortcut to create inlined ERT insets. I couldn't find any
documentation
on how to go about submitting patches etc - is there any? In any event,
I've included the code below.
I am now interested in adding support
56 matches
Mail list logo
