Re: [patch] fix bug 2629
Uwe Stöhr wrote: This is my first patch to the source code so don't beat me when I did it wrong, just tell me how it's done correctly and I'll learn my lesson. Add fancyplain to Page Style list: http://bugzilla.lyx.org/show_bug.cgi?id=2629 That looks like a file format change to me, so lyx2lyx support would be needed. Georg
Re: [patch 1.4] fix update of natbib labels cache
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jürgen Jean-Marc, this patch is what I committed to trunk yesterday. Jürgen I'd like to have it in 1.4 as well. O.K.? Yes. JMarc
Re: r16622 [1/3] - in /lyx-devel/branches/BRANCH_1_4_X/lib: d...
[EMAIL PROTECTED] wrote: Author: uwestoehr Date: Tue Jan 9 03:29:35 2007 New Revision: 16622 URL: http://www.lyx.org/trac/changeset/16622 Log: New Extended-Insets manual Added: lyx-devel/branches/BRANCH_1_4_X/lib/doc/Extended-Insets.lyx Modified: lyx-devel/branches/BRANCH_1_4_X/lib/ui/stdmenus.ui So your svn access finally works. Great! Unfortunately this is not only a privilege, but you have some duties, too: - Never ever commit stuff to 1.4 only, unless that is a fix for a bug not present in 1.5. We always need to have current documentation in 1.5, too. Then there is a chance that somebody who modifies a feature will update the documentation at the same time. Otherwise that will not happen for sure. - If you add new files, you have to add them to the appropriate Makefile.am and to scons_manifest. Otherwise they will not show up in the binary package. You also have to set the svn:eol-style flag if it is not a binary file, otherwise wwe will get useless diffs because of line ending changes. - In this particular case, you have to add Extended-Insets to tge list at the top of lib/doc/depend.py - If you add any new documentation file, you should also run lib/doc/depend.py to update lib/doc/Makefile.depend. This is not very important, Jean-Marc keeps forgetting this too, and since this is run automatically by the autotools if needed I usually notice that and commit the changes. - Always ask Jean-Marc for permission to commit to 1.4, even for tiny fixes. Georg
Re: r16622 [1/3] - in /lyx-devel/branches/BRANCH_1_4_X/lib: d...
Georg Baum wrote: - Never ever commit stuff to 1.4 only, unless that is a fix for a bug not present in 1.5. We always need to have current documentation in 1.5, too. Then there is a chance that somebody who modifies a feature will update the documentation at the same time. Otherwise that will not happen for sure. What I forgot: You can use the svn merge feature to merge changes from trunk to the 1.4 branch. Then you don't need to do the whole procedure twice. I don't know how much svn knowledge you have, if there are questions please read the svn book: http://svnbook.red-bean.com/ Georg
Re: Policy of adding new commands to syntax.default
Gregor Gorjanc wrote: I have another set of Sweave specific commands. I believe this is the last one. Here is the patch. Trunk and 1_4_X branch please. Thank you very much! I put it in trunk. Jean-Marc, I guess 1.4 is also OK? I did not forget your other mail, but that will stay in the todo queue for some time since it requires some thinking. Georg
Re: slow opening of docs
Abdelrazak Younes wrote: Edwin Leuven wrote: Abdelrazak Younes wrote: Could you profile this instead: lyx -e text UserGuide.lyx then you get this: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 100.00 0.01 0.01110.0010.00 lyx::frontend::GuiWorkArea::doGreyOut(lyx::frontend:: QLPainter) There is something wrong here, the GUI should not even be loaded with the '-e' option. Are you sure you passed the correct patch to the document? this was yesterday evenings svn. i agree it looks suspicious. will have another look tonight...
Re: [patch] fix bug 2721 now with attached patch
LyX creates dvi documents without proper dimension information
http://bugzilla.lyx.org/show_bug.cgi?id=2721
Simply add the [dvips] option to the geometry package when landscape is
used.
Opinions?
regards Uwe
Index: bufferparams.C
===
--- bufferparams.C (revision 16619)
+++ bufferparams.C (working copy)
@@ -879,7 +879,10 @@
}
if (use_geometry || nonstandard_papersize) {
- os \\usepackage{geometry}\n;
+ if (orientation == ORIENTATION_LANDSCAPE) {
+ os \\usepackage[dvips]{geometry}\n;}
+ else {
+ os \\usepackage{geometry}\n;}
texrow.newline();
os \\geometry{verbose;
if (orientation == ORIENTATION_LANDSCAPE)
FYI: Uwe now can access SVN properly :-)
It's been a long process, but thanks to Jean-Marc, it is now possible for Uwe to commit. cheers /Christian PS. I'll make sure the necessary steps are documented. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Developers' wiki: To be or not to be?
The developers' wiki suffered an accident a while back. I've resurrected most of the pages in a static form through the help of google. This was a while back and nothing much has happened since then. One thing I was using the devevlopers' wiki was to document the LFUNs. It is not that much work for me to restore the wiki, and manually copy/paste the wiki pages. My question is however if it is desirable. As far as I know, it has not been used very much? What do you think? Should we have a separate developers' wiki, or just use a single group in the users' wiki? Any other ideas, suggestions or requests? cheers /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
AW: Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
I do know that the new bookmark code has plenty of advantages. What this does not tell me is why bookmarks have to be a stack instead of a vector. Bo I can not see a way to implement dynamic bookmark menu items Bo without this stack (regression). So tell us, why? I agree that a stack of bookmarks has limited use, because the poor user has no idea of what boomark #5 actually is at a given time (a moving target). IMHO the slot-based approach was better. #1 is #1 and will always be #1. BTW: Why don't we allow the user to label bookmarks? That would be a good compromise. Just my 2 cents, Michael
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: Opinions? I think it is correct to use this option. However, even if it does not harm when using pdflatex, I've read that you have to expect errors if you're using another dvi-to-something driver that does not understand the dvi specials this option inserts (for instance: dvipdfm and dvipdfmx). So I'd prefer to insert this option only if we are actually exporting via dvips. Jürgen
Re: [patch] fix bug 2721 now with attached patch
Jürgen Spitzmüller wrote:
Opinions?
I think it is correct to use this option. However, even if it does not harm
when using pdflatex, I've read that you have to expect errors if you're
using another dvi-to-something driver that does not understand the dvi
specials this option inserts (for instance: dvipdfm and dvipdfmx).
So I'd prefer to insert this option only if we are actually exporting via
dvips.
Furthermore, this should not be inserted as an option to the usepackage
command, but as an argument to the \geometry{} command, as we do for all the
other options.
See some lines below in bufferparams.C.
Jürgen
Re: Policy of adding new commands to syntax.default
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Gregor Gorjanc wrote: I have another set of Sweave specific commands. I believe this is the last one. Here is the patch. Trunk and 1_4_X branch please. Thank you very much! Georg I put it in trunk. Jean-Marc, I guess 1.4 is also OK? Yes please. JMarc
Re: r16622 [1/3] - in /lyx-devel/branches/BRANCH_1_4_X/lib: d...
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg [EMAIL PROTECTED] wrote: Author: uwestoehr Date: Tue Jan 9 03:29:35 2007 New Revision: 16622 URL: http://www.lyx.org/trac/changeset/16622 Log: New Extended-Insets manual Added: lyx-devel/branches/BRANCH_1_4_X/lib/doc/Extended-Insets.lyx Modified: lyx-devel/branches/BRANCH_1_4_X/lib/ui/stdmenus.ui Georg So your svn access finally works. Great! Georg Unfortunately this is not only a privilege, but you have some Georg duties, too: Very good list Georg. Also, I will ask that you do not implement big changes (like creating a new document or removing one) without discussing it first. Shall I ask JMarc
Re: r16622 [1/3] - in /lyx-devel/branches/BRANCH_1_4_X/lib: d...
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc Shall I ask JMarc I am not sure what I was trying to write here...
Re: [PATCH] delay bibfileCache first update
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Could you test the attached patch nevertheless? Or Georg maybe?
It fails whenever different documents use different bib files of the same name
(without absolute path).
Consider the following case:
- I have a file one.lyx in directory /myfiles/one/ that includes a bibfile
refs.bib, which is also in that directory (and hence inserted without path).
- In directory /myfiles/two/, I have another file two.lyx, that also includes
a (different) file refs.lyx, which is either included in /myfiles/two/ or
situated in the TEXMF tree, so that it also is inserted without path.
When I open one.lyx and then two.lyx, not only the labels in two.lyx are
broken, but also the entries in the citation dialog are wrong (i.e. the ones
from /myfiles/one/refs.bib).
Since it makes sense to have bib files without path, I think that the scanning
has to be buffer-dependend.
Another case where it breaks is when you copy the contents of a.lyx to an
empty document which is not saved yet (or saved elsewhere).
OK then, IIUC, the attached patch is correct for all use-cases:
1) if a bib file is found in the same directory of the lyx file, this is
the one.
2) if not look in the cache.
3) if not in the cache, look for it with kpsewhich.
In practice, this means that we cache only files that are in the texmf
tree and there is no room for confusion.
As an added bonus, the patch also avoid the use of 'Path'.
By the way, is it normal that we don't allow bib files outside the texmf
tree or along the lyx file?
Abdel.
Index: insets/insetbibtex.C
===
--- insets/insetbibtex.C(revision 16588)
+++ insets/insetbibtex.C(working copy)
@@ -26,14 +26,27 @@
#include frontends/Alert.h
#include support/filetools.h
+#include support/fs_extras.h
#include support/lstrings.h
#include support/lyxlib.h
#include support/os.h
#include support/path.h
#include boost/tokenizer.hpp
+#include boost/filesystem/operations.hpp
+#include map
+using std::endl;
+using std::getline;
+using std::string;
+using std::ostream;
+using std::map;
+using std::pair;
+using std::vector;
+
+namespace fs = boost::filesystem;
+
namespace lyx {
using support::absolutePath;
@@ -61,14 +74,7 @@
namespace Alert = frontend::Alert;
namespace os = support::os;
-using std::endl;
-using std::getline;
-using std::string;
-using std::ostream;
-using std::pair;
-using std::vector;
-
InsetBibtex::InsetBibtex(InsetCommandParams const p)
: InsetCommand(p, bibtex)
{}
@@ -304,24 +310,45 @@
vectorFileName const InsetBibtex::getFiles(Buffer const buffer) const
{
- Path p(buffer.filePath());
+ string const file_path = buffer.filePath();
vectorFileName vec;
- string tmp;
+ typedef mapstring, FileName BibCache;
+ static mapstring, FileName bib_cache;
+
// FIXME UNICODE
string bibfiles = to_utf8(getParam(bibfiles));
- bibfiles = split(bibfiles, tmp, ',');
- while (!tmp.empty()) {
- FileName const file = findtexfile(changeExtension(tmp, bib),
bib);
- lyxerr[Debug::LATEX] Bibfile: file endl;
+ while (!bibfiles.empty()) {
+ // Get next file name
+ string bibcode;
+ bibfiles = split(bibfiles, bibcode, ',');
+ bibcode = changeExtension(bibcode, bib);
+ // If the file can be found directly, we just return an
+ // absolute path version of it.
+ FileName const absfile(file_path + bibcode);
+ if (fs::exists(absfile.toFilesystemEncoding())) {
+ vec.push_back(absfile);
+ continue;
+ }
+
+ BibCache::const_iterator it = bib_cache.find(bibcode);
+ if (it != bib_cache.end()) {
+ // We found it in the cache.
+ vec.push_back(it-second);
+ lyxerr[Debug::LATEX] Bibfile: it-second
endl;
+ continue;
+ }
+
+ FileName const file = findtexfile(bibcode, bib);
// If we didn't find a matching file name just fail silently
- if (!file.empty())
- vec.push_back(file);
+ if (file.empty())
+ continue;
- // Get next file name
- bibfiles = split(bibfiles, tmp, ',');
+ bib_cache[bibcode] = file;
+ vec.push_back(file);
+ lyxerr[Debug::LATEX] Bibfile: file endl;
}
return vec;
Re: [PATCH] delay bibfileCache first update
Abdelrazak Younes wrote: By the way, is it normal that we don't allow bib files outside the texmf tree or along the lyx file? We allow them, but they are identified with (absolute or relative) path, whereas those in the texmf tree or the same directory are only stored as file names. Jürgen
Re: [PATCH] delay bibfileCache first update
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: By the way, is it normal that we don't allow bib files outside the texmf tree or along the lyx file? We allow them, but they are identified with (absolute or relative) path, whereas those in the texmf tree or the same directory are only stored as file names. Then there is bug somewhere because selecting any bib file in the BibTex dialog will always truncate the path and the extension. So I am afraid that there is no way to select a file that is not in the textmf tree or in the same directory. Abdel.
Re: [PATCH] delay bibfileCache first update
Abdelrazak Younes wrote: Then there is bug somewhere because selecting any bib file in the BibTex dialog will always truncate the path and the extension. So I am afraid that there is no way to select a file that is not in the textmf tree or in the same directory. Works for me (via Add-Browse). Jürgen
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
Bo I can not see a way to implement dynamic bookmark menu items Bo without this stack (regression). So tell us, why? OK, use a vector and set bookmark-save x directly, then 1. you will need a lot of shortcuts for 20 bookmarks, currently, we only need one bookmark-save. 2. you will have 19 disabled menu items if bookmark-save 20 is used. To address your problem, I can implement tagged-bookmark. I mean, I can consider 1/2/3/4/5 or a/b/c/d/e etc as tags to bookmarks, display the tag before filename, and use 'bookmark-goto tag' to go to a saved bookmark. This way, I do not have to list invalid bookmarks. Bo
Re: [PATCH] delay bibfileCache first update
Georg Baum wrote: Abdelrazak Younes wrote: OK then, IIUC, the attached patch is correct for all use-cases: 1) if a bib file is found in the same directory of the lyx file, this is the one. 2) if not look in the cache. 3) if not in the cache, look for it with kpsewhich. Now you duplicated partly what findtexfile does. Not good IMHO. Agreed but, well, I wanted to remove this code from findtexfile but then it is used in Latex.C and I am not sure it is useful there. In practice, this means that we cache only files that are in the texmf tree and there is no room for confusion. Not good. We should cache all files. This makes the code simpler. As you prefer... It can be done with a map. No strong opinion on that... As an added bonus, the patch also avoid the use of 'Path'. At the cost of duplicated code. I prefer using Path and one utility function over not using Path but duplicating the code. Personally I don't like utility function that do two independant things like this finxdtexfile(). An utility function should do one thing and do it well IMHO. By the way, is it normal that we don't allow bib files outside the texmf tree or along the lyx file? As Jürgen already said: We allow them. If the dialog would not allow to add them then that would be a different bug, but in fact that works here. The dialog is only clever: It strips the path if the file is in the same directory as the document. Well, I think this is misleading somewhat. Because if you use a local bib file that has the same name as one in the Textmf tree, then you don't know which one you are using. I think we should prefix './' to the local one. It does not do so if it is somehere completely else, and you give the absolute path. We do this for all included files BTW, and it makes sense: Usually if I include files in the same directory or a subdirectory I want relative paths, because I can then transfer the whole document easily. Agreed but for me relative path means './toto' and not 'toto'. Abdel.
Re: Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
I agree that a stack of bookmarks has limited use, because the poor user has no idea of what boomark #5 actually is at a given time (a moving target). That is why I display filename of a bookmark. Previously, the poor user has to face ice-cold bookmark 1/2/3/4/5. BTW: Why don't we allow the user to label bookmarks? That would be a good compromise. This is similar to my tag idea. But if it needs another dialog, it has to wait. Bo
Re: Policy of adding new commands to syntax.default
Georg Baum [EMAIL PROTECTED] writes: Gregor Gorjanc wrote: I have another set of Sweave specific commands. I believe this is the last one. Here is the patch. Trunk and 1_4_X branch please. Thank you very much! I put it in trunk. Jean-Marc, I guess 1.4 is also OK? Great. I did not forget your other mail, but that will stay in the todo queue for some time since it requires some thinking. Thank you for this! I did thought nobody is interested in Sweave support. I agree that it need some more thinking. I am looking forward if anyone would like to discuss this. I guess this will not make it into 1.5. Am I right? As I mentioned I am writing a short note about Sweave with LyX for Rnews[1]. I have all the needed customisations described and it is really not much to do from a user perspective. If my reasoning about 1.5. is right, I will go ahead with this note and mention possible direct support in the future. Perhaps anyone interested in this and with more C++ knowledge could jump in. I can send this note to anyone interested for review/comments? [1]http://cran.r-project.org/doc/Rnews Gregor
Re: [PATCH] delay bibfileCache first update
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Then there is bug somewhere because selecting any bib file in the BibTex dialog will always truncate the path and the extension. So I am afraid that there is no way to select a file that is not in the textmf tree or in the same directory. Works for me (via Add-Browse). Here too. I was confused by the name stripping done in the dialog and I did not try a file in another path. We should change this misleading behaviour IMO. Right now, the dialog presentation is: * stripped file name for installed bib files. - OK * stripped file name for file in the current directory. - this should be changed to relative path (with './') * absolute path for other files (via add-browse) - its OK for dialog purpose as they are transformed to relative path internally if I understood Georg correctly. Abdel.
Re: Policy of adding new commands to syntax.default
Gregor == Gregor Gorjanc [EMAIL PROTECTED] writes: Gregor Thank you for this! I did thought nobody is interested in Gregor Sweave support. I spent these last three monthes writing documents with LyX and R, so I am definitely interested :) JMarc
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
Bo == Bo Peng [EMAIL PROTECTED] writes: I agree that a stack of bookmarks has limited use, because the poor user has no idea of what boomark #5 actually is at a given time (a moving target). Bo That is why I display filename of a bookmark. Previously, the poor Bo user has to face ice-cold bookmark 1/2/3/4/5. BTW: Why don't we allow the user to label bookmarks? That would be a good compromise. Bo This is similar to my tag idea. But if it needs another dialog, it Bo has to wait. If we are going to this route, we should stop a bit and remember that we already have something named label, and it is probably not necessary to implement them _again_. JMarc
Re: [PATCH] delay bibfileCache first update
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak * stripped file name for file in the current directory. - this should be changed to relative path (with './') Why? JMarc
Re: [PATCH] delay bibfileCache first update
Georg Baum wrote: Abdelrazak Younes wrote: In practice, this means that we cache only files that are in the texmf tree and there is no room for confusion. Not good. We should cache all files. This makes the code simpler. I thought a bit more about this and I think I disagree. It is OK to cache bibtex filenames because they are not supposed to change. But it is quite possible that you want to move one bib file onto another directory without having to restart LyX. Because of that, we should always make sure that the pointed file name really exists. Abdel.
Re: [PATCH] delay bibfileCache first update
Abdelrazak Younes wrote: Agreed but, well, I wanted to remove this code from findtexfile but then it is used in Latex.C and I am not sure it is useful there. It is used there on purpose IIRC. findtexfile was designed for exactly this use case: Find a file, using the same search algorithm as TeX. I don't blame you for no knowing that, because (as so often) it is not documented. In practice, this means that we cache only files that are in the texmf tree and there is no room for confusion. Not good. We should cache all files. This makes the code simpler. As you prefer... It can be done with a map. No strong opinion on that... Well, the cache is a map, isnt it? And we should always store FileNames, no strings please. Personally I don't like utility function that do two independant things like this finxdtexfile(). An utility function should do one thing and do it well IMHO. I agree, but in this case I think it is doing one simple thing: Use the TeX serach algorithm to find a file. Well, I think this is misleading somewhat. Because if you use a local bib file that has the same name as one in the Textmf tree, then you don't know which one you are using. I think we should prefix './' to the local one. This was simply designed to work exactly as it works in LaTeX. If we want to change that, then we should not store the filenames in a comma separated list, but use something similar to the new InsetCommandParams, and for each file store also a flag whether it comes from texmf or not. Using a ./ prefix for that is too fragile IMHO: ./xyz will not be found using kpsewhich if it is not local, but xyz will both be found using kpsewhich and as a local file. But please: We need to get 1.5.0 out of the door, so lets keep the bibfile storage as it is. If you know an easy way to fix the reload problem that is fine, but without redesigning the bibfile storage please. Agreed but for me relative path means './toto' and not 'toto'. Concerning the file system that is the same. Both will work. This seems to be a personal preference. Georg
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
Bo == Bo Peng [EMAIL PROTECTED] writes: Bo OK, use a vector and set bookmark-save x directly, then Bo 1. you will need a lot of shortcuts for 20 bookmarks, currently, Bo we only need one bookmark-save. Anyway we would need 20 shortcuts for bookmark_goto already (and I do not think that we have them). Or maybe you mean underlined shortcuts in menu? Bo 2. you will have 19 disabled menu items if bookmark-save 20 is Bo used. Changing MenuBackend to avoid this should not be too difficult. I am not sure anyway that having 20 bookmarks is the main goal. This is too much until we do have a proper bookmark management like a web browser has. Bo To address your problem, I can implement tagged-bookmark. I mean, Bo I can consider 1/2/3/4/5 or a/b/c/d/e etc as tags to bookmarks, Bo display the tag before filename, and use 'bookmark-goto tag' to go Bo to a saved bookmark. This way, I do not have to list invalid Bo bookmarks. Yes, something like that. But I am not sure we need to go beyond 9 bookmarks. What do bookmark users say? JMarc PS: Bo, I do not mean to criticize your new bookmarks implementation. I like most of what you have done there. It is only the stack that I do not like much.
Re: [PATCH] delay bibfileCache first update
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak * stripped file name for file in the current directory. - this should be changed to relative path (with './') Why? To be able to distinguish between this and a bibfile that have the same name in the Texmf tree. Abdel.
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
I like most of what you have done there. It is only the stack that I do not like much. That is fair. I missed one point though. It is easy change menu backend to display only valid bookmarks, but I really do not like menu items 'save bookmark 1', 'save bookmark 2' to 5 or 9. That was actually the major reason for me to use a stack. A small dialog that allow a user to enter a short phase (with a default) would make this feature more useful. If this is too troublesome for some poeple, I can also allow 'quick add' using the current stack. Bo
Re: [PATCH] delay bibfileCache first update
Georg Baum wrote: Abdelrazak Younes wrote: Agreed but, well, I wanted to remove this code from findtexfile but then it is used in Latex.C and I am not sure it is useful there. It is used there on purpose IIRC. findtexfile was designed for exactly this use case: Find a file, using the same search algorithm as TeX. OK, now I understand that it is used like that in Latex.C. But we are it for something internal to LyX now and that is not good I guess. I don't blame you for no knowing that, because (as so often) it is not documented. Indeed. In practice, this means that we cache only files that are in the texmf tree and there is no room for confusion. Not good. We should cache all files. This makes the code simpler. As you prefer... It can be done with a map. No strong opinion on that... Well, the cache is a map, isnt it? Yes, sorry, I mean a vector of FileName instead of a simple Filename map data. And we should always store FileNames, no strings please. Yes. Well, I think this is misleading somewhat. Because if you use a local bib file that has the same name as one in the Textmf tree, then you don't know which one you are using. I think we should prefix './' to the local one. This was simply designed to work exactly as it works in LaTeX. If we want to change that, then we should not store the filenames in a comma separated list, but use something similar to the new InsetCommandParams, and for each file store also a flag whether it comes from texmf or not. Using a ./ prefix for that is too fragile IMHO: ./xyz will not be found using kpsewhich if it is not local, but xyz will both be found using kpsewhich and as a local file. But then, how does it works for files that are neither local nor in the texmf tree? But please: We need to get 1.5.0 out of the door, so lets keep the bibfile storage as it is. If you know an easy way to fix the reload problem that is fine, but without redesigning the bibfile storage please. OK, I'll stop here. Agreed but for me relative path means './toto' and not 'toto'. Concerning the file system that is the same. Both will work. This seems to be a personal preference. On windows yes but not on Unix I think. Abdel.
Allowing multiple empty lines and spaces in the Lyx editor...
Hi I have now used lyx for a while for writing my master thesis and I am now quite happy to the it's usage with bibtex, separation of chapters to own includeable files, etc... While writing my text and thinking what to write, I have however often noticed that I want to separate the different parts of my text more freely from each others in the editor. I think it is a habit from the usage of word, notepads, etc... but while working, it helps me to see the different parts of the text more easily. (Especially crash notes I usually write first before writing the real text.) Therefore I always automatically try to press enter or spaces multiple times to notice that Lyx editor does not allow me to do this... (Being like a human being which newer learn :-) What do you think, would it be possible to add a support for more free-er usage of spaces and enter lines in the Lyx editor, without changing the way how they are really treated in the final DVI/PDF output? (As I am happy to the final pdf output that Lyx/latex currently produces) Mika
Re: Allowing multiple empty lines and spaces in the Lyx editor...
lamikr [EMAIL PROTECTED] writes: What do you think, would it be possible to add a support for more free-er usage of spaces and enter lines in the Lyx editor, without changing the way how they are really treated in the final DVI/PDF output? A simple answer: No. A more detailed answer: No. It's against the fundamental philosophy of LyX. Regards, Andreas
Re: Allowing multiple empty lines and spaces in the Lyx editor...
On Tue, 9 Jan 2007, Andreas K. wrote: lamikr [EMAIL PROTECTED] writes: What do you think, would it be possible to add a support for more free-er usage of spaces and enter lines in the Lyx editor, without changing the way how they are really treated in the final DVI/PDF output? A simple answer: No. A more detailed answer: No. It's against the fundamental philosophy of LyX. Don't feel discouraged. Perhaps if you rephrase what you want, there might be an alternative solution? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Allowing multiple empty lines and spaces in the Lyx editor...
lamikr wrote: Hi I have now used lyx for a while for writing my master thesis and I am now quite happy to the it's usage with bibtex, separation of chapters to own includeable files, etc... While writing my text and thinking what to write, I have however often noticed that I want to separate the different parts of my text more freely from each others in the editor. I think it is a habit from the usage of word, notepads, etc... but while working, it helps me to see the different parts of the text more easily. (Especially crash notes I usually write first before writing the real text.) Therefore I always automatically try to press enter or spaces multiple times to notice that Lyx editor does not allow me to do this... (Being like a human being which newer learn :-) What do you think, would it be possible to add a support for more free-er usage of spaces and enter lines in the Lyx editor, without changing the way how they are really treated in the final DVI/PDF output? (As I am happy to the final pdf output that Lyx/latex currently produces) Mika As noted elsewhere, this violates the what you see is what you meant philosophy underlying LyX. That said, to string out multiple spaces in a row, you can just enter hard spaces (C-space); to enter a bunch of blank lines (that won't collapse), use C-enter. /Paul
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
On Wed, Jan 10, 2007 at 09:41:27AM +1800, Bo Peng wrote: I like most of what you have done there. It is only the stack that I do not like much. That is fair. I missed one point though. It is easy change menu backend to display only valid bookmarks, but I really do not like menu items 'save bookmark 1', 'save bookmark 2' to 5 or 9. That was actually the major reason for me to use a stack. A small dialog that allow a user to enter a short phase (with a default) would make this feature more useful. If this is too troublesome for some poeple, I can also allow 'quick add' using the current stack. Bo, it is the stack organization which is confusing. The first saved bookmark gets assigned the number 1. When I save another bookmark, this last one is now the bookmark number 1. When I try to go to bookmark 1 by the menu, I expect to go to the *first* bookmark I saved. -- Enrico
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
Bo, it is the stack organization which is confusing. The first saved bookmark gets assigned the number 1. When I save another bookmark, this last one is now the bookmark number 1. When I try to go to bookmark 1 by the menu, I expect to go to the *first* bookmark I saved. OK. I will use list, but do you have any good idea to avoid many 'bookmark-save 1/2/3/4/5' menu items? Bo
Re: [PATCH] delay bibfileCache first update
On Tue, Jan 09, 2007 at 04:30:47PM +0100, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak * stripped file name for file in the current directory. - this should be changed to relative path (with './') Why? To be able to distinguish between this and a bibfile that have the same name in the Texmf tree. Please Abdel, don't try and fix what is not broken ;-) -- Enrico
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
If we are going to this route, we should stop a bit and remember that we already have something named label, and it is probably not necessary to implement them _again_. What exactly is this label? I can see inset-label that actually inset a \label to the latex code. I also see a disabled 'navigation - go to label'. So, how to set (multiple) label? Bo
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
On Wed, Jan 10, 2007 at 11:17:46AM +1800, Bo Peng wrote: Bo, it is the stack organization which is confusing. The first saved bookmark gets assigned the number 1. When I save another bookmark, this last one is now the bookmark number 1. When I try to go to bookmark 1 by the menu, I expect to go to the *first* bookmark I saved. OK. I will use list, but do you have any good idea to avoid many 'bookmark-save 1/2/3/4/5' menu items? I think that the LIFO - FIFO change should be enough. -- Enrico
Re: slow opening of docs
Abdelrazak Younes wrote: Could you profile this instead: lyx -e text UserGuide.lyx another try: % cumulative self self total time seconds secondscalls ms/call ms/call name 16.00 0.04 0.0424961 0.00 0.00 lyx::LyXLex::Pimpl::nextToken() 12.00 0.07 0.03 184108 0.00 0.00 lyx::Paragraph::setFont(int, lyx::LyXFont const) 8.00 0.09 0.02 180583 0.00 0.00 lyx::Paragraph::insertChar(int, wchar_t, lyx::LyXFont const, lyx::Change const) 8.00 0.11 0.0239984 0.00 0.00 lyx::LyXLex::getString() const 8.00 0.13 0.02 1148 0.02 0.02 lyx::LyXTextClass::LyXTextClass(lyx::LyXTextClass con st) 4.00 0.14 0.01 183891 0.00 0.00 lyx::Changes::set(lyx::Change const, int, int) 4.00 0.15 0.0114266 0.00 0.00 lyx::LyXLex::Pimpl::next(bool) 4.00 0.16 0.0112631 0.00 0.00 lyx::InsetBase::clone() const 4.00 0.17 0.01 9763 0.00 0.00 lyx::LyXFont::LyXFont() 4.00 0.18 0.01 9491 0.00 0.00 lyx::Paragraph::Pimpl::~Pimpl() 4.00 0.19 0.01 6765 0.00 0.00 std::vectorlyx::Paragraph::Pimpl::FontTable, std::al locatorlyx::Paragraph::Pimpl::FontTable ::operator=(std::vectorlyx::Paragraph::Pimpl::FontTable, std::a llocatorlyx::Paragraph::Pimpl::FontTable const) 4.00 0.20 0.01 4159 0.00 0.00 __gnu_cxx::__normal_iteratorboost::shared_ptrlyx::L yXLayout const*, std::vectorboost::shared_ptrlyx::LyXLayout, std::allocatorboost::shared_ptrlyx::LyXL ayout std::__find_if__gnu_cxx::__normal_iteratorboost::shared_ptrlyx::LyXLayout const*, std::vec torboost::shared_ptrlyx::LyXLayout, std::allocatorboost::shared_ptrlyx::LyXLayout , lyx::(anonym ous namespace)::LayoutNamesEqual(__gnu_cxx::__normal_iteratorboost::shared_ptrlyx::LyXLayout const*, st d::vectorboost::shared_ptrlyx::LyXLayout, std::allocatorboost::shared_ptrlyx::LyXLayout , __gnu_ cxx::__normal_iteratorboost::shared_ptrlyx::LyXLayout const*, std::vectorboost::shared_ptrlyx::LyXLayo ut, std::allocatorboost::shared_ptrlyx::LyXLayout , lyx::(anonymous namespace)::LayoutNamesEqual, std::random_access_iterator_tag)
qpainter warning
when starting lyx from the command line *with* a doc i see this: [EMAIL PROTECTED]:~/svn/build$ lyx-svn UserGuide.lyx QPainter::begin: Cannot paint on a null pixmap QPainter::end: Painter not active, aborted and the top part (couple of lines) of the document is hidden and i need to scroll down and up again to see it... (this is linux)
Re: Allowing multiple empty lines and spaces in the Lyx editor...
[EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andreas K. wrote:
lamikr [EMAIL PROTECTED] writes:
What do you think, would it be possible to add a support for more
free-er usage of spaces and enter lines in the Lyx editor, without
changing the way how they are really treated in the final DVI/PDF
output?
A simple answer: No.
A more detailed answer: No. It's against the fundamental philosophy
of LyX.
Don't feel discouraged. Perhaps if you rephrase what you want, there
might be an alternative solution?
One way I could argument in favor of this are code editors and different
code formats people have.
(50% of the people say that { must be in the if line with if, while
other 50% say that it must be in the next line, and both of them are
right...)
To help in this kind of situations, most of the code editors (Eclipse
for example) have nowadays code formatters, which
allow the developer to see the code written by others in the format they
have used to do.
And as I see the Lyx editor anyway as a smart code editor for Latex, I
would not think it being against the WYSIWYM principles Lyx try to
follow if it would allow writers to set some more air to their text in
the editor side. Instead I see that Lyx would just came smarter than
normal editors as it would allow the writing of latex source code in
Lyx editor a more flexible way while still guarantee the coherent output
and that could actually be a
KILLER FEATURE
for some more artistic persons than I to assist them to get their
keyboard, ideas and text fly faster than the screen can scroll :-)
Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
I think that the LIFO - FIFO change should be enough. This is very simple, and has been done. I am not going to add support for bookmark-save 2/3/4/5 right now, not because it is difficult to do, but because I dislike the menu items for them. Suggestions are welcome. Cheers, Bo
Re: Allowing multiple empty lines and spaces in the Lyx editor...
lamikr wrote: And as I see the Lyx editor anyway as a smart code editor for Latex, I would not think it being against the WYSIWYM principles Lyx try to follow if it would allow writers to set some more air to their text in the editor side. Instead I see that Lyx would just came smarter than normal editors as it would allow the writing of latex source code in Lyx editor a more flexible way while still guarantee the coherent output and that could actually be a KILLER FEATURE for some more artistic persons than I to assist them to get their keyboard, ideas and text fly faster than the screen can scroll :-) I suggest then to organise your writings with sections. Then, you can navigate through your document using the Toc dialog. When 1.5.0 is out you will even be able to _organize_ your document with the Toc dialog. Que demande le peuple? :-) Abdel. PS: this kind of discussion is best suited to the users' list. Please continue that there (and don't reply to all).
python help needed
José or any other python expert, I need your help. The attached patch is
the lyx2lyx part of the getting rid of InsetLaTeXAccent patch.
convert_accent works well, but revert_accent does not. I put the error
messages in the file. Can anybody tell me why
document.body[i] = unicodedata.normalize(NFKD, document.body[i])
does not work?
If you want to try this, use the attached test file (don't save it with LyX
if you want to test convert_accent, it is hand crafted).
Georg
latexaccent-all.lyx
Description: application/lyx
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (Revision 16629)
+++ lib/lyx2lyx/LyX.py (Arbeitskopie)
@@ -73,7 +73,7 @@ format_relation = [(0_06,[200], ge
(1_2, [220], generate_minor_versions(1.2 , 4)),
(1_3, [221], generate_minor_versions(1.3 , 7)),
(1_4, range(222,246), generate_minor_versions(1.4 , 3)),
- (1_5, range(246,257), generate_minor_versions(1.5 , 0))]
+ (1_5, range(246,258), generate_minor_versions(1.5 , 0))]
def formats_list():
Index: lib/lyx2lyx/lyx_1_5.py
===
--- lib/lyx2lyx/lyx_1_5.py (Revision 16629)
+++ lib/lyx2lyx/lyx_1_5.py (Arbeitskopie)
@@ -20,7 +20,9 @@
Convert files to the file format generated by lyx 1.5
import re
-from parser_tools import find_token, find_token_exact, find_tokens, find_end_of, get_value
+import unicodedata
+
+from parser_tools import find_re, find_token, find_token_exact, find_tokens, find_end_of, get_value
from LyX import get_encoding
@@ -719,6 +721,167 @@ def revert_encodings(document):
document.inputencoding = get_value(document.header, \\inputencoding, 0)
+accent_map = {
+` : 0x0309, # grave
+' : 0x0301, # acute
+^ : 0x0302, # circumflex
+~ : 0x0303, # tilde
+= : 0x0304, # macron
+u : 0x0306, # breve
+. : 0x0307, # dot above
+\: 0x0308, # diaresis
+r : 0x030a, # ring above
+H : 0x030b, # double acute
+v : 0x030c, # caron
+b : 0x0320, # minus sign below
+d : 0x0323, # dot below
+c : 0x0327, # cedilla
+k : 0x0328, # ogonek
+t : 0x0361 # tie
+}
+
+
+special_accent_map = {
+'i' : 0x0131, # dotless i
+'j' : 0x0237, # dotless j
+'l' : 0x0142, # l with stroke
+'L' : 0x0141, # L with stroke
+}
+
+def _convert_accent(type, char):
+if char == '':
+if type in special_accent_map:
+return unichr(special_accent_map[type])
+# a missing char is treated as space by LyX
+char = ' '
+if (len(char) 1):
+# We can only convert accents on a single char
+return ''
+# \i and \j
+if char[0] == \\:
+char = char[1:]
+a = accent_map.get(type)
+if a:
+return unicodedata.normalize(NFKC, %s%s % (char, unichr(a)))
+return ''
+
+
+def convert_ertbackslash(body, i, ert, default_layout):
+r ---
+Convert backslashes and '\n' into valid ERT code, append the converted
+text to body[i] and return the (maybe incremented) line index i
+
+for c in ert:
+if c == '\\':
+body[i] = body[i] + '\\backslash '
+i = i + 1
+body.insert(i, '')
+elif c == '\n':
+body[i+1:i+1] = ['\\end_layout', '', '\\begin_layout %s' % default_layout, '']
+i = i + 4
+else:
+body[i] = body[i] + c
+return i
+
+
+def convert_accent(document):
+# The following forms are supported by LyX:
+# '\i \{a}' (standard form, as written by LyX)
+# '\i \{ }' (standard form, as written by LyX if the accented char is a space)
+# '\i \{}' (also accepted if the accented char is a space)
+# '\i \ a' (also accepted)
+# '\i \'(also accepted)
+re_wholeinset = re.compile(r'^(.*)(\\i\s+)(.*)$')
+re_contents = re.compile(r'^([^\s{]+)(.*)$')
+re_accentedcontents = re.compile(r'^\s*{?([^{}]*)}?\s*$')
+i = 0
+while 1:
+i = find_re(document.body, re_wholeinset, i)
+if i == -1:
+return
+match = re_wholeinset.match(document.body[i])
+prefix = match.group(1)
+contents = match.group(3).strip()
+match = re_contents.match(contents)
+if match:
+# Strip first char (always \)
+accent = match.group(1)[1:]
+accented_contents = match.group(2).strip()
+match = re_accentedcontents.match(accented_contents)
+accented_char = match.group(1).strip()
+converted = _convert_accent(accent, accented_char)
+if converted == '':
+contents = '%s{%s}' % (accent, accented_char),
+else:
+document.body[i] = '%s%s' % (prefix, converted)
+i += 1
+continue
+
Re: FYI: Uwe now can access SVN properly :-)
Am Dienstag, 9. Januar 2007 11:38 schrieb [EMAIL PROTECTED]: It's been a long process, but thanks to Jean-Marc, it is now possible for Uwe to commit. But his commits are missing in the cvslog list (probably awaiting moderator approval). Georg
Re: [Cvslog] r16516 - /lyx-devel/trunk/lib/ui/stdmenus.ui
Am Montag, 8. Januar 2007 21:00 schrieb Bo Peng: They also work for the internal selection, but do not make much sense because you can't paste them somewhere else than the current cursor location as you found out. After you finish your selection cleanup/fixes, I will try to implement 'persistent selection' (show me how, please :-). Don't be afraid, I did not forget that. These days I write stuff that is not much work quickly, but everything else is a bit slow. Georg
Re: [PATCH] delay bibfileCache first update
Am Dienstag, 9. Januar 2007 16:46 schrieb Abdelrazak Younes: Georg Baum wrote: This was simply designed to work exactly as it works in LaTeX. If we want to change that, then we should not store the filenames in a comma separated list, but use something similar to the new InsetCommandParams, and for each file store also a flag whether it comes from texmf or not. Using a ./ prefix for that is too fragile IMHO: ./xyz will not be found using kpsewhich if it is not local, but xyz will both be found using kpsewhich and as a local file. But then, how does it works for files that are neither local nor in the texmf tree? findtexfile will return an empty FileName, and therefore such files will not be added to the cache. Those entries would still be contained in the LaTeX output, and if a user has a special installation where the latex compiler can find files that kpsewhich can not find then it will indeed work. However, these files are not considered when building the labels. I don't think that we can do any better than that. Agreed but for me relative path means './toto' and not 'toto'. Concerning the file system that is the same. Both will work. This seems to be a personal preference. On windows yes but not on Unix I think. If that would not be true on linux (and it is also true on all other unices I know) I would not have stated that ;-) Georg
Re: Developers' wiki: To be or not to be?
Am Dienstag, 9. Januar 2007 11:43 schrieb [EMAIL PROTECTED]: The developers' wiki suffered an accident a while back. I've resurrected most of the pages in a static form through the help of google. This was a while back and nothing much has happened since then. One thing I was using the devevlopers' wiki was to document the LFUNs. As I already said back then: That should be done in the source. Then we have automatic backup via svn. What do you think? Should we have a separate developers' wiki, or just use a single group in the users' wiki? Any other ideas, suggestions or requests? I don't think that we need a separate devel wiki. Georg
Re: Developers' wiki: To be or not to be?
I don't think that we need a separate devel wiki. I do not see an immediate use of devel wiki, but can doxygen generated source doc be hosted somewhere? Bo
Re: Developers' wiki: To be or not to be?
Am Dienstag, 9. Januar 2007 19:53 schrieb Bo Peng: I don't think that we need a separate devel wiki. I do not see an immediate use of devel wiki, but can doxygen generated source doc be hosted somewhere? That should definitely be done. The problem is that it takes really long to generate it, and some volunteer would need to write the scripts. Georg
Re: Allowing multiple empty lines and spaces in the Lyx editor...
Am Dienstag, 9. Januar 2007 19:38 schrieb lamikr: And as I see the Lyx editor anyway as a smart code editor for Latex, That is not who we see it. LyX is no code editor for LaTeX, but a document processor that can use LaTeX to generate well typeset output. If you mostly think in terms of LaTeX and code, then maybe LyX is not the right tool for you, but rather something like kile. Georg
Re: Allowing multiple empty lines and spaces in the Lyx editor...
On Tue, Jan 09, 2007 at 07:19:20PM +0100, Abdelrazak Younes wrote: lamikr wrote: And as I see the Lyx editor anyway as a smart code editor for Latex, I would not think it being against the WYSIWYM principles Lyx try to follow if it would allow writers to set some more air to their text in the editor side. Instead I see that Lyx would just came smarter than normal editors as it would allow the writing of latex source code in Lyx editor a more flexible way while still guarantee the coherent output and that could actually be a KILLER FEATURE for some more artistic persons than I to assist them to get their keyboard, ideas and text fly faster than the screen can scroll :-) ... PS: this kind of discussion is best suited to the users' list. Please continue that there (and don't reply to all). Actually I remember there was (and still is in mathed) the feature that multiple presses of space cycle through different space widths. The same could be done for vertical space. I don't think this would go against the LyX philosophy, and might make Mika happy. - Martin pgplNmcbN20ij.pgp Description: PGP signature
Re: [PATCH] delay bibfileCache first update
Am Dienstag, 9. Januar 2007 16:29 schrieb Abdelrazak Younes: Georg Baum wrote: Abdelrazak Younes wrote: In practice, this means that we cache only files that are in the texmf tree and there is no room for confusion. Not good. We should cache all files. This makes the code simpler. I thought a bit more about this and I think I disagree. It is OK to cache bibtex filenames because they are not supposed to change. But it is quite possible that you want to move one bib file onto another directory without having to restart LyX. Because of that, we should always make sure that the pointed file name really exists. Yes, every cache can get out of date and needs a reasonable update strategy, but I don't see a difference between texmf files an others. Also texmf files can change. The system texmf files are not likely to move, but some people organize their whole directory structure with BIB_INPUTS etc. Georg
inputencoding default again
After the unicode merge to trunk in summer we discussed the question what \inputencoding default in a LyX file was supposed to do. We came to the conclusion then that this simply meant to not use the inputenc package, and simply output the document in 8bit characters as is. Then the question arose how to convert those documents to utf8. LyX 1.4 can ignore the encoding very well, but this is not possible anymore in 1.5, since we can't pass 8bit characters as is anymore. We decided that the best lyx2lyx can do is to assume latin1 encoding for those documents. Meanwhile we found out that the original assumption of lyx2lyx that the whole file is encoded using only one encoding was wrong. I implemented support for multiple encodings that is used for files with \inputencoding default I propose to change the conversion of files with default inputencoding to be the same as with auto, together with the corresponding changes in LyX itself. The only difference between auto and default in LyX 1.5 would then be that documents with auto would use the inputenc package, but documents with default would not. Reasons: - This will make LyX 1.-5 display the same stuff on screen as 1.4, because the encoding for this is derived from the language in 1.4 - It will avoid nasty conversion errors like that decsribed in http://bugzilla.lyx.org/show_bug.cgi?id=3043#c6 Of course that means that all default documents that are already converted to 1.5 would not be valid anymore. IMO this is better than to add a new file format with an intermediate conversion step that might fail as in http://bugzilla.lyx.org/show_bug.cgi?id=3043#c6. Opinions? If this is OK I'll develop a patch (will be easy). Georg
Re: Policy of adding new commands to syntax.default
Am Dienstag, 9. Januar 2007 16:17 schrieb Gregor Gorjanc: like to discuss this. I guess this will not make it into 1.5. Am I right? Yes. Although it may not look like that with the recent flow of patches 1.5 is in feature freeze. This is unfortunate timing, but not a problem: This would not be the first feature first developed as a patch outside the official sources and only integrated later. Georg
Re: slow opening of docs
although loading and saving feels snappier, i find that selecting text (especially in a large doc like the userguide) is slow on linux, the selection lags a bit behind the mouse when i move the mouse quickly. if i just change the selection (with the mouse) in a single paragraph for a while (setting the selection and moving the mouse) i get the following profile: time seconds secondscalls ms/call ms/call name 21.74 0.30 0.30 2202370 0.00 0.00 QHashwchar_t, int::findNode(wchar_t const, unsigne d int*) const 5.07 0.37 0.07 1101181 0.00 0.00 lyx::frontend::GuiFontMetrics::width(wchar_t) const 5.07 0.44 0.07 160930 0.00 0.00 lyx::LyXText::getFont(lyx::Buffer const, lyx::Paragr aph const, int) const 3.62 0.49 0.05 1942532 0.00 0.00 lyx::LyX::application() 3.62 0.54 0.05 336956 0.00 0.00 lyx::LyXFont::LyXFont() 2.90 0.58 0.04 286721 0.00 0.00 lyx::LyXTextClass::load(std::string const) const 2.17 0.61 0.03 1942532 0.00 0.00 lyx::theApp() 2.17 0.64 0.03 864733 0.00 0.00 lyx::LyXText::singleWidth(lyx::Paragraph const, int, wchar_t, lyx::LyXFont const) const 2.17 0.67 0.03 272689 0.00 0.00 lyx::Paragraph::getDepth() const 1.45 0.69 0.02 970628 0.00 0.00 lyx::theFontMetrics(lyx::LyXFont const) 1.45 0.71 0.02 970628 0.00 0.00 lyx::frontend::GuiFontLoader::metrics(lyx::LyXFont co nst) 1.45 0.73 0.02 496805 0.00 0.00 lyx::FontIterator::operator++() 1.45 0.75 0.02 286639 0.00 0.00 lyx::Paragraph::lookupChange(int) const
Re: python help needed
On Tue, Jan 09, 2007 at 07:46:47PM +0100, Georg Baum wrote: José or any other python expert, I need your help. The attached patch is the lyx2lyx part of the getting rid of InsetLaTeXAccent patch. convert_accent works well, but revert_accent does not. I put the error messages in the file. Can anybody tell me why document.body[i] = unicodedata.normalize(NFKD, document.body[i]) does not work? result = unicodedata.normalize(NFKD, unicode(utf8encodedstring, 'utf8')) works fine here. -- Enrico
Re: python help needed
Am Dienstag, 9. Januar 2007 21:42 schrieb Enrico Forestieri: On Tue, Jan 09, 2007 at 07:46:47PM +0100, Georg Baum wrote: José or any other python expert, I need your help. The attached patch is the lyx2lyx part of the getting rid of InsetLaTeXAccent patch. convert_accent works well, but revert_accent does not. I put the error messages in the file. Can anybody tell me why document.body[i] = unicodedata.normalize(NFKD, document.body[i]) does not work? result = unicodedata.normalize(NFKD, unicode(utf8encodedstring, 'utf8')) works fine here. How edid you set utf8encodedstring? Is that with my test document (first converted to 257 and then back)? What python version? I use 2.4.4. Georg
Re: inputencoding default again
Georg Baum wrote: I propose to change the conversion of files with default inputencoding to be the same as with auto, together with the corresponding changes in LyX itself. The only difference between auto and default in LyX 1.5 would then be that documents with auto would use the inputenc package, but documents with default would not. This is exactly the right behavior as far as Hebrew is concerned. Thanks!
Re: Developers' wiki: To be or not to be?
Georg Baum [EMAIL PROTECTED] writes: Am Dienstag, 9. Januar 2007 19:53 schrieb Bo Peng: I don't think that we need a separate devel wiki. I do not see an immediate use of devel wiki, but can doxygen generated source doc be hosted somewhere? That should definitely be done. The problem is that it takes really long to generate it, and some volunteer would need to write the scripts. Did not Lars set that up some time ago (one or more years) to do just that? Angus
Re: Developers' wiki: To be or not to be?
Did not Lars set that up some time ago (one or more years) to do just that? Link? Bo
Re: python help needed
On Tue, Jan 09, 2007 at 09:57:12PM +0100, Georg Baum wrote: Am Dienstag, 9. Januar 2007 21:42 schrieb Enrico Forestieri: On Tue, Jan 09, 2007 at 07:46:47PM +0100, Georg Baum wrote: José or any other python expert, I need your help. The attached patch is the lyx2lyx part of the getting rid of InsetLaTeXAccent patch. convert_accent works well, but revert_accent does not. I put the error messages in the file. Can anybody tell me why document.body[i] = unicodedata.normalize(NFKD, document.body[i]) does not work? result = unicodedata.normalize(NFKD, unicode(utf8encodedstring, 'utf8')) works fine here. How edid you set utf8encodedstring? I used the attached script. Is that with my test document (first converted to 257 and then back)? No, I didn't try your patch. What python version? I use 2.4.4. Works with python 2.3.3 on solaris and 2.4.3 on cygwin. -- Enrico #!/usr/bin/env python # -*- coding: utf-8 -*- import unicodedata result = unicodedata.normalize(NFKD, unicode(olà, 'utf8'))
Re: python help needed
Am Dienstag, 9. Januar 2007 22:19 schrieb Enrico Forestieri: No, I didn't try your patch. That does not help :-( Your script works for me, too. The strange thing is that the type of document.body[i] is neither a normal string nor a unicode string. At least the error messages seem to suggest that. Georg
[patch] fix another problem with non-ascii filenames
When trying to insert a child document with a non-ascii filename LyX asserts: Assertion triggered in const lyx::docstring lyx::from_ascii(const std::string) by failing check static_castunsigned char(ascii[i]) 0x80 in file ../../../src/support/docstring.C:41 The fix is obvious (see attached), but I would like to know if I can also ditch the comment as it is bogus, apparently. -- Enrico Index: src/insets/insetinclude.C === --- src/insets/insetinclude.C (revision 16623) +++ src/insets/insetinclude.C (working copy) @@ -319,7 +319,7 @@ docstring const InsetInclude::getScreenL temp += ???; else // FIXME: We don't know the encoding of the filename - temp += from_ascii(onlyFilename(to_utf8(params_[filename]))); + temp += from_utf8(onlyFilename(to_utf8(params_[filename]))); return temp; }
Re: [patch] fix another problem with non-ascii filenames
Am Dienstag, 9. Januar 2007 22:28 schrieb Enrico Forestieri: The fix is obvious (see attached), but I would like to know if I can also ditch the comment as it is bogus, apparently. Yes. Both the from_ascii and the comment where added by me when I did not yet fully understand the filename encoding isssues as a reminder that this needed to be looked at. Georg
Re: another small bug for status 1.5.x
Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:
On Jan 5, 2007, at 12:39 PM, Georg Baum wrote:
Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:
In addition, cut and paste is currently not working well: it only
pastes unformatted text (and omits footnotes and other insets). I
haven't reported this given the flux in the cut-and-paste code,
though I don't know if it's a Mac specific bug.
This looks like QClipboard::ownsClipboard() always returns false.
Can you
please verify that by a debug message in GuiClipboard::isInternal?
If you
just add the line
lyxerr GuiClipboard::isInternal:
qApp-clipboard()-ownsClipboard() endl;
, do a copy and then paste it should print
GuiClipboard::isInternal: 1
If my guess it right it will print
GuiClipboard::isInternal: 0
instead.
You're right: GuiClipboard::isInternal: 0
This patch should work around that problem by using the system clipboard to
store LyX formatted stuff. As a side effect, it also fixes this bug:
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)
Seriously: I started to implement this as a fix for 2138 over a year ago,
but never found the time to finish it, because at that time it was far
more complicated. When I realized that it could fix this problem as well
(at a possible performance cost, we need to investigate that) I could not
resist to try to finish it. Thanks to some cleanup that has happened
during the last months it was now quite easy to get it working. This patch
is not well tested and has a lot of debug output (+ some error handling
missing), but if this is OK to go in I plan to polish it when I find time.
Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 16633)
+++ src/insets/insettabular.C (Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor
case LFUN_CLIPBOARD_PASTE:
case LFUN_PRIMARY_SELECTION_PASTE: {
docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
- theClipboard().get() :
+ theClipboard().getAsText() :
theSelection().get();
if (clip.empty())
break;
@@ -1811,13 +1811,13 @@ bool InsetTabular::copySelection(LCursor
paste_tabular-setRightLine(paste_tabular-getLastCellInRow(0),
true, true);
- odocstringstream os;
- OutputParams const runparams;
- paste_tabular-plaintext(cur.buffer(), os, runparams, 0, true, '\t');
- theClipboard().put(os.str());
+ // Needed for the Edit-Paste recent menu and the system clipboard.
+ cap::copySelectionToStack(cur);
+
// mark tabular stack dirty
// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
// when we (hopefully) have a one-for-all paste mechanism.
+ // This must be called after cap::copySelectionToStack.
dirtyTabularStack(true);
return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C (Revision 16633)
+++ src/mathed/InsetMathGrid.C (Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor
cap::replaceSelection(cur);
docstring topaste;
if (cmd.argument().empty() !theClipboard().isInternal())
- topaste = theClipboard().get();
+ topaste = theClipboard().getAsText();
else {
idocstringstream is(cmd.argument());
int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C (Revision 16633)
+++ src/mathed/InsetMathNest.C (Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor
replaceSelection(cur);
docstring topaste;
if (cmd.argument().empty() !theClipboard().isInternal())
- topaste = theClipboard().get();
+ topaste = theClipboard().getAsText();
else {
size_t n = 0;
idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C (Revision 16633)
+++ src/buffer.C (Arbeitskopie)
@@ -566,6 +566,20 @@ void Buffer::insertStringAsLines(Paragra
}
+bool Buffer::read(std::istream is)
+{
+ // We need to construct a temp file in order to be able to use lyx2lyx
+ FileName const tmpfile(tempName());
+ if (tmpfile.empty()) {
+ return false;
+ }
+ ofstream os(tmpfile.toFilesystemEncoding().c_str(), ios::binary | ios::out | ios::trunc);
+ os is.rdbuf();
+ os.close();
+ return readFile(tmpfile);
+}
+
+
bool Buffer::readFile(FileName const filename)
{
// Check if the file is compressed.
@@ -763,20 +777,20 @@ bool Buffer::writeFile(FileName const
if (!ofs)
return false;
- retval = do_writeFile(ofs);
+ retval = write(ofs);
} else {
ofstream ofs(fname.toFilesystemEncoding().c_str(), ios::out|ios::trunc);
if (!ofs)
return false;
- retval = do_writeFile(ofs);
+ retval = write(ofs);
}
return retval;
}
-bool Buffer::do_writeFile(ostream ofs) const
+bool Buffer::write(ostream
Re: another small bug for status 1.5.x
As a side effect, it also fixes this bug: http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-) I am happy to see that you are going toward the removal of internal clipboards. :-) Bo
Re: python help needed
On Tue, Jan 09, 2007 at 10:25:15PM +0100, Georg Baum wrote:
Am Dienstag, 9. Januar 2007 22:19 schrieb Enrico Forestieri:
No, I didn't try your patch.
That does not help :-( Your script works for me, too. The strange thing is
that the type of document.body[i] is neither a normal string nor a unicode
string. At least the error messages seem to suggest that.
I was compiling. Now I tried it. The TypeError is due to this statement:
unicode(document.body[i], 'utf8')
I noticed that the error occurs when document.body[i] is empty, but even
after taking care of this it still occurs, so maybe it is due to some
wrong encoding. I am using the following trick to debug, maybe it can
be of help to you as I really don't know what I should expect:
import os
...
for i in range(numberoflines):
if (document.body[i] == ''):
continue
os.system(r'zenity --info --text=(%s)' % document.body[i])
unistring = unicode(document.body[i], 'utf8')
result = unicodedata.normalize(NFKD, unistring)
document.body[i] = result.encode('utf8')
...
--
Enrico
Re: python help needed
On Tue, Jan 09, 2007 at 11:23:52PM +0100, Enrico Forestieri wrote: On Tue, Jan 09, 2007 at 10:25:15PM +0100, Georg Baum wrote: Am Dienstag, 9. Januar 2007 22:19 schrieb Enrico Forestieri: No, I didn't try your patch. That does not help :-( Your script works for me, too. The strange thing is that the type of document.body[i] is neither a normal string nor a unicode string. At least the error messages seem to suggest that. I was compiling. Now I tried it. The TypeError is due to this statement: unicode(document.body[i], 'utf8') I noticed that the error occurs when document.body[i] is empty, but even after taking care of this it still occurs, so maybe it is due to some wrong encoding. I am using the following trick to debug, maybe it can be of help to you as I really don't know what I should expect: I bet the problem are the backslashes... -- Enrico
Re: another small bug for status 1.5.x
Georg Baum wrote: This patch should work around that problem by using the system clipboard to store LyX formatted stuff. As a side effect, it also fixes this bug: http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-) Seriously: I started to implement this as a fix for 2138 over a year ago, but never found the time to finish it, because at that time it was far more complicated. When I realized that it could fix this problem as well (at a possible performance cost, we need to investigate that) I could not resist to try to finish it. Thanks to some cleanup that has happened during the last months it was now quite easy to get it working. This patch is not well tested and has a lot of debug output (+ some error handling missing), but if this is OK to go in I plan to polish it when I find time. Quite frankly I am not very confident that you can achieve the same performance as the internal Clipboard. You are putting in the chain lyx2lyx parsing + lyx format parsing which is known to take some time. Right now, I can copy and paste the full UserGuide.lyx into another document without _any_ delay. I doubt this would ever be possible with your solution. Moreover, we have now the multiple view feature so we don't need this feature anymore. If we are going that route then I would prefer that you use binary dump of the internal structure instead. Sorry for not being optimistic about this. Moreover I really think that the Clipboard/Selection stuff is OK right now for 1.5, the Mac problem can be cured without this hammer solution IMHO. Abdel.
Re: another small bug for status 1.5.x
Quite frankly I am not very confident that you can achieve the same performance as the internal Clipboard. You are putting in the chain lyx2lyx parsing + lyx format parsing which is known to take some time. I do not think you need to do lyx2lyx stuff. Technically speaking, what we need is boost::serialization which is quite fast from my experience. Bo
Re: Developers' wiki: To be or not to be?
On Tuesday 09 January 2007 9:08 pm, Angus Leeming wrote: Did not Lars set that up some time ago (one or more years) to do just that? AFAIR yes but I do not remember the link. Angus -- José Abílio
Re: inputencoding default again
On Tuesday 09 January 2007 8:02 pm, Georg Baum wrote: Opinions? If this is OK I'll develop a patch (will be easy). Yes, it is OK. That is the price to pay for using the bleeding edge, sometimes bleeds happen. ;-) Georg -- José Abílio
Re: Policy of adding new commands to syntax.default
On Tuesday 09 January 2007 3:17 pm, Gregor Gorjanc wrote: Thank you for this! I did thought nobody is interested in Sweave support. I agree that it need some more thinking. I am looking forward if anyone would like to discuss this. I guess this will not make it into 1.5. Am I right? Show us the changes, if they are self-contained and clean I will consider them. If not for 1.5.0 possibly for 1.5.x ( x 1) as long as it does not involve backwards incompatible changes in the file format. Note that I don't make any promisses (even although I have been packing several R modules for Fedora). ;-) -- José Abílio
Re: python help needed
On Tuesday 09 January 2007 6:46 pm, Georg Baum wrote: José or any other python expert, I need your help. The attached patch is the lyx2lyx part of the getting rid of InsetLaTeXAccent patch. convert_accent works well, but revert_accent does not. I put the error messages in the file. Can anybody tell me why document.body[i] = unicodedata.normalize(NFKD, document.body[i]) By default the file stream returns a string when reading a file. This will change in python 3.0 where all strings will be unicode. A shortcut now is to transform every line when reading to unicode in line 194 of LyX.py line = unicode(trim_eol(line)) This is just a guess but it should be enough for this. does not work? If you want to try this, use the attached test file (don't save it with LyX if you want to test convert_accent, it is hand crafted). Georg -- José Abílio
Re: Developers' wiki: To be or not to be?
On Tue, 9 Jan 2007, Georg Baum wrote: Am Dienstag, 9. Januar 2007 11:43 schrieb [EMAIL PROTECTED]: The developers' wiki suffered an accident a while back. I've resurrected most of the pages in a static form through the help of google. This was a while back and nothing much has happened since then. One thing I was using the devevlopers' wiki was to document the LFUNs. As I already said back then: That should be done in the source. Then we have automatic backup via svn. And as I said back then, I'm (was) using the wiki for *creating* the documentation. Then it'd be placed in the source as it stabilizes. I don't think sending patches back and forth is a good way to review that kind of documentation. What do you think? Should we have a separate developers' wiki, or just use a single group in the users' wiki? Any other ideas, suggestions or requests? I don't think that we need a separate devel wiki. Ok. /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Developers' wiki: To be or not to be?
On Tue, 9 Jan 2007, Angus Leeming wrote: Georg Baum [EMAIL PROTECTED] writes: Am Dienstag, 9. Januar 2007 19:53 schrieb Bo Peng: I don't think that we need a separate devel wiki. I do not see an immediate use of devel wiki, but can doxygen generated source doc be hosted somewhere? That should definitely be done. The problem is that it takes really long to generate it, and some volunteer would need to write the scripts. I agree that hosting doxygen generated source should definitely be done. Unfortunately I have no experience at all with it, otherwise I'd do it. As for hosting it, that should be possible to do on aussie (aka www.lyx.org and wiki.lyx.org). This I can place in some suitable location if I just had the actual material. I'll look around for something related to doxygen on aussie though. But I wonder... how long is 'really long to generate'? It's not generated online is it? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: python help needed
On Tue, Jan 09, 2007 at 11:28:04PM +0100, Enrico Forestieri wrote: On Tue, Jan 09, 2007 at 11:23:52PM +0100, Enrico Forestieri wrote: On Tue, Jan 09, 2007 at 10:25:15PM +0100, Georg Baum wrote: Am Dienstag, 9. Januar 2007 22:19 schrieb Enrico Forestieri: No, I didn't try your patch. That does not help :-( Your script works for me, too. The strange thing is that the type of document.body[i] is neither a normal string nor a unicode string. At least the error messages seem to suggest that. I was compiling. Now I tried it. The TypeError is due to this statement: unicode(document.body[i], 'utf8') I noticed that the error occurs when document.body[i] is empty, but even after taking care of this it still occurs, so maybe it is due to some wrong encoding. I am using the following trick to debug, maybe it can be of help to you as I really don't know what I should expect: I bet the problem are the backslashes... No, the problem is that something is messed up. Apparently, document.body[i] may already be in unicode format. See for example: http://www.red-mercury.com/blog/eclectic-tech/python-mystery-of-the-day/ I see that lyx_1_5.py messes up with conversions from/to unicode... -- Enrico
Re: another small bug for status 1.5.x
On Jan 9, 2007, at 5:42 PM, Abdelrazak Younes wrote: Georg Baum wrote: This patch should work around that problem by using the system clipboard to store LyX formatted stuff. As a side effect, it also fixes this bug: http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-) Seriously: I started to implement this as a fix for 2138 over a year ago, but never found the time to finish it, because at that time it was far more complicated. When I realized that it could fix this problem as well (at a possible performance cost, we need to investigate that) I could not resist to try to finish it. Thanks to some cleanup that has happened during the last months it was now quite easy to get it working. This patch is not well tested and has a lot of debug output (+ some error handling missing), but if this is OK to go in I plan to polish it when I find time. Quite frankly I am not very confident that you can achieve the same performance as the internal Clipboard. You are putting in the chain lyx2lyx parsing + lyx format parsing which is known to take some time. Right now, I can copy and paste the full UserGuide.lyx into another document without _any_ delay. I doubt this would ever be possible with your solution. Moreover, we have now the multiple view feature so we don't need this feature anymore. If we are going that route then I would prefer that you use binary dump of the internal structure instead. Sorry for not being optimistic about this. Moreover I really think that the Clipboard/Selection stuff is OK right now for 1.5, the Mac problem can be cured without this hammer solution IMHO. Well, it does work on Mac: insets and formatting are correctly cut- and-pasted within LyX (though cutting and pasting between LyX and other programs destroys the formatting and deletes the contents of insets, which I assume is intended behavior). As for speed, I can cut a 110,000 word document in about 2 seconds and paste it in about 1 second with this patch. (Without the patch it's very quick -- .25 second -- but, of course, without formatting or insets.) Bennett
1.5svn: Keyboard Navigation Oddities
On Mac, at least, I have some arrow navigation problems with today's 1.5svn. Previously, I reported that pressing down-arrow causes the cursor to jump 2 lines down. That has now been fixed. However, now the cursor seems to remember a particular horizontal position when moving up or down in a document when using the arrow keys or page-up/down. That is, if I click the mouse somewhere in the document window (towards the left side, say), I can then move right or left with the arrow keys (or even by adding or deleting text). However, when I then try navigating up or down with the arrow keys (or page-up/down), the horizontal position of the cursor jumps to wherever the cursor started -- wherever I clicked the mouse. Clicking the mouse somewhere else causes this new horizontal position to be remembered. Bennett
Re: [Cvslog] r16635 - in /lyx-devel/trunk/lib/scripts: fen2ascii.py fi...
On Wed, Jan 10, 2007 at 03:42:12AM -, [EMAIL PROTECTED] wrote: Author: forenr Date: Wed Jan 10 04:42:06 2007 New Revision: 16635 URL: http://www.lyx.org/trac/changeset/16635 Log: Fix encoding of filenames in python scripts * lib/scripts/fig2pstex.py * lib/scripts/fig2pdftex.py * lib/scripts/fig_copy.py * lib/scripts/fen2ascii.py: convert filenames from utf8 to the default locale encoding. I have not touched clean_dvi.py as the filename passed to it is mangled in the same way as the one actually copied to the tmpdir. For example, if a .lyx file is named testè.lyx, the file copied to the tmpdir is named testC(.tex. I don't know whether this is intentional or it is a by-product of the filename mangling which always produces ascii names. -- Enrico
Re: [Cvslog] r16636 - in /lyx-devel/trunk/lib/scripts: fen2ascii.py fi...
On Wed, Jan 10, 2007 at 04:24:37AM -, [EMAIL PROTECTED] wrote: Author: forenr Date: Wed Jan 10 05:24:36 2007 New Revision: 16636 URL: http://www.lyx.org/trac/changeset/16636 Log: Partially revert changeset 16635. Modified: lyx-devel/trunk/lib/scripts/fen2ascii.py lyx-devel/trunk/lib/scripts/fig_copy.py La gatta frettolosa fa i gattini ciechi (more haste, less speed). -- Enrico
AW: Re: Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
I agree that a stack of bookmarks has limited use, because the poor user has no idea of what boomark #5 actually is at a given time (a moving target). That is why I display filename of a bookmark. Previously, the poor user has to face ice-cold bookmark 1/2/3/4/5. Well, I guess many people use multiple bookmarks within a _single_ document. In this case, the filename doesn't help either. This is similar to my tag idea. But if it needs another dialog, it has to wait. You could make use of an existing, generic dialog (IIRC askForText or similiar) Michael
Re: Policy of adding new commands to syntax.default
José Matos [EMAIL PROTECTED] writes: On Tuesday 09 January 2007 3:17 pm, Gregor Gorjanc wrote: Thank you for this! I did thought nobody is interested in Sweave support. I agree that it need some more thinking. I am looking forward if anyone would like to discuss this. I guess this will not make it into 1.5. Am I right? Show us the changes, if they are self-contained and clean I will consider them. If not for 1.5.0 possibly for 1.5.x ( x 1) as long as it does not involve backwards incompatible changes in the file format. Note that I don't make any promisses (even although I have been packing several R modules for Fedora). I am glad to see the interest. José, please read the thread Literate: noweb Sweave, especially my last post http://thread.gmane.org/gmane.editors.lyx.devel/73050/focus=73577 where I describe what I think could or should be changed. Unfortunatelly, the needed changes in tex2lyx and elsewhere where strings literate, LITERATE, noweb etc appear are not yet done as I do not have a clue about C++. This is the stuff Georg say that needs a bit of thinking. But I do have all stuff with layouts, prefrences etc. I will finnish the note this days and send the files to the list. Best wishes, Gregor
Re: [patch] fix bug 2629
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes:
fancyhdr.sty (v. 3.1) states that: % Fancyplain stuff shouldn't be
used anymore (rather % \fancypagestyle{plain} should be used), but
it must be present for % compatibility reasons.
Uwe Thanks for the info, I dropped this and marked the bug as
Uwe WONTFIX.
Well, we could also have the format fancy (plain) and DTRT in
BufferParams::write.
JMarc
Re: [patch] fix bug 2629
Uwe Stöhr wrote: > This is my first patch to the source code so don't beat me when I did it > wrong, just tell me how it's done correctly and I'll learn my lesson. > > Add fancyplain to Page Style list: > http://bugzilla.lyx.org/show_bug.cgi?id=2629 That looks like a file format change to me, so lyx2lyx support would be needed. Georg
Re: [patch 1.4] fix update of natbib labels cache
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: Jürgen> Jean-Marc, this patch is what I committed to trunk yesterday. Jürgen> I'd like to have it in 1.4 as well. O.K.? Yes. JMarc
Re: r16622 [1/3] - in /lyx-devel/branches/BRANCH_1_4_X/lib: d...
[EMAIL PROTECTED] wrote: > Author: uwestoehr > Date: Tue Jan 9 03:29:35 2007 > New Revision: 16622 > > URL: http://www.lyx.org/trac/changeset/16622 > Log: > New Extended-Insets manual > > Added: > lyx-devel/branches/BRANCH_1_4_X/lib/doc/Extended-Insets.lyx > Modified: > lyx-devel/branches/BRANCH_1_4_X/lib/ui/stdmenus.ui So your svn access finally works. Great! Unfortunately this is not only a privilege, but you have some duties, too: - Never ever commit stuff to 1.4 only, unless that is a fix for a bug not present in 1.5. We always need to have current documentation in 1.5, too. Then there is a chance that somebody who modifies a feature will update the documentation at the same time. Otherwise that will not happen for sure. - If you add new files, you have to add them to the appropriate Makefile.am and to scons_manifest. Otherwise they will not show up in the binary package. You also have to set the svn:eol-style flag if it is not a binary file, otherwise wwe will get useless diffs because of line ending changes. - In this particular case, you have to add "Extended-Insets" to tge list at the top of lib/doc/depend.py - If you add any new documentation file, you should also run lib/doc/depend.py to update lib/doc/Makefile.depend. This is not very important, Jean-Marc keeps forgetting this too, and since this is run automatically by the autotools if needed I usually notice that and commit the changes. - Always ask Jean-Marc for permission to commit to 1.4, even for tiny fixes. Georg
Re: r16622 [1/3] - in /lyx-devel/branches/BRANCH_1_4_X/lib: d...
Georg Baum wrote: > - Never ever commit stuff to 1.4 only, unless that is a fix for a bug not > present in 1.5. We always need to have current documentation in 1.5, too. > Then there is a chance that somebody who modifies a feature will update > the documentation at the same time. Otherwise that will not happen for > sure. What I forgot: You can use the svn merge feature to merge changes from trunk to the 1.4 branch. Then you don't need to do the whole procedure twice. I don't know how much svn knowledge you have, if there are questions please read the svn book: http://svnbook.red-bean.com/ Georg
Re: Policy of adding new commands to syntax.default
Gregor Gorjanc wrote: > I have another set of Sweave specific commands. I believe this is the last > one. Here is the patch. Trunk and 1_4_X branch please. Thank you very > much! I put it in trunk. Jean-Marc, I guess 1.4 is also OK? I did not forget your other mail, but that will stay in the todo queue for some time since it requires some thinking. Georg
Re: slow opening of docs
Abdelrazak Younes wrote: Edwin Leuven wrote: Abdelrazak Younes wrote: Could you profile this instead: lyx -e text UserGuide.lyx then you get this: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 100.00 0.01 0.01110.0010.00 lyx::frontend::GuiWorkArea::doGreyOut(lyx::frontend:: QLPainter&) There is something wrong here, the GUI should not even be loaded with the '-e' option. Are you sure you passed the correct patch to the document? this was yesterday evenings svn. i agree it looks suspicious. will have another look tonight...
Re: [patch] fix bug 2721 now with attached patch
LyX creates dvi documents without proper dimension information
http://bugzilla.lyx.org/show_bug.cgi?id=2721
Simply add the [dvips] option to the geometry package when landscape is
used.
Opinions?
regards Uwe
Index: bufferparams.C
===
--- bufferparams.C (revision 16619)
+++ bufferparams.C (working copy)
@@ -879,7 +879,10 @@
}
if (use_geometry || nonstandard_papersize) {
- os << "\\usepackage{geometry}\n";
+ if (orientation == ORIENTATION_LANDSCAPE) {
+ os << "\\usepackage[dvips]{geometry}\n";}
+ else {
+ os << "\\usepackage{geometry}\n";}
texrow.newline();
os << "\\geometry{verbose";
if (orientation == ORIENTATION_LANDSCAPE)
FYI: Uwe now can access SVN properly :-)
It's been a long process, but thanks to Jean-Marc, it is now possible for Uwe to commit. cheers /Christian PS. I'll make sure the necessary steps are documented. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Developers' wiki: To be or not to be?
The developers' wiki suffered an accident a while back. I've resurrected most of the pages in a static form through the help of google. This was a while back and nothing much has happened since then. One thing I was using the devevlopers' wiki was to document the LFUNs. It is not that much work for me to restore the wiki, and manually copy/paste the wiki pages. My question is however if it is desirable. As far as I know, it has not been used very much? What do you think? Should we have a separate developers' wiki, or just use a single group in the users' wiki? Any other ideas, suggestions or requests? cheers /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
AW: Re: SVN changeset 16589: remove shortcuts to bookmark-save 2/3/4/5
>I do know that the new bookmark code has plenty of advantages. What >this does not tell me is why bookmarks have to be a stack instead of a >vector. > >Bo> I can not see a way to implement dynamic bookmark menu items >Bo> without this stack (regression). > >So tell us, why? I agree that a stack of bookmarks has limited use, because the poor user has no idea of what boomark #5 actually is at a given time (a moving target). IMHO the slot-based approach was better. #1 is #1 and will always be #1. BTW: Why don't we allow the user to label bookmarks? That would be a good compromise. Just my 2 cents, Michael
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: > Opinions? I think it is correct to use this option. However, even if it does not harm when using pdflatex, I've read that you have to expect errors if you're using another dvi-to-something driver that does not understand the dvi specials this option inserts (for instance: dvipdfm and dvipdfmx). So I'd prefer to insert this option only if we are actually exporting via dvips. Jürgen
