Re: slides
"Mike" == [EMAIL PROTECTED] writes: Mike On Thu, 7 Jan 1999, Amir Karger wrote: Did anyone check John Weiss' slide patch in the docs (Mike)? How about in lyx-1_0_x/lib/layouts? Mike Not me. I tend to ignore such things unless someone specifically Mike says "Mike, please check this into the docs" since I do not have Mike CVS access to anything but the lyxdoc area. Since the entire Mike patch includes more than docs, one of our fearless developers Mike should check it in. (Of course, I will check in the docs if one Mike of those aforementioned fearless devies says "Mike, please check Mike this into the docs" :-) I tried to commit it, but the various parts of the patch fail for some reason. So, until John sends me an updated version, nothing will happen. JMarc
Re: slides
"Amir" == Amir Karger [EMAIL PROTECTED] writes: Amir btw, I *still* think that adding magenta, blue, cyan, and green Amir is adding more colors you don't need. Why not make all slide Amir stuff one color? Am I the only one uncomfortable with all these Amir colors? Agreed. JMarc
Re: reLyX.lyx doc!
"Amir" == Amir Karger [EMAIL PROTECTED] writes: Amir Then I though I could use the fancy new sgml utilities, but from Amir discussions with José, it didn't sound very possible. José Amir suggested, however, that it would be easy for a Perl expert Amir (*blush* :) to modify pod2latex to output LyX Amir instead. (Especially if that Perl expert knew how to convert Amir latex to lyx!) Excellent idea! And I like the result. Amir Well, I'm happy to report that I did a major hack job on Amir pod2latex, and my pre-alpha version of pod2lyx actually works! Amir Of course, I've been using it on reLyX.pod, so anything not Amir included in that isn't supported. Nonetheless, it means I'm able Amir to attach reLyX.lyx (gzipped). Which is legal LyX and produces Amir legal LaTeX, which really surprises me. I wish I was so impressive I could impress myself. Amir Do me a favor and take a look at it. Are there things I need to Amir translate differently, or could we include it just like this in Amir lyxdoc? Are there typos? Would it be possible to make it have a real title instead of this stupid first section? To have some of the text in tt font when necessary (even if it is not visible in the Man)? To avoid having UPPERCASE section titles. In short, I'd like to have the best of both worlds: a man page which looks like a man page, and a LyX document which looks like a document. Amir I guess the only question now is whether it's better to continue Amir editing it as a pod page or a LyX doc. I guess the answer is Amir that José is going to have support for a "man page" linuxdoc Amir (OK, I don't really know what that means) which means I"ll have Amir the best of both worlds. I.e., we'll have a lyxdoc, but also be Amir able to export a man page for someone to call if they're using Amir reLyX from the command line. Great! Until a man page class exists, I think you should continue developping the pod version. Besides, having a pod2lyx script could appeal to perl hackers... in particular if we add pod support into LyX (how difficult would that be?). JMarc
Re: literate programming reviwed
"Edmar" == Edmar Wienskoski [EMAIL PROTECTED] writes: Edmar Here are the literate programming patches again. I did all the Edmar requested modifications and put them in one single patch Edmar (against pre6). I will go quickly over each one and tell what I Edmar have modified from my original post. Thanks for the submission. I commited parts of those patches. First, I really like the quality of the patches and the way they integrate to LyX. I guess this was to be expected from somebody who uses web techniques ;) In fact, I did not took the parts which directly relate to litterate programming for two reasons: - it is a big change, that have to be properly documented and tested (although I trust your own tests on this one). I would not want to delay 1.0.0 for this and it could easily go into 1.0.1. - I am waiting a bit for Lars' decision on this one, since he is the main architext. Now for the details: 1 - The first patch is to allow the choice of the color of the new-line character. ... Obs: The default color is the same it is today. Edmar This patch remains the same. I took this one. 2 - Patch to include new shortcut buttons in the toolbar. ... Obs: The customization of the toolbar itself is left to the user do in his/her lyxrc file. Thus, the toolbar defaults to its present looks. Edmar This patch remains the same. This one is fine, but does not make sense until the rest is in. 3 - Patch to not output the protected space '~' during translation of latex paragraphs. ... Edmar This patch remains the same. This one was already in. 4 - Patch to always produce "nice-latex" This one is good, but I did not take it because it depends on the rest. 5 - Patch to allow Item_Environment and Environment layouts to have a "dummy" latex command name Edmar Eliminated. Fine. 6 - The addition of the Scrap layout to lyxmacros.inc Edmar Not anymore... That's fine. Note that you should define OutputType after Inputing article.layout, since someone could decide to add 'OutputType latex' in there ;) Other than that, it looks fine to me. 7 - Patch to have different buttons and menu options for running latex, and building the code. The following new entries in the lyxrc are possible now: command: default: \web_command noweave -delay -index \web_extension .nw \web_error_filter cat \build_command make \build_error_filter cat Some comments: - could you write a short documentation about those in lyxrc? [something for the real docs about litterate programming would be nice too, but that's more work] - the default values for these commands should be "none" and the existence of the relevant programs should be tested in lib/configure (have a look at config/lib_configure.m4 to see how it works). If you have a problem with this, tell me what has to be tested for and I'll add it. The textclasses should be made available only if the program is found. - I am a bit worried that the 'web' name can be confusing for many users. Would it be possible to find another generic buzzword to describe that? Edmar In summary, the only difference a plain text user will notice Edmar in LyX is the new entry in the file menu: "Build Program". If Edmar a user tries to execute it in a plain text document, a message Edmar will pop up. (Other way would be to gray it out ...) It would be indeed better to grey it out when the buffer type is not Web or \web_command is "none". 8 - Patch to implement "server-goto-file-row" function Edmar This patch remains the same. This one is in. For reference, I append to this message a copy of what remains from your patch. Since I edited that by hand, it is possible that I made mistakes... I took only 20% of it yet, but all will eventually go in, I guess. Oh, and I added you to the CREDITS file. JMarc wiensk-981227-pending.patch.gz
Re: Update of WHATSNEW
"Rick" == Richard E Hawkins Esq [EMAIL PROTECTED] writes: Rick - The word immediately prior to the cursor now appears as a Rick default when inserting an index entry. An additional command Rick exists to insert this word by keystroke and without a dialog Rick box. Since we are not supposed to enter into details, I replaced this with: - easier handling of index entries. Is that alright for you? Oh, I also removed the authors names in the INSTALL file, since they do not make much sense now. JMarc
Re: back with the matrix dialog
"Emmanuel" == Emmanuel GUREGHIAN [EMAIL PROTECTED] writes: Emmanuel After making up my mind, I have tried to change the matrix Emmanuel dialog in math_forms.fd in such a way that size does not Emmanuel change. The side effect is that buttons are now on the Emmanuel right. Hmm, I do not have any special thought about it. What do you people prefer? The old one with horizontal sliders or Emmanuel's version with a vertical rows slider? In any case, we should use similar solutions for the table and matrix popups. JMarc
Re: back with the matrix dialog
"Emmanuel" == Emmanuel GUREGHIAN [EMAIL PROTECTED] writes: Emmanuel After making up my mind, I have tried to change the matrix Emmanuel dialog in math_forms.fd in such a way that size does not Emmanuel change. The side effect is that buttons are now on the Emmanuel right. Hmm, I do not have any special thought about it. What do you people prefer? The old one with horizontal sliders or Emmanuel's version with a vertical rows slider? In any case, we should use similar solutions for the table and matrix popups. I'd prefer exactly the same dialog for matrices as for tables. Probably because I've never understood the conceptional difference between matrices and tables... Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: back with the matrix dialog
"Andre'" == Andre' Poenitz [EMAIL PROTECTED] writes: Hmm, I do not have any special thought about it. What do you people prefer? The old one with horizontal sliders or Emmanuel's version with a vertical rows slider? In any case, we should use similar solutions for the table and matrix popups. Andre' I'd prefer exactly the same dialog for matrices as for tables. Andre' Probably because I've never understood the conceptional Andre' difference between matrices and tables... There is no conceptual difference as far as LaTeX is concerned. However, the LyX implementations are completely separate. JMarc
Re: reLyX.lyx doc!
On Fri, Jan 08, 1999 at 08:55:02AM +0100, Jean-Marc Lasgouttes wrote: Excellent idea! And I like the result. Yay! I wish I was so impressive I could impress myself. Well, if you'd like, you can just be impressed by me instead. That will make two of us :) Amir Do me a favor and take a look at it. Are there things I need to Amir translate differently, or could we include it just like this in Amir lyxdoc? Are there typos? Would it be possible to make it have a real title instead of this stupid first section? To have some of the text in tt font when necessary (even if it is not visible in the Man)? To avoid having UPPERCASE section titles. In short, I'd like to have the best of both worlds: a man page which looks like a man page, and a LyX document which looks like a document. This is a great idea, and at least parts of it ought to be entirely possible. I definitely have various ideas for upgrading pod2lyx so that the resulting LyX file is more appropriate to LyX. Make the section names "ufirst" is a good example. Things we could do: - as you suggest, make the name of the pod file into the title. Hm. We could either use the actual name of the pod OR take the "NAME" section. The NAME section is required for conforming pod, so that should be safe. The only problem is that the title might be too long. Another option would be to make the NAME section into an Abstract---or compromise and make the actual program name into a \title and its description (anything following a - and whitespace) into an abstract. - add a table of contents. (Why not? It's essentially free if we use Section instead of Section*). Admittedly, you don't expect a table of contents in a man page, but I wish they had one in, say, the csh man page (26 pages)! - pod L references. pod2man turns L"BUGS" into "the BUGS section in elsewhere in this man page. We can do the same BUT we can create labels for each section, and then ADD A REFERENCE when translating the L to make it a hyperlink! - pod2latex automatically indexes every section item. I turned that off but we could make it an option. (And there's an X pod thing to index anyway) -handle accents. I just realized that pod does, so I added the accent aigu (sp?) to the e and i in José Abílio. Etienne and David Suarez de Lis (and John Weiss :) should let me know if they have latin1 accents in their names, too. Anyway, "man" doesn't support it but lyx does, so we could translate that too. (pod2latex already does this, so it should be easy) - other ideas? I'm in excited to be coding mode now, so now's the time for feature requests :) Until a man page class exists, I think you should continue developping the pod version. Besides, having a pod2lyx script could appeal to perl hackers... in particular if we add pod support into LyX (how difficult would that be?). I would think that José could make linuxdoc/docbook output this pretty easily, since it's similar to man/html sorts of things and very simple. I agree that this could be useful to perl hackers, especially if we make the pod2lyx and lyx2pod translations trivial. Then you could write docs in LyX, without needing to remember the fancy escape characters, and output pod, which is the extremely portable perl standard. Or output man/html/text straight from lyx instead of going through pod. Neat! -Amir
Re: Bug, lyx1pre6, resizing window
At 12:07 PM 1/7/99 +0100, you wrote: Steven somewhat unusual port (I ported LyX to Windows NT using the Steven Cygwin library), I would like to know if others have the same Steven problem. Interesting. Did you need to change things to make it work? Several things. However, I tried to compile it using the latest version of the Cygwin library and always all the problems disappeared. Only the fact that Cygwin does not support mkfifo remains. Unfortunately, I didn't get the ports voor Xlib and Xforms right, so I didn't actually see anything. I do not have time to look into it now. You (and Roland and Berhard as well) can check out my LyX-page for the port: http://www.cs.uu.nl/~steven/lyx.html . It currently shows pre4. Steven bitmaps and not by explicitly redrawing the screen. When I Steven scroll up and down, I can see the bitmap of the overlapping Steven window again. I would say this is a problem with your X server or the xforms port. What server are you using? I use Exceed. Dag, Steven --- (http://www.cs.uu.nl/staff/steven.html)
Re: Bug, lyx1pre6, resizing window
At 12:54 PM 1/7/99 +0100, you wrote: [problems with refresh and overlapping windows.] I would say this is a problem with your X server or the xforms port. What server are you using? Actually, this bug is a feature. We changed it to be like this in order to have fast, fast redraws. Of course, on WinNt, this is not the case, so maybe we should make this behaviour conditional? If the screen update slows down, it is probably not worth it. It is very predictable behaviour, so it more convenient to just avoid resizing overlapping windows. It wouldn't hurt to make it conditional of course... Dag, Steven --- (http://www.cs.uu.nl/staff/steven.html)
Re: back with the matrix dialog
"Andre'" == Andre' Poenitz [EMAIL PROTECTED] writes: Andre' I'd prefer exactly the same dialog for matrices as for tables. Andre' Probably because I've never understood the conceptional Andre' difference between matrices and tables... There is no conceptual difference as far as LaTeX is concerned. However, the LyX implementations are completely separate. Andre' Why? Andre' Why does LyX introduce a difference, when there is none on the Andre' LaTeX-level? The code is not the same, was written by different people at different times and does not have the same features. Does that answer your question? ;) Andre' Why do I have to learn to use two different dialog to do Andre' basically the same thing? Andre' Why can't we just use the table dialog for both cases? *Maybe* will it be possible in LyX 1.1 to use the same inset for tables and matrices. But don't hold your breath... JMarc
Re: Bug, lyx1pre6, resizing window
"Steven" == Steven van Dijk [EMAIL PROTECTED] writes: Steven At 12:07 PM 1/7/99 +0100, you wrote: somewhat unusual port (I Steven ported LyX to Windows NT using the Cygwin library), I would Steven like to know if others have the same problem. Interesting. Did you need to change things to make it work? Steven Several things. However, I tried to compile it using the Steven latest version of the Cygwin library and always all the Steven problems disappeared. Only the fact that Cygwin does not Steven support mkfifo remains. Unfortunately, I didn't get the ports Steven voor Xlib and Xforms right, so I didn't actually see Steven anything. I do not have time to look into it now. Steven You (and Roland and Berhard as well) can check out my LyX-page Steven for the port: http://www.cs.uu.nl/~steven/lyx.html . It Steven currently shows pre4. That's pretty interesting. I guess that switching to autoconf 2.13 should fix several of your problems with suffixes. Other than that, with the appropriate updates to cygwin (assuming they fix it soon), we could add support for winNt in LyX pretty easily. It seems almost easier than in OS/2, since you do not have all the problems with file names. Congratulations. JMarc
Re: reLyX.lyx doc!
"Amir" == Amir Karger [EMAIL PROTECTED] writes: Amir This is a great idea, and at least parts of it ought to be Amir entirely possible. I definitely have various ideas for Amir upgrading pod2lyx so that the resulting LyX file is more Amir appropriate to LyX. Make the section names "ufirst" is a good Amir example. Things we could do: [...lots of good ideas...] Amir - other ideas? I'm in excited to be coding mode now, so now's Amir the time for feature requests :) And what about reLyX? g JMarc PS: to reward to from your hard work, not that I took care of removing your name from the To: field, so that you get only one copy of this otherwise very interesting message.
Re: Update of WHATSNEW
Since we are not supposed to enter into details, I replaced this with: - easier handling of index entries. sounds good to me. I just figure that it's important enough to add, as it was one of the things that used to irritate me, and I'd assume lot's of others. But then again, I want to file bugs against cat, mkdir, and rmdir, as commands this important should have two letter names :) Rick, the keystroke reduction junkie --
Re: back with the matrix dialog
The code is not the same, was written by different people at different times and does not have the same features. Does that answer your question? ;) No ;-) It was merely a 'leading question' hoping to see one day the same dialog in both places. *Maybe* will it be possible in LyX 1.1 to use the same inset for tables and matrices. But don't hold your breath... Oki, I hold my breath ;---) Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: Find Replace change
"Jochen" == Jochen Kuepper [EMAIL PROTECTED] writes: Jochen Hi, Daniel Naber send in a patch to KLyX to find forward on Jochen each replace in the FindReplace dialog. We sent that patch to Jochen Matthias to judge wether we want to put it in or not. ( It Jochen seems he is still thinking :-) Jochen What do you think about that feature ? I like the feature, but shouldn't it continue backwards if we were searching backwards? We should keep a bool saying in which direction the last search was, I think. Thanks for the input. BTW, do you still keep KLyX up-to-date with the changes in LyX, or do you include only some specific fixes? Just to know. JMarc
Editing in Table-Extra
Hi all, I'm not sure if it's a problem of our local installation, so maybe you could check this: If I want to use special table layout formats using the Table-Extra dialogbox, the editing of the input field is broken: Typing text is ok, but when I move the cursor to some point inside the line and type a character there, *after* inserting the character (or deleting one, if I pressed DELETE) the cursor position is set at the end of the line. It seems not XForms related, as other input fields work OK. Peter -- ~~ Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit Universitaets-Sternwarte Goettingen Tel.: +49 551 39-5048 [EMAIL PROTECTED] -- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- Come and see the stars! http://www.kis.uni-freiburg.de/~ps/SFB Sternfreunde Breisgau e.V. Tel.: +49 7641 3492 __
Re: reLyX.lyx doc!
On Fri, Jan 08, 1999 at 05:03:05PM +0100, Jean-Marc Lasgouttes wrote:
Amir - other ideas? I'm in excited to be coding mode now, so now's
Amir the time for feature requests :)
And what about reLyX? g
Humph. I recently found out that reLyX can't find \include'd files if you run
reLyX on a file not in the current directory. For example:
reLyX dir/foo.tex
if foo has "\include{bar}" then reLyX looks for bar in the current directory,
not in dir. That's dumb! Unfortunately, the solution isn't trivial, since e.g.
an included file might have another included file. In addition, there's the
whole mess of the new -o option to consider. It means the argument to the
\include command may be very different from the actual file you're including.
My current idea for a fix is to chdir my way around so that the file we're
reLyXing is always in the current directory. This may not be the best
solution. For example, how slow is changing directories?
There's a perl module that turns relative path names into absolute ones and
vice versa. However, I can't use it because it's not in the standard perl
distribution. I might steal ideas from it, though.
PS: to reward to from your hard work, not that I took care of removing
your name from the To: field, so that you get only one copy of this
otherwise very interesting message.
I'm so grateful! Maybe I'll send an extra copy of this message to show that my
gratitude can't fit in just one message.
-Amir
Re: reLyX.lyx doc!
Amir Karger wrote: On Fri, Jan 08, 1999 at 08:55:02AM +0100, Jean-Marc Lasgouttes wrote: I would think that José could make linuxdoc/docbook output this pretty easily, since it's similar to man/html sorts of things and very simple. The support for manpages in linuxdoc is an workaround (read hack) but it works, the problem with sgmltools 2.0 is that there aren't any groff or nroff backend. linuxdoc will be insuported , Cees declared that. The present implementation of manpages doesn't allow 2 sections levels, as you use it in pod (I have read the reLyX manpage so I know that), would you (Amir) like to have such a support? It is easy to have it (a one line patch). The other thing that the manpage model doesn't support are references (both internal and external), again it is a one line patch to solve this. Since the changes are so small I will request to Cees to incorporate it in the next realease of sgmltools 1.0.x (probably the last). The code generation will require an hack to support the manpages (since their support behaves differently from the other elements in linuxdoc), the problem is the the title manipulation, the same problem that Amir has now. So all the Intitle layouts will be manipulated in a different way from the other layouts... I agree that this could be useful to perl hackers, especially if we make the pod2lyx and lyx2pod translations trivial. Then you could write docs in LyX, without needing to remember the fancy escape characters, and output pod, which is the extremely portable perl standard. Or output man/html/text straight from lyx instead of going through pod. Neat! -Amir -- José Abílio de Oliveira Matos ~ I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!!
Re: reLyX.lyx doc!
"Amir" == Amir Karger [EMAIL PROTECTED] writes:
Amir Humph. I recently found out that reLyX can't find \include'd
Amir files if you run reLyX on a file not in the current
Amir directory. For example: reLyX dir/foo.tex if foo has
Amir "\include{bar}" then reLyX looks for bar in the current
Amir directory, not in dir.
If the name has been given as dir/foo.tex and no -o option has been
given, you can do something like
outdir=`pwd`
cd dir/
do the usual stuff as if -o outdir had been specified.
If -o has been specified, make sure you turn the out spec to an
absolute path, and then cd dir/ and then do the usual stuff.
I am sure there are problems with this approach, but I do not see them
right now.
JMarc
Re: Editing in Table-Extra
"Peter" == Peter Suetterlin [EMAIL PROTECTED] writes: Peter Hi all, Peter I'm not sure if it's a problem of our local installation, so Peter maybe you could check this: Peter If I want to use special table layout formats using the Peter Table-Extra dialogbox, the editing of the input field is Peter broken: Typing text is ok, but when I move the cursor to some Peter point inside the line and type a character there, *after* Peter inserting the character (or deleting one, if I pressed DELETE) Peter the cursor position is set at the end of the line. I can confirm that. Maybe this is some kind of clever hack from Juergen that turned out to be a bad idea... [I can safely badmouth him, he is not here to defend himself. Ha!] Inspecting the code it turns out that there is a callback on this input field, which is maybe the reason why the entering of characters is interrupted. Since the bug is benign and the 'fix' could be devastating, I propose that we just document it :) JMarc
Re: Find Replace change
On Fre, 08 Jan 1999 Jean-Marc Lasgouttes wrote:
"Jochen" == Jochen Kuepper [EMAIL PROTECTED] writes:
Jochen Hi, Daniel Naber send in a patch to KLyX to find forward on
Jochen each replace in the FindReplace dialog. We sent that patch to
Jochen Matthias to judge wether we want to put it in or not. ( It
Jochen seems he is still thinking :-)
Jochen What do you think about that feature ?
I like the feature, but shouldn't it continue backwards if we were
searching backwards? We should keep a bool saying in which direction
the last search was, I think.
Hey, yeah, this is why I wasn't that enthusiastic, but I was to rigid to find
your easy solution. Here we go !
So what's about the patch I appended - it does exactly that. It's against
lyx-1_0_x repository ?
If we agree, I would put it into KLyX, you into LyX, JMarc ?
I would absolutely vote for the addition of such a flag and get a natural UI to
that. Here we go.
Thanks for the input. BTW, do you still keep KLyX up-to-date with the
changes in LyX, or do you include only some specific fixes?
Well, I basically do not work on LyX nor KLyX at all :-( I try to follow the
development, try to get people that are willing to do some work started, and
also try to synchronize stuff somehow. That's difficult without coding, though.
PS: Nice idea, Daniel !
Greetings,
Jochen
---
Jochen K"upper
Heinrich-Heine-Universit"at D"usseldorf [EMAIL PROTECTED]
Institut f"ur Physikalische Chemie I
Universit"atsstr. 1, Geb 26.43 Raum 02.29phone ++49-211-8113681
40225 D"usseldorffax ++49-211-8115195
Germany http://www-public.rz.uni-duesseldorf.de/~jochen
---
=== cd /usr/src/lyx/lyx-1_0_x/src/
=== cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/lyxsrc/cvsroot diff -u lyxfr1.C
Index: lyxfr1.C
===
RCS file: /usr/local/lyxsrc/cvsroot/lyx-1_0_x/src/lyxfr1.C,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 lyxfr1.C
--- lyxfr1.C 1998/10/26 22:18:29 1.1.1.1
+++ lyxfr1.C 1999/01/08 16:30:06
@@ -163,6 +163,9 @@
current_view-currentBuffer()-text-
SetSelectionOverString(replacestring.c_str());
current_view-currentBuffer()-update(1);
+
+ // jump to next match:
+ SearchCB( searchForward );
}
@@ -170,6 +173,9 @@
{
LyXText *ltCur;
+ // store search direction
+ searchForward = fForward;
+
if (!current_view-getScreen())
return;
ReLyX directores [was: Re: reLyX.lyx doc!]
OK, thinking about the JMarc method of putting all lyx files we create in pwd (or -o dir)... There are a couple of different cases where we need to make sure you're not creating two LyX files with the same name. (1) a.tex includes foo/inc.tex and bar/inc.tex. So the LyX filenames we create ought to have something to differentiate two files with the same basename (as JMarc had previously mentioned). I had previously wanted to create a name like relyx_foo_inc.lyx and relyx_bar_inc.lyx. However, the Lyx file names could get extremely long that way. Why not just make them relyx_1_inc.lyx and relyx_2_inc.lyx? That way, we can't possibly write two copies of the same lyx file during one reLyX run. (2) a.tex includes foo/inc.tex, and b.tex includes bar/inc.tex. At one point, you run reLyX on a.tex. At some later time, you run reLyX on b.tex. Using the above methodology, both of these files will create relyx_1_inc.lyx. So let's put in the PID. then we'll have relyx_15342_1_inc.lyx and relyx_16234_1_inc.lyx, for example. These file names aren't *that* long, and we've ensured that the file names are safely unique. Now. I suspect that usually, the files a person \includes *will* be in the same directory, and it would be inconvenient always to have to rename those files from relyx_4324_1_inc.lyx to just inc.lyx. We know it's impossible to have two files with the same name in a directory, so if a.tex includes outputdir/inc.tex (where outputdir is the dir given with the -o option or is the directory of the original file (hm. what about the -p option?)) it seems safe to just change outputdir/inc.tex into outputdir/inc.lyx without any fancy prefix. Now, people would still have to rename those ugly long files. But the other option is to leave things the way they are, where if a file includes dir/foo.tex then you create dir/foo.lyx, which is a problem if you include a file in a read-only directory, for example. Seems like all of the options are kind of ugly. _Amir
Re: Find Replace change
On Fre, 08 Jan 1999 Daniel Naber wrote: Jean-Marc Lasgouttes wrote: I like the feature, but shouldn't it continue backwards if we were searching backwards? We should keep a bool saying in which direction the last search was, I think. I don't think searching backwards is that important. I have to admit I often use it (not only in (K)Lyx), but only to go back one position because I clicked too fast in forward search. Well, at least it keeps the Search/Replace facility consistent. Anyway, I'm trying to improve the dialog: -More feedback (status line: 'Not found'...) -'Replace All' Hey boy, you are pretty creative :-) Keep on going. Greetings, Jochen --- Jochen K"upper Heinrich-Heine-Universit"at D"usseldorf [EMAIL PROTECTED] Institut f"ur Physikalische Chemie I Universit"atsstr. 1, Geb 26.43 Raum 02.29phone ++49-211-8113681 40225 D"usseldorffax ++49-211-8115195 Germany http://www-public.rz.uni-duesseldorf.de/~jochen ---
new hollywood
This fixes the lower case issue and some spacing problems pointed out by Larry. JMarc, I tried moving preamble stuff from the preamble and .layout to .cls, but this screwed up the margins somehow. .cls is still a mystery to me. Thanks for the help and suggestions. -- Garst hollywood.tar.bz2
Re: Find Replace change
daniel dabbled, I don't think searching backwards is that important. I have to admit I often use it (not only in (K)Lyx), but only to go back one position because I clicked too fast in forward search. yikes! it's rather important, in figuring out where a word most recently came up (issues such as indexing), or where the current context for that word started . . . --
Re: slides
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> On Thu, 7 Jan 1999, Amir Karger wrote: >> Did anyone check John Weiss' slide patch in the docs (Mike)? How >> about in lyx-1_0_x/lib/layouts? Mike> Not me. I tend to ignore such things unless someone specifically Mike> says "Mike, please check this into the docs" since I do not have Mike> CVS access to anything but the lyxdoc area. Since the entire Mike> patch includes more than docs, one of our fearless developers Mike> should check it in. (Of course, I will check in the docs if one Mike> of those aforementioned fearless devies says "Mike, please check Mike> this into the docs" :-) I tried to commit it, but the various parts of the patch fail for some reason. So, until John sends me an updated version, nothing will happen. JMarc
Re: slides
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> btw, I *still* think that adding magenta, blue, cyan, and green Amir> is adding more colors you don't need. Why not make all slide Amir> stuff one color? Am I the only one uncomfortable with all these Amir> colors? Agreed. JMarc
Re: reLyX.lyx doc!
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> Then I though I could use the fancy new sgml utilities, but from Amir> discussions with José, it didn't sound very possible. José Amir> suggested, however, that it would be easy for a Perl expert Amir> (*blush* :) to modify pod2latex to output LyX Amir> instead. (Especially if that Perl expert knew how to convert Amir> latex to lyx!) Excellent idea! And I like the result. Amir> Well, I'm happy to report that I did a major hack job on Amir> pod2latex, and my pre-alpha version of pod2lyx actually works! Amir> Of course, I've been using it on reLyX.pod, so anything not Amir> included in that isn't supported. Nonetheless, it means I'm able Amir> to attach reLyX.lyx (gzipped). Which is legal LyX and produces Amir> legal LaTeX, which really surprises me. I wish I was so impressive I could impress myself. Amir> Do me a favor and take a look at it. Are there things I need to Amir> translate differently, or could we include it just like this in Amir> lyxdoc? Are there typos? Would it be possible to make it have a real title instead of this stupid first section? To have some of the text in tt font when necessary (even if it is not visible in the Man)? To avoid having UPPERCASE section titles. In short, I'd like to have the best of both worlds: a man page which looks like a man page, and a LyX document which looks like a document. Amir> I guess the only question now is whether it's better to continue Amir> editing it as a pod page or a LyX doc. I guess the answer is Amir> that José is going to have support for a "man page" linuxdoc Amir> (OK, I don't really know what that means) which means I"ll have Amir> the best of both worlds. I.e., we'll have a lyxdoc, but also be Amir> able to export a man page for someone to call if they're using Amir> reLyX from the command line. Great! Until a man page class exists, I think you should continue developping the pod version. Besides, having a pod2lyx script could appeal to perl hackers... in particular if we add pod support into LyX (how difficult would that be?). JMarc
Re: literate programming reviwed
> "Edmar" == Edmar Wienskoski <[EMAIL PROTECTED]> writes: Edmar> Here are the literate programming patches again. I did all the Edmar> requested modifications and put them in one single patch Edmar> (against pre6). I will go quickly over each one and tell what I Edmar> have modified from my original post. Thanks for the submission. I commited parts of those patches. First, I really like the quality of the patches and the way they integrate to LyX. I guess this was to be expected from somebody who uses web techniques ;) In fact, I did not took the parts which directly relate to litterate programming for two reasons: - it is a big change, that have to be properly documented and tested (although I trust your own tests on this one). I would not want to delay 1.0.0 for this and it could easily go into 1.0.1. - I am waiting a bit for Lars' decision on this one, since he is the main architext. Now for the details: >> 1 - The first patch is to allow the choice of the color of the >> new-line character. ... Obs: The default color is the same it is >> today. Edmar> This patch remains the same. I took this one. >> 2 - Patch to include new shortcut buttons in the toolbar. ... Obs: >> The customization of the toolbar itself is left to the user do in >> his/her lyxrc file. Thus, the toolbar defaults to its present >> looks. Edmar> This patch remains the same. This one is fine, but does not make sense until the rest is in. >> 3 - Patch to not output the protected space '~' during translation >> of latex paragraphs. ... Edmar> This patch remains the same. This one was already in. >> 4 - Patch to always produce "nice-latex" This one is good, but I did not take it because it depends on the rest. >> 5 - Patch to allow Item_Environment and Environment layouts to have >> a "dummy" latex command name Edmar> Eliminated. Fine. >> 6 - The addition of the Scrap layout to lyxmacros.inc Edmar> Not anymore... That's fine. Note that you should define OutputType after Inputing article.layout, since someone could decide to add 'OutputType latex' in there ;) Other than that, it looks fine to me. >> 7 - Patch to have different buttons and menu options for running >> latex, and building the code. The following new entries in the >> lyxrc are possible now: >> >> command: default: \web_command noweave -delay -index \web_extension >> .nw \web_error_filter cat \build_command make \build_error_filter >> cat Some comments: - could you write a short documentation about those in lyxrc? [something for the real docs about litterate programming would be nice too, but that's more work] - the default values for these commands should be "none" and the existence of the relevant programs should be tested in lib/configure (have a look at config/lib_configure.m4 to see how it works). If you have a problem with this, tell me what has to be tested for and I'll add it. The textclasses should be made available only if the program is found. - I am a bit worried that the 'web' name can be confusing for many users. Would it be possible to find another generic buzzword to describe that? Edmar> In summary, the only difference a plain text user will notice Edmar> in LyX is the new entry in the file menu: "Build Program". If Edmar> a user tries to execute it in a plain text document, a message Edmar> will pop up. (Other way would be to gray it out ...) It would be indeed better to grey it out when the buffer type is not Web or \web_command is "none". >> 8 - Patch to implement "server-goto-file-row" function >> Edmar> This patch remains the same. This one is in. For reference, I append to this message a copy of what remains from your patch. Since I edited that by hand, it is possible that I made mistakes... I took only 20% of it yet, but all will eventually go in, I guess. Oh, and I added you to the CREDITS file. JMarc wiensk-981227-pending.patch.gz
Re: Update of WHATSNEW
> "Rick" == Richard E Hawkins Esq <[EMAIL PROTECTED]> writes: Rick> - The word immediately prior to the cursor now appears as a Rick> default when inserting an index entry. An additional command Rick> exists to insert this word by keystroke and without a dialog Rick> box. Since we are not supposed to enter into details, I replaced this with: - easier handling of index entries. Is that alright for you? Oh, I also removed the authors names in the INSTALL file, since they do not make much sense now. JMarc
Re: back with the matrix dialog
> "Emmanuel" == Emmanuel GUREGHIAN <[EMAIL PROTECTED]> writes: Emmanuel> After making up my mind, I have tried to change the matrix Emmanuel> dialog in math_forms.fd in such a way that size does not Emmanuel> change. The side effect is that buttons are now on the Emmanuel> right. Hmm, I do not have any special thought about it. What do you people prefer? The old one with horizontal sliders or Emmanuel's version with a vertical rows slider? In any case, we should use similar solutions for the table and matrix popups. JMarc
Re: back with the matrix dialog
> > > "Emmanuel" == Emmanuel GUREGHIAN <[EMAIL PROTECTED]> writes: > > Emmanuel> After making up my mind, I have tried to change the matrix > Emmanuel> dialog in math_forms.fd in such a way that size does not > Emmanuel> change. The side effect is that buttons are now on the > Emmanuel> right. > > Hmm, I do not have any special thought about it. What do you people > prefer? The old one with horizontal sliders or Emmanuel's version with > a vertical rows slider? In any case, we should use similar solutions > for the table and matrix popups. I'd prefer exactly the same dialog for matrices as for tables. Probably because I've never understood the conceptional difference between matrices and tables... Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: back with the matrix dialog
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: >> Hmm, I do not have any special thought about it. What do you >> people prefer? The old one with horizontal sliders or Emmanuel's >> version with a vertical rows slider? In any case, we should use >> similar solutions for the table and matrix popups. Andre'> I'd prefer exactly the same dialog for matrices as for tables. Andre'> Probably because I've never understood the conceptional Andre'> difference between matrices and tables... There is no conceptual difference as far as LaTeX is concerned. However, the LyX implementations are completely separate. JMarc
Re: reLyX.lyx doc!
On Fri, Jan 08, 1999 at 08:55:02AM +0100, Jean-Marc Lasgouttes wrote: > > Excellent idea! And I like the result. Yay! > > I wish I was so impressive I could impress myself. Well, if you'd like, you can just be impressed by me instead. That will make two of us :) > Amir> Do me a favor and take a look at it. Are there things I need to > Amir> translate differently, or could we include it just like this in > Amir> lyxdoc? Are there typos? > > Would it be possible to make it have a real title instead of this > stupid first section? To have some of the text in tt font when > necessary (even if it is not visible in the Man)? To avoid having > UPPERCASE section titles. > > In short, I'd like to have the best of both worlds: a man page which > looks like a man page, and a LyX document which looks like a document. This is a great idea, and at least parts of it ought to be entirely possible. I definitely have various ideas for upgrading pod2lyx so that the resulting LyX file is more appropriate to LyX. Make the section names "ufirst" is a good example. Things we could do: - as you suggest, make the name of the pod file into the title. Hm. We could either use the actual name of the pod OR take the "NAME" section. The NAME section is required for conforming pod, so that should be safe. The only problem is that the title might be too long. Another option would be to make the NAME section into an Abstract---or compromise and make the actual program name into a \title and its description (anything following a - and whitespace) into an abstract. - add a table of contents. (Why not? It's essentially free if we use Section instead of Section*). Admittedly, you don't expect a table of contents in a man page, but I wish they had one in, say, the csh man page (26 pages)! - pod L<> references. pod2man turns L<"BUGS"> into "the BUGS section in elsewhere in this man page. We can do the same BUT we can create labels for each section, and then ADD A REFERENCE when translating the L<> to make it a hyperlink! - pod2latex automatically indexes every section & item. I turned that off but we could make it an option. (And there's an X<> pod thing to index anyway) -handle accents. I just realized that pod does, so I added the accent aigu (sp?) to the e and i in José Abílio. Etienne and David Suarez de Lis (and John Weiss :) should let me know if they have latin1 accents in their names, too. Anyway, "man" doesn't support it but lyx does, so we could translate that too. (pod2latex already does this, so it should be easy) - other ideas? I'm in excited to be coding mode now, so now's the time for feature requests :) > Until a man page class exists, I think you should continue developping > the pod version. Besides, having a pod2lyx script could appeal to perl > hackers... in particular if we add pod support into LyX (how difficult > would that be?). I would think that José could make linuxdoc/docbook output this pretty easily, since it's similar to man/html sorts of things and very simple. I agree that this could be useful to perl hackers, especially if we make the pod2lyx and lyx2pod translations trivial. Then you could write docs in LyX, without needing to remember the fancy escape characters, and output pod, which is the extremely portable perl standard. Or output man/html/text straight from lyx instead of going through pod. Neat! -Amir
Re: back with the matrix dialog
> Andre'> I'd prefer exactly the same dialog for matrices as for tables. > Andre'> Probably because I've never understood the conceptional > Andre'> difference between matrices and tables... > > There is no conceptual difference as far as LaTeX is > concerned. However, the LyX implementations are completely separate. Why? Why does LyX introduce a difference, when there is none on the LaTeX-level? Why do I have to learn to use two different dialog to do basically the same thing? Why can't we just use the table dialog for both cases? Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: Bug, lyx1pre6, resizing window
At 12:07 PM 1/7/99 +0100, you wrote: >Steven> somewhat unusual port (I ported LyX to Windows NT using the >Steven> Cygwin library), I would like to know if others have the same >Steven> problem. >Interesting. Did you need to change things to make it work? Several things. However, I tried to compile it using the latest version of the Cygwin library and always all the problems disappeared. Only the fact that Cygwin does not support mkfifo remains. Unfortunately, I didn't get the ports voor Xlib and Xforms right, so I didn't actually see anything. I do not have time to look into it now. You (and Roland and Berhard as well) can check out my LyX-page for the port: http://www.cs.uu.nl/~steven/lyx.html . It currently shows pre4. >Steven> bitmaps and not by explicitly redrawing the screen. When I >Steven> scroll up and down, I can see the bitmap of the overlapping >Steven> window again. >I would say this is a problem with your X server or the xforms >port. What server are you using? I use Exceed. Dag, Steven --- (http://www.cs.uu.nl/staff/steven.html)
Re: Bug, lyx1pre6, resizing window
At 12:54 PM 1/7/99 +0100, you wrote: >[problems with refresh and overlapping windows.] >> I would say this is a problem with your X server or the xforms >> port. What server are you using? >Actually, this bug is a feature. >We changed it to be like this in order to have fast, fast redraws. >Of course, on WinNt, this is not the case, so maybe we should make this >behaviour conditional? If the screen update slows down, it is probably not worth it. It is very predictable behaviour, so it more convenient to just avoid resizing overlapping windows. It wouldn't hurt to make it conditional of course... Dag, Steven --- (http://www.cs.uu.nl/staff/steven.html)
Re: back with the matrix dialog
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: >> Andre'> I'd prefer exactly the same dialog for matrices as for >> tables. Andre'> Probably because I've never understood the >> conceptional Andre'> difference between matrices and tables... >> >> There is no conceptual difference as far as LaTeX is >> concerned. However, the LyX implementations are completely >> separate. Andre'> Why? Andre'> Why does LyX introduce a difference, when there is none on the Andre'> LaTeX-level? The code is not the same, was written by different people at different times and does not have the same features. Does that answer your question? ;) Andre'> Why do I have to learn to use two different dialog to do Andre'> basically the same thing? Andre'> Why can't we just use the table dialog for both cases? *Maybe* will it be possible in LyX 1.1 to use the same inset for tables and matrices. But don't hold your breath... JMarc
Re: Bug, lyx1pre6, resizing window
> "Steven" == Steven van Dijk <[EMAIL PROTECTED]> writes: Steven> At 12:07 PM 1/7/99 +0100, you wrote: somewhat unusual port (I Steven> ported LyX to Windows NT using the Cygwin library), I would Steven> like to know if others have the same problem. >> Interesting. Did you need to change things to make it work? Steven> Several things. However, I tried to compile it using the Steven> latest version of the Cygwin library and always all the Steven> problems disappeared. Only the fact that Cygwin does not Steven> support mkfifo remains. Unfortunately, I didn't get the ports Steven> voor Xlib and Xforms right, so I didn't actually see Steven> anything. I do not have time to look into it now. Steven> You (and Roland and Berhard as well) can check out my LyX-page Steven> for the port: http://www.cs.uu.nl/~steven/lyx.html . It Steven> currently shows pre4. That's pretty interesting. I guess that switching to autoconf 2.13 should fix several of your problems with suffixes. Other than that, with the appropriate updates to cygwin (assuming they fix it soon), we could add support for winNt in LyX pretty easily. It seems almost easier than in OS/2, since you do not have all the problems with file names. Congratulations. JMarc
Re: reLyX.lyx doc!
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> This is a great idea, and at least parts of it ought to be Amir> entirely possible. I definitely have various ideas for Amir> upgrading pod2lyx so that the resulting LyX file is more Amir> appropriate to LyX. Make the section names "ufirst" is a good Amir> example. Things we could do: [...lots of good ideas...] Amir> - other ideas? I'm in excited to be coding mode now, so now's Amir> the time for feature requests :) And what about reLyX? JMarc PS: to reward to from your hard work, not that I took care of removing your name from the To: field, so that you get only one copy of this otherwise very interesting message.
Re: Update of WHATSNEW
> Since we are not supposed to enter into details, I replaced this with: > - easier handling of index entries. sounds good to me. I just figure that it's important enough to add, as it was one of the things that used to irritate me, and I'd assume lot's of others. But then again, I want to file bugs against cat, mkdir, and rmdir, as commands this important should have two letter names :) Rick, the keystroke reduction junkie --
Re: back with the matrix dialog
> The code is not the same, was written by different people at different > times and does not have the same features. Does that answer your > question? ;) No ;-) It was merely a 'leading question' hoping to see one day the same dialog in both places. > *Maybe* will it be possible in LyX 1.1 to use the same inset for > tables and matrices. But don't hold your breath... Oki, I hold my breath ;---) Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: Find & Replace change
> "Jochen" == Jochen Kuepper <[EMAIL PROTECTED]> writes: Jochen> Hi, Daniel Naber send in a patch to KLyX to find forward on Jochen> each replace in the Find dialog. We sent that patch to Jochen> Matthias to judge wether we want to put it in or not. ( It Jochen> seems he is still thinking :-) Jochen> What do you think about that feature ? I like the feature, but shouldn't it continue backwards if we were searching backwards? We should keep a bool saying in which direction the last search was, I think. Thanks for the input. BTW, do you still keep KLyX up-to-date with the changes in LyX, or do you include only some specific fixes? Just to know. JMarc
Editing in Table->Extra
Hi all, I'm not sure if it's a problem of our local installation, so maybe you could check this: If I want to use special table layout formats using the Table->Extra dialogbox, the editing of the input field is broken: Typing text is ok, but when I move the cursor to some point inside the line and type a character there, *after* inserting the character (or deleting one, if I pressed DELETE) the cursor position is set at the end of the line. It seems not XForms related, as other input fields work OK. Peter -- ~~ Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit Universitaets-Sternwarte Goettingen Tel.: +49 551 39-5048 [EMAIL PROTECTED] -- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- Come and see the stars! http://www.kis.uni-freiburg.de/~ps/SFB Sternfreunde Breisgau e.V. Tel.: +49 7641 3492 __
Re: reLyX.lyx doc!
On Fri, Jan 08, 1999 at 05:03:05PM +0100, Jean-Marc Lasgouttes wrote:
>
> Amir> - other ideas? I'm in excited to be coding mode now, so now's
> Amir> the time for feature requests :)
>
> And what about reLyX?
Humph. I recently found out that reLyX can't find \include'd files if you run
reLyX on a file not in the current directory. For example:
reLyX dir/foo.tex
if foo has "\include{bar}" then reLyX looks for bar in the current directory,
not in dir. That's dumb! Unfortunately, the solution isn't trivial, since e.g.
an included file might have another included file. In addition, there's the
whole mess of the new -o option to consider. It means the argument to the
\include command may be very different from the actual file you're including.
My current idea for a fix is to chdir my way around so that the file we're
reLyXing is always in the current directory. This may not be the best
solution. For example, how slow is changing directories?
There's a perl module that turns relative path names into absolute ones and
vice versa. However, I can't use it because it's not in the standard perl
distribution. I might steal ideas from it, though.
> PS: to reward to from your hard work, not that I took care of removing
> your name from the To: field, so that you get only one copy of this
> otherwise very interesting message.
I'm so grateful! Maybe I'll send an extra copy of this message to show that my
gratitude can't fit in just one message.
-Amir
Re: reLyX.lyx doc!
Amir Karger wrote: > > On Fri, Jan 08, 1999 at 08:55:02AM +0100, Jean-Marc Lasgouttes wrote: > > I would think that José could make linuxdoc/docbook output this pretty easily, > since it's similar to man/html sorts of things and very simple. The support for manpages in linuxdoc is an workaround (read hack) but it works, the problem with sgmltools 2.0 is that there aren't any groff or nroff backend. linuxdoc will be insuported , Cees declared that. The present implementation of manpages doesn't allow 2 sections levels, as you use it in pod (I have read the reLyX manpage so I know that), would you (Amir) like to have such a support? It is easy to have it (a one line patch). The other thing that the manpage model doesn't support are references (both internal and external), again it is a one line patch to solve this. Since the changes are so small I will request to Cees to incorporate it in the next realease of sgmltools 1.0.x (probably the last). The code generation will require an hack to support the manpages (since their support behaves differently from the other elements in linuxdoc), the problem is the the title manipulation, the same problem that Amir has now. So all the Intitle layouts will be manipulated in a different way from the other layouts... > I agree that this could be useful to perl hackers, especially if we make the > pod2lyx and lyx2pod translations trivial. Then you could write docs in LyX, > without needing to remember the fancy escape characters, and output pod, which > is the extremely portable perl standard. Or output man/html/text straight from > lyx instead of going through pod. Neat! > > -Amir -- José Abílio de Oliveira Matos ~ I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!!
Re: reLyX.lyx doc!
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes:
Amir> Humph. I recently found out that reLyX can't find \include'd
Amir> files if you run reLyX on a file not in the current
Amir> directory. For example: reLyX dir/foo.tex if foo has
Amir> "\include{bar}" then reLyX looks for bar in the current
Amir> directory, not in dir.
If the name has been given as dir/foo.tex and no -o option has been
given, you can do something like
outdir=`pwd`
cd dir/
do the usual stuff as if -o outdir had been specified.
If -o has been specified, make sure you turn the out spec to an
absolute path, and then cd dir/ and then do the usual stuff.
I am sure there are problems with this approach, but I do not see them
right now.
JMarc
Re: Editing in Table->Extra
> "Peter" == Peter Suetterlin <[EMAIL PROTECTED]> writes: Peter> Hi all, Peter> I'm not sure if it's a problem of our local installation, so Peter> maybe you could check this: Peter> If I want to use special table layout formats using the Peter> Table->Extra dialogbox, the editing of the input field is Peter> broken: Typing text is ok, but when I move the cursor to some Peter> point inside the line and type a character there, *after* Peter> inserting the character (or deleting one, if I pressed DELETE) Peter> the cursor position is set at the end of the line. I can confirm that. Maybe this is some kind of clever hack from Juergen that turned out to be a bad idea... [I can safely badmouth him, he is not here to defend himself. Ha!] Inspecting the code it turns out that there is a callback on this input field, which is maybe the reason why the entering of characters is interrupted. Since the bug is benign and the 'fix' could be devastating, I propose that we just document it :) JMarc
Re: Find & Replace change
On Fre, 08 Jan 1999 Jean-Marc Lasgouttes wrote:
>> "Jochen" == Jochen Kuepper <[EMAIL PROTECTED]> writes:
>
>Jochen> Hi, Daniel Naber send in a patch to KLyX to find forward on
>Jochen> each replace in the Find dialog. We sent that patch to
>Jochen> Matthias to judge wether we want to put it in or not. ( It
>Jochen> seems he is still thinking :-)
>
>Jochen> What do you think about that feature ?
>
>I like the feature, but shouldn't it continue backwards if we were
>searching backwards? We should keep a bool saying in which direction
>the last search was, I think.
Hey, yeah, this is why I wasn't that enthusiastic, but I was to rigid to find
your easy solution. Here we go !
So what's about the patch I appended - it does exactly that. It's against
lyx-1_0_x repository ?
If we agree, I would put it into KLyX, you into LyX, JMarc ?
I would absolutely vote for the addition of such a flag and get a natural UI to
that. Here we go.
>Thanks for the input. BTW, do you still keep KLyX up-to-date with the
>changes in LyX, or do you include only some specific fixes?
Well, I basically do not work on LyX nor KLyX at all :-( I try to follow the
development, try to get people that are willing to do some work started, and
also try to synchronize stuff somehow. That's difficult without coding, though.
PS: Nice idea, Daniel !
Greetings,
Jochen
---
Jochen K"upper
Heinrich-Heine-Universit"at D"usseldorf [EMAIL PROTECTED]
Institut f"ur Physikalische Chemie I
Universit"atsstr. 1, Geb 26.43 Raum 02.29phone ++49-211-8113681
40225 D"usseldorffax ++49-211-8115195
Germany http://www-public.rz.uni-duesseldorf.de/~jochen
---
=== cd /usr/src/lyx/lyx-1_0_x/src/
=== cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/lyxsrc/cvsroot diff -u lyxfr1.C
Index: lyxfr1.C
===
RCS file: /usr/local/lyxsrc/cvsroot/lyx-1_0_x/src/lyxfr1.C,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 lyxfr1.C
--- lyxfr1.C 1998/10/26 22:18:29 1.1.1.1
+++ lyxfr1.C 1999/01/08 16:30:06
@@ -163,6 +163,9 @@
current_view->currentBuffer()->text->
SetSelectionOverString(replacestring.c_str());
current_view->currentBuffer()->update(1);
+
+ // jump to next match:
+ SearchCB( searchForward );
}
@@ -170,6 +173,9 @@
{
LyXText *ltCur;
+ // store search direction
+ searchForward = fForward;
+
if (!current_view->getScreen())
return;
ReLyX directores [was: Re: reLyX.lyx doc!]
OK, thinking about the JMarc method of putting all lyx files we create in pwd (or -o dir)... There are a couple of different cases where we need to make sure you're not creating two LyX files with the same name. (1) a.tex includes foo/inc.tex and bar/inc.tex. So the LyX filenames we create ought to have something to differentiate two files with the same basename (as JMarc had previously mentioned). I had previously wanted to create a name like relyx_foo_inc.lyx and relyx_bar_inc.lyx. However, the Lyx file names could get extremely long that way. Why not just make them relyx_1_inc.lyx and relyx_2_inc.lyx? That way, we can't possibly write two copies of the same lyx file during one reLyX run. (2) a.tex includes foo/inc.tex, and b.tex includes bar/inc.tex. At one point, you run reLyX on a.tex. At some later time, you run reLyX on b.tex. Using the above methodology, both of these files will create relyx_1_inc.lyx. So let's put in the PID. then we'll have relyx_15342_1_inc.lyx and relyx_16234_1_inc.lyx, for example. These file names aren't *that* long, and we've ensured that the file names are safely unique. Now. I suspect that usually, the files a person \includes *will* be in the same directory, and it would be inconvenient always to have to rename those files from relyx_4324_1_inc.lyx to just inc.lyx. We know it's impossible to have two files with the same name in a directory, so if a.tex includes outputdir/inc.tex (where outputdir is the dir given with the -o option or is the directory of the original file (hm. what about the -p option?)) it seems safe to just change outputdir/inc.tex into outputdir/inc.lyx without any fancy prefix. Now, people would still have to rename those ugly long files. But the other option is to leave things the way they are, where if a file includes dir/foo.tex then you create dir/foo.lyx, which is a problem if you include a file in a read-only directory, for example. Seems like all of the options are kind of ugly. _Amir
Re: Find & Replace change
On Fre, 08 Jan 1999 Daniel Naber wrote: >Jean-Marc Lasgouttes wrote: > >> I like the feature, but shouldn't it continue backwards if we were >> searching backwards? We should keep a bool saying in which direction >> the last search was, I think. > >I don't think searching backwards is that important. I have to admit I >often use it (not only in (K)Lyx), but only to go back one position >because I clicked too fast in forward search. Well, at least it keeps the Search/Replace facility consistent. >Anyway, I'm trying to improve the dialog: >-More feedback (status line: 'Not found'...) >-'Replace All' Hey boy, you are pretty creative :-) Keep on going. Greetings, Jochen --- Jochen K"upper Heinrich-Heine-Universit"at D"usseldorf [EMAIL PROTECTED] Institut f"ur Physikalische Chemie I Universit"atsstr. 1, Geb 26.43 Raum 02.29phone ++49-211-8113681 40225 D"usseldorffax ++49-211-8115195 Germany http://www-public.rz.uni-duesseldorf.de/~jochen ---
new hollywood
This fixes the lower case issue and some spacing problems pointed out by Larry. JMarc, I tried moving preamble stuff from the preamble and .layout to .cls, but this screwed up the margins somehow. .cls is still a mystery to me. Thanks for the help and suggestions. -- Garst hollywood.tar.bz2
Re: Find & Replace change
daniel dabbled, > I don't think searching backwards is that important. I have to admit I > often use it (not only in (K)Lyx), but only to go back one position > because I clicked too fast in forward search. yikes! it's rather important, in figuring out where a word most recently came up (issues such as indexing), or where the current context for that word started . . . --
