Re: [PATCH] InsetInclude and version control bug
On Fri, 14 Feb 2003, Allan Rae wrote: > Yes, but I haven't gotten around to it yet. Will update again and > commit today. Haven't had time after all. Feel free to make the one line change yourself. Allan. (ARRae)
Re: [PATCH] InsetInclude and version control bug
On Fri, 14 Feb 2003, John Levon wrote: > On Thu, Jan 30, 2003 at 02:15:37PM +1000, Allan Rae wrote: > > > +2003-01-27 Allan Rae <[EMAIL PROTECTED]> > > + > > + * insetinclude.C (loadIfNeeded): included files might be under > > + VCS control so we need loadLyXFile() not readFile() for that. > > + > > Are you still planning to apply this at some point ? I guess you tested > it Yes, but I haven't gotten around to it yet. Will update again and commit today. Yes, it works for me. Can't think of anything I might do to break it -- loadLyXFile() just adds VCS handling a little bit extra then calls readFile() and the existing tests in loadIfNeeded() cover all possibilities of an alert dialog in both functions. Allan. (ARRae)
kmap quote character doesn't work
Hello,
I haven't been on the list for a long time, so sorry if the same
question has been already asked. (I couldn't find anything on
bugzilla).
A few years ago I've made kmap file for serbocroatian.
Last time I used it in 1.1.6fix4 it worked fine.
Today I have installed 1.3.0 (and then just to check 1.2.3) and the
result was the same. The quote key mappings do not work (see
/usr/share/lyx/kbd/serbocroatian.kmap):
\kmap @ \"
\kmap \" "\\'{C}"
On pressing @, I get " and I should be getting the quotation sign <<
and >>, and on pressing " I get quotation signs << >>, instead of
capital C' (C acute).
Where should I start looking for the bug (kbmap.C wasn't too
promising)? This was obviously introduced between 1.1.6 and 1.2.x.
Regards,
--
Zvezdan Petkovic <[EMAIL PROTECTED]>
http://www.cs.wm.edu/~zvezdan/
Re: [PATCH] InsetInclude and version control bug
On Thu, Jan 30, 2003 at 02:15:37PM +1000, Allan Rae wrote: > +2003-01-27 Allan Rae <[EMAIL PROTECTED]> > + > + * insetinclude.C (loadIfNeeded): included files might be under > + VCS control so we need loadLyXFile() not readFile() for that. > + Are you still planning to apply this at some point ? I guess you tested it john
to:Öйú½ð¶¦ÉÌÎñÍø
Title: Öйú½ð¶¦ÉÌÎñÍø ×𾴵ĸºÔðÈË: ÐÂÄêºÃ! Öйú½ð¶¦ÉÌÎñÍø www.vxyv.com ³ÏÕ÷ÓÑÇéÁ´½Ó Ãâ·ÑΪÄú·¢²¼¸÷ÀàÐÅÏ¢,µç×ÓÉÌÎñÈí¼þ³ÏÕ÷´úÀíÉÌ. QQÔÚÏß×Éѯ:21677192 5189773 LQ:55028 55027 PP:12721676 4234627 Öйú½ð¶¦ÉÌÎñÍø µã»÷Í˶©¡ïÓʼþ²ÉÓùú¼ÊÉÌÎñ¿ì³µ·¢ËÍ,½âÊÍȨÊô·¢¼þÈËËùÓС£¡ï½ö¹©ºÏ·¨ÓÃ;,Èí¼þÔÚÏßQQ:21677192 http://55028.126.com
Re: Insert key
> We do not have an over-write-mode :-) > > -- > Lgb That explains it. How many people would actually want such a thing. I can't think of the last time I used it deliberatly. As John said, that functionality is a holdover from years ago. Cheers Koz.
Re: Insert key
On Fri, Feb 14, 2003 at 02:35:27AM +0100, Lars Gullik Bj?nnes wrote: > | To do what ? It has no purpose in LyX > > Would be more logical to use it to toggle over-write-mode I certainly don't want to implement this. I've always thought it was a stupid idea ever since graphical displays became common. > a menu... or even insert the cut-buffer or from the clip-board. Hmm. We should leave it then, don't want to open a can of worms ;) I wish PC keyboards had taken the Paste keys from the Sun keyboards... john
Re: Insert key
John Levon <[EMAIL PROTECTED]> writes: | On Fri, Feb 14, 2003 at 02:10:31PM +1300, Michael A. Koziarksi wrote: | | > > I wonder what people think of making the Insert key open the Insert | > > menu. | > | > of course I'm an oddity, I use a kinesis keyboard (http://www.kinesis- | > ergo.com/images/500-blk.jpg) and the insert key is right below X. So I hit it | > all the time. | | To do what ? It has no purpose in LyX Would be more logical to use it to toggle over-write-mode than to open a menu... or even insert the cut-buffer or from the clip-board. -- Lgb
Re: Insert key
On Fri, Feb 14, 2003 at 02:21:36PM +1300, Michael A. Koziarksi wrote: > It has very little purpose in other applications too. However surely the > default behaviour should follow the principle of 'least-surprises'? Maybe you're right. john
Re: bug 686 (delete empty mathbox from within.)
On Thu, Feb 13, 2003 at 06:06:02PM +0100, Andre Poenitz wrote: > The patch does not apply cleanly to current CVS The patch was made several weeks ago for 1.3CVS. I should have made another one > and it does not really follow LyX coding rules. I have read the 'coding rules' and I would appreciate it if you can show me the problems of my patch. It certainly need time to get used to all the rules. > Seems to work though. I just applied some modification of this patch. Thank you very much! It is encouraging and of special meaning to me since this is my first patch. -- Bo Peng
Re: Insert key
> To do what ? It has no purpose in LyX > > john It has very little purpose in other applications too. However surely the default behaviour should follow the principle of 'least-surprises'? Cheers Koz.
Re: Insert key
On Fri, Feb 14, 2003 at 02:10:31PM +1300, Michael A. Koziarksi wrote: > > I wonder what people think of making the Insert key open the Insert > > menu. > > of course I'm an oddity, I use a kinesis keyboard (http://www.kinesis- > ergo.com/images/500-blk.jpg) and the insert key is right below X. So I hit it > all the time. To do what ? It has no purpose in LyX john
Insert key
> I wonder what people think of making the Insert key open the Insert > menu. I don't know about anyone else, but I'd prefer the insert key to behave as expected. of course I'm an oddity, I use a kinesis keyboard (http://www.kinesis- ergo.com/images/500-blk.jpg) and the insert key is right below X. So I hit it all the time. Cheers Koz.
Re: Closing quote fubar ?
On Fri, Feb 14, 2003 at 01:46:29AM +0100, Lars Gullik Bj?nnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Thu, Feb 13, 2003 at 10:03:26PM +, John Levon wrote: > | > | > Is this some totally surreal bug in some changes I've made, > | > or is anyone else seeing that the closing smart quote no longer > | > looks like a quote in current CVS with Qt frontend, but like 2 Z's ?? > | > | Just confirmed - it happens with clean 1.4.0cvs. Something broke. > > Hmm... what quote style? Normal english ones. > > if << >> («») and some utf8 locale then it could be rendered > completely wrong. But I guess that would be a bit way off... This has broken since 1.4.0cvs branched. My 1.3.0 build does not show the error. I'm not sure what change has caused this. > It seems to only exist in the qt frontend. I do not see this with > xforms. Same here. regards john
Insert key
I wonder what people think of making the Insert key open the Insert menu. john
Re: Closing quote fubar ?
John Levon <[EMAIL PROTECTED]> writes: | On Thu, Feb 13, 2003 at 10:03:26PM +, John Levon wrote: | | > Is this some totally surreal bug in some changes I've made, | > or is anyone else seeing that the closing smart quote no longer | > looks like a quote in current CVS with Qt frontend, but like 2 Z's ?? | | Just confirmed - it happens with clean 1.4.0cvs. Something broke. Hmm... what quote style? if << >> («») and some utf8 locale then it could be rendered completely wrong. But I guess that would be a bit way off... It seems to only exist in the qt frontend. I do not see this with xforms. -- Lgb
Re: Closing quote fubar ?
On Thu, Feb 13, 2003 at 10:03:26PM +, John Levon wrote: > Is this some totally surreal bug in some changes I've made, > or is anyone else seeing that the closing smart quote no longer > looks like a quote in current CVS with Qt frontend, but like 2 Z's ?? Just confirmed - it happens with clean 1.4.0cvs. Something broke. john
Re: LyX 1.3.0 compile problems with -finstrument-functions
On Fri, Feb 14, 2003 at 10:11:14AM +1100, Amir Michail wrote: > We tried to write a LyX 1.3.0 template for DRT, but found > that the source no longer compiles with CXXFLAGS=-finstrument-functions. > This used to work with LyX 1.2.1. Here is the error (with Qt frontend): > > /usr/include/string.h:229: declaration of `char *strerror (int) throw > ()' throws different exceptions > ../../src/config.h:428: than previous declaration `char *strerror > (int)' Remember to autogen.sh and configure again after applying this Index: configure.ac === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/configure.ac,v retrieving revision 1.23 diff -u -r1.23 configure.ac --- configure.ac30 Jan 2003 10:05:18 - 1.23 +++ configure.ac7 Feb 2003 10:39:25 - @@ -238,7 +238,7 @@ AC_TYPE_SIZE_T AC_TYPE_UID_T -AC_CHECK_FUNCS(snprintf vsnprintf) +AC_CHECK_FUNCS(snprintf vsnprintf strerror) LYX_CHECK_DECL(snprintf, stdio.h) LYX_CHECK_DECL(vsnprintf, stdio.h) LYX_CHECK_DECL(istreambuf_iterator, iterator) Index: configure.in === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/configure.in,v retrieving revision 1.16 diff -u -r1.16 configure.in --- configure.in30 Jan 2003 10:05:18 - 1.16 +++ configure.in7 Feb 2003 10:39:26 - @@ -243,7 +243,7 @@ AC_TYPE_SIZE_T AC_TYPE_UID_T -AC_CHECK_FUNCS(snprintf vsnprintf) +AC_CHECK_FUNCS(snprintf vsnprintf strerror) LYX_CHECK_DECL(snprintf, stdio.h) LYX_CHECK_DECL(vsnprintf, stdio.h) LYX_CHECK_DECL(istreambuf_iterator, iterator)
1.3.0 still doesn't work!
Hi.. based on suggestions from this list, I upgraded to gcc3.2 and recompiled QT 3 and then compiled lyx 1.3.0. I still can't startup Lyx.. gives the following error: src/lyx: relocation error: src/lyx: undefined symbol: _ZN5QChar4nullE I'm using gcc/g++ 3.2.1 with Qt 3.0.7 on a Debian powerpc platform.. I'd really appreciate some help with getting this to work.. thanks, nirmal
bad import from 1.1.6 to 1.3
Dear developers,
if you use a math-macro in 1.1.6 it appears sometimes without its
brackets in 1.3.0, which surprisingly works sometimes. I have isolated a
case where it doesn't work, with a calligraphic font. Attached is a
minimum 1.1.6 file. It doesn't happen with lyx 1.2.3
all the best,
Pedro
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\begin_preamble
\newcommand{\bfmath}[1]{\mbox{\boldmath$#1$\unboldmath}}
\let\newcommand=\providecommand
\end_preamble
\language spanish
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset Formula \[
\bfmath {\mathcal{E}}_{i}\]
\end_inset
\the_end
Option clash between postscript driver default and using graphicx
This problem was reported earlier and I've "confirmed" it. I don't know if it's a lyx-bug or a latex-bug, here's the rundown: This file works: http://www.md.kth.se/~chr/lyx/bugs/option-clash/works.lyx This file fails: http://www.md.kth.se/~chr/lyx/bugs/option-clash/fails.lyx With the error that the package graphicx has already been loaded with a different option [], and is now being loaded with option [dvips]. The difference between the two files: diff fails.lyx works.lyx 7c7 < \graphics dvips --- > \graphics default so that explains why it tries to call graphicx with [dvips] the second time. The reason (I think) that grpahicx has already been called is that the document contains a table cell with text that's rotated, and therefore rotate.sty is callled, that calls graphicx.sty ... but I'm no latex-guru. (The rotating hypothesis comes from the fact that removing the setting that rotates the table cell removes the problem) Anyway, here's an excerpt of the log: [snip] (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/base/article.cls Document Class: article 1999/09/10 v1.4a Standard LaTeX document class [snip] )) (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/misc/rotating.sty Package: rotating 1997/09/26, v2.13 Rotation package (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/graphics/graphicx.sty Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/graphics/keyval.sty Package: keyval 1999/03/16 v1.13 key=value parser (DPC) \KV@toks@=\toks14 ) (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/graphics/graphics.sty Package: graphics 1999/02/16 v1.0l Standard LaTeX Graphics (DPC,SPQR) (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/graphics/trig.sty Package: trig 1999/03/16 v1.09 sin cos tan (DPC) ) (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/config/graphics.cfg) Package graphics Info: Driver file: dvips.def on input line 80. (/afs/md.kth.se/pkg/teTeX/1.07/share/texmf/tex/latex/graphics/dvips.def File: dvips.def 1999/02/16 v3.0i Driver-dependant file (DPC,SPQR) )) [snip] ! LaTeX Error: Option clash for package graphicx. [snip] The package graphicx has already been loaded with options: [] There has now been an attempt to load it with options [dvips] Adding the global options: ,dvips to your \documentclass declaration may fix this. [snip] One workaround, as in the log above, is to the the document option to: dvips and set the postscript driver option to default. (I think anyway). So... is this a lyx bug that I should report or? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
LyX 1.3.0 compile problems with -finstrument-functions
Hi, We tried to write a LyX 1.3.0 template for DRT, but found that the source no longer compiles with CXXFLAGS=-finstrument-functions. This used to work with LyX 1.2.1. Here is the error (with Qt frontend): g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include - finstrument-functions -c dimension.C -MT dimension.lo -MD -MP -MF .deps/dimension.TPlo In file included from /usr/include/g++-3/cstring:7, from /usr/include/g++-3/std/straits.h:106, from /usr/include/g++-3/std/bastring.h:36, from /usr/include/g++-3/string:6, from ../../src/LString.h:23, from math_support.h:10, from dimension.C:17: /usr/include/string.h:229: declaration of `char *strerror (int) throw ()' throws different exceptions ../../src/config.h:428: than previous declaration `char *strerror (int)' make[3]: *** [dimension.lo] Error 1 make[3]: Leaving directory `/root/lyx-1.3.0/src/mathed' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/lyx-1.3.0/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/lyx-1.3.0/src' make: *** [all-recursive] Error 1 Amir
Closing quote fubar ?
Is this some totally surreal bug in some changes I've made, or is anyone else seeing that the closing smart quote no longer looks like a quote in current CVS with Qt frontend, but like 2 Z's ?? john
Re: The bugzilla www page.
On 13 Feb 2003, Jean-Marc Lasgouttes wrote: > Could somebody update it to show that lyx 1.3.0 has been released? Who > has the right to do that? At the same time, the person could perhaps add a small footer saying who's responsible for the content? (for Lyx 1.3.1...) :) /C -- Christian Ridderström http://www.md.kth.se/~chr
Re: Win32-release
Claus Hentschel wrote: Hello, Claus. You've been busy! > Embedded eps-images cannot be viewed inside Lyx with Qt-3. Anything > went wrong trying to convert them from eps to xpm! (Using the > Xforms-Lyx eps images will be converted into ppm format w/o any > error) Cluas, I would suggest removing any converter to xpm format. Moreover, the Qt frontend can load png format natively, so why not define a converter eps -> png? Alternatively, use the same eps -> ppm converter that you've used for the xforms frontend. HTH, -- Angus
The bugzilla www page.
Could somebody update it to show that lyx 1.3.0 has been released? Who has the right to do that? JMarc
Re: bug 686 (delete empty mathbox from within.)
On Thu, Feb 13, 2003 at 06:06:02PM +0100, Andre' Poenitz wrote: > Seems to work though. I just applied some modification of this patch. Aerm. Could you please verify it works and close the bug? 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: bug 686 (delete empty mathbox from within.)
On Thu, Feb 13, 2003 at 10:46:54AM -0600, Bo Peng wrote: > On Mon, Feb 10, 2003 at 10:40:25AM -0600, Bo Peng wrote: > > If we are no longer on freeze, could anyone have a look at bug686? The > > patch is pretty small and easy to understand. > > I guess no one is interested in such small improvement right now. I will > just patch my own tree and wait. The patch does not apply cleanly to current CVS and it does not really follow LyX coding rules. Seems to work though. I just applied some modification of this patch. 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: bug 686 (delete empty mathbox from within.)
On Mon, Feb 10, 2003 at 10:40:25AM -0600, Bo Peng wrote: > If we are no longer on freeze, could anyone have a look at bug686? The > patch is pretty small and easy to understand. I guess no one is interested in such small improvement right now. I will just patch my own tree and wait. -- Bo Peng
Re: debug messages
On Thu, Feb 13, 2003 at 05:22:17PM +0100, Andre Poenitz wrote: > deleting pit 0x8b6bcb0 > > lately. > > Is that intentional behaviour? ooops, looks like some of my debug stuff got in too. fixed john
debug messages
I get lots of deleting pit 0x8b6bcb0 deleting pit 0x8f20de0 deleting pit 0xa7edbd8 deleting pit 0xa174470 deleting pit 0x8afe050 deleting pit 0x8ba2760 deleting pit 0x8ba27c8 lately. Is that intentional behaviour? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Win32-release
According to the current README I've removed XForms 0.89.6 and tried to use XForms 1.0 and/or Qt! A new Cygwin release with a new gcc 3.2 compiler. The new xforms 1.0 as well as the new choice to use the Qt frontend and the new lyx 1.3.0 sources: Too much changes in a too short time 8(( Since Friday afternoon I'd compiled the lyx sources more then 3 times a day looking for a combination of a compiler and a gui frontend that could be used to build a new usable lyx executable Anyway - I'm now preparing the tarballs and hopefully this afternoon will release LyX 1.3.0 for Win32 :-) What went wrong? 1) New Cygwin runs autoconf 2.57 which isn't supported in autogen.sh (There was a topic in lyx-devel concerning that, too). A change in line 22 did it: -*2.5[2346]) +*2.5[23467]) 2) autogen.sh's output was: cp config/relyx_configure.ac: No such file ... Generating acinclude.m4 ... cat: pkg.m4: No such file Any idea? It seems that we don't have to care about it because ./configure was okay. 3) config/libtool.m4: Using libtool (created with that m4 file) the file impgen.c will be created nearly before linking the executable lyx. To create impgen.c sed is told to remove all leading '# ' combinations. Unfortenately there are a few lines starting with '#'. Those lines of course will produce syntax errors in a C/C++ file! 4) Linking lyx using Xforms 1.0 does produce a lot of unresolved errors to fl_flget4MSBF fl_flget4LSBF fl_flget2LSBF fl_readpint All errors are told to be in functions located in libflimage.a. nm shows the missing entries to be in libforms.a. The link command includes ... -lforms -lflimage Changing tthe order into ... -lflimage -lforms was successfull! (I'll check that with my Linux libraries because it is strange to change the order if it does run on other systems) Here some remarks for those interested: === Xforms 1.0 does not compile using gcc 3.2.1 or gcc 2.95.3-5 (taken from the old Cygwin 1.3.12 release). Compilation has to be done using the current gcc-2 package, i.e. gcc 2.95.3-10 !! Using Qt-2 and gcc 2.95.3-10 linking the lyx executable failed to some strange unresolved errors. (Maybe another gcc or another library order will do the trick, too) Using Qt-3 and gcc 3.2.1 failed. Obviously those libs were build using gcc 2.95.3-10 because using that compiler all went well! === Now LyX using XForms 1.0 has proofed to be usable on Win32. I have'nt found any topic that is not working as before. (I'll releasing that today!) LyX using Qt-3 looks very different but it's running now, too. But I recognized that LyX did not run configure automatically when called the first time. Therefore opening a math box with M-m m produces an error message, telling me that any fonts are missing (xset was called in the background). After restarting Lyx math fonts are usable. Embedded eps-images cannot be viewed inside Lyx with Qt-3. Anything went wrong trying to convert them from eps to xpm! (Using the Xforms-Lyx eps images will be converted into ppm format w/o any error) Screen fonts with Qt3 seems to be half in size compared to Lyx/XForms? Is that correct or am I missing anything? What about those latex-ttf-fonts? Are they usable on Win32? So long ... Claus P.S.: Please use my e-mail address for responses!
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> btw... If I were a harddisk... I would prefere gcc 3.2... And then you will feel bored all day, waiting for someone to write on your lonely sectors... JMarc
Re: Patch that lets 1.3.0 import files from subdirectories
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
[I add lyx-devel in cc because I'd like some discussion]
Helge> I have tested your patch with the following document structure:
Helge> A main document (dtest.lyx) includes dtest2.lyx from the same
Helge> directory, and d1/d1.lyx and d2/d2.lyx d1/d1.lyx includes a
Helge> d1/d3/d3.lyx
Helge> Printing this don't work with plain lyx 1.3.0, but it works
Helge> with your patch. Opening just d1.lyx (in its own directory)
Helge> viewing the combined d1.lyx and d3/d3.lyx works with either
Helge> version of lyx, because d3.lyx don't include anything further.
OK, so it basically works for include insets.
Helge> Reading bugzilla I see some problems though. First the obvious
Helge> - this isn't finished and don't yet work with graphichs &
Helge> external insets.
I have a second patch attached to the bug that handles graphics and
should improve a few other things.
Helge> This however points to a more serious problem - the fact that
Helge> you need to do something special for external insets and
Helge> graphichs to work. I am sure you can get that to work, but will
Helge> it still work if I create a custom external inset (by adding to
Helge> .lyx/external_insets, no actual update to the lyx source?)
I have not looked to external insets yet, but the code changes should
be limited to the insetexternal.C code. But changes to
external_templates should not be necessary.
Helge> And how about files referenced from commands in ERT insets
Helge> and/or preamble commands?
AFAIK, preambles of child documents are not output, so this should not
be a concern.
Helge> My approach using subimport* works with all that. I use a lot
Helge> of ERT in my book because I do things that probably never will
Helge> be supported directly. Such as stuffing a two-column
Helge> multicolumns inside a float, using the listings package to get
Helge> a java program in one column and a C program in the other.
Helge> (with line numbers and syntax highlighting) This looks nice, my
Helge> source never breaks across a page, and one can see how C and
Helge> Java does the same in slightly different ways. The source files
Helge> are only mentioned in ERT code though. A latex macro defined in
Helge> the preamble takes a base filename given in the ert inset and
Helge> adds .C and .java and hands those filenames to the listing
Helge> package. Will your way of handling directories support that
Helge> sort of thing?
Well, if you do this kind of complicated things, you can probably also
use ERT to get \subimport* ;)
Seriously, I agree that this will not be supported. However, when you
do heavy ERT, you are basically on your own. We try to have a policy
of avoiding to add code just for the sake of making ERT work.
Helge> This is my reason for using import.sty, because it supports
Helge> this transparently. And I guess lots of other people do
Helge> similiar things, i.e. reference various files from ERT. And
Helge> hope to include that lyx-file from another in another
Helge> directory.
I took a look at your patch and at import.sty, and here is my current
thinking on it
The pros:
- it is a clean patch and I have no stylistic issue with it
- import.sty is not too new (meaning it will be generally available)
and is written by Donald Arseneau (this last point is important
because it means we can rely on its quality)
- it works with ERT and external insets
The cons:
- what your patch does not do is to make sure that, when using a temp
dir, all files end up in the master document's
- it depends on an extra package, whereas we have all the information
to do it ourselves
- not all packages honor \input@path (the macro that makes all that
possible). For example skak.sty (used for the chess external
template) does not.
- I do not think either that it will work for \bibliography{} when the
bib file is in a subdirectory. This case can work easily (meaning I
have to write it) with my approach
- this adds yet another way of including files in the dialog. I
suspect that this will rapidly become very confusing for users who
do not need all these bells and whistles. I tried to find a solution
that ``just works''.
I'd like to have other points of view on that too. People, please try
the patches at
http://www.aitel.hist.no/~helgehaf/sw/sw.html
and
http://bugzilla.lyx.org/show_bug.cgi?id=605
and tell us what you think. This is a bug that people have been
complaining about for several years, and the time has come to do
something about it.
I will try to finish the patch this week end (external insets and
bibliography).
JMarc
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 03:09:12PM +0100, Lars Gullik Bjønnes wrote: > It seems that the benefits that were present with gcc 2.7.x are just > not present anymore, so I think we should just get rid of the pragma. > > I have a patch ready, should I commit it? I think so. > btw... If I were a harddisk... I would prefere gcc 3.2... If I were sitting in front of my machine waiting for a compile to finish I would prefer 2.95. 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: lyx-1.3.0pre3 (MacOS 10.2.3)
Andre Poenitz <[EMAIL PROTECTED]> writes: | gcc 2.95 Without #pragma |textdata bss dec hex filename | 5856658 1828572 53284 7738514 761492 src/lyx | -rwxr-xr-x1 poenitz users141053566 Feb 13 13:33 src/lyx | | gcc 2.95 With #pragma |textdata bss dec hex filename | 5885074 1844584 53284 7782942 76c21e src/lyx | -rwxr-xr-x1 poenitz users134764982 Feb 13 14:37 src/lyx gcc 3.2 without #pragma textdata bss dec hex filename 2833803 81436 48860 2964099 2d3a83 src/lyx -rwxrwxr-x1 larsbj larsbj 76515434 Feb 13 12:43 src/lyx gcc 3.2 with #pragma textdata bss dec hex filename 2854587 81468 48864 2984919 2d8bd7 src/lyx -rwxrwxr-x1 larsbj larsbj 72220223 Feb 13 13:42 src/lyx Ok, to me the results are clear. Without pragma the filesize goes up a bit (after a strip I guess the differences are really small...), but binary size goes down. It seems that the benefits that were present with gcc 2.7.x are just not present anymore, so I think we should just get rid of the pragma. I have a patch ready, should I commit it? btw... If I were a harddisk... I would prefere gcc 3.2... -- Lgb
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: > | As sort of a surprise there is _no_ noticable difference > | (less than 2 seconds on a 12-minute run). > > Speed is not the issue, binary size is. > > run size on the one with and without pragma. Without #pragma textdata bss dec hex filename 5856658 1828572 53284 7738514 761492 src/lyx -rwxr-xr-x1 poenitz users141053566 Feb 13 13:33 src/lyx With #pragma textdata bss dec hex filename 5885074 1844584 53284 7782942 76c21e src/lyx -rwxr-xr-x1 poenitz users134764982 Feb 13 14:37 src/lyx Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Unexpected popularity for preview-latex
In the last few days, the Sourceforge statistics for preview-latex exhibited quite large page views, particularly considering that we are in a time of relative quietness (ok, the last release managed over a 1000 hits, about double the current interest, but still...). It's pretty obvious where this current popularity comes from: LyX-1.3.0 has been released, and the announcement contain a link to our home page (preview.sty is used in the new math preview functionality). The announcement appeared with various delays on various lists/sites/groups, and there have been corresponding highs of web traffic. Kudos, and thanks for the exposure, folks! I guess I should get thinking about how to make it easier to download just the LaTeX style files: after all, I already provide CTAN with such an archive. Problem is that the archive file name on CTAN is probably not the best choice for Sourceforge: it does nothing to suggest that you don't need to fetch it in case you are going to use the complete preview-latex package under Emacs. On CTAN, that is not a problem, since the archive for just the preview styles is in a completely different directory. Perhaps have the file keep the same contents, but call it something different like preview-only-styles-0.7.9.tar.gz (we already have some only-docs which is also optional). That's not a name I would want for CTAN, though... Thoughts? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Feb 13, 2003 at 01:01:56PM +0100, Lars Gullik Bjønnes wrote: | > That is very dependant on the compiler used. | > (version of gcc) | | As sort of a surprise there is _no_ noticable difference | (less than 2 seconds on a 12-minute run). Speed is not the issue, binary size is. run size on the one with and without pragma. -- Lgb
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 01:01:56PM +0100, Lars Gullik Bjønnes wrote: > That is very dependant on the compiler used. > (version of gcc) As sort of a surprise there is _no_ noticable difference (less than 2 seconds on a 12-minute run). 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: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 01:06:14PM +0100, Lars Gullik Bjønnes wrote: > | I'll have a go and post results after two clean recompiles > > You are using gcc 2.95, right? Yes. 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: lyx-1.3.0pre3 (MacOS 10.2.3)
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Feb 13, 2003 at 12:27:26PM +0100, Andre' Poenitz wrote: | > Well. I suppose killling all '#pragma' lines would be sufficient for the | > test... | | I'll have a go and post results after two clean recompiles You are using gcc 2.95, right? -- Lgb
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Feb 13, 2003 at 12:13:39PM +0100, Lars Gullik Bjønnes wrote: | > The question is if we want to do it or not? | > (I think yes.) | | I think yes, too, but I would have checked wheter it makes difference | first. That is very dependant on the compiler used. (version of gcc) | Well. I suppose killling all '#pragma' lines would be sufficient for the | test... Yes. I'll do a check with gcc 3.2. -- Lgb
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 12:27:26PM +0100, Andre' Poenitz wrote: > Well. I suppose killling all '#pragma' lines would be sufficient for the > test... I'll have a go and post results after two clean recompiles 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: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 12:13:39PM +0100, Lars Gullik Bjønnes wrote: > The question is if we want to do it or not? > (I think yes.) I think yes, too, but I would have checked wheter it makes difference first. Well. I suppose killling all '#pragma' lines would be sufficient for the test... 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: lyx-1.3.0pre3 (MacOS 10.2.3)
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Feb 13, 2003 at 11:27:49AM +0100, Lars Gullik Bjønnes wrote: | > Have you checked #pragma implementation/interface? | | Good point. But looks ok. | | > (I have a patch to remove all of those...) | | As script? No... I had a script when I created the patch... The question is if we want to do it or not? (I think yes.) -- Lgb
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
On Thu, Feb 13, 2003 at 11:27:49AM +0100, Lars Gullik Bjønnes wrote: > Have you checked #pragma implementation/interface? Good point. But looks ok. > (I have a patch to remove all of those...) As script? 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: mouse needed before keys in insert reference
On Sat, Feb 08, 2003 at 01:14:49PM -0500, Dr. Richard E. Hawkins wrote: > While it is possible to change the selection in insert-reference with > the up/down keys, this cannot be done until the mouse is moved into the > scroll-window (is that the right term?). This is odd and frustrating. > > If the keys are ususable, home/end and pageup/down should probably also > work. XForms sucks. Use the QT frontend.
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
Angus Leeming <[EMAIL PROTECTED]> writes: | Andre Poenitz wrote: | | > On Wed, Feb 12, 2003 at 11:57:10AM -0700, Jeff Whitaker wrote: | >> Ugh. I was afraid of that. Guess I'll just wait for the next | >> release of the Developer Tools. | >> | >> At least 1.2.3 works! | > | > I just renamed that 'type_info' field to 'ref_type_info'. | > Does that help? | | Apparently not. At least s/o else on the users' list reported that it | had no impact. Have you checked #pragma implementation/interface? (I have a patch to remove all of those...) -- Lgb
Re: lyx-1.3.0pre3 (MacOS 10.2.3)
Andre Poenitz wrote: > On Wed, Feb 12, 2003 at 11:57:10AM -0700, Jeff Whitaker wrote: >> Ugh. I was afraid of that. Guess I'll just wait for the next >> release of the Developer Tools. >> >> At least 1.2.3 works! > > I just renamed that 'type_info' field to 'ref_type_info'. > Does that help? Apparently not. At least s/o else on the users' list reported that it had no impact. -- Angus
Re: What's in a name???
Andre Poenitz wrote: > On Wed, Feb 12, 2003 at 10:48:56PM +, Angus Leeming wrote: >> I'm edging towards LFUN_CITATION_SHOW and LFUN_CITATION_APPLY as a >> first step towards the most general LFUN_DIALOG_SHOW and >> LFUN_DIALOG_APPLY. Do these names sound reasonable or does anybody >> have a better idea? > > Sounds reasonable. > >> - inset->setLoadingBuffer(bv_->buffer(), >> false); >> - updateInset(inset, true); >> + stringstream data(ev.argument); > > Why no istringstream? No reason other than cluelessness. As I said, it's clunky still. -- Angus
Re: Option clash
On Thu, 13 Feb 2003, Pedro Tejedor wrote:
> Dear developers,
>
> I downloaded and compiled recently lyx 1.3. It produces an error when I
>
> - choose interline space to be one and a half
> - use dvips option
> - use a table with a figure in one cell, and a rotated text in the other
> - try to compile it
>
> the error message says:
>
> LaTeX Error: Option clash for package graphicx.
> \usepackage
> {setspace}
> The package graphicx has already been loaded with options:
>[]
> There has now been an attempt to load it with options
>[dvips]
> Adding the global options:
>,dvips
> to your \documentclass declaration may fix this.
>
> It also happens if I have another table float rotated near the table
> with a figure on it.
>
> If I deselect the "dvips" option and choose default the file compiles
> without error, but I don't know the consecuences of not choosing dvips.
>
> Have I done something wrong, or is it a plain little bug?
>
> Thankyou
>
> Pedro
I tried repeating this but couldn't, could you send a minimal example
file?
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
Re: What's in a name???
On Wed, Feb 12, 2003 at 10:48:56PM +, Angus Leeming wrote: > I'm edging towards LFUN_CITATION_SHOW and LFUN_CITATION_APPLY as a first > step towards the most general LFUN_DIALOG_SHOW and LFUN_DIALOG_APPLY. Do > these names sound reasonable or does anybody have a better idea? Sounds reasonable. > - inset->setLoadingBuffer(bv_->buffer(), false); > - updateInset(inset, true); > + stringstream data(ev.argument); Why no istringstream? 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: lyx-1.3.0pre3 (MacOS 10.2.3)
On Wed, Feb 12, 2003 at 11:57:10AM -0700, Jeff Whitaker wrote: > Ugh. I was afraid of that. Guess I'll just wait for the next release of > the Developer Tools. > > At least 1.2.3 works! I just renamed that 'type_info' field to 'ref_type_info'. Does that help? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
