Re: [rework docs] reasons, plans, questions
On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe Stöhr wrote: > Plans: I would rework the Tutorial and the UserGuide. [...] I don't think anybody is going to stop you. Not me at least. > But I want to delete platform specifig stuff like "Configuring the X > keyboard" etc. and ironic comments. (These comments are often funny but > shouldn't be part of a manual.) If they are really funny you could leave them in. As a reality check you might ask one of the regular readers from the Western Islands (where the Pound is still a Pound...). > [...] As koma-script is no longer part of the default installation of > VTeX and MikTeX, [Why btw? Sounds like a strange decision ...] > But if the rework is done, I want to merge the manual files to a > printable koma-script book file using all layout tricks, so that it can > be published as a real book. (I wondered why there is no book about LyX > available.) Publishing a book could help to reach more people and could > possibly help to pay the bills for one of the next developer meeting. > What do you think about it? Not bad. > Questions: > While working on the docs, many questions came in my mind that I would > ask in several other messages to this list. I hope someone can help me. I am not reading lyx-doc. Should I? Andre'
lyx140cvs, export html
export html has some errors: 1. subdocuments are not converted 2. paths are converted incorrectly, i. e. /a/b/c will be converted to _a_b_c 3. sans serif will be converted to (italic) -- Hartmut Hungerhilfe: http://www.thehungersite.com Das heutige Motto: Don't judge a boat by its paint or a man by his shadow.
Re: confirm unsubscribe from lyx-devel-UqbJ+GOpo4+hPH1hqNUYSQ@public.gmane.org
sorry guys, did "reply to list" accidentially. Karsten
Re: [rework docs] questions part one
Uwe Stöhr wrote: > I don't understand the sense of the menu Edit -> Open/Close Float. This > menu works only when the cursor is placed before an inset (it also works > for footnote insets), but not when it is inside the float. For me, it also works inside the float (1.3.6cvs). > And > opening/closing an inset goes much faster by a mouse click than by a > menu. In my opinion this would only be useful if it opens/close _all_ > insets at once. that would be all-insets-toggle. > So what is the real usage of this menu? Dunno. But anyway, this menu entry is no more in 1.4cvs. > What happens in LyX 1.4.x with the error boxes. I read they disappeard > there. But how is the error handling managed? An error dialog (see attached screenshot). And the context of the chosen error is marked in the text (which is currently broken btw). > Spellchecker: > As I remember LyX offers once the support for pspell. Is it gone? Why? Don't think so (you still can compile --with-pspell). >In the current version of the UserGuide I found a lot of > ispell-specific stuff that I would get rid of. Does the problems with > ispell described there still exist? Or does everybody replaced ispell by > the "newer and generally better aspell"? I think gnu aspell has superceeded ispell for a lot of languages now, but there might still be languages that are not supported well (or at all) by aspell. In any case, it is good to have the choice. >In the preferences I can choose between aspell, ispell and hspell. > But as personal dictionary I can only set an ispell one. Why? I think that (gnu) aspell does not use this option (it uses the personal dictionary ~/.aspell..pws by default). This might as well count for other spellchecker options. Don't know. Jürgen > thanks and regards Uwe <>
Re: [patch] fix bug 1459
Am Samstag, 8. Januar 2005 21:31 schrieb Andre Poenitz:
> Patch attached. You could commit that if it fixes the problem.
Thanks a lot. It does fix the problem for
\displaystyle a &= b
but not for
a &= \displaystyle b\\
c
I'll commit the attached modified version unless you find a reason not to
do so.
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/mathed/ChangeLog lyx-1.4-cvs/src/mathed/ChangeLog
--- lyx-1.4-clean/src/mathed/ChangeLog 2005-01-06 20:28:42.0 +0100
+++ lyx-1.4-cvs/src/mathed/ChangeLog 2005-01-09 11:58:54.0 +0100
@@ -1,3 +1,8 @@
+2005-01-09 Georg Baum <[EMAIL PROTECTED]>
+
+ * math_parser.C (parse1): handle style commands that are not inside
+ a {} pair, fixes bug 1459 (from André)
+
2005-01-03 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* math_decorationinset.C (ams, validate): new methods. Require
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/mathed/math_parser.C lyx-1.4-cvs/src/mathed/math_parser.C
--- lyx-1.4-clean/src/mathed/math_parser.C 2005-01-08 11:15:02.0 +0100
+++ lyx-1.4-cvs/src/mathed/math_parser.C 2005-01-09 11:58:07.0 +0100
@@ -191,7 +191,8 @@ inline CatCode catcode(unsigned char c)
enum {
- FLAG_BRACE_LAST = 1 << 1, // last closing brace ends the parsing
+ FLAG_ALIGN = 1 << 0, // next & or \\ ends the parsing process
+ FLAG_BRACE_LAST = 1 << 1, // next closing brace ends the parsing
FLAG_RIGHT = 1 << 2, // next \\right ends the parsing process
FLAG_END= 1 << 3, // next \\end ends the parsing process
FLAG_BRACK_LAST = 1 << 4, // next closing bracket ends the parsing
@@ -757,9 +758,10 @@ void Parser::parse1(MathGridInset & grid
else if (t.cat() == catAlign) {
//lyxerr << " column now " << (cellcol + 1)
// << " max: " << grid.ncols() << endl;
+ if (flags & FLAG_ALIGN)
+return;
if (addCol(grid, cellcol))
-cell = &grid.cell(grid.index(cellrow,
- cellcol));
+cell = &grid.cell(grid.index(cellrow, cellcol));
}
else if (t.cat() == catSuper || t.cat() == catSub) {
@@ -917,6 +919,8 @@ void Parser::parse1(MathGridInset & grid
}
else if (t.cs() == "\\") {
+ if (flags & FLAG_ALIGN)
+return;
if (addRow(grid, cellrow, getArg('[', ']'))) {
cellcol = 0;
if (grid.asHullInset())
@@ -1210,25 +1214,35 @@ void Parser::parse1(MathGridInset & grid
if (l) {
if (l->inset == "font") {
cell->push_back(createMathInset(t.cs()));
- parse(cell->back().nucleus()->cell(0), FLAG_ITEM, asMode(mode, l->extra));
+ parse(cell->back().nucleus()->cell(0),
+ FLAG_ITEM, asMode(mode, l->extra));
}
else if (l->inset == "oldfont") {
cell->push_back(createMathInset(t.cs()));
- parse(cell->back().nucleus()->cell(0), flags, asMode(mode, l->extra));
- return;
+ parse(cell->back().nucleus()->cell(0),
+ flags | FLAG_ALIGN, asMode(mode, l->extra));
+ if (prevToken().cat() != catAlign &&
+ prevToken().cs() != "\\")
+ return;
+ putback();
}
else if (l->inset == "style") {
cell->push_back(createMathInset(t.cs()));
- parse(cell->back().nucleus()->cell(0), flags, mode);
- return;
+ parse(cell->back().nucleus()->cell(0),
+ flags | FLAG_ALIGN, mode);
+ if (prevToken().cat() != catAlign &&
+ prevToken().cs() != "\\")
+ return;
+ putback();
}
else {
MathAtom at = createMathInset(t.cs());
for (MathInset::idx_type i = 0; i < at->nargs(); ++i)
- parse(at.nucleus()->cell(i), FLAG_ITEM, asMode(mode, l->extra));
+ parse(at.nucleus()->cell(i),
+ FLAG_ITEM, asMode(mode, l->extra));
cell->push_back(at);
}
}
Re: [rework docs] reasons, plans, questions
Am Samstag, 8. Januar 2005 20:35 schrieb Uwe Stöhr: > Hello LyXers, > > last month I started to rework the documentation files. I am sure that this will be appreciated by many users. > First I just wanted to update the documentation for LyX QT 1.3.x and > make a bit more platform independent. But while working on the > UserGuide, I realized that it is really out of date. The last complete > rework was done in 2000 for the LyX 1.0.x series. In the meantime many > updates and new sections were added. But the documentation still misses > many informations and doesn't follow a structured concept. E.g. not all > menus are described and there is no explanation for the icon buttons > under the menu bar. I see one problem: What happens to the 1.4 documentation? At some point one would need to merge your changes back. Did you consider to leave 1.3 as is and modify 1.4 instead? This would avoid some additional work. IMHO we should not put too much effort in 1.3 anymore but concentrate on getting 1.4 ready. >The UserGuide will also have a short section about needed programs > and install issues for the platforms Linux/Unix, Mac and Win. I don't think that install issues belong into the user guide. IMHO they would be better put in an installation manual (that all users of prepackaged versions like the application bundle on Mac or .rpm, .deb etc can ignore). Or maybe put the install issues into an appendix. Georg
Re: [rework docs] questions part two
Am Samstag, 8. Januar 2005 22:43 schrieb Uwe Stöhr: > As I use LyXWin, could somebody please send me his file > "LaTeX-Configuration"? This menu is broken in LyXWin and I need it to > describe it in the docs. Thanks. I guess you don't mean the file that you can get via Help->LaTeX Configuration? This should be a help file by itself and not needed to be described. BTW, this document is generated from lib/doc/lib/doc/LaTeXConfig.lyx.in in the source package. What you can see under View->TeX information are lists of found LaTeX class files (.cls), style files (.sty) and BibTeX style files (.sty) > I want the example and template LyX files that comes with the beamer > package to be added to LyX CVS. These files works very well and the > author of course allows this. Is this possible or are there some objections? I don't think that it is worth the effort: 1. The need for updates. Including the files makes only sense if they are always up to date. Who is going to do that? 2. More effort for .rpm and .deb creators. At least debian has a latex-beamer package that contains the latex and lyx files. If lyx would also contain the files, there would be a conflict, so they must be excluded from the .deb package. If people want to use beamer who don't have it preinstalled, they need to install the latex files anyway, so they can as well install the lyx files, too. Georg
Re: [rework docs] reasons, plans, questions
Hi Uwe, I would rework the Tutorial and the UserGuide. The UserGuide will also have a short section about needed programs and install issues for the platforms Linux/Unix, Mac and Win. Hmmm... Does this make sense? If the user is able to read the UserGuide, he already managed to install LyX. Installation issues should be described in the README files provided with the source code. I started once with a new layout for the UserGuide in koma-script book format. As koma-script is no longer part of the default installation of VTeX and MikTeX, I returned back to the standard book class. Very interesting. Was komascript replaced by some new classes? Publishing a book could help to reach more people and could possibly help to pay the bills for one of the next developer meeting. What do you think about it? Great idea, in principle. However, I wonder whether the audience is broad enough. Has anybody ever counted to the number of LyX downloads? Do we have 100, 1.000, 10.000 or even more users? I changed the menu names in the documentation to the one used in LyX QT 1.3.x. I hope that they are the same as in LyX XForms. If this isn't the case, we should make them as uniform as possible for all GUIs. LyX 1.4 support the "branch inset " concept. You can put different texts in different branches, e.g. one branch for XForms and one branch for Qt. However, personally, I think it is best to stick to the Qt frontend only. IIRC even Angus admits that Qt is the GUI of the future. What I did/do: The rework of the Introduction is done. I currently working on the sections describing all menus and icon buttons. Please note that LyX 1.4 will look _substantially_ different from LyX 1.3. IMHO you should concentrate on LyX 1.4 and leave LyX 1.3 as it is. Kind regards, Michael
Re: Latest CVS LyX on cygwin: can not remove temp dir
Kayvan A. Sylvan wrote: > Exiting lyx, I see a dialog box: > > "Could not remove the temporary directory > /tmp/lyx_tmpdir3432003432/lyx_tmpbuf0" > > I am not sure why, but I suspect it has to do with the recent > cleanups. I can investigate more later, but maybe someone already > has a fix. Doesn't this happen when some file that should have been deleted is left in the directory? -- Angus
Re: [rework docs] reasons, plans, questions
Michael Schmitt wrote: > LyX 1.4 support the "branch inset " concept. You can put different texts > in different branches, e.g. one branch for XForms and one branch for Qt. > However, personally, I think it is best to stick to the Qt frontend only. > IIRC even Angus admits that Qt is the GUI of the future. Even Angus? When did I say that I like XForms? Just for the record, I am fully in agreement with André when he said in his mail "Re: Comments on structured authoring, LyX, OpenOffice, and life" to the lyx-users list (7 Jan): > Dropping xforms seems indeed sensible to me, even considering the amount > of work people like Jean-Marc and Angus already put there, and also > considering the fact that I am one of the remaining LyX/xforms users > myself. -- Angus
Re: packaging on Windows
Here's some notes of my experiences trying to build LyX on Windows having applied my 'packaging' patch which itself contains Jean-Marc's changes to the configuration stuff. Angus, could you please repost the very latest version of your patch? (Thanks!) Executive summary: with a little tweaking it works --- almost. By which I mean, I can create a LyX executable that does all the right things (so far I've only tried to run it from the build directory) but 'make install' is failing at the moment. Spaces in paths... What is even more important than supporting install paths with spaces is supporting document paths with spaces! At least LyX 1.3.5 (compiled with cygwin) did not support them Michael
Re: packaging on Windows
Michael Schmitt wrote: >> Here's some notes of my experiences trying to build LyX on Windows >> having applied my 'packaging' patch which itself contains Jean-Marc's >> changes to the configuration stuff. > > Angus, could you please repost the very latest version of your patch? > (Thanks!) You mean inclusive of all remaining MinGW kludges? Here it comes. -- Angus 07Jan05_plus_package_13x.patch.bz2 Description: BZip2 compressed data
Re: [rework docs] questions part two
I wrote: The menu Navigate -> Refs seems to be broken. I expect that this menu let me jump from cross- and citation-reference to the next, but nothing happens. Sorry. The menu works., but it doesn't jump from reference to reference. It jumps from one label to the next. So the menu name is a bit confusing. It should better have the name "Label". regards Uwe
Re: [rework docs] reasons, plans, questions
Andre Poenitz wrote: [...] As koma-script is no longer part of the default installation of VTeX and MikTeX, [Why btw? Sounds like a strange decision ...] The author of koma-script complained about the inclusion of his package to MikTeX. MikTeX has a different (but very user friendly) package handling in comparison to teTeX that the MikTeX people wouldn't change. Therefore MikTeX comes with a slightly older version of koma-script (because the old license of the package allows it) but not in the smallest (basic) installation. I don't know what happend for VTeX. regards Uwe
Re: [rework docs] reasons, plans, questions
Georg Baum wrote: I see one problem: What happens to the 1.4 documentation? At some point one would need to merge your changes back. Did you consider to leave 1.3 as is and modify 1.4 instead? This would avoid some additional work. IMHO we should not put too much effort in 1.3 anymore but concentrate on getting 1.4 ready. I started with the UserGuide found in the CVS under lib/docs. I thaught it is the version for LyX 1.4. If not where can I get the right one? I don't think that install issues belong into the user guide. IMHO they would be better put in an installation manual (that all users of prepackaged versions like the application bundle on Mac or .rpm, .deb etc can ignore). Or maybe put the install issues into an appendix. You are right. I wrote a section about installing under win and it takes only a half page. That should be enough. A detailed description could be indeed added to a special install manual. regards Uwe
Re: [rework docs] reasons, plans, questions
Michael Schmitt wrote: The UserGuide will also have a short section about needed programs and install issues for the platforms Linux/Unix, Mac and Win. Hmmm... Does this make sense? If the user is able to read the UserGuide, he already managed to install LyX. Installation issues should be described in the README files provided with the source code. Of course you are right. I want only a _short_ section with the programs needed for proper work (a half page should be enough). I noticed that some users managed to install LyX but forgot to install a pdf-viewer or ghostscript. Publishing a book could help to reach more people and could possibly help to pay the bills for one of the next developer meeting. What do you think about it? Great idea, in principle. However, I wonder whether the audience is broad enough. Has anybody ever counted to the number of LyX downloads? Do we have 100, 1.000, 10.000 or even more users? Interesting question. But the audience is bigger than the counted downloads from lyx.org. All LyX and Linux users I know use the version shipped with the Linux distribution. I know that publishing a book is not as easy as it seems and is not the primary goal for now. I came on the idea by Dante's book series. They published the koma-script manual and a beautiful book about PStricks. The latter is written by Herbet Voss. I bought them because they are very cheap and a printed book is easier to read than an online version. Please note that LyX 1.4 will look _substantially_ different from LyX 1.3. IMHO you should concentrate on LyX 1.4 and leave LyX 1.3 as it is. This is what I want. But I found only the old UserGuide in CVS. As I'm using Windows (there are many different reasons) I wasn't able to compile a CVS version. If Angus completed the support for LyX under Win I could try it again. Or Someone could send me a CVS binary. This binary needn't to be usable, only that I know how it looks. BTW. If LyX 1.4 is such a big step to the future why don't we name it LyX 2.0? Btw2 Is it planned to release LyX 1.4 with a GTK GUI? regards Uwe
Re: [rework docs] reasons, plans, questions
Uwe Stöhr wrote: Andre Poenitz wrote: [...] As koma-script is no longer part of the default installation of VTeX and MikTeX, [Why btw? Sounds like a strange decision ...] The author of koma-script complained about the inclusion of his package to MikTeX. no, Markus never complained, that his package is part of miktex. He doesn't like it, when his distribution is split into several parts, just as MiKTeX does. MikTeX has a different (but very user friendly) package handling in comparison to teTeX that the MikTeX people wouldn't change. the package handling of MiKTeX is not user-friendly! is is _better_ than nothing, as for teTeX, but MiKTeX ghandles only packages, which are part of the MiKTeX base, other packages must be installed by the user. The problem is not KOMAscript and not MiKTeX, the problem are the two maintainers ... Therefore MikTeX comes with a slightly older version of koma-script (because the old license of the package allows it) but not in the smallest (basic) installation. I don't know what happend for VTeX. VTeX has nothing to do with MiKTeX ... Herbert -- http://TeXnik.de/ http://PSTricks.de/ ftp://ftp.dante.de/tex-archive/info/math/voss/Voss-Mathmode.pdf http://www.dante.de/faq/de-tex-faq/ http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes
Re: [rework docs] questions part two
Georg Baum wrote: As I use LyXWin, could somebody please send me his file "LaTeX-Configuration"? This menu is broken in LyXWin and I need it to describe it in the docs. Thanks. I guess you don't mean the file that you can get via Help->LaTeX Configuration? No I mean exactly this one. BTW, this document is generated from lib/doc/lib/doc/LaTeXConfig.lyx.in in the source package. Thanks. I managed to have my own version know. There is a little bug: LyX searches for the obsolete package "a4wide". As described in the file "l2tabu", that can be downloaded from CTAN, a4wide shouldn't be used. I want the example and template LyX files that comes with the beamer package to be added to LyX CVS. These files works very well and the author of course allows this. Is this possible or are there some I don't think that it is worth the effort: 1. The need for updates. Including the files makes only sense if they are always up to date. Who is going to do that? The layout and example files needn't to be changed when beamer comes up with a new version. I tested the actual files hardly and improved them together with the beamer author, so that they are stable since beamer 2 (the actual one is beamer 3.1). 2. More effort for .rpm and .deb creators. At least debian has a latex-beamer package that contains the latex and lyx files. If lyx would also contain the files, there would be a conflict, so they must be excluded from the .deb package. Why that? All we have to do, is to copy the files to the folders lyx/share/lyx/layouts etc. So why do files in different folders cause trouble? The LyX files of the beamer package are placed by default in tex/latex/beamer/lyx but they are "senseless" there; LaTeX doesn't register them and can't take up something with. If a LyX user wants to use beamer, he has to copy the files from tex/latex/beamer/lyx to lyx/share/lyx/ manually. So I thaught we can do this for the user by deliver the files with the Lyx package. regards uwe
Re: [rework docs] questions part two
Uwe Stöhr wrote: > There is a little bug: LyX searches for the obsolete package "a4wide". This isn't a bug. LyX needs this package for the special a4 margin "feature". > As described in the file "l2tabu", that can be downloaded from CTAN, > a4wide shouldn't be used. Yes, therefore the native support for this (and a4.sty) should be dropped (there are other cases like this). But until then, we should certainly search for this package. This won't happen before 1.5. Jürgen
Re: [rework docs] reasons, plans, questions
Herbert Voss wrote: no, Markus never complained, that his package is part of miktex. He doesn't like it, when his distribution is split into several parts, just as MiKTeX does. That was what I meant. MikTeX has a different (but very user friendly) package handling in comparison to teTeX that the MikTeX people wouldn't change. the package handling of MiKTeX is not user-friendly! is is _better_ than nothing OK its just my opinion. I find it very useful that MikTeX is able to install missing packages on the fly (while a file is texed). This also works while reconfiguring LyX; MikTeX installs all the packages LyX is looking for - very comfortable. In comparison to teTeX the user haven't to use commands like texhash, it is done in the background without bothering the user. but MiKTeX handles only packages, which are part of the MiKTeX base, other packages must be installed by the user. I've never had a package that was not in MikTeX's base. The base is also updated every month. But discussing about the best distribution is useless. Both works very well and in one or two weeks the new teTeX 3 comes out. The problem is not KOMAscript and not MiKTeX, the problem are the two maintainers ... As I'ver heard that's the real point. VTeX has nothing to do with MiKTeX ... I know that. regards Uwe
[patch] fix bug 1332
The attached patch fixes bug 1332. OK to apply?
Georg
PS: Uwe, I am not going to do anything for 1.3, because I don't understand
the code well enough. 1.4 was quite easy to understand (although I am not
familiar with the LyX core).
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/ChangeLog lyx-1.4-cvs/src/ChangeLog
--- lyx-1.4-clean/src/ChangeLog 2005-01-08 11:13:50.0 +0100
+++ lyx-1.4-cvs/src/ChangeLog 2005-01-09 16:43:46.0 +0100
@@ -1,3 +1,8 @@
+2005-01-09 Georg Baum <[EMAIL PROTECTED]>
+
+ * CutAndPaste.C (pasteSelectionHelper): fix bug 1332 (preserve the
+ layout if pasting into an empty paragraph)
+
2005-01-07 Lars Gullik Bjonnes <[EMAIL PROTECTED]>
* tex-accent.C: add
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/CutAndPaste.C lyx-1.4-cvs/src/CutAndPaste.C
--- lyx-1.4-clean/src/CutAndPaste.C 2004-12-02 14:04:39.0 +0100
+++ lyx-1.4-cvs/src/CutAndPaste.C 2005-01-09 16:34:04.0 +0100
@@ -151,8 +151,12 @@ pasteSelectionHelper(Buffer const & buff
}
}
- // Make the buf exactly the same layout as the cursor paragraph.
- insertion.begin()->makeSameLayout(pars[pit]);
+ bool const empty = pars[pit].empty();
+ if (!empty) {
+ // Make the buf exactly the same layout as the cursor
+ // paragraph.
+ insertion.begin()->makeSameLayout(pars[pit]);
+ }
// Prepare the paragraphs and insets for insertion.
// A couple of insets store buffer references so need updating.
@@ -182,15 +186,24 @@ pasteSelectionHelper(Buffer const & buff
std::swap(in.paragraphs(), insertion);
// Split the paragraph for inserting the buf if necessary.
- bool did_split = false;
- if (pars[pit].size() || pit + 1 == pit_type(pars.size())) {
+ if (!empty)
breakParagraphConservative(buffer.params(), pars, pit, pos);
- did_split = true;
- }
// Paste it!
- pars.insert(pars.begin() + pit + 1, insertion.begin(), insertion.end());
- mergeParagraph(buffer.params(), pars, pit);
+ if (empty) {
+ pars.insert(pars.begin() + pit, insertion.begin(),
+ insertion.end());
+
+ // merge the empty par with the last par of the insertion
+ mergeParagraph(buffer.params(), pars,
+ pit + insertion.size() - 1);
+ } else {
+ pars.insert(pars.begin() + pit + 1, insertion.begin(),
+ insertion.end());
+
+ // merge the first par of the insertion with the current par
+ mergeParagraph(buffer.params(), pars, pit);
+ }
pit_type last_paste = pit + insertion.size() - 1;
@@ -199,7 +212,7 @@ pasteSelectionHelper(Buffer const & buff
pos = pars[last_paste].size();
// Maybe some pasting.
- if (did_split && last_paste + 1 != pit_type(pars.size())) {
+ if (!empty && last_paste + 1 != pit_type(pars.size())) {
if (pars[last_paste + 1].hasSameLayout(pars[last_paste])) {
mergeParagraph(buffer.params(), pars, last_paste);
} else if (pars[last_paste + 1].empty()) {
Re: [rework docs] reasons, plans, questions
On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe St?hr wrote: > The UserGuide will also have a short section about needed programs > and install issues for the platforms Linux/Unix, Mac and Win. IMO, whilst such docs would be great, the User Guide is the wrong place for it. I'd prefer such stuff to be on the website / wiki, plus a plain ASCII file in the tarball regards john
Re: [rework docs] reasons, plans, questions
Uwe Stöhr wrote: the package handling of MiKTeX is not user-friendly! is is _better_ than nothing OK its just my opinion. I find it very useful that MikTeX is able to install missing packages on the fly (while a file is texed). This also works while reconfiguring LyX; MikTeX installs all the packages LyX is looking for - very comfortable. In comparison to teTeX the user haven't to use commands like texhash, it is done in the background without bothering the user. As I wrote, this is not right. A package, which is not listed in the MiKTeX base must be installed by the user _with_ mktexlsr! I've never had a package that was not in MikTeX's base. The base is also updated every month. sure, but _new_ packages had to be put _by hand_ into the MiKTeX base, e.g. nearly _all_ contributed packages of pstricks where not part of MiKTeX, until someone told Christian ... But discussing about the best distribution is useless. Both works very well and in one or two weeks the new teTeX 3 comes out. There will be no change to the _user_ VTeX has nothing to do with MiKTeX ... I know that. I wanted to say, that komascript is no problem here ... ;-) Herbert -- http://TeXnik.de/ http://PSTricks.de/ ftp://ftp.dante.de/tex-archive/info/math/voss/Voss-Mathmode.pdf http://www.dante.de/faq/de-tex-faq/ http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes
Re: [rework docs] questions part two
Am Sonntag, 9. Januar 2005 16:26 schrieb Uwe Stöhr: > The layout and example files needn't to be changed when beamer comes up > with a new version. I tested the actual files hardly and improved them > together with the beamer author, so that they are stable since beamer 2 > (the actual one is beamer 3.1). The fact that it was like that in the past does not mean that it will not be necessary in the future, but form what you say I guess it is at least unlikely. > > 2. More effort for .rpm and .deb creators. At least debian has a > > latex-beamer package that contains the latex and lyx files. If lyx would > > also contain the files, there would be a conflict, so they must be > > excluded from the .deb package. > > Why that? All we have to do, is to copy the files to the folders > lyx/share/lyx/layouts etc. So why do files in different folders cause > trouble? Because they are not in different folders. The debian package latex-beamer (in .deb format) installs them (ready for use) under /usr/share/lyx. I don't know if there exist .rpm packages for latex-beamer, but if they do, and if they are packaged carefully, they'll do the same. So all a user has to do is to install both latex-beamer and lyx, and he has everything he needs. If the lyx package would contain the beamer files, latex-beamer and lyx would not be installable at the same time. Therefore the packagers would need to tweak the lyx install process to exclude the beamer files. Of course the situation changes if lyx was the primary source for the files and they were not contained in latex-beamer anymore. > manually. So I thaught we can do this for the user by deliver the files > with the Lyx package. I understood that. In fact, I don't really care very much, but I only wanted to make clear that this would also create more work at other places. Georg
Re: [rework docs] reasons, plans, questions
Am Sonntag, 9. Januar 2005 15:34 schrieb Uwe Stöhr: > I started with the UserGuide found in the CVS under lib/docs. I thaught > it is the version for LyX 1.4. If not where can I get the right one? This is correct if it is the HEAD branch. I thought you used 1.3 because you wrote that you wanted to update the 1.3 documentation originally. Georg
Re: lyx140cvs, export html
Am Samstag, 8. Januar 2005 09:48 schrieb Hartmut Haase: > export html has some errors: > 1. subdocuments are not converted > 2. paths are converted incorrectly, i. e. /a/b/c will be converted to _a_b_c What kind of paths do you mean? Paths to included graphics? > 3. sans serif will be converted to (italic) This is probably a bug of your html converter, since the conversion goes via latex. BTW, which one do you use? Does it work when you export to latex and call the HTML converter by hand? Georg
Re: [rework docs] reasons, plans, questions
On Sun, Jan 09, 2005 at 04:11:09PM +, John Levon wrote: > On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe St?hr wrote: > > > The UserGuide will also have a short section about needed programs > > and install issues for the platforms Linux/Unix, Mac and Win. > > IMO, whilst such docs would be great, the User Guide is the wrong place > for it. I'd prefer such stuff to be on the website / wiki, plus a plain > ASCII file in the tarball Indeed. Having it in the UserGuide only serves people masochistic enough to read it either as .lyx in a text editor before installation or after installation to see what might have sped up the installation... Andre'
Re: [rework docs] reasons, plans, questions
On Sun, Jan 09, 2005 at 03:58:08PM +0100, Uwe Stöhr wrote: > BTW. If LyX 1.4 is such a big step to the future why don't we name it > LyX 2.0? Because most of the infrastructure changes will bear user visible fruit only in the next release, or even later. > Btw2 Is it planned to release LyX 1.4 with a GTK GUI? Depends on the release date. If that's 'soonish', probably not, otherwise i depends on th GTK frontend to catch up... Andre'
Re: [patch] fix bug 1459
On Sun, Jan 09, 2005 at 12:10:56PM +0100, Georg Baum wrote: > Am Samstag, 8. Januar 2005 21:31 schrieb Andre Poenitz: > > > Patch attached. You could commit that if it fixes the problem. > > Thanks a lot. It does fix the problem for > > \displaystyle a &= b > > but not for > > a &= \displaystyle b\\ > c > > I'll commit the attached modified version unless you find a reason not to > do so. Add the same thing (check for \\) to the parsing of oldfonts, please (the chunk above). This fixes anaother bug... Andre' --
Block Cursor: Feature Request
Hi, I have been a LyX user for many many years now and I would like to thank the developers for your dedication. LyX used to have a block cursor, but in the Qt version now there is only a blinking line cursor. It is extremely hard to see the cursor on a page that is dense with equations. It would greatly enhance usability to add a block cursor. Thanks, Binu Mathew -- ___ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
Re: [patch] fix bug 1459
Am Sonntag, 9. Januar 2005 20:06 schrieb Andre Poenitz:
> Add the same thing (check for \\) to the parsing of oldfonts, please
> (the chunk above). This fixes anaother bug...
I did that already! (Or I don't understand what you mean):
else if (l->inset == "oldfont") {
cell->push_back(createMathInset(t.cs()));
- parse(cell->back().nucleus()->cell(0), flags, asMode(mode,
l->extra));
- return;
+ parse(cell->back().nucleus()->cell(0),
+ flags | FLAG_ALIGN, asMode(mode, l->extra));
+ if (prevToken().cat() != catAlign &&
+ prevToken().cs() != "\\")
+ return;
+ putback();
}
Georg
Re: [rework docs] questions part two
Georg Baum wrote: Why that? All we have to do, is to copy the files to the folders lyx/share/lyx/layouts etc. So why do files in different folders cause trouble? Because they are not in different folders. The debian package latex-beamer (in .deb format) installs them (ready for use) under /usr/share/lyx. That was new for me. I assumed the beamer class is installed as LaTeX-package on all platforms and not a separately. So I retract my request. regards Uwe
Re: [rework docs] reasons, plans, questions
Andre Poenitz wrote: Indeed. Having it in the UserGuide only serves people masochistic enough to read it either as .lyx in a text editor before installation or after installation to see what might have sped up the installation... You are right, I dropped this now. thanks Uwe
[patch 14x] packaging
For the sake of completeness, I attach the 'packaging' patch for LyX 1.4.x.
It's meant to be functionally equivalent to LyX 1.3.x, but differs in one
important respect:
In LyX 1.3.x, gettext is initialised after the localedir is set with an
explicit call "gettext_init(localedir);".
In LyX 1.4.x, someone get clever and wrote the code in message.C which
initialises gettext the first time it is invoked. All very clever, except
we spend some effort in establishing what the localedir is and, in the
process, we may well send some stuff to lyxerr through gettext. Bummer.
gettext is now initialised with an empty localedir and there's no way to
re-initialise it once the localedir has actually been found.
Clearly, there are two possible solutions:
1. Ensure that nothing is set to gettext before the localdir is
ascertained.
2. Enable gettext to be initialised explicitly, as it is in LyX 1.3.x.
I think that, for now, I'd like to bring back (2).
Later I have an idea to use
#include
// Phoenix is currently hardcoded to know about std::ostream.
// It knows nothing about our LyXErr stream.
std::ostream & lyxerr_ref = lyxerr;
phoenix::actor > lyxerr_ =
phoenix::var(lyxerr_ref);
// struct to invoke gettext 'lazily'.
struct lazy_gettext {
template
struct result {
typedef string const type;
};
// gettext is called when this operator() is called
// which isn't when
// lyxerr_ << tr_("some text");
// is executed in the text, but some time later when
// lyxerr_();
// is called. Ie when lyxerr_'s operator() is called.
template
string const operator()(DataType const & data) const
{
return _(data);
}
};
phoenix::function const tr_ = lazy_gettext();
int main() {
// Only the first data sent to lyxerr_ needs to be a
// phoenix actor.
lyxerr_ << phoenix::val(22) << ' ' << 33 << std::endl;
// Flag some text for translation, but don't do so yet.
// Ie, equivalent to "N_(...)" to the stuff in po.
// We'd need the awk script to search for "tr_(...)".
lyxerr_ << tr_("some translated text") << std::endl;
string const localedir = ...;
gettext_init(localedir);
// Flush what is in lyxerr_ through to lyxerr itself:
// Ie, invoke the phoenix actor's operator() which
// causes the lazy function to get it's ass into gear.
lyxerr_();
// Just to be safe, flush the buffer.
std::flush(lyxerr);
}
The point I'm trying to make is that this is a fabulously powerful and
unintrusive way to output only translated text, assuming that a localedir
can be found.
As I was saying. For later ;-)
--
Angus
package_14x.diff.bz2
Description: BZip2 compressed data
[patch 14x] packaging
Hi Angus! Are we allowed to try your patch out or are we suppoes just to read it? ;-) At least the last file is necessary for compilation: ? src/frontends/xforms/1.4-XFormsView.C ? src/frontends/xforms/1.4-XWorkArea.C ? src/frontends/xforms/1.4-XWorkArea.h ? src/frontends/xforms/1.4-bmtable.c ? src/frontends/xforms/1.4-bmtable.h ? src/support/lyxlib-orig.C ? src/support/lyxlib.C ? src/support/package.C.in ? src/support/package.h Do I need to run "make clean ; autogen.sh" by hand or is the maintainer mode taking care of that? Cheers /Andreas
Re: [rework docs] reasons, plans, questions
On Sun, 2005-01-09 at 20:14 +0100, Andre Poenitz wrote: > Depends on the release date. If that's 'soonish', probably not, > otherwise i depends on th GTK frontend to catch up... I keep offering the GTK frontend cookies and sweets to try and get it to catch up, but it just sits there obstinately waiting for me to work on it. lyx-gtk is pretty broken atm, actually, one can't even scroll around in a document due to some changes somewhere along the line in lyx proper: I cannot say when since I was not paying attention at the time. I'm hoping that my sense of humour will improve when I've had some sleep. To quote Lars: "Blame it on the Pub"[1]. John 1. http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg49464.html
