Re: Intuitive views of nesting -- conglomerate
> On Mon, 13 Dec 1999, Amir Karger wrote: > > That doesn't sound too bad, does it? The last time I remember lars talking > > about it, he wanted to make it a bit more like html (xml?) where you'd have > > begins and ends, not just begins, and perhaps better structuring for > > nesting. But that was months, perhaps a year ago. It's obviously not a very > > high priority, although as I mentioned there are some people clamoring for > > XML now, and I don't know if that would change matters. The other issue is > > that the change in file format might reflect the change in buffer structure, > > which I don't know when that's planned for. > > I'm such a clamorer. But I don't think clamoring will make any > difference. Code will :-). Next chance I get to spend on free software > projects (after I sort out my debian projects) will be to grok the LyX > kernel and think about XML. But that's no small task :-) We are currently building a prototype for next year's project and I surprisingly (*cough* ;-)) decided to switch our file format to something 'XMLish'. Naturally I had to write some very rudimentary parser. It doesn't handle any fancy stuff yet (and probably won't, since we do not need full XML support), but maybe it could serve as a base for LyX. I put it on http://mathematik.htwm.de/Software/LyX/element.h and element.cc if anybody is interested, take it, otherwise leave it. I probably won't try to get it into LyX myself. Andre' PS: > Unless someone beats me to it... Well... -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: LyX 1.1.3 trace log - reproducible
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Why not a prerelease of 1.1.4 instead? Lars> Anyway I am going to put out a 1.1.4pre1 today anyway, I think Lars> it is time, and I'd like to have 1.1.4 out before christmas. Good idea. Lars> If you still want to make a 1.1.3.1 do that. I'll do it if it appears that 1.1.4pre1 has problems. The idea is that 1.1.4pre1 has large changes, and such changes necessarily has small problems (like what we saw in 1.1.3). Since these problems are usually one-liners, releasing a safe update makes sense. We'll see later. JMarc
lyx-1.1.4pre1 RPM's
Hi folks, The lyx-1.1.4 RPMs are now posted in the usual place: ftp://ftp.sylvan.com/pub/lyx/lyx-1.1.4pre1-1.i386.rpm ftp://ftp.sylvan.com/pub/lyx/tetex-lyx-1.1.4pre1-1.i386.rpm The source RPM is at: ftp://ftp.sylvan.com/pub/lyx/lyx-1.1.4pre1-1.src.rpm Please test and report problems to me for RPM-related issues and to the [EMAIL PROTECTED] list for lyx-related issues. Hokey slogan of the week: Test the pre-releases today so that we can create a better lyx tomorrow! ---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
relyx (fwd)
- Forwarded message from William M Connolley - >From [EMAIL PROTECTED] Mon Dec 13 18:38:04 1999 Return-Path: <[EMAIL PROTECTED]> Received: from bsfiles.nerc-bas.ac.uk (bsfiles.nerc-bas.ac.uk [192.171.137.25]) by vidar.diku.dk (8.9.0/8.9.0) with ESMTP id SAA11916 for <[EMAIL PROTECTED]>; Mon, 13 Dec 1999 18:38:03 +0100 (MET) Received: from bsaicdf.nerc-bas.ac.uk by bsfiles.nerc-bas.ac.uk (8.8.8/NERC-1.5(Solaris 2.x, SMTP)) id RAA07069; Mon, 13 Dec 1999 17:38:01 GMT Date: Mon, 13 Dec 1999 17:38:01 + (GMT) From: William M Connolley <[EMAIL PROTECTED]> X-Sender: wmc@bsaicdf To: [EMAIL PROTECTED] Subject: relyx Message-Id: Hi. I was looking through www.lyx.org for where-to-get-reLyX. Only when I donwloaded and untarred the whole lyx distribution did I find that its in there... what I mean is, could you somewhere say: "you can get relyx from place X", or even say "relyx is in the main distribution". That would have saved me a lot of time. But I mustn't grumble... lyx is a fine product & you're doing a good job. -W. William M Connolley | [EMAIL PROTECTED] | http://www.nbs.ac.uk/public/icd/wmc/ Climate Modeller, British Antarctic Survey | (01223) 221479 - End of forwarded message from William M Connolley -
Re: relyx (fwd)
W> Hi. I was looking through www.lyx.org for where-to-get-reLyX. Only W> when I donwloaded and untarred the whole lyx distribution did I W> find that its in there... what I mean is, could you somewhere say: W> "you can get relyx from place X", or even say "relyx is in the main W> distribution". That would have saved me a lot of time. Hello, What are the places where reLyX was mentionned without telling where it is? JMarc
Re: Intuitive views of nesting -- conglomerate
Regarding the LyX file format: There will not be any mayor changes in the LyX format for a long time. First, we focus on the general clean-up (very much in progress) and the GUI independence. This job will take a long time to finish. A rough estimate is around a year, judging from the current development speed. If André, Jules and others continue to have the interest in helping, and we manage to make it easy to contribute, this time frame obviously will be shorter. As it is now, Lgb and Jean-Marc are the only ones that are doing any real work on the cvs code. When the GUI independence work is done, we will most probably put in the new kernel, and at the same time change the file format drastically to XML. The new kernel already reads most of the old LyX format, so obviously we will be backwards compatible in the sense that all LyX format files will be readable by the new format. However, as part of the now ongoing clean-up, Lgb might want to do a little tidying of the LyX format, as mentioned. I.e. get rid of a few superflous blanks, add an ending tag here and there, but nothing mayor. Personally, I don't think it's worth the effort, but if Lgb is bored some day, he might do it for the fun of it. So, the conclusion is that there is no reason to wait to write converters to and from the LyX format. The work will not be wasted, and very much welcomed. Greets, Asger
MuxiXteX (fwd)
- Forwarded message from Pablo Lopez - >From [EMAIL PROTECTED] Tue Dec 14 11:51:37 1999 Return-Path: <[EMAIL PROTECTED]> Received: from mesache.encomix.es (mesache.encomix.es [194.143.192.3]) by vidar.diku.dk (8.9.0/8.9.0) with SMTP id LAA24107 for <[EMAIL PROTECTED]>; Tue, 14 Dec 1999 11:51:36 +0100 (MET) Received: (qmail 20950 invoked from network); 14 Dec 1999 10:51:34 - Received: from dynamic.es.g-matrix.net (HELO writeme.com) (194.143.217.100) by mesache.encomix.es with SMTP; 14 Dec 1999 10:51:34 - Sender: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Date: Tue, 14 Dec 1999 11:53:11 +0100 From: Pablo Lopez <[EMAIL PROTECTED]> X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: es-ES, en To: [EMAIL PROTECTED] Subject: MuxiXteX Hi, I have no experience in using tex, latex or lyx, but I started working with lyx recently and I feel comfortable. I'd like to use it to produce music sheets and I've got MusiXteX. The question is.. can I use it with lyx? How? (cause I can't waste too much time to write ascii sources and compile them). Thanks, Pablo. - End of forwarded message from Pablo Lopez -
Re: FILE -> ostream
> Another comment: there has been some work from Asger on the old 1.1 > branch for making a LaTeXWriter (hmm, I've tried to find it but > failed... has it been actually written? %-|). The LaTeXWriter was not written. However, it would be an easy task to do it. The AsciiWriter exists in the old development branch, and only needs to be extended with a few routines before a usable LaTeXWriter is ready. Now, if only I had time... Greets, Asger
Re: Hebrew support for LyX
> > The following patch add basic Hebrew support for LyX: > > When changing the document language to Hebrew (in Document Layout popup), > > the text will be rendered from right-to-left > > (except when entering TeX-mode) > > Cool! At last someone has done this! Yes, this patch is very cool. Hebrew support can be considered a FURF, and it's great to see somebody do something about it. > > The patch is against the cvs source (Dec 11). > > I should note that this patch is very incomplete (but still usable). > > Furthermore, there may be better ways to add right-to-left support > > for LyX (e.g., in the patch the text rendering is still done from left > > to right. It may be better to do the rendering from right to left). > > The rendering method isn't a problem that could be altered later. It's > the restriction on document language (ie. all or nothing) that is a > problem IMO. This is not a problem IMO. Yes, in the ideal world, we would like an inset that handles this, but we don't live in an ideal world. The ideal world will come with the new kernel some day, but until then, this is not an issue. After all, how common is it to write a mixed document? Furthermore, this is our only change to get Hebrew support: None of the existing developers have any expertise in Hebrew, so we should not waste this unique chance to get a high quality patch, and a high quality developer. I think the patch should go in as it is. Also, I think we should give cvs access to the author, because this is good work. Greets, Asger
small docbook patch
Hi,
I have tested the latest cvs and lyx.
With the docbook example file lyx crashes.
Debuging it is possible to see that some assertion is raised
where a non initialised string is accessed, throught the [] operator.
That is (was ;) my fault and it here follows the bug fix. I take the
change also to update the header of the docbook file exported...
--
José
--- buffer.C.oldMon Dec 13 12:30:45 1999
+++ buffer.CTue Dec 14 12:13:37 1999
@@ -2790,7 +2790,7 @@
ofs << "\n [ " << params.preamble << " \n]>\n\n";
string userName(getUserName());
- ofs << "\n";
if(params.options.empty())
@@ -3107,7 +3107,7 @@
// desc_on == 4
//
if(desc_on!= 3 || i!= 0) {
- if(tmp_out[0] == '@') {
+ if(!tmp_out.empty() && tmp_out[0] == '@') {
if(desc_on == 4)
extra += frontStrip(tmp_out, '@');
else
Re: Comments, dummies, etc. Was: Re: SpaceLess() function is dead :) [Arnd and SMiyata, please read]
> So my idea was something similar to this: > > Setup each source file with a comment form just at the beginning, > something like the following and ask developers to fill them by and by > (I think this will work better than abstract recommendations): [commenting policy] Yes, this is very nice. However, it's overkill. Let's just clean up the existing header files, and add comments where appropriate. It is not realistic to impose a policy and expect that all random contributors will heed to it. Instead, we should just set a nice example. > Another somewhat more general point here: cvs is rapidly changing. Once > having setup some working patch the update is likely to break it. Actually, the breakage percentage is not high. cvs does a remarkable job at avoiding conflicts. [I say that system code is best tested by deployment in an open source setting.] > Is it really? Bug tracing is AFAIK all in all by far the most costly > part of software development (some 10:1 or 20:1 depending on > complexity). Some kind of 'quality management' might be painful at > first but most cost effective on the long run. Notice that I was talking about system code. System code is special in the sense that the bugs that appear, appear because the interfaces differ on different platforms. The only way to determine this is by trying it on all different platforms. The best way to try code an all platforms is to put it into LyX, and let people report the problems they find. The only cost effective way to test system code is by testing. It's impossible to predict the problems that appear on different platforms, because of buggy operating systems, missing standards, and the phase of the moon. And since it's impossible for me as an individual person to have access to all relevant operating systems and architectures, the only way to go about this business is to write the code, release it, and then weed out all the inevitable problems that appear. > >The method is not dummy on Unix. It's better to have the same structure > >across platforms, even if the implementation is different (or missing.) > > If a child is started with exec*() instead of spawn*() emx might need a > waitForChild() which is not a dummy. Making it dummy is a good way to > introduce a hard to trace bug in the future. Ok, so the solution might be to introduce a new set of functions that abstract these two fundamentally different interfaces: One set for functions that don't wait, and one that waits. I think we can agree that using the preprocessor to prevent semantic programming errors that are caught at link time is a bad idea. The preprocessor is not meant for imposing semantic information, and the linker is suboptimal for compile time error diagnostics, because it can only say that there is a problem, not where the problem is. Let's solve the problem is the correct manner: By imposing the correct semantic structure in the code, rather than in the preprocessor. Greets, Asger
Re: small docbook patch
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: Jose> Content-Type: text/plain; charset=iso-8859-1 Jose> Content-Transfer-Encoding: 8bit Jose> Hi, I have tested the latest cvs and lyx. With the docbook Jose> example file lyx crashes. Jose> Debuging it is possible to see that some assertion is raised Jose> where a non initialised string is accessed, throught the [] Jose> operator. OK, I just commited it. JMarc PS: you could probably ask Lars for cvs access...
Re: small docbook patch
> - ofs << "
Re: small docbook patch
> + ofs << "\n"; Aehm.. sorry, forgot one. "userName"? I thought big brother was dropped a few weeks ago ;-) Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Strange "feature"
1.1.4cvs, option->keyboard german. Encoding latin1.
When pressing ö (this funny german letter with two dots above an o)
I get something that looks like two dots above an o.
Well, no big deal you might think, that's what it is supposed to do.
But: The dots are far higher than 'normal' and it does not look like a
single character at all. Indeed, when looking at the .lyx file there
is a \i \"{o} instead of ö in the file.
Anybody an idea?
Andre'
--
Andre' Poenitz .. [EMAIL PROTECTED]
Re: Hebrew support for LyX
On Tue, Dec 14, 1999 at 01:19:23PM +0100, Asger K. Alstrup Nielsen wrote: > > Yes, this patch is very cool. Hebrew support can be considered a FURF, > and it's great to see somebody do something about it. Yay! Dekel, how is this patch related to TeX--XeT? I seem to remember you needed more than just a Hebrew font to write hebrew in LaTeX. > After all, how common is it to write a mixed document? Actually, I suspect it's not uncommon. First, in the scientific world (a popular LyX niche) I think there's stuff you have to write in English, even if you want to write most of a document in hebrew. ALternatively, a lot of science in Israel is done in English, but folks might want to put some hebrew stuff in. But of course, limited support for hebrew is better than none. In addition, most of the Jews in the world don't live in Israel. But very often when Jews are discussing religious stuff they want to use Hebrew (getting hebrew on web pages is a popular FAQ), in combination with a mainly English (Spanish, French...) document. Heck, with multi-column (or something like it) you could even write a bible translation! LyX would be really great for this. btw, do we get arabic for free with this? Arabic is an URF, if not a FURF. > Furthermore, this is our only change to get Hebrew support: None of the > existing developers have any expertise in Hebrew, I'm offended! Oh, you mean expertise in coding a Hebrew document processor. OK. (Well, OK, I'm not really an active developer these days, but don't tell anyone.) -Amir
broken_cont.h
Does anybody know the reason for the existence of broken_const.h? It looks like a good candidate for a move to /dev/null Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: broken_cont.h
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: Andre'> Does anybody know the reason for the existence of Andre'> broken_const.h? It looks like a good candidate for a move to Andre'> /dev/null Yes, I have a plan to do that, and drop the --with-broken-const option of configure. --with-gcc-hack should go too, and (later when we come to GUI work) --with-two-colors. JMarc
Re: broken_cont.h
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: Jean-Marc> Andre'> Does anybody know the reason for the existence of Jean-Marc> Andre'> broken_const.h? It looks like a good candidate for Jean-Marc> a move to Andre'> /dev/null Jean-Marc> Yes, I have a plan to do that, and drop the Jean-Marc> --with-broken-const option of configure. --with-gcc-hack Jean-Marc> should go too, and (later when we come to GUI work) Jean-Marc> --with-two-colors. OK, I removed this a a few other old things. I'll have to read the configure script a second time and figure out what should go away. JMarc
Re: Comments, dummies, etc. Was: Re: SpaceLess() function is dead :) [Arnd and SMiyata, please read]
On Tue, 14 Dec 1999 13:38:02 +0100 (MET), Asger K. Alstrup Nielsen wrote: >> So my idea was something similar to this: >> >> Setup each source file with a comment form just at the beginning, >> something like the following and ask developers to fill them by and by >> (I think this will work better than abstract recommendations): > >[commenting policy] > >Yes, this is very nice. However, it's overkill. Let's just >clean up the existing header files, and add comments where >appropriate. >It is not realistic to impose a policy and expect that all >random contributors will heed to it. Instead, we should just >set a nice example. Developers will soon contribute their own ideas on better comment policy and give better examples. They are too 'creative' to follow some dull pattern which they feel they can do better. The idea is only to encourage them to invest some minutes in thinking of those poor others which must read their code someday. An example is good, a small form is better: Makes commenting in fact easier and is well 'tested' psychology, "recommended by friendly bureaucrats worldwide" ;-) > >> Another somewhat more general point here: cvs is rapidly changing. Once >> having setup some working patch the update is likely to break it. > >Actually, the breakage percentage is not high. cvs does a remarkable job >at avoiding conflicts. OK >[I say that system code is best tested by deployment in an open source >setting.] >> Is it really? Bug tracing is AFAIK all in all by far the most costly >> part of software development (some 10:1 or 20:1 depending on >> complexity). Some kind of 'quality management' might be painful at >> first but most cost effective on the long run. > >Notice that I was talking about system code. System code is special in >the sense that the bugs that appear, appear because the interfaces differ >on different platforms. The only way to determine this is by trying it >on all different platforms. The best way to try code an all platforms >is to put it into LyX, and let people report the problems they find. > >The only cost effective way to test system code is by testing. It's >impossible to predict the problems that appear on different platforms, >because of buggy operating systems, missing standards, and the phase >of the moon. And since it's impossible for me as an individual person >to have access to all relevant operating systems and architectures, the >only way to go about this business is to write the code, release it, and >then weed out all the inevitable problems that appear. There is some kind of de facto standard, which may well be observed right from the beginning [design!] to avoid unneeded trouble. Posix is good in this respect, ANSI helps much, and there is a modification of Posix as a de facto standard api, which is present on win32 and OS/2 and works especially well with cygwin or emx. (The only prominent differences to Posix I can remember now are the notorious 'drive letter/backslash' issue and the split fork()/exec*() and spawn*(), resp. Different shell semantics is another well known problem, which is mostly up to the sysadmin. This should not not be too difficult to keep in mind and really helps people to avoid frustration.) Don't bother about the few losing systems which are totally incompatible with Posix. (I'll always remember my EpiX shock (ControlData et. al.), which those lost souls dared to claim to be a Unix variant, *shudder*). Others like BeOS are modelled after this, i.e. Posix + variants, so porting is not so difficult then. (Even complicated api's like pthreads exist nearly everywhere or are at least a good base for trivial ports to 'xyz native'.) Testing is still necessary. You cannot avoid this by any reasonable effort. > >> >The method is not dummy on Unix. It's better to have the same structure >> >across platforms, even if the implementation is different (or missing.) >> >> If a child is started with exec*() instead of spawn*() emx might need a >> waitForChild() which is not a dummy. Making it dummy is a good way to >> introduce a hard to trace bug in the future. > >Ok, so the solution might be to introduce a new set of functions that >abstract these two fundamentally different interfaces: One set for >functions that don't wait, and one that waits. Sounds nice, I just cannot decide, if it is worthwile. > >I think we can agree that using the preprocessor to prevent semantic >programming errors that are caught at link time is a bad idea. The >preprocessor is not meant for imposing semantic information, and the >linker is suboptimal for compile time error diagnostics, because it can >only say that there is a problem, not where the problem is. >Let's solve the problem is the correct manner: By imposing the correct >semantic structure in the code, rather than in the preprocessor. Yup, use the correct semantics! The prepro traditionally has been widely used as a last resource for hackish semantic adaptation (think of all
setNumberOfFiles and ABSOLUTEMAXFILES
In lastfile.[Ch]. Both of the could go IMO since they are not used anywhere else. It's pure bloat. Actually I think num_files could go as well since it can be obtained by calling files.size(). Should I prepare a patch? Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Hebrew support for LyX
On Tue, 14 Dec 1999 11:15:30 -0500, Amir Karger wrote: >> After all, how common is it to write a mixed document? > >Actually, I suspect it's not uncommon. First, in the scientific world (a >popular LyX niche) I think there's stuff you have to write in English, even >if you want to write most of a document in hebrew. ALternatively, a >lot of science in Israel is done in English, but folks might want to put >some hebrew stuff in. But of course, limited support for hebrew is better >than none. > >In addition, most of the Jews in the world don't live in Israel. But very >often when Jews are discussing religious stuff they want to use Hebrew >(getting hebrew on web pages is a popular FAQ), in combination with a mainly >English (Spanish, French...) document. Heck, with multi-column (or something >like it) you could even write a bible translation! LyX would be really great >for this. And don't forget all those crazy souls in literature and humanities, who are accustomed to write half of their books as a synopsis of hebrew and greek, the rest in some medieval ecclesiastic bohemian dialect or whatever. A whole new planet full of LyX fanatics is awaiting your work :-) Greets, Arnd
cleanup
There are quite a few places where spaces had been used instead of tabs. I put a patch under http://mathematik.htwm.de/Software/LyX/spacing-patch-1 or a bit shorter http://mathematik.htwm.de/Software/LyX/spacing-patch-1.gz that changes most occurences of a multiple of eight spaces on the beginning of a line into tabs. Consider this as an RFITMT ;-) Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Hebrew support for LyX
Chinese (as well as Japanese and Korean) can also be written from right to left, even though this isn't very common nowadays. Actually, in tradition, Chinese is written from top to the bottom, then from right to left. But I don't think Latex is able to support this :-)
Re: Internalization
About i18n, I've read the "encoding.lyx" article written by Asger Alstrup Nielsen. (By the way, the file is no longer available at the URL where I got it before. Is it no longer available?) The article is talking about strings and encodings in LyX v1.2. Regarding this article and i18n/l10n, I've got a few questions (mainly concerning Unicode) in my mind: For translations in menus/messages (ie. excluding documentations) which are encoded in multi-byte encoding, eg for Asian languages, isn't it better that these translations should be encoded in Unicode? Actually, newer versions of XFree86 support already natively Unicode, so do a lot of commercial X (if not all). So I suppose characters (eg in menus) are displayed using Unicode. However, people still use Big5 as traditional Chinese encoding. Convesion from Big5 to and from Unicode isn't quite straightforward as from Latin-1 to and from Unicode. If the translation is done in Big5, there will be a lot of unnecessary conversion Big5 <-> Unicode. That's why I ask if it's better to use Unicode as the underlying encoding. I take Chinese as an example, but the argument can be very well applied to Japanese, Korean and any language encodings other than Latin-1. I see that for the moment there's no translation for Chinese, Japanese or Korean (and other non Latin-1 languages). Thus, maybe it's not too late to apply this. But of course, this would raise a second question: how is one supposed to edit in Unicode? With what editor? I just know yudit but I just managed to make it work partially. And how are .po files saved? In utf-7, utf-8 or UCS-2? Probably not in UCS-2, I think, but I might be wrong. Who knows?
Re: Strange "feature"
"Andre' Poenitz" <[EMAIL PROTECTED]> writes:
| 1.1.4cvs, option->keyboard german. Encoding latin1.
|
| When pressing ö (this funny german letter with two dots above an o)
| I get something that looks like two dots above an o.
|
| Well, no big deal you might think, that's what it is supposed to do.
|
| But: The dots are far higher than 'normal' and it does not look like a
| single character at all. Indeed, when looking at the .lyx file there
| is a \i \"{o} instead of ö in the file.
Is this also treu after reading the file again?
What keynap are you using?
Seems like Lyx does not think that this char can be directly
showed/dispplayed, and used a InsetLatexInset to show it.
Lgb
Re: setNumberOfFiles and ABSOLUTEMAXFILES
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | In lastfile.[Ch]. Both of the could go IMO since they are not used | anywhere else. It's pure bloat. | | Actually I think num_files could go as well since it can be obtained | by calling files.size(). I think I agree...almost but is is indented to be used. And num_files is used and needed. and files.size(9 does not cur it. (we add a new file and check if the size is larger than num_files. Or do I need to reread my code...) | Should I prepare a patch? No, need I will look at this. Lgb
Re: cleanup
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | There are quite a few places where spaces had been used instead of tabs. | I put a patch under | | http://mathematik.htwm.de/Software/LyX/spacing-patch-1 | | or a bit shorter | | http://mathematik.htwm.de/Software/LyX/spacing-patch-1.gz | | that changes most occurences of a multiple of eight spaces on the | beginning of a line into tabs. | | Consider this as an RFITMT ;-) Request for indent to my tabs? | | Andre' | | -- | Andre' Poenitz .. [EMAIL PROTECTED] Lgb
Re: Hebrew support for LyX
On Tue, 14 Dec 1999, Arnd Hanses wrote: > On Tue, 14 Dec 1999 11:15:30 -0500, Amir Karger wrote: > > >> After all, how common is it to write a mixed document? > > > >Actually, I suspect it's not uncommon. First, in the scientific world (a > >popular LyX niche) I think there's stuff you have to write in English, even > >if you want to write most of a document in hebrew. ALternatively, a > >lot of science in Israel is done in English, but folks might want to put > >some hebrew stuff in. But of course, limited support for hebrew is better > >than none. [..] > And don't forget all those crazy souls in literature and humanities, > who are accustomed to write half of their books as a synopsis of hebrew > and greek, the rest in some medieval ecclesiastic bohemian dialect or > whatever. > > A whole new planet full of LyX fanatics is awaiting your work :-) I have a few friends in the "Studies in Religion" and "Classics and Ancient History" departments here and they aren't prepared to switch to LyX till we get the ability to easily insert quotations or individual words in Hebrew or Sanskrit(sp?). Currently they use either specialised software or plug symbols in from a character chart in their Windblows software. A good second step (after including this patch) would be to allow language on a per-paragraph basis. That way quotes at least could be included in an English language document for example. Then I could try to get a couple of people here to try it out also. Allan. (ARRae)
Re: setNumberOfFiles and ABSOLUTEMAXFILES
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | "Andre' Poenitz" <[EMAIL PROTECTED]> writes: | | | In lastfile.[Ch]. Both of the could go IMO since they are not used | | anywhere else. It's pure bloat. | | | | Actually I think num_files could go as well since it can be obtained | | by calling files.size(). | | I think I agree...almost but is is indented to be used. | And num_files is used and needed. and files.size(9 does not cur it. | (we add a new file and check if the size is larger than num_files. Or | do I need to reread my code...) | | | Should I prepare a patch? | | No, need I will look at this. | | Lgb After looking at this I can't see the bloat that you are speaking of. Lgb
Re: Hebrew support for LyX
Dekel Tsur <[EMAIL PROTECTED]> wrote: > The following patch add basic Hebrew support for LyX: > When changing the document language to Hebrew (in Document Layout popup), > the text will be rendered from right-to-left > (except when entering TeX-mode) IMHO RTL is a paragraph property rather than a buffer property. And there might be a need for a short RTL pharase embedded in a line in LTR paragraph and vice versa. > The patch is against the cvs source (Dec 11). > I should note that this patch is very incomplete (but still usable). > Furthermore, there may be better ways to add right-to-left support > for LyX (e.g., in the patch the text rendering is still done from left > to right. It may be better to do the rendering from right to left). AFAIK the only way for X to render string from right to left is to use a font with negative width characters. Is there any other way? This approach is "easier" in a way that you don't have to rearrange strings just as you did. On the other hand, all Arabic/Hebrew fonts I checked have only characters of positive widths, so that we will have to prepare special fonts if this approach is taken. Besides LyXText::GetColumnNearX() may be more heavily patched. Probably your approach to rearrange a string constituting each row would be better. Now it strikes me that you are talking something completely different. Are you refering to the fact that the end-of-paragraph lines which do not span the full width of the screen are left aligned? > If the LyX developers choose to use this patch, then I would like to > become a developer to make additional changes. You can ask Lars to set up a new branch. I think every developer welcomes you. Regards, SMiyata
Re: handling evil stuff in mathed (and simplifying the lexer too :-).
A half year ago, Duncan Simpson <[EMAIL PROTECTED]> wrote: > mathed's lexer has some really stupid hacks in it. Following TeX on what is a > macro makes the code *much* simpler and would eliminate even more if I could > rebuild math_hash.C (the CVS sources seem to lack to input to gperf). All the > change required is to put the first character after the \ in the macro name > before checking whether it is a letter (just like TeX does). Doing this allows > the special cases handling things like \, to be nuked and , to be placed in > math_hash.C's list instead. [... (More good stuffs deleted)] Where can I find this proposal for an improved math lexer/hash table? Regards, SMiyata
