Bugs
I've found the following bugs in LyX 1.1.5cvs (they are not present in 1.1.4) 1. LyX crashes after opening a bibtex inset and pressing OK 2. The size of the font in a math insets which is inside a paragraph with a larger font size (e.g. title, section etc.) is incorrect. Load the attached bug.lyx file to see an example. 3. When importing ASCII text as lines, the leading spaces at each line are not translated into protected spaces. Moreover, LyX generates many error messages: ERROR (LyXParagraph::InsertInset): there is no LyXParagraph::META_INSET ERROR (LyXParagraph::GetChar): position does not exist.1 (1) ERROR (LyXParagraph::InsertInset): position does not exist: 57 ERROR (LyXParagraph::ParFromPos): position does not exist. ERROR (LyXParagraph::InsertInset): there is no LyXParagraph::META_INSET ERROR (LyXParagraph::GetChar): position does not exist.1 (1) ERROR (LyXParagraph::InsertInset): position does not exist: 3 ERROR (LyXParagraph::ParFromPos): position does not exist. ERROR (LyXParagraph::InsertInset): there is no LyXParagraph::META_INSET ERROR (LyXParagraph::InsertInset): position does not exist: 2 ERROR (LyXParagraph::InsertInset): position does not exist: 3 4. The following may be intentional changes: - The colors for math-mode,latex-mode etc. are darker than before - In math mode, the empty delimiter (i.e. \left. or \right. ) is drawn as a continuous line, instead of dotted line as before. #LyX 1.1 created this file. For more info see http://www.lyx.org/ \lyxformat 2.15 \textclass article \language default \inputencoding default \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Title A \begin_inset Formula \( X \) \end_inset \layout Standard B \begin_inset Formula \( y \) \end_inset \the_end
Re: GUI independence and XTL
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: Dekel However, the real problem lies on parsing .lyx files at Dekel Buffer::readLyXformat2 which is done using if-else statements Dekel (... else if (token == "\\emph") ... ) This is very Dekel inefficient! Yes, this code should use LyxLex correctly. Actually, this is not a real problem at all. The bottleneck at load time is the rendering of the figures and of the document, not the parsing of the LyX document. You can assert this for yourself by loading the user guide. As soon as the program says "Formatting" or "Loading font", the raw loading part is over. You have to be fast to see it, though. It depends of the document. If you have a very large file, with lots of insets, and a weak CPU, you will notice the time for parsing the document. So: There is no reason to change this. So much else to do. If you want, I can do the changes (and also do the changes I suggested for layout.C)
Re: Bugs
On Sat, Mar 04, 2000 at 01:02:09PM +0200, Dekel Tsur wrote:
I've found the following bugs in LyX 1.1.5cvs (they are not present in 1.1.4)
2. The size of the font in a math insets which is inside a paragraph with a
larger font size (e.g. title, section etc.) is incorrect.
Load the attached bug.lyx file to see an example.
I've managed to fix this bug. The patch is attached.
Index: src/mathed/formula.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/formula.C,v
retrieving revision 1.29
diff -u -p -r1.29 formula.C
--- src/mathed/formula.C2000/03/02 02:19:42 1.29
+++ src/mathed/formula.C2000/03/04 11:04:33
@@ -404,11 +404,9 @@ int InsetFormula::width(Painter , LyXFo
}
-void InsetFormula::draw(Painter pain, LyXFont const ,
+void InsetFormula::draw(Painter pain, LyXFont const font,
int baseline, float x) const
{
- LyXFont font = mathed_get_font(LM_TC_TEXTRM, LM_ST_TEXT);
-
lfont_size = font.size();
/// Let's try to wait a bit with this... (Lgb)
//UpdatableInset::draw(pain, font, baseline, x);
Re: GUI independence and XTL
[Rewrite the loading parsing logic] If you want, I can do the changes (and also do the changes I suggested for layout.C) When you volunteer, obviously it's a good idea to make the change. You won't find me arguing against that ;-) I'm sure the patch would be welcomed. Maybe it's time for Dekel to get cvs write access? Greets, Asger
Re: m4 question
On 3 Mar 2000, Jean-Marc Lasgouttes wrote: "Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus having read the latest installment of the lyx development news, Angus I checked the rae branch out of cvs and tried to compile it. Angus Compilation fails in sigc++ with m4 -I./macros Angus macros/func_slot.h.m4 func_slot.h m4: illegal option -- I Angus I'm running on an Alpha with Digital Unix v3.2 and have the Angus Digital version of m4. Synopsis: m4 [-Bnumber] [-es] [-Hnumber] Angus [-Snumber] [-Tnumber] [-Dmacro][=value] [-Umacro] file ... | - I got the same problem and it is fixed by the following patch. It works here because I have GNU m4 installed as gm4. Allan, I did not commit that patch because you said not to touch at this directory. What should I do? Send it to Karl: [EMAIL PROTECTED] and apply it also. Karl's usually pretty quick at accepting little patches like this. Angus: do like JMarc and install GNU m4 as gm4. Allan. (ARRae)
Re: Compiling rae-branch on gcc 2.8.x or compaq cxx
commit all your patches.
On 3 Mar 2000, Jean-Marc Lasgouttes wrote:
* Gcc 2.8.1: things seems to works except that, since there is no
namespace support, everything is declared in global namespace. The
solution is to add a few #ifdef in PopupBase.h and Popups.h. If done
correclty, it would be very transparent. Allan, what are the classes
from SigC which are needed?
Slot, Object and the various Signal[01]. Those are the only ones we refer
to directly at present (I think). I guess I just forgot to put those
lines in originally.
* Compaq cxx: the main problem that I have is with xforms callbacks,
which have to be wrapped with a C function (because cxx says that C
linkage is not compatible with C++ linkage, and it is right). Should
I add those wrappers, or do you have a better idea? Here is the
error message I get:
cxx: Warning: ../../../sigc++/sigc++config.h, line 33: unrecognized
preprocessing directive
#warning "Unknown architecture (send me gcc --dumpspecs)"
-^
[BTW, what should I do with that?]
Tell Karl to put a:
#ifdef __GNUC__
...
#endif
around it? [EMAIL PROTECTED]
cxx: Error: ../../../../rae/src/frontends/xforms/FormCopyright.C, line 57:
argument of type "void (*)(FL_OBJECT *, long)" is incompatible with
parameter of type "FL_CALLBACKPTR"
fl_set_object_callback(obj, FormCopyright::CopyrightOKCB, 0);
^
cxx: Error: ../../../../rae/src/frontends/xforms/FormCopyright.C, line 73:
argument of type "int (*)(FL_FORM *, void *)" is incompatible with
parameter of type "FL_FORM_ATCLOSE"
FormCopyright::CopyrightWMHideCB, 0);
^
cxx: Info: 2 errors detected in the compilation of
"../../../../rae/src/frontends/xforms/FormCopyright.C".
I thought I'd added those already... must have forgetten to. I was just
going to try extern "C" {...} and see if that worked -- but none of my
compilers complain anyway.
Are there any undocumented "extern C" or namespace checking switches for
gcc (1.1, 1.1.2 or 2.95.2)? There don't appear to be any documented ones.
Allan. (ARRae)
cvs install nit
I installed cvs 1.1.5cvs (this morning's) with --with-lyxname=lyxd All of the share directories etc went well, but the bin went into (overwrote) /usr/local/bin/lyx instead of lyxd. Garst
Re: GUI independence and XTL
Dekel Tsur [EMAIL PROTECTED] writes: | On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: | Dekel However, the real problem lies on parsing .lyx files at | Dekel Buffer::readLyXformat2 which is done using if-else statements | Dekel (... else if (token == "\\emph") ... ) This is very | Dekel inefficient! | | Yes, this code should use LyxLex correctly. | | Actually, this is not a real problem at all. | The bottleneck at load time is the rendering of the figures and | of the document, not the parsing of the LyX document. | | You can assert this for yourself by loading the user guide. | As soon as the program says "Formatting" or "Loading font", | the raw loading part is over. You have to be fast to see it, | though. | | It depends of the document. If you have a very large file, with lots of | insets, and a weak CPU, you will notice the time for parsing the document. | | | So: There is no reason to change this. So much else to do. | | | If you want, I can do the changes (and also do the changes I suggested | for layout.C) Nooo! :-) I absolutely disagree with you ad. the parsing of layout files. Lgb
Re: GUI independence and XTL
"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes: | [Rewrite the loading parsing logic] | If you want, I can do the changes (and also do the changes I suggested | for layout.C) | | When you volunteer, obviously it's a good idea to make the change. | You won't find me arguing against that ;-) | | I'm sure the patch would be welcomed. | | Maybe it's time for Dekel to get cvs write access? We should not ahve too many people with cvs access, anyway this has to wait a bit since we might have some lyx.org changes soon. Lgb
Arabic patch
The following patch adds better support for Arabic, and fix several other
things.
Also, it includes the end-of-proof patch (which haven't yet been applied)
patch.gz
#
# Arabic keyboard definition for LyX
#
# Generated automatically from kikbd map by Adil Alsaid [EMAIL PROTECTED]
#
\kmap q Ö
\kmap w Õ
\kmap e Ë
\kmap r
\kmap t
\kmap y Ú
\kmap u Ù
\kmap i
\kmap o Î
\kmap p Í
\kmap a Ô
\kmap s Ó
\kmap d
\kmap f È
\kmap g
\kmap h Ç
\kmap j Ê
\kmap k
\kmap l
\kmap z Æ
\kmap x Á
\kmap c Ä
\kmap v Ñ
\kmap b ¡
\kmap n
\kmap m É
\kmap ;
\kmap ' ×
\kmap ","
\kmap . Ò
\kmap / Ø
\kmap ` ;
\kmap ` Ð
\kmap [ Ì
\kmap ] Ï
\kmap Q
\kmap W
\kmap E
\kmap R
\kmap T
\kmap Y Å
\kmap U
\kmap I
\kmap O Î
\kmap P
\kmap A
\kmap S
\kmap D [
\kmap F ]
\kmap G
\kmap H Ã
\kmap J
\kmap K
\kmap L /
\kmap Z
\kmap X
\kmap C {
\kmap V }
\kmap B
\kmap N Â
\kmap M
\kmap ","
\kmap .
\kmap ? ¿
\kmap ~ Ð
\kmap {
\kmap }
Re: GUI independence and XTL
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bjnnes wrote: Dekel Tsur [EMAIL PROTECTED] writes: | | If you want, I can do the changes (and also do the changes I suggested | for layout.C) Nooo! :-) I absolutely disagree with you ad. the parsing of layout files. Plaese explain why you don't agree with me (give your comment to my mail " The code in layout.C ")
Re: lyx-1.1.5cvs bug: All protected spaces export as ~
So this is the free spacing hack... My suggestion is that someone help me get this right in cvs with the new InsetSpecialchar for protected spaces. Hmmm... What would be involved here? | My suggestion is that inside Scrap layouts, the protected-space should output | just a space (better yet, allow SPC SPC to work in a Scrap layout, obviating | the need for doing protected-SPC for formatting code) Hardcoding anything for Scrap layout is not an option unless it is in the layout file. This is also a more general problem. I'm working on it. I've added a new boolean AllowMultipleSpaces to the layout file and am making the corresponding changes to make it work right. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: LDN
Allan: news.inc = news/news.inc should either be split into [half-]year long archives or we make a news/news.php3 that lets you "scroll" through the list (news/news.php3?2 to get the news from the second pageful of news_items) Sure. Naming things news_1999.php3 and linking them from the bottom of news.php3 would be clear and simple. And I think once per year maintenance isn't too bad. news/format.inc clean up so we get prettier looking entries I'd like the news category beside the news title in news_item for example -- at for the LDN issues anyway. Can't hurt. All that stuff was somewhat hacked together and I"m sure there's room for improvement. I took a look at AbiWord's news page yesterday to see what the competition are doing. Seems statistics are all the rage. Anyway, we trounce them on number of languages supported: 20 vs 15. And nobody else does RTL that I'm aware of (living in my little cocoon). Hold up! I'm not sure that we should be looking at them as competition. I've seen many "why should I use LyX instead of Word" mails but not one abiword one yet. The number of people in the world currently using neither Abi nor LyX is probably large enough that we don't have to worry about this for a while. So just because they use a lot of statistics, doesn't mean we have to either. Certainly, we ought to be tooting our own horn. But we should do it the way we want to. And actually, I didn't notice a focus on statistics. Other stats that they like to list are numbers of emails, numbers of lines of code changed or added. Shouldn't be too hard to generate big numbers with Lars' current_view purge and so on. Frankly, I think number of emails is a silly stat. Same with lines changed. I mean, if you want to just once mention that Lars changed nK lines of code which proves how big the kernel rewrite is, that's fine. But I see no reason to do it often. I couldn't figure out how to make a `ü' in html so Jürgen missed out Hee hee. Darned foreigners can't just use regular letters like us educated folk. News ideas: + Personality Profiles - like a mini interview or resume (wrt LyX) of a different developer each fortnight -- starting with our illustrious leader Lars (or maybe some comments from Matthias about why he started LyX). Ideas? Each developers vision of where we're headed? Well, I'm worried that something like this might be a bit overambitious. Are you sure that (a) there are enough core developers that you'll be able to find one each fortnight? (b) Are you sure you (and they) will have time? I would suggest instead that *sometimes* you have one of the news items (what do you call the items that aren't tiny but aren't features - editorials?) be an interview/bio. No reason to promise certain things will happen in every issue. + Statistics - code count - number of checkins per person - number of emails on each list - bugs fixed/created See above. I think some of these are silly. I find bugs fixed to be a neat thing in mozilla, but since we're not using bugzilla I think that'll be hard to track. Number of checkins is also rather meaningless. Again, I think this would be silly to have every time. Why not have a FUDD (Fortnightly Useless Developer Datum) in each issue. Things I think would be interesting on a one-time rather than fortnightly basis are: - number of people subscribing to each list (OK, maybe once per 6 months) - lines of code in LyX (Separated into C++, Perl, and other, of course :) - number of people in the CREDITS file - number of people who sent in patches in a given week (if it's large :) - number of pages of docs (OK, this requires someone latexing all of them - maybe number of K?) Even more Useless: - length of average post to lyx-devel, who's the most prolific (most posts) poster? Who's the most verbose poster (no contest there :)? - greatest number of insults on the list in 24 hours (e.g. a Friday) - number of beers drunk at the last LDM I'm sure you could come up with at least one thing to write each time. + Major threads on the lists Great idea to steal! For example, if someone read that they might be drawn to a new area of development, or find an answer to a question they have, or something. But of course it's ok if this section is empty sometimes. + Port info - WinNT and Win98 - OS/2 - KDE/KLyX? Maybe the issue before or after the l10n/i18n issue could be about the "many flavors of LyX". You could also mention a bunch of unixes it's been on, and maybe even give some short hints on compiling issues, autoconf, etc. + Aussie breakin? Why? + Focus on a particular development area - global variable purging (Lars and his current_view campaign) - STL use I'd put these together. - Mathed Where's Alejandro, btw? - keymaps i18n Or "non-English" in general, since you'd also mention l10n,
Bugs
I've found the following bugs in LyX 1.1.5cvs (they are not present in 1.1.4) 1. LyX crashes after opening a bibtex inset and pressing OK 2. The size of the font in a math insets which is inside a paragraph with a larger font size (e.g. title, section etc.) is incorrect. Load the attached bug.lyx file to see an example. 3. When importing ASCII text as lines, the leading spaces at each line are not translated into protected spaces. Moreover, LyX generates many error messages: ERROR (LyXParagraph::InsertInset): there is no LyXParagraph::META_INSET ERROR (LyXParagraph::GetChar): position does not exist.1 (1) ERROR (LyXParagraph::InsertInset): position does not exist: 57 ERROR (LyXParagraph::ParFromPos): position does not exist. ERROR (LyXParagraph::InsertInset): there is no LyXParagraph::META_INSET ERROR (LyXParagraph::GetChar): position does not exist.1 (1) ERROR (LyXParagraph::InsertInset): position does not exist: 3 ERROR (LyXParagraph::ParFromPos): position does not exist. ERROR (LyXParagraph::InsertInset): there is no LyXParagraph::META_INSET ERROR (LyXParagraph::InsertInset): position does not exist: 2 ERROR (LyXParagraph::InsertInset): position does not exist: 3 4. The following may be intentional changes: - The colors for math-mode,latex-mode etc. are darker than before - In math mode, the empty delimiter (i.e. \left. or \right. ) is drawn as a continuous line, instead of dotted line as before. #LyX 1.1 created this file. For more info see http://www.lyx.org/ \lyxformat 2.15 \textclass article \language default \inputencoding default \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Title A \begin_inset Formula \( X \) \end_inset \layout Standard B \begin_inset Formula \( y \) \end_inset \the_end
Re: GUI independence and XTL
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: > > Dekel> However, the real problem lies on parsing .lyx files at > > Dekel> Buffer::readLyXformat2 which is done using if-else statements > > Dekel> (... else if (token == "\\emph") ... ) This is very > > Dekel> inefficient! > > > > Yes, this code should use LyxLex correctly. > > Actually, this is not a real problem at all. > The bottleneck at load time is the rendering of the figures and > of the document, not the parsing of the LyX document. > > You can assert this for yourself by loading the user guide. > As soon as the program says "Formatting" or "Loading font", > the raw loading part is over. You have to be fast to see it, > though. It depends of the document. If you have a very large file, with lots of insets, and a weak CPU, you will notice the time for parsing the document. > > So: There is no reason to change this. So much else to do. > If you want, I can do the changes (and also do the changes I suggested for layout.C)
Re: Bugs
On Sat, Mar 04, 2000 at 01:02:09PM +0200, Dekel Tsur wrote:
> I've found the following bugs in LyX 1.1.5cvs (they are not present in 1.1.4)
>
> 2. The size of the font in a math insets which is inside a paragraph with a
> larger font size (e.g. title, section etc.) is incorrect.
> Load the attached bug.lyx file to see an example.
>
I've managed to fix this bug. The patch is attached.
Index: src/mathed/formula.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/formula.C,v
retrieving revision 1.29
diff -u -p -r1.29 formula.C
--- src/mathed/formula.C2000/03/02 02:19:42 1.29
+++ src/mathed/formula.C2000/03/04 11:04:33
@@ -404,11 +404,9 @@ int InsetFormula::width(Painter &, LyXFo
}
-void InsetFormula::draw(Painter & pain, LyXFont const &,
+void InsetFormula::draw(Painter & pain, LyXFont const & font,
int baseline, float & x) const
{
- LyXFont font = mathed_get_font(LM_TC_TEXTRM, LM_ST_TEXT);
-
lfont_size = font.size();
/// Let's try to wait a bit with this... (Lgb)
//UpdatableInset::draw(pain, font, baseline, x);
Re: GUI independence and XTL
[Rewrite the loading parsing logic] > If you want, I can do the changes (and also do the changes I suggested > for layout.C) When you volunteer, obviously it's a good idea to make the change. You won't find me arguing against that ;-) I'm sure the patch would be welcomed. Maybe it's time for Dekel to get cvs write access? Greets, Asger
Re: m4 question
On 3 Mar 2000, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> having read the latest installment of the lyx development news, > Angus> I checked the rae branch out of cvs and tried to compile it. > > Angus> Compilation fails in sigc++ with m4 -I./macros > Angus> macros/func_slot.h.m4 > func_slot.h m4: illegal option -- I > > Angus> I'm running on an Alpha with Digital Unix v3.2 and have the > Angus> Digital version of m4. Synopsis: m4 [-Bnumber] [-es] [-Hnumber] > Angus> [-Snumber] [-Tnumber] [-Dmacro][=value] [-Umacro] file ... | - > > I got the same problem and it is fixed by the following patch. It > works here because I have GNU m4 installed as gm4. > > Allan, I did not commit that patch because you said not to touch at > this directory. What should I do? Send it to Karl: [EMAIL PROTECTED] and apply it also. Karl's usually pretty quick at accepting little patches like this. Angus: do like JMarc and install GNU m4 as gm4. Allan. (ARRae)
Re: Compiling rae-branch on gcc 2.8.x or compaq cxx
commit all your patches.
On 3 Mar 2000, Jean-Marc Lasgouttes wrote:
> * Gcc 2.8.1: things seems to works except that, since there is no
> namespace support, everything is declared in global namespace. The
> solution is to add a few #ifdef in PopupBase.h and Popups.h. If done
> correclty, it would be very transparent. Allan, what are the classes
> from SigC which are needed?
Slot, Object and the various Signal[01]. Those are the only ones we refer
to directly at present (I think). I guess I just forgot to put those
lines in originally.
> * Compaq cxx: the main problem that I have is with xforms callbacks,
> which have to be wrapped with a C function (because cxx says that C
> linkage is not compatible with C++ linkage, and it is right). Should
> I add those wrappers, or do you have a better idea? Here is the
> error message I get:
>
> cxx: Warning: ../../../sigc++/sigc++config.h, line 33: unrecognized
> preprocessing directive
> #warning "Unknown architecture (send me gcc --dumpspecs)"
> -^
>
> [BTW, what should I do with that?]
Tell Karl to put a:
#ifdef __GNUC__
...
#endif
around it? [EMAIL PROTECTED]
> cxx: Error: ../../../../rae/src/frontends/xforms/FormCopyright.C, line 57:
> argument of type "void (*)(FL_OBJECT *, long)" is incompatible with
> parameter of type "FL_CALLBACKPTR"
> fl_set_object_callback(obj, FormCopyright::CopyrightOKCB, 0);
> ^
> cxx: Error: ../../../../rae/src/frontends/xforms/FormCopyright.C, line 73:
> argument of type "int (*)(FL_FORM *, void *)" is incompatible with
> parameter of type "FL_FORM_ATCLOSE"
> FormCopyright::CopyrightWMHideCB, 0);
> ^
> cxx: Info: 2 errors detected in the compilation of
>"../../../../rae/src/frontends/xforms/FormCopyright.C".
I thought I'd added those already... must have forgetten to. I was just
going to try extern "C" {...} and see if that worked -- but none of my
compilers complain anyway.
Are there any undocumented "extern C" or namespace checking switches for
gcc (1.1, 1.1.2 or 2.95.2)? There don't appear to be any documented ones.
Allan. (ARRae)
cvs install nit
I installed cvs 1.1.5cvs (this morning's) with --with-lyxname=lyxd All of the share directories etc went well, but the bin went into (overwrote) /usr/local/bin/lyx instead of lyxd. Garst
Re: GUI independence and XTL
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: | > > Dekel> However, the real problem lies on parsing .lyx files at | > > Dekel> Buffer::readLyXformat2 which is done using if-else statements | > > Dekel> (... else if (token == "\\emph") ... ) This is very | > > Dekel> inefficient! | > > | > > Yes, this code should use LyxLex correctly. | > | > Actually, this is not a real problem at all. | > The bottleneck at load time is the rendering of the figures and | > of the document, not the parsing of the LyX document. | > | > You can assert this for yourself by loading the user guide. | > As soon as the program says "Formatting" or "Loading font", | > the raw loading part is over. You have to be fast to see it, | > though. | | It depends of the document. If you have a very large file, with lots of | insets, and a weak CPU, you will notice the time for parsing the document. | | > | > So: There is no reason to change this. So much else to do. | > | | If you want, I can do the changes (and also do the changes I suggested | for layout.C) Nooo! :-) I absolutely disagree with you ad. the parsing of layout files. Lgb
Re: GUI independence and XTL
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: | [Rewrite the loading parsing logic] | > If you want, I can do the changes (and also do the changes I suggested | > for layout.C) | | When you volunteer, obviously it's a good idea to make the change. | You won't find me arguing against that ;-) | | I'm sure the patch would be welcomed. | | Maybe it's time for Dekel to get cvs write access? We should not ahve too many people with cvs access, anyway this has to wait a bit since we might have some lyx.org changes soon. Lgb
Arabic patch
The following patch adds better support for Arabic, and fix several other
things.
Also, it includes the end-of-proof patch (which haven't yet been applied)
patch.gz
#
# Arabic keyboard definition for LyX
#
# Generated automatically from kikbd map by Adil Alsaid <[EMAIL PROTECTED]>
#
\kmap q Ö
\kmap w Õ
\kmap e Ë
\kmap r
\kmap t
\kmap y Ú
\kmap u Ù
\kmap i
\kmap o Î
\kmap p Í
\kmap a Ô
\kmap s Ó
\kmap d
\kmap f È
\kmap g
\kmap h Ç
\kmap j Ê
\kmap k
\kmap l
\kmap z Æ
\kmap x Á
\kmap c Ä
\kmap v Ñ
\kmap b ¡
\kmap n
\kmap m É
\kmap ;
\kmap ' ×
\kmap ","
\kmap . Ò
\kmap / Ø
\kmap ` ;
\kmap ` Ð
\kmap [ Ì
\kmap ] Ï
\kmap Q «
\kmap W
\kmap E ¬
\kmap R ©
\kmap T ¤
\kmap Y Å
\kmap U ÷
\kmap I
\kmap O Î
\kmap P »
\kmap A
\kmap S ×
\kmap D [
\kmap F ]
\kmap G £
\kmap H Ã
\kmap J
\kmap K ÷
\kmap L /
\kmap Z ®
\kmap X ¯
\kmap C {
\kmap V }
\kmap B ¢
\kmap N Â
\kmap M ÷
\kmap < ","
\kmap > .
\kmap ? ¿
\kmap ~ Ð
\kmap { <
\kmap } >
Re: GUI independence and XTL
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bjnnes wrote: > Dekel Tsur <[EMAIL PROTECTED]> writes: > | > | If you want, I can do the changes (and also do the changes I suggested > | for layout.C) > > Nooo! :-) > > I absolutely disagree with you ad. the parsing of layout files. > Plaese explain why you don't agree with me (give your comment to my mail " The code in layout.C ")
Re: lyx-1.1.5cvs bug: All protected spaces export as ~
> So this is the free spacing hack... > My suggestion is that someone help me get this right in cvs with the > new InsetSpecialchar for protected spaces. Hmmm... What would be involved here? > | My suggestion is that inside Scrap layouts, the protected-space should output > | just a space (better yet, allow SPC SPC to work in a Scrap layout, obviating > | the need for doing protected-SPC for formatting code) > > Hardcoding anything for Scrap layout is not an option unless it is in > the layout file. This is also a more general problem. I'm working on it. I've added a new boolean AllowMultipleSpaces to the layout file and am making the corresponding changes to make it work right. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: LDN
Allan: > > news.inc => news/news.inc > should either be split into [half-]year long archives > or we make a news/news.php3 that lets you "scroll" through the > list (news/news.php3?2 to get the news from the second pageful > of news_items) Sure. Naming things news_1999.php3 and linking them from the bottom of news.php3 would be clear and simple. And I think once per year maintenance isn't too bad. > news/format.inc > clean up so we get prettier looking entries > I'd like the news category beside the news title in news_item > for example -- at for the LDN issues anyway. Can't hurt. All that stuff was somewhat hacked together and I"m sure there's room for improvement. > I took a look at AbiWord's news page yesterday to see what the > competition are doing. Seems statistics are all the rage. > > Anyway, we trounce them on number of languages supported: 20 vs 15. > And nobody else does RTL that I'm aware of (living in my little > cocoon). Hold up! I'm not sure that we should be looking at them as competition. I've seen many "why should I use LyX instead of Word" mails but not one abiword one yet. The number of people in the world currently using neither Abi nor LyX is probably large enough that we don't have to worry about this for a while. So just because they use a lot of statistics, doesn't mean we have to either. Certainly, we ought to be tooting our own horn. But we should do it the way we want to. And actually, I didn't notice a focus on statistics. > Other stats that they like to list are numbers of emails, numbers of > lines of code changed or added. Shouldn't be too hard to generate big > numbers with Lars' current_view purge and so on. Frankly, I think number of emails is a silly stat. Same with lines changed. I mean, if you want to just once mention that Lars changed nK lines of code which proves how big the kernel rewrite is, that's fine. But I see no reason to do it often. > I couldn't figure out how to make a `ü' in > html so Jürgen missed out Hee hee. Darned foreigners can't just use regular letters like us educated folk. > News ideas: > + Personality Profiles > - like a mini interview or resume (wrt LyX) of a different > developer each fortnight -- starting with our illustrious leader Lars > (or maybe some comments from Matthias about why he started LyX). > Ideas? Each developers vision of where we're headed? Well, I'm worried that something like this might be a bit overambitious. Are you sure that (a) there are enough core developers that you'll be able to find one each fortnight? (b) Are you sure you (and they) will have time? I would suggest instead that *sometimes* you have one of the news items (what do you call the items that aren't tiny but aren't features - editorials?) be an interview/bio. No reason to promise certain things will happen in every issue. > + Statistics > - code count > - number of checkins per person > - number of emails on each list > - bugs fixed/created See above. I think some of these are silly. I find bugs fixed to be a neat thing in mozilla, but since we're not using bugzilla I think that'll be hard to track. Number of checkins is also rather meaningless. Again, I think this would be silly to have every time. Why not have a FUDD (Fortnightly Useless Developer Datum) in each issue. Things I think would be interesting on a one-time rather than fortnightly basis are: - number of people subscribing to each list (OK, maybe once per 6 months) - lines of code in LyX (Separated into C++, Perl, and other, of course :) - number of people in the CREDITS file - number of people who sent in patches in a given week (if it's large :) - number of pages of docs (OK, this requires someone latexing all of them - maybe number of K?) Even more Useless: - length of average post to lyx-devel, who's the most prolific (most posts) poster? Who's the most verbose poster (no contest there :)? - greatest number of insults on the list in 24 hours (e.g. a Friday) - number of beers drunk at the last LDM I'm sure you could come up with at least one thing to write each time. > + Major threads on the lists Great idea to steal! For example, if someone read that they might be drawn to a new area of development, or find an answer to a question they have, or something. But of course it's ok if this section is empty sometimes. > + Port info > - WinNT and Win98 > - OS/2 > - KDE/KLyX? Maybe the issue before or after the l10n/i18n issue could be about the "many flavors of LyX". You could also mention a bunch of unixes it's been on, and maybe even give some short hints on compiling issues, autoconf, etc. > + Aussie breakin? Why? > + Focus on a particular development area > - global variable purging (Lars and his current_view campaign) > - STL use I'd put these together. > - Mathed Where's Alejandro, btw? > - keymaps & i18n Or "non-English" in
