Re: dotfill,hrulefill status open behavior
"Lars Gullik Bjønnes" wrote: "Garst R. Reese" [EMAIL PROTECTED] writes: | I'll start with the open behavior. | I click open and give a new file name. LyX asks if it wants to create | the new file and I answer yes. I later try to save the file and it asks | for a file name. | I enter the same file name that I entered before. LyX saves the file in | /home/garst instead of /home/garst/lyxdocs which is specifed in my | lyxrc. Is this your code playing tricks on us Jürgen? Or it is something older/else? | I think Lars was working on adding dotfill and hrulefill to the insert | special character menu. I looked at it... but it really involves a bit more than just the menu... Lgb I figure as much :( Just checked the file open problem again. Seems to be fixed. Thanks Júrgen. Garst
Re: [PATCH] hollywood.cls
On Thu, 14 Sep 2000, Garst R. Reese wrote: One of our users has made some well researched suggestions for changes to the hollywood.cls file. The diff from cvs -N -u is attached, including the Changelog. Can you do a 'make clean' in src/frontends/xforms/forms before running make in $topsrc. That will avoid having all the extra *.[Ch] files added to POTFILES.in from that directory. In the meanwhile we need to change the autogen.sh script to exclude those files when rebuilding POTFILES.IN. I've been thinking we should either use a Makefile target and let make rebuild it whenever we add/remove files or maybe make use of the .cvsignore files to exclude some files from the building of POTFILES.IN. Simply searching for all the *.[Ch] files isn't good enough. Allan. (ARRae)
Re: dotfill,hrulefill status open behavior
Just checked the file open problem again. Seems to be fixed. Thanks Júrgen. #:O) Thanks to you for all your reports!!! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If you can't understand it, it is intuitively obvious.
RE: [PATCH] KDE FormRef
On 13-Sep-2000 John Levon wrote: On Wed, 13 Sep 2000, Juergen Vigna wrote: There is still the Changelog missing in the diff-file please resubmit! sorry, I thought it was as other projects, where the changelog doesn't go in the diff so there's not syncing problems between patches. New one with Changelog diff included. Sorry to be a bother ;) #:O) Applied and commited! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Reality is just a convenient measure of complexity. -- Alvy Ray Smith
Re: class_choice - combo_class
On 13-Sep-2000 Jean-Marc Lasgouttes wrote: "Juergen" == Juergen Vigna [EMAIL PROTECTED] writes: Juergen Now I've a problem, when I select a new class I get a Juergen question from the system if I want also change the layouts of Juergen paragraphs. Now the combox did a mouse-grab so I'm not able Juergen to click with the mouse on the yes/no buttons (i use kb-y)! Isn't it possible to close the combox before changing the layout? Well you are in the callback of the combox how would you do that? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ ...when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. - Fred Brooks, Jr.
Re: SIGSEGV signal caught
"Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan Anyone have a problem with me adding this as lyx-devel/BUGS? Allan I'll add a bit more as well. Check out also the stuff which is in BUGS.lyx. BUGS.lyx has the advantage to be easy to find for anybody (since BUGS will be only in the source distribution), but it cannot be read if you cannot run LyX :( JMarc PS: the LDN is very good.
Re: class_choice - combo_class
"Juergen" == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 13-Sep-2000 Jean-Marc Lasgouttes wrote: "Juergen" == Juergen Vigna [EMAIL PROTECTED] writes: Juergen Now I've a problem, when I select a new class I get a Juergen question from the system if I want also change the layouts of Juergen paragraphs. Now the combox did a mouse-grab so I'm not able Juergen to click with the mouse on the yes/no buttons (i use kb-y)! Isn't it possible to close the combox before changing the layout? Juergen Well you are in the callback of the combox how would you do Juergen that? And would it make sense to change Combox so that the callback is called _after_ closing the list? JMarc PS: no, I do not now what I am talking about :)
Re: class_choice - combo_class
And would it make sense to change Combox so that the callback is called _after_ closing the list? Could be an idea I'll have a look! PS: no, I do not now what I am talking about :) Well mee too ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ One learns to itch where one can scratch. -- Ernest Bramah
Re: [PATCH] KDE FormToc cleanup
On Wed, 13 Sep 2000, Dekel Tsur wrote: On Wed, Sep 13, 2000 at 11:27:40AM +0200, Juergen Vigna wrote: On 13-Sep-2000 John Levon wrote: I should get some sleep :/ I forgot in my former mail: GOOD WORK!!! I like the new look of the KDE-TOC-DIALOG!!! The Klyx TOC dialog is a little bit nicer (e.g. the ability to select a depth threshold). John, why aren't you reusing code from Klyx ? That's an incredibly good question. I suppose I thought that LyX might have changed too much inbetween, but I suppose a lot of it will still be useful. I have a source tarball at home, I should dig it out ! john -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
Re: [PATCH] KDE FormRef
On Thu, 14 Sep 2000, Allan Rae wrote: On Wed, 13 Sep 2000, John Levon wrote: This is 95%, as there is still a big hole when we edit an existing crossref, and we hide the refs list. It seems difficult to get Qt to redo the layout, and remove the widget Just disable it then. You don't have to make the KDE port work and look just like the XForms port does. Allan. (ARRae) Well, it just looked a bit funny because there's no real hint when it's disabled. I'll play with it more later. thanks john -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
Gnome Menubar update
Hi! this patch adds TOC and *Formats menu items to the Gnome menubar implementation. TOC menu updates itself automatically using the ListsTracker class. The current implementation doesn't support large TOCs and you can't manage your references via Gnome menu yet. However, the current implementation is easily extendable to show LOT, LOF, and LOA as soon as LyX Menu will support these lists. Marko gnomemenu.patch.gz
Re: new lyx
Andre Poenitz [EMAIL PROTECTED] writes: | | Have you tried to use it together with lyxstring? | | No, I haven't had much time for playing around lately, | so I used it only in my own project (due 2000/09/30 *sigh*) Ok, I have tested it with lyxstring. Only one small thing needed fixing. I also had to remove the dynamic_casts (replaced with static_cast) With gcc 2.95.2 I have no problem with LyX with or witout lyxstring and this sstream. I will commit this so that we can see wat other problems arises. Lgb
[Edmar Wienskoski Jr edmar-w-jr@technologist.com] LyX/Literate programming bug report and fix
Hi Lars. I worked on the literate programming extension for LyX a while back (LyX-1.0.1). Unfortunately political trends here at my job shifted and it is a long time I don't have opportunity to use this feature. Then, on July one guy sent me email saying it was broken. In fact it was, but it is a small thing: If you get compilation errors, the errors were not shown on the document. (The reason this bug was introduced is that the parsing of the latex log file changed, and the corresponding parsing routine for literate programming building process were not.) He told me he was going to fix it. But last week I downloaded the latest version of LyX, and this problem was still there. So I fixed it myself. The fix was easy, mostly cut and paste from scanLogFile LaTeX routine into scanLiterateLogFile. My question is how we submit patches nowadays. I couldn't find the familiar script to diff two source trees... (Yeah, it's being a long time...) Anyway... If you forgive me the abuse, I am enclosing a tar file with the 3 files that I changed (based on the 1.1.5fix1 release): lib/examples/Literate.lyx src/Literate.C src/Literate.h Would you integrate these changes for me ? Thanks Edmar W. Jr. -- /*--*/ /* Edmar Wienskoski Jr. - [EMAIL PROTECTED] */ /* - http://www.cs.rice.edu/~wiensk */ /*--*/ | [] | __()_||_ ---++--- | [] | | | | | | | | | | | ___| | |_|__|_| |__| |__| |__| |__\ "o-o o-o""o-o o-o""o-o o-o""o-o o-o""o-o O-O-O o-o " litfix.tar.gz
siamltex.layout
I put a .layout file for the siamltex class (SIAM = Society for Industrial and Applied Mathematics) under http://mathematik.htwm.de/tmp/siamltex.layout This fits more or less to Paul Duggan's LaTeX class found e.g. under ftp://ftp.dante.de/tex-archive/macros/latex/contrib/other/siam/siamltex.tar It's the first shot at a .layout over here, so maybe someone more experienced would comment ;-) Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: I'm back, take 2 :)
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars | Lars does not | want to have M-m bindings which are not real
| Lars menu bindings. I'd be | surprised if people like it %-]
|
| Lars What is the problem with changing it to "C-m {"?
|
| I don't know yet. Someone has to review all the bindings and see how
| to change them.
|
| OK, C-m is already
|
| - mark-toggle (what's that??) in (x)emacs
|
| - math-mode in others.
|
| - "menu-open Matemático" in portuguese menus (why?).
This sould be removed anyway. Menus are not opened by bindings any
more, but by menu shortcuts.
| I do not know whether thes toggles matter or not.
Other options is to use:
C-c C-m or C-c m
We cannot expect to solve al binding by just one indirecton.
Lgb
Re: the Window Name
"Paolo" == Paolo M Pumilia [EMAIL PROTECTED] writes: From Jean-Marc Lasgouttes, Wed Sep 13, at 12:31: | "Paolo" == Paolo M Pumilia [EMAIL PROTECTED] writes: |Paolo I noticed that the name of the window hosting my LyX editing |Paolo session has the form 'LyX: filename', that is the path to the |Paolo opened filename has been discarded. E.g., entering the command |Paolo % /usr/bin/X11/lyx Notes/file1.lyx spawns a window with name |Paolo 'LyX: file1.lyx' open |Paolo Is there a way to preserve in the window name the original |Paolo argument passed along with the command? |Do you mean exactly the argument entered or rather have the |full path .to the file? Paolo preserving the full path would be enough for what i am trying Paolo to do: manage open lyx files depending on the directory they Paolo reside. OK, it is pretty easy to have the full (nice) file name in the title bar. Are there people who find it is a bad idea? Otherwise, I'll just do it. JMarc
Re: [PATCH] hollywood.cls
"Garst" == Garst R Reese [EMAIL PROTECTED] writes: Garst One of our users has made some well researched suggestions for Garst changes to the hollywood.cls file. The diff from cvs -N -u is Garst attached, including the Changelog. Thanks, I'll commit it (in the 1.1.5 branch too). JMarc
Re: I'm back, take 2 :)
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars | Lars does not | want to have M-m bindings which are not real
Lars menu bindings. I'd be | surprised if people like it %-]
Lars What is the problem with changing it to "C-m {"?
I don't know yet. Someone has to review all the bindings and see how
to change them.
OK, C-m is already
- mark-toggle (what's that??) in (x)emacs
- math-mode in others.
- "menu-open Matemático" in portuguese menus (why?).
I do not know whether thes toggles matter or not.
JMarc
Re: NEW_INSETS (was Re: [PATCH] Fix KDE Citation thinko)
"John" == John Levon [EMAIL PROTECTED] writes: John So l[TOC_LOF] et al are never filled What am I missing ? With new insets, floats are moved to a new inset structure, so the code should be rewritten to handle these float insets. JMarc
Sun i18n code goes open source!
It is already Friday here in Japan. But I presume it is still not for most of you, and I hope it all right for me to turn down all the objections I've expressed here towards Dekel Tsur's efforts for the LyX internationalization instead of accusing him further. Today Sun Microsystems is supposed to release their i18n technology open source to X org: http://www.sun.com/smi/Press/sunflash/2000-08/sunflash.2829.1.html Among other things is IIIMF an Input Method Framework which enable an X client to connect to (possibly multiple) Input Method Server(s) of different locale(s) than that of the process. --Remember, unlike C++, C process has only one locale object-- If this technology becomes a commonality which is widely available, not only on XFree86, then my argument against Dekel's effort will lose the ground. I had proceeded as thus: - some languages, especially Japanese and Korean, requires very sophisticated language engines to be input, which unlike keymaps are obviously too complicated and large to bundle with LyX; - currently X allows an X client to connect to an IM server which may in turn connect to language engines, but only in the process locale (LC_CTYPE) of the client; - so, for such languages, the process locale of LyX and the document language to be edited must be the same; - for CJK which employs thousands of glyphs, a Unicode based text drawing will be inefficient and very complicated (bug prone) unless Unicode fonts are availble; - Unicode CJK fonts are cheaply available only in bitmap (not scalable) and TrueType (not widely supported on X) formats; - then, since the process and the document locale must coincide for such languages, why don't you use the Xlib built-in locale based text drawing method rather than reinventing the wheel in an inefficient Unicode based manner; Dekel already had answered that the point 4 will not count once we adopt to use FreeType for better rendering. Now the points 2, 3, and 6 will no longer be true. What do you think? Regards, SMiyata
Re: the Window Name
"John" == John Levon [EMAIL PROTECTED] writes: John On 14 Sep 2000, Jean-Marc Lasgouttes wrote: OK, it is pretty easy to have the full (nice) file name in the title bar. Are there people who find it is a bad idea? Otherwise, I'll just do it. John I assume you just mean the relative path not the full path yes ? Relative to what? This is the full path, but shortened to begin with "~/" if in your home directory. Of course, this will not look nice for documentation... Ideas? JMarc
Re: the Window Name
On 14 Sep 2000, Jean-Marc Lasgouttes wrote: John I assume you just mean the relative path not the full path yes ? Relative to what? This is the full path, but shortened to begin with "~/" if in your home directory. Of course, this will not look nice for documentation... Ideas? JMarc That was indeed my concern :) this can also be a problem if you're not working from your home dir. I can see this happening a lot (personally when I used to do collab work, rather than sanely using CVS or similar, we just all worked on an exported NFS share with a *long* path). Maybe you can make this an option ? I can't think of any way of reliably knowing when the user won't be able to see the end of the path string in the titlebar :/ I would suggest to default to full/relative path on a certain length, otherwise just filename, so the standard thing can get 95% of the cases right. What do you think ? thanks john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming
Re: I'm back, take 2 :)
On Thu, Sep 14, 2000 at 04:48:37PM +0200, Lars Gullik Bjnnes wrote:
Other options is to use:
C-c C-m or C-c m
We cannot expect to solve al binding by just one indirecton.
Why not put more items in the math menu ?
E.g.
Menu "math"
...
Item "Delim ()|(" "math-delim ( )"
We can then use the old key bindings.
Re: [PATCH] KDE FormRef
On Thu, Sep 14, 2000 at 01:14:06PM +0100, John Levon wrote: On Thu, 14 Sep 2000, Allan Rae wrote: On Wed, 13 Sep 2000, John Levon wrote: This is 95%, as there is still a big hole when we edit an existing crossref, and we hide the refs list. It seems difficult to get Qt to redo the layout, and remove the widget Just disable it then. You don't have to make the KDE port work and look just like the XForms port does. Allan. (ARRae) Well, it just looked a bit funny because there's no real hint when it's disabled. I'll play with it more later. Why not show the labels list when editing a reference, so you will be able to change an existing ref?
Re: Comments Notes in LyX
On Wed, Sep 13, 2000 at 08:44:13PM +0200, Gaillard Pierre-Olivier wrote:
I am currently in the process of replacing Interleaf (a big publishing
package like Framemaker) with LyX/Latex.
I have managed to write a Python program that converts our Interleaf
documents . This convinced a few of my coworkers that LyX is a great
choice since editing in LyX is more intuitive than in Interleaf
(bibliography and indexes are really better).
Cool!
- XML format. this is not a real problem since I have shown that a basic
utility to write LyX files could be written in less than one day. I
think they will trust me if I say that we could export our LyX files to
some XML format in a few day. Anyway I really think that the current
format is strange ('end float' is not the same as 'end float ' !!) and
XML would be an EASY and FASHIONABLE replacement.
You are not alone in thinking this; it comes up frequently (I proposed
it once). There is quite a high level of support for the general idea,
but the core developers don't see it as a high priority --- so it's
most likely to happen if some interested third-party (like me, if I
had more time) does the grunt work!
Jules
Re: I'm back, take 2 :)
Other options is to use: C-c C-m or C-c m Too long. Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: I'm back, take 2 :)
dekel deklared,
On Thu, Sep 14, 2000 at 04:48:37PM +0200, Lars Gullik Bjønnes wrote:
Other options is to use:
C-c C-m or C-c m
We cannot expect to solve al binding by just one indirecton.
Why not put more items in the math menu ?
E.g.
Menu "math"
...
Item "Delim ()|(" "math-delim ( )"
We can then use the old key bindings.
There's *way* too many math bindings for that :)
However, it occurs to me that the last several used from the math
panel might be nice, as with the last several files in the file panel.
What we really need to keep in mind is that keystrokes count--three
keys for commonly used math is way to many.
hawk
--
Re: [PATCH] hollywood.cls
Allan Rae wrote: On Thu, 14 Sep 2000, Garst R. Reese wrote: One of our users has made some well researched suggestions for changes to the hollywood.cls file. The diff from cvs -N -u is attached, including the Changelog. Can you do a 'make clean' in src/frontends/xforms/forms before running make in $topsrc. That will avoid having all the extra *.[Ch] files added to POTFILES.in from that directory. In the meanwhile we need to change the autogen.sh script to exclude those files when rebuilding POTFILES.IN. I've been thinking we should either use a Makefile target and let make rebuild it whenever we add/remove files or maybe make use of the .cvsignore files to exclude some files from the building of POTFILES.IN. Simply searching for all the *.[Ch] files isn't good enough. Allan. (ARRae) No problem. I knew something was remiss when the first diff I made include stuff from POTFILES.IN. I figured it was generated by autogen.sh, so moved it out of the way and did another diff. BTW, I was impressed by how polite you were to the guy/gal who sent the core file. Garst
Re: I'm back, take 2 :)
Andre Poenitz [EMAIL PROTECTED] writes: | Other options is to use: | | C-c C-m or C-c m | | Too long. Say that to thousends of emacs users. It is only in your mind. Lgb
new sstream + lots of small other things
I have committed my latest stuff. this might break some compiler libraries, but I hope the chances for that are slim. I am put the sstream posted to this list into use, and on gcc 2.95.2 it works fine with both lyxstring and the string class included with gcc 2.95.2. I have changed most non-pod return to return a const object, this avoid spurrius changes to temporary object and is in most cases a lot nicer (with a potential speedup) please try the current cvs out and report all problems releated to this checkin. Lgb
Lost math bindings
OK, maybe it's late for me to be getting into this discussion. But I just
tried to play with the new LyX (now that I can compile it) and realized how
annoying it was not to have the math bindings any more.
I'll also note that noone created the layout.bind that Lars suggested, so
the paragraph layout stuff isn't there any more. Nor are the character
changing commands.
Lars seems to be saying that if something isn't in the menu, it shouldn't
have an Alt- keyboard shortcut. I disagree. I want *all* of my shortcuts to
be Alt. Why? Because it's *much* easier to remember that way! Especially if
you're talking about something like "M-m (". Am I supposed to remember which
math commands are in the menu (frac, exp, sqrt...) are in the menu and
therefore start with Alt, and which are not and therefore start with Ctrl?
That seems arbitrary and kind of annoying. Especially since the only thing I
ever use the math menu for is opening the math panel.
It's important to think of ease of use for new users, but what about
experienced users? Many of them won't want to use the menus most of the
time.
-Amir
Re: I'm back, take 2 :)
Lars leered, Andre Poenitz [EMAIL PROTECTED] writes: | Other options is to use: | C-c C-m or C-c m | Too long. Say that to thousends of emacs users. vile heretics, all :) more seriously, the insanely long keystrokes are a major reason that I tend to vi rather than emacs. *everything* should be mapped to quick sequences. It's friday; that means I can call emacs users vile heretics, can't I? It is only in your mind. It's my fingers. More keystrokes leads to less typed output. hawk, who still needs to file bug reports on mkdir and rmdir, as any commands that important should only be two letters . . . --
Re: I'm back, take 2 :)
On Thu, Sep 14, 2000 at 04:42:53PM -0400, hawk wrote:
Say that to thousends of emacs users.
vile heretics, all :)
I think it's no accident that the first two letters of VILE are "vi" :-)
Seriously, I use both... So that makes me the worst type of vile
heretic.
It's my fingers. More keystrokes leads to less typed output.
hawk, who still needs to file bug reports on mkdir and rmdir, as any
commands that important should only be two letters . . .
Use aliases ('md' and 'rd').
---Kayvan
Re: the Window Name
From John Levon, Thu Sep 14, at 16:38: .I would suggest to default to full/relative path on a certain length, .otherwise just filename, so the standard thing can get 95% of the cases .right. .What do you think ? I would prefer a dot string (...) inserted just after the highest directory in the address string; this way, you can always tell which is which among files with the same name (e.g. "Notes.lyx") but stored in different locations. Pol -- Paolo Pumilia email: [EMAIL PROTECTED] o o o cstc o o o
Latex error parsing
The parsing of latex errors assumes that an error begins with a line
beginning with "! ", and afterwards there is a line beginning with "l."
containing the error line number.
However, the "l." lines doesn't already exist.
For example, by putting "\emph{" with no closing bracket,
the error message is
Runaway argument?
{ \end {document}
! File ended while scanning use of \emph .
inserted text
\par
We can remove the check for the "l." line by removing the
"if (prefixIs(tmp, "l.")) {" line in LaTeX::scanLogFile, but we need to be
sure that latex never prints a line beginning with "! " unless there is an
error.
A safer solution is to do the following:
- if (prefixIs(tmp, "l.")) {
+ if (prefixIs(tmp, "l.") ||
+ contains(token, "File ended while")) {
which only handle the specific type of error which is shown above.
I've attached a patch for this.
patch.gz
STL gcc-2.95.2 question
The basic question is, does it work. I installed the STL headers and used --with-extra-inc=/usr/local/include/stl to point to them. LyX cvs would not compile. Is it supposed to? Garst
Re: SIGSEGV signal caught
On 14 Sep 2000, Jean-Marc Lasgouttes wrote: "Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan Anyone have a problem with me adding this as lyx-devel/BUGS? Allan I'll add a bit more as well. Check out also the stuff which is in BUGS.lyx. BUGS.lyx has the advantage to be easy to find for anybody (since BUGS will be only in the source distribution), but it cannot be read if you cannot run LyX :( I was talking to Mike about a week or so ago (when I wrote the last "gdb HOWTO") about getting this sort of thing in the FAQ. I'll update the details in BUGS.lyx but also think we should have BUGS. Binary distro's should include BUGS in the documentation. RPMs put stuff like BUGS in /usr/doc/[packages/]lyx-x.x.x/ after all. Sure we'll have 3 duplicate places for users to look but at least one of them will be plain unadorned text and they can't say, "LyX wouldn't run so I couldn't read BUGS.lyx." Besides, INSTALL already says to look at BUGS or BUGS.lyx. PS: the LDN is very good. Thanks. Allan. (ARRae)
Re: I'm back, take 2 :)
On Thu, 14 Sep 2000, hawk wrote: Lars leered, Andre Poenitz [EMAIL PROTECTED] writes: | Other options is to use: | C-c C-m or C-c m | Too long. Say that to thousends of emacs users. vile heretics, all :) C-c C-m Two keystrokes(4 keys) C-c m again two keystrokes (3 keys) How often would you do this? Not as often as saving I would expect which is: C-x C-s Two keystrokes(3 keys) one hand (adjacent keys) vs that abomination vi (and it really is Friday as I write this not late Thursday afternoon as your emails datestamp indicated for you!! Hummphf) S-: w Enter Three keystrokes (4 keys) two hands (all over the place) more seriously, the insanely long keystrokes are a major reason that I tend to vi rather than emacs. *everything* should be mapped to quick sequences. I agree with all but the order of the words "vi" and "emacs" in the above quote. If vi is so popular why isn't there a vi binding for LyX? It's friday; that means I can call emacs users vile heretics, can't I? It is only in your mind. Lars, was ahead of you when he wrote this. See emacs users are even pre-emptive! If you want to claim it's Friday change your email date stamp before sending on a Thursday! It's my fingers. More keystrokes leads to less typed output. hawk, who still needs to file bug reports on mkdir and rmdir, as any commands that important should only be two letters . . . Two keystrokes, two hands? VI? Viral Infection? Allan. (ARRae)
Re: STL gcc-2.95.2 question
On Thu, 14 Sep 2000, Garst R. Reese wrote: The basic question is, does it work. I installed the STL headers and used --with-extra-inc=/usr/local/include/stl to point to them. LyX cvs would not compile. Is it supposed to? Which STL implementation did you download? SGI's STL? STLport? Which version did you try? LyX should compile. If it doesn't, we need to fix something (but not necessarily LyX). Allan. (ARRae)
Re: STL gcc-2.95.2 question
Allan Rae wrote: On Thu, 14 Sep 2000, Garst R. Reese wrote: The basic question is, does it work. I installed the STL headers and used --with-extra-inc=/usr/local/include/stl to point to them. LyX cvs would not compile. Is it supposed to? Which STL implementation did you download? SGI's STL? STLport? Which version did you try? SGI's I can try STLport if you have a URL. LyX should compile. If it doesn't, we need to fix something (but not necessarily LyX). I'll compile again and save a log. There were msgs about something being too long to inline. Garst
Making patches: one possible solution.
On 13 Sep 2000, Lars Gullik Bjønnes wrote: Juergen Vigna [EMAIL PROTECTED] writes: | On 13-Sep-2000 John Levon wrote: | | But to do that would require me to have *two* source trees, because cvs | won't know about the new files because I can't do "cvs add". | | Well I guess we can add you to the cvs-readonly list AND this means you | CAN do an add ;) yes. Then we'll never be able to accept patches from anyone unless they have cvs access of some description (excluding anonymous cvs). I have modified GNU diff to be able to emulate `cvs diff`. This allows anyone with two copies of a cvs snapshot to modify one and generate a diff between the two that is the equivalent of what they'd get if we gave them cvs access. This way people without anonymous cvs access can work on a snapshot of the source tree (such as Kayvan makes available). It also means anyone with anonymous cvs access can generate patches without Lars having to add them to a growing list of contributors with read-only access. They can do a `cvs update` and fix conflicts just before submitting their patch and everyone should be happy. I have both a patch against diffutils-2.7: (14kB) http://www.devel.lyx.org/~rae/code/arrae-2910.diffutils-2.7.patch.bz2 and a patched diffutils-2.7 tree: (256kB) http://www.devel.lyx.org/~rae/code/diffutil-2.7.arrae-2911.tar.bz2 The patch includes full documentation. I probably went a bit overboard when I added a couple of extra options for making diffs of directories not controlled by cvs. But that's a minor quibble. I'll probably remove those extra bits before submitting it to somebody (the ChangeLog indicates it hasn't been worked on since 1994). Try: ./configure ; make ; make dvi ; xdvi diff.dvi and read the documentation (see concept index under "comparing cvs snapshots" or just go direct to "Comparing Directories") ## Something else that's there that I find useful is: http://www.devel.lyx.org/~rae/code/packcvs This is a shell script that works a bit like the old makepatch script we used to use. It takes from one to three directories as parameters. With one directory it produces a tarball of all the files in a subdirectory _not_ ignored by cvs. I developed this in an effort to reduce the delays when trying to compile on my machine at uni. I previously did a `make maintainer-clean` before making a cvs snapshot to put on a floppy to take home. With two or three directories as arguements a recursive diff will be made of the two directories using: diff -p -N -U 4 -r --emulate-cvs $1 $2 $3/$patchname So you don't have to remember what the options are for diff to generate a nice patch. ## History 101 === I developed these because I had been struggling to work on LyX at home (no cvs access possible) while minimising the delays when sorting out conflicts on the lame machine I have to use at Uni and to test compile after sorting out those conflicts. I take tarballs home on a floppy disk (just barely fits these days at 1.85MB on a 1.44MB floppy¹) and bring patches back to Uni. I had a modified makepatch script that worked okay but there were a lot of things it couldn't do (ignored too much or not enough for example). So packdir (the redecessor of packcvs) was born to allow me to build tarballs without losing all the compiled object files (the lame machine takes about 45minutes to compile LyX). Then I decided that I couldn't make decent patches using a shell script and modified diff instead. That lead to the final revision of packcvs that supports both packing and diffing cvs snapshots. Allan. (ARRae) ¹ I "overclock" the floppy to get 1.9MB disks.
Re: STL gcc-2.95.2 question
On Fri, 15 Sep 2000, Garst R. Reese wrote: Allan Rae wrote: LyX should compile. If it doesn't, we need to fix something (but not necessarily LyX). Here's the end of the log. That shows only warnings. I wouldn't have thought it'd stop just because it can't inline -- the compiler would try to place the code out-of-line. There should be an error message somewhere earlier in the compiler output. Again I'll ask which version of SGI STL are you using? Everything after 3.2.x was being switched to add several new things (like iostreams) and these have been very unstable and almost unusable on the few occasions I tried them (last time was 6 months ago). Allan. (ARRae)
LyX/Literate programming bug report and fix
yucky-html-email pMy question is how we submit patches nowadays. I couldn't find the brfamiliar script to diff two source trees... (Yeah, it's being a long brtime...) /yucky-html-email Makepatch doesn't exist anymore. Everyone is expected to use cvs to build patches against the latest cvs not against fix releases. Although if you do both (fix release and current) you will make JMarc's job easier. There are some problems with requiring patch submitters to use cvs. This is really only a problem with new files. I have written a patch for GNU diffutils-2.7 to get it to emulate `cvs diff`. This makes diff do similar stuff to what makepatch tried to do but isn't capable of handling with the new cvs-based development. I also have a shell script that you can call so you don't have to remember which options you should give to diff. I have these at: http://www.devel.lyx.org/~rae/code/ So in summary: If you have cvs access but no new files use `cvs diff -p -N -u` if you have no cvs access (using snapshots or releases) _or_ have cvs access but have added new files then get the modified diff and a script called packcvs from the above site and run: packcvs original.directory modified.directory Allan. (ARRae)
Re: LyX/Literate programming bug report and fix
Allan Rae wrote: So in summary: If you have cvs access but no new files use `cvs diff -p -N -u` if you have no cvs access (using snapshots or releases) _or_ have cvs access but have added new files then get the modified diff and a script called packcvs from the above site and run: packcvs original.directory modified.directory Allan. (ARRae) What was wrong with cvs diff -N -u mypatch.diff and sending mypatch.diff to the list? Garst
Re: dotfill,hrulefill status & open behavior
"Lars Gullik Bjønnes" wrote: > > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > > | I'll start with the open behavior. > | I click open and give a new file name. LyX asks if it wants to create > | the new file and I answer yes. I later try to save the file and it asks > | for a file name. > | I enter the same file name that I entered before. LyX saves the file in > | /home/garst instead of /home/garst/lyxdocs which is specifed in my > | lyxrc. > > Is this your code playing tricks on us Jürgen? > Or it is something older/else? > > | I think Lars was working on adding dotfill and hrulefill to the insert > | special character menu. > > I looked at it... but it really involves a bit more than just the > menu... > > Lgb I figure as much :( Just checked the file open problem again. Seems to be fixed. Thanks Júrgen. Garst
Re: [PATCH] hollywood.cls
On Thu, 14 Sep 2000, Garst R. Reese wrote: > One of our users has made some well researched suggestions for changes > to the hollywood.cls file. > The diff from cvs -N -u is attached, including the Changelog. Can you do a 'make clean' in src/frontends/xforms/forms before running make in $topsrc. That will avoid having all the extra *.[Ch] files added to POTFILES.in from that directory. In the meanwhile we need to change the autogen.sh script to exclude those files when rebuilding POTFILES.IN. I've been thinking we should either use a Makefile target and let make rebuild it whenever we add/remove files or maybe make use of the .cvsignore files to exclude some files from the building of POTFILES.IN. Simply searching for all the *.[Ch] files isn't good enough. Allan. (ARRae)
Re: dotfill,hrulefill status & open behavior
> Just checked the file open problem again. Seems to be fixed. > Thanks Júrgen. #:O) Thanks to you for all your reports!!! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If you can't understand it, it is intuitively obvious.
RE: [PATCH] KDE FormRef
On 13-Sep-2000 John Levon wrote: > On Wed, 13 Sep 2000, Juergen Vigna wrote: > >> There is still the Changelog missing in the diff-file please resubmit! >> > > sorry, I thought it was as other projects, where the changelog doesn't go > in the diff so there's not syncing problems between patches. New one with > Changelog diff included. Sorry to be a bother ;) #:O) Applied and commited! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Reality is just a convenient measure of complexity. -- Alvy Ray Smith
Re: class_choice -> combo_class
On 13-Sep-2000 Jean-Marc Lasgouttes wrote: >> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: > > Juergen> Now I've a problem, when I select a new class I get a > Juergen> question from the system if I want also change the layouts of > Juergen> paragraphs. Now the combox did a mouse-grab so I'm not able > Juergen> to click with the mouse on the yes/no buttons (i use kb-y)! > > Isn't it possible to close the combox before changing the layout? Well you are in the callback of the combox how would you do that? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ ...when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. - Fred Brooks, Jr.
Re: SIGSEGV signal caught
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> Anyone have a problem with me adding this as lyx-devel/BUGS? Allan> I'll add a bit more as well. Check out also the stuff which is in BUGS.lyx. BUGS.lyx has the advantage to be easy to find for anybody (since BUGS will be only in the source distribution), but it cannot be read if you cannot run LyX :( JMarc PS: the LDN is very good.
Re: class_choice -> combo_class
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 13-Sep-2000 Jean-Marc Lasgouttes wrote: >>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: >> Juergen> Now I've a problem, when I select a new class I get a Juergen> question from the system if I want also change the layouts of Juergen> paragraphs. Now the combox did a mouse-grab so I'm not able Juergen> to click with the mouse on the yes/no buttons (i use kb-y)! >> Isn't it possible to close the combox before changing the layout? Juergen> Well you are in the callback of the combox how would you do Juergen> that? And would it make sense to change Combox so that the callback is called _after_ closing the list? JMarc PS: no, I do not now what I am talking about :)
Re: class_choice -> combo_class
> > And would it make sense to change Combox so that the callback is > called _after_ closing the list? Could be an idea I'll have a look! > > PS: no, I do not now what I am talking about :) Well mee too ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ One learns to itch where one can scratch. -- Ernest Bramah
Re: [PATCH] KDE FormToc cleanup
On Wed, 13 Sep 2000, Dekel Tsur wrote: > On Wed, Sep 13, 2000 at 11:27:40AM +0200, Juergen Vigna wrote: > > > > On 13-Sep-2000 John Levon wrote: > > > > > > I should get some sleep :/ > > > > I forgot in my former mail: > > > > GOOD WORK!!! > > > > I like the new look of the KDE-TOC-DIALOG!!! > > The Klyx TOC dialog is a little bit nicer (e.g. the ability to select a depth > threshold). > John, why aren't you reusing code from Klyx ? > That's an incredibly good question. I suppose I thought that LyX might have changed too much inbetween, but I suppose a lot of it will still be useful. I have a source tarball at home, I should dig it out ! john -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
Re: [PATCH] KDE FormRef
On Thu, 14 Sep 2000, Allan Rae wrote: > On Wed, 13 Sep 2000, John Levon wrote: > > This is 95%, as there is still a big hole when we edit an existing > > crossref, and we hide the refs list. It seems difficult to get Qt to redo > > the layout, and remove the widget > > Just disable it then. You don't have to make the KDE port work and look > just like the XForms port does. > > Allan. (ARRae) > Well, it just looked a bit funny because there's no real hint when it's disabled. I'll play with it more later. thanks john -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
Gnome Menubar update
Hi! this patch adds TOC and *Formats menu items to the Gnome menubar implementation. TOC menu updates itself automatically using the ListsTracker class. The current implementation doesn't support large TOCs and you can't manage your references via Gnome menu yet. However, the current implementation is easily extendable to show LOT, LOF, and LOA as soon as LyX Menu will support these lists. Marko gnomemenu.patch.gz
Re: new lyx
Andre Poenitz <[EMAIL PROTECTED]> writes: | > | Have you tried to use it together with lyxstring? | | No, I haven't had much time for playing around lately, | so I used it only in my own project (due 2000/09/30 *sigh*) Ok, I have tested it with lyxstring. Only one small thing needed fixing. I also had to remove the dynamic_casts (replaced with static_cast) With gcc 2.95.2 I have no problem with LyX with or witout lyxstring and this sstream. I will commit this so that we can see wat other problems arises. Lgb
[Edmar Wienskoski Jr <edmar-w-jr@technologist.com>] "LyX/Literate programming" bug report and fix
Hi Lars. I worked on the literate programming extension for LyX a while back (LyX-1.0.1). Unfortunately political trends here at my job shifted and it is a long time I don't have opportunity to use this feature. Then, on July one guy sent me email saying it was broken. In fact it was, but it is a small thing: If you get compilation errors, the errors were not shown on the document. (The reason this bug was introduced is that the parsing of the latex log file changed, and the corresponding parsing routine for literate programming building process were not.) He told me he was going to fix it. But last week I downloaded the latest version of LyX, and this problem was still there. So I fixed it myself. The fix was easy, mostly cut and paste from scanLogFile LaTeX routine into scanLiterateLogFile. My question is how we submit patches nowadays. I couldn't find the familiar script to diff two source trees... (Yeah, it's being a long time...) Anyway... If you forgive me the abuse, I am enclosing a tar file with the 3 files that I changed (based on the 1.1.5fix1 release): lib/examples/Literate.lyx src/Literate.C src/Literate.h Would you integrate these changes for me ? Thanks Edmar W. Jr. -- /*--*/ /* Edmar Wienskoski Jr. - [EMAIL PROTECTED] */ /* - http://www.cs.rice.edu/~wiensk */ /*--*/ | [] | __()_||_ ---++--- | [] | | | | | | | | | | | ___| | |_|__|_| |__| |__| |__| |__\ "o-o o-o""o-o o-o""o-o o-o""o-o o-o""o-o O-O-O o-o " litfix.tar.gz
siamltex.layout
I put a .layout file for the siamltex class (SIAM = Society for Industrial and Applied Mathematics) under http://mathematik.htwm.de/tmp/siamltex.layout This fits more or less to Paul Duggan's LaTeX class found e.g. under ftp://ftp.dante.de/tex-archive/macros/latex/contrib/other/siam/siamltex.tar It's the first shot at a .layout over here, so maybe someone more experienced would comment ;-) Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: I'm back, take 2 :)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> | Lars does not | want to have M-m bindings which are not real
| Lars> menu bindings. I'd be | surprised if people like it %-]
|
| Lars> What is the problem with changing it to "C-m {"?
|
| I don't know yet. Someone has to review all the bindings and see how
| to change them.
|
| OK, C-m is already
|
| - mark-toggle (what's that??) in (x)emacs
|
| - math-mode in others.
|
| - "menu-open Matemático" in portuguese menus (why?).
This sould be removed anyway. Menus are not opened by bindings any
more, but by menu shortcuts.
| I do not know whether thes toggles matter or not.
Other options is to use:
C-c C-m or C-c m
We cannot expect to solve al binding by just one indirecton.
Lgb
Re: the Window Name
> "Paolo" == Paolo M Pumilia <[EMAIL PROTECTED]> writes: >> From Jean-Marc Lasgouttes, Wed Sep 13, at 12:31: | "Paolo" == Paolo M Pumilia <[EMAIL PROTECTED]> writes: |Paolo> I noticed that the name of the window hosting my LyX editing |Paolo> session has the form 'LyX: filename', that is the path to the |Paolo> opened filename has been discarded. E.g., entering the command |Paolo> % /usr/bin/X11/lyx Notes/file1.lyx spawns a window with name |Paolo> 'LyX: file1.lyx' open |Paolo> Is there a way to preserve in the window name the original |Paolo> argument passed along with the command? |Do you mean exactly the argument entered or rather have the |full path .to the file? Paolo> preserving the full path would be enough for what i am trying Paolo> to do: manage open lyx files depending on the directory they Paolo> reside. OK, it is pretty easy to have the full (nice) file name in the title bar. Are there people who find it is a bad idea? Otherwise, I'll just do it. JMarc
Re: [PATCH] hollywood.cls
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: Garst> One of our users has made some well researched suggestions for Garst> changes to the hollywood.cls file. The diff from cvs -N -u is Garst> attached, including the Changelog. Thanks, I'll commit it (in the 1.1.5 branch too). JMarc
Re: I'm back, take 2 :)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | Lars does not | want to have M-m bindings which are not real
Lars> menu bindings. I'd be | surprised if people like it %-]
Lars> What is the problem with changing it to "C-m {"?
I don't know yet. Someone has to review all the bindings and see how
to change them.
OK, C-m is already
- mark-toggle (what's that??) in (x)emacs
- math-mode in others.
- "menu-open Matemático" in portuguese menus (why?).
I do not know whether thes toggles matter or not.
JMarc
Re: NEW_INSETS (was Re: [PATCH] Fix KDE Citation thinko)
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> So l[TOC_LOF] et al are never filled What am I missing ? With new insets, floats are moved to a new inset structure, so the code should be rewritten to handle these float insets. JMarc
Sun i18n code goes open source!
It is already Friday here in Japan. But I presume it is still not for most of you, and I hope it all right for me to turn down all the objections I've expressed here towards Dekel Tsur's efforts for the LyX internationalization instead of accusing him further. Today Sun Microsystems is supposed to release their i18n technology open source to X org: http://www.sun.com/smi/Press/sunflash/2000-08/sunflash.2829.1.html Among other things is IIIMF an Input Method Framework which enable an X client to connect to (possibly multiple) Input Method Server(s) of different locale(s) than that of the process. --Remember, unlike C++, C process has only one locale object-- If this technology becomes a commonality which is widely available, not only on XFree86, then my argument against Dekel's effort will lose the ground. I had proceeded as thus: - some languages, especially Japanese and Korean, requires very sophisticated language engines to be input, which unlike keymaps are obviously too complicated and large to bundle with LyX; - currently X allows an X client to connect to an IM server which may in turn connect to language engines, but only in the process locale (LC_CTYPE) of the client; - so, for such languages, the process locale of LyX and the document language to be edited must be the same; - for CJK which employs thousands of glyphs, a Unicode based text drawing will be inefficient and very complicated (bug prone) unless Unicode fonts are availble; - Unicode CJK fonts are cheaply available only in bitmap (not scalable) and TrueType (not widely supported on X) formats; - then, since the process and the document locale must coincide for such languages, why don't you use the Xlib built-in locale based text drawing method rather than reinventing the wheel in an inefficient Unicode based manner; Dekel already had answered that the point 4 will not count once we adopt to use FreeType for better rendering. Now the points 2, 3, and 6 will no longer be true. What do you think? Regards, SMiyata
Re: the Window Name
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On 14 Sep 2000, Jean-Marc Lasgouttes wrote: >> OK, it is pretty easy to have the full (nice) file name in the >> title bar. Are there people who find it is a bad idea? Otherwise, >> I'll just do it. John> I assume you just mean the relative path not the full path yes ? Relative to what? This is the full path, but shortened to begin with "~/" if in your home directory. Of course, this will not look nice for documentation... Ideas? JMarc
Re: the Window Name
On 14 Sep 2000, Jean-Marc Lasgouttes wrote: > John> I assume you just mean the relative path not the full path yes ? > > Relative to what? This is the full path, but shortened to begin with > "~/" if in your home directory. Of course, this will not look nice for > documentation... > > Ideas? > > JMarc > That was indeed my concern :) this can also be a problem if you're not working from your home dir. I can see this happening a lot (personally when I used to do collab work, rather than sanely using CVS or similar, we just all worked on an exported NFS share with a *long* path). Maybe you can make this an option ? I can't think of any way of reliably knowing when the user won't be able to see the end of the path string in the titlebar :/ I would suggest to default to full/relative path on a certain length, otherwise just filename, so the standard thing can get 95% of the cases right. What do you think ? thanks john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming
Re: I'm back, take 2 :)
On Thu, Sep 14, 2000 at 04:48:37PM +0200, Lars Gullik Bjnnes wrote:
>
> Other options is to use:
>
> C-c C-m or C-c m
>
> We cannot expect to solve al binding by just one indirecton.
>
Why not put more items in the math menu ?
E.g.
Menu "math"
...
Item "Delim ()|(" "math-delim ( )"
We can then use the old key bindings.
Re: [PATCH] KDE FormRef
On Thu, Sep 14, 2000 at 01:14:06PM +0100, John Levon wrote: > On Thu, 14 Sep 2000, Allan Rae wrote: > > > On Wed, 13 Sep 2000, John Levon wrote: > > > This is 95%, as there is still a big hole when we edit an existing > > > crossref, and we hide the refs list. It seems difficult to get Qt to redo > > > the layout, and remove the widget > > > > Just disable it then. You don't have to make the KDE port work and look > > just like the XForms port does. > > > > Allan. (ARRae) > > > > Well, it just looked a bit funny because there's no real hint when it's > disabled. I'll play with it more later. Why not show the labels list when editing a reference, so you will be able to change an existing ref?
Re: Comments & Notes in LyX
On Wed, Sep 13, 2000 at 08:44:13PM +0200, Gaillard Pierre-Olivier wrote:
> I am currently in the process of replacing Interleaf (a big publishing
> package like Framemaker) with LyX/Latex.
> I have managed to write a Python program that converts our Interleaf
> documents . This convinced a few of my coworkers that LyX is a great
> choice since editing in LyX is more intuitive than in Interleaf
> (bibliography and indexes are really better).
Cool!
> - XML format. this is not a real problem since I have shown that a basic
> utility to write LyX files could be written in less than one day. I
> think they will trust me if I say that we could export our LyX files to
> some XML format in a few day. Anyway I really think that the current
> format is strange ('end float' is not the same as 'end float ' !!) and
> XML would be an EASY and FASHIONABLE replacement.
You are not alone in thinking this; it comes up frequently (I proposed
it once). There is quite a high level of support for the general idea,
but the core developers don't see it as a high priority --- so it's
most likely to happen if some interested third-party (like me, if I
had more time) does the grunt work!
Jules
Re: I'm back, take 2 :)
> Other options is to use: > > C-c C-m or C-c m Too long. Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: I'm back, take 2 :)
dekel deklared,
> On Thu, Sep 14, 2000 at 04:48:37PM +0200, Lars Gullik Bjønnes wrote:
> > Other options is to use:
> > C-c C-m or C-c m
> > We cannot expect to solve al binding by just one indirecton.
> Why not put more items in the math menu ?
> E.g.
> Menu "math"
>...
>Item "Delim ()|(" "math-delim ( )"
> We can then use the old key bindings.
There's *way* too many math bindings for that :)
However, it occurs to me that the last several used from the math
panel might be nice, as with the last several files in the file panel.
What we really need to keep in mind is that keystrokes count--three
keys for commonly used math is way to many.
hawk
--
Re: [PATCH] hollywood.cls
Allan Rae wrote: > > On Thu, 14 Sep 2000, Garst R. Reese wrote: > > > One of our users has made some well researched suggestions for changes > > to the hollywood.cls file. > > The diff from cvs -N -u is attached, including the Changelog. > > Can you do a 'make clean' in src/frontends/xforms/forms before running > make in $topsrc. That will avoid having all the extra *.[Ch] files added > to POTFILES.in from that directory. > > In the meanwhile we need to change the autogen.sh script to exclude those > files when rebuilding POTFILES.IN. I've been thinking we should either > use a Makefile target and let make rebuild it whenever we add/remove > files or maybe make use of the .cvsignore files to exclude some files from > the building of POTFILES.IN. Simply searching for all the *.[Ch] files > isn't good enough. > > Allan. (ARRae) No problem. I knew something was remiss when the first diff I made include stuff from POTFILES.IN. I figured it was generated by autogen.sh, so moved it out of the way and did another diff. BTW, I was impressed by how polite you were to the guy/gal who sent the core file. Garst
Re: I'm back, take 2 :)
Andre Poenitz <[EMAIL PROTECTED]> writes: | > Other options is to use: | > | > C-c C-m or C-c m | | Too long. Say that to thousends of emacs users. It is only in your mind. Lgb
new sstream + lots of small other things
I have committed my latest stuff. this might break some compiler libraries, but I hope the chances for that are slim. I am put the sstream posted to this list into use, and on gcc 2.95.2 it works fine with both lyxstring and the string class included with gcc 2.95.2. I have changed most non-pod return to return a const object, this avoid spurrius changes to temporary object and is in most cases a lot nicer (with a potential speedup) please try the current cvs out and report all problems releated to this checkin. Lgb
Lost math bindings
OK, maybe it's late for me to be getting into this discussion. But I just
tried to play with the new LyX (now that I can compile it) and realized how
annoying it was not to have the math bindings any more.
I'll also note that noone created the layout.bind that Lars suggested, so
the paragraph layout stuff isn't there any more. Nor are the character
changing commands.
Lars seems to be saying that if something isn't in the menu, it shouldn't
have an Alt- keyboard shortcut. I disagree. I want *all* of my shortcuts to
be Alt. Why? Because it's *much* easier to remember that way! Especially if
you're talking about something like "M-m (". Am I supposed to remember which
math commands are in the menu (frac, exp, sqrt...) are in the menu and
therefore start with Alt, and which are not and therefore start with Ctrl?
That seems arbitrary and kind of annoying. Especially since the only thing I
ever use the math menu for is opening the math panel.
It's important to think of ease of use for new users, but what about
experienced users? Many of them won't want to use the menus most of the
time.
-Amir
Re: I'm back, take 2 :)
Lars leered, > Andre Poenitz <[EMAIL PROTECTED]> writes: > | > Other options is to use: > | > C-c C-m or C-c m > | Too long. > Say that to thousends of emacs users. vile heretics, all :) more seriously, the insanely long keystrokes are a major reason that I tend to vi rather than emacs. *everything* should be mapped to quick sequences. It's friday; that means I can call emacs users vile heretics, can't I? > It is only in your mind. It's my fingers. More keystrokes leads to less typed output. hawk, who still needs to file bug reports on mkdir and rmdir, as any commands that important should only be two letters . . . --
Re: I'm back, take 2 :)
On Thu, Sep 14, 2000 at 04:42:53PM -0400, hawk wrote:
>
> > Say that to thousends of emacs users.
>
> vile heretics, all :)
I think it's no accident that the first two letters of VILE are "vi" :-)
Seriously, I use both... So that makes me the worst type of vile
heretic.
> It's my fingers. More keystrokes leads to less typed output.
>
> hawk, who still needs to file bug reports on mkdir and rmdir, as any
> commands that important should only be two letters . . .
Use aliases ('md' and 'rd').
---Kayvan
Re: the Window Name
>From John Levon, Thu Sep 14, at 16:38: .I would suggest to default to full/relative path on a certain length, .otherwise just filename, so the standard thing can get 95% of the cases .right. .What do you think ? I would prefer a dot string (...) inserted just after the highest directory in the address string; this way, you can always tell which is which among files with the same name (e.g. "Notes.lyx") but stored in different locations. Pol -- Paolo Pumilia email: [EMAIL PROTECTED] o o o cstc o o o
Latex error parsing
The parsing of latex errors assumes that an error begins with a line
beginning with "! ", and afterwards there is a line beginning with "l."
containing the error line number.
However, the "l." lines doesn't already exist.
For example, by putting "\emph{" with no closing bracket,
the error message is
Runaway argument?
{ \end {document}
! File ended while scanning use of \emph .
\par
We can remove the check for the "l." line by removing the
"if (prefixIs(tmp, "l.")) {" line in LaTeX::scanLogFile, but we need to be
sure that latex never prints a line beginning with "! " unless there is an
error.
A safer solution is to do the following:
- if (prefixIs(tmp, "l.")) {
+ if (prefixIs(tmp, "l.") ||
+ contains(token, "File ended while")) {
which only handle the specific type of error which is shown above.
I've attached a patch for this.
patch.gz
STL & gcc-2.95.2 question
The basic question is, does it work. I installed the STL headers and used --with-extra-inc=/usr/local/include/stl to point to them. LyX cvs would not compile. Is it supposed to? Garst
Re: SIGSEGV signal caught
On 14 Sep 2000, Jean-Marc Lasgouttes wrote: > > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: > > Allan> Anyone have a problem with me adding this as lyx-devel/BUGS? > Allan> I'll add a bit more as well. > > Check out also the stuff which is in BUGS.lyx. BUGS.lyx has the > advantage to be easy to find for anybody (since BUGS will be only in > the source distribution), but it cannot be read if you cannot run LyX > :( I was talking to Mike about a week or so ago (when I wrote the last "gdb HOWTO") about getting this sort of thing in the FAQ. I'll update the details in BUGS.lyx but also think we should have BUGS. Binary distro's should include BUGS in the documentation. RPMs put stuff like BUGS in /usr/doc/[packages/]lyx-x.x.x/ after all. Sure we'll have 3 duplicate places for users to look but at least one of them will be plain unadorned text and they can't say, "LyX wouldn't run so I couldn't read BUGS.lyx." Besides, INSTALL already says to look at BUGS or BUGS.lyx. > PS: the LDN is very good. Thanks. Allan. (ARRae)
Re: I'm back, take 2 :)
On Thu, 14 Sep 2000, hawk wrote: > Lars leered, > > > Andre Poenitz <[EMAIL PROTECTED]> writes: > > > | > Other options is to use: > > > | > C-c C-m or C-c m > > > | Too long. > > > Say that to thousends of emacs users. > > vile heretics, all :) C-c C-m Two keystrokes(4 keys) C-c m again two keystrokes (3 keys) How often would you do this? Not as often as saving I would expect which is: C-x C-s Two keystrokes(3 keys) one hand (adjacent keys) vs that abomination vi (and it really is Friday as I write this not late Thursday afternoon as your emails datestamp indicated for you!! Hummphf) S-: w Enter Three keystrokes (4 keys) two hands (all over the place) > more seriously, the insanely long keystrokes are a major reason that I > tend to vi rather than emacs. *everything* should be mapped to quick > sequences. I agree with all but the order of the words "vi" and "emacs" in the above quote. If vi is so popular why isn't there a vi binding for LyX? > It's friday; that means I can call emacs users vile heretics, can't I? > > > It is only in your mind. Lars, was ahead of you when he wrote this. See emacs users are even pre-emptive! If you want to claim it's Friday change your email date stamp before sending on a Thursday! > It's my fingers. More keystrokes leads to less typed output. > > hawk, who still needs to file bug reports on mkdir and rmdir, as any > commands that important should only be two letters . . . Two keystrokes, two hands? VI? Viral Infection? Allan. (ARRae)
Re: STL & gcc-2.95.2 question
On Thu, 14 Sep 2000, Garst R. Reese wrote: > The basic question is, does it work. > I installed the STL headers and used > --with-extra-inc=/usr/local/include/stl > to point to them. LyX cvs would not compile. Is it supposed to? Which STL implementation did you download? SGI's STL? STLport? Which version did you try? LyX should compile. If it doesn't, we need to fix something (but not necessarily LyX). Allan. (ARRae)
Re: STL & gcc-2.95.2 question
Allan Rae wrote: > > On Thu, 14 Sep 2000, Garst R. Reese wrote: > > > The basic question is, does it work. > > I installed the STL headers and used > > --with-extra-inc=/usr/local/include/stl > > to point to them. LyX cvs would not compile. Is it supposed to? > > Which STL implementation did you download? SGI's STL? STLport? > Which version did you try? SGI's I can try STLport if you have a URL. > > LyX should compile. If it doesn't, we need to fix something (but not > necessarily LyX). I'll compile again and save a log. There were msgs about something being too long to inline. Garst
Making patches: one possible solution.
On 13 Sep 2000, Lars Gullik Bjønnes wrote: > Juergen Vigna <[EMAIL PROTECTED]> writes: > > | On 13-Sep-2000 John Levon wrote: > | > > | > But to do that would require me to have *two* source trees, because cvs > | > won't know about the new files because I can't do "cvs add". > | > | Well I guess we can add you to the cvs-readonly list AND this means you > | CAN do an add ;) > > yes. Then we'll never be able to accept patches from anyone unless they have cvs access of some description (excluding anonymous cvs). I have modified GNU diff to be able to emulate `cvs diff`. This allows anyone with two copies of a cvs snapshot to modify one and generate a diff between the two that is the equivalent of what they'd get if we gave them cvs access. This way people without anonymous cvs access can work on a snapshot of the source tree (such as Kayvan makes available). It also means anyone with anonymous cvs access can generate patches without Lars having to add them to a growing list of contributors with read-only access. They can do a `cvs update` and fix conflicts just before submitting their patch and everyone should be happy. I have both a patch against diffutils-2.7: (14kB) http://www.devel.lyx.org/~rae/code/arrae-2910.diffutils-2.7.patch.bz2 and a patched diffutils-2.7 tree: (256kB) http://www.devel.lyx.org/~rae/code/diffutil-2.7.arrae-2911.tar.bz2 The patch includes full documentation. I probably went a bit overboard when I added a couple of extra options for making diffs of directories not controlled by cvs. But that's a minor quibble. I'll probably remove those extra bits before submitting it to somebody (the ChangeLog indicates it hasn't been worked on since 1994). Try: ./configure ; make ; make dvi ; xdvi diff.dvi and read the documentation (see concept index under "comparing cvs snapshots" or just go direct to "Comparing Directories") ## Something else that's there that I find useful is: http://www.devel.lyx.org/~rae/code/packcvs This is a shell script that works a bit like the old makepatch script we used to use. It takes from one to three directories as parameters. With one directory it produces a tarball of all the files in a subdirectory _not_ ignored by cvs. I developed this in an effort to reduce the delays when trying to compile on my machine at uni. I previously did a `make maintainer-clean` before making a cvs snapshot to put on a floppy to take home. With two or three directories as arguements a recursive diff will be made of the two directories using: diff -p -N -U 4 -r --emulate-cvs $1 $2 > $3/$patchname So you don't have to remember what the options are for diff to generate a nice patch. ## History 101 === I developed these because I had been struggling to work on LyX at home (no cvs access possible) while minimising the delays when sorting out conflicts on the lame machine I have to use at Uni and to test compile after sorting out those conflicts. I take tarballs home on a floppy disk (just barely fits these days at 1.85MB on a 1.44MB floppy¹) and bring patches back to Uni. I had a modified makepatch script that worked okay but there were a lot of things it couldn't do (ignored too much or not enough for example). So packdir (the redecessor of packcvs) was born to allow me to build tarballs without losing all the compiled object files (the lame machine takes about 45minutes to compile LyX). Then I decided that I couldn't make decent patches using a shell script and modified diff instead. That lead to the final revision of packcvs that supports both packing and diffing cvs snapshots. Allan. (ARRae) ¹ I "overclock" the floppy to get 1.9MB disks.
Re: STL & gcc-2.95.2 question
On Fri, 15 Sep 2000, Garst R. Reese wrote: > Allan Rae wrote: > > > LyX should compile. If it doesn't, we need to fix something (but not > > necessarily LyX). > Here's the end of the log. That shows only warnings. I wouldn't have thought it'd stop just because it can't inline -- the compiler would try to place the code out-of-line. There should be an error message somewhere earlier in the compiler output. Again I'll ask which version of SGI STL are you using? Everything after 3.2.x was being switched to add several new things (like iostreams) and these have been very unstable and almost unusable on the few occasions I tried them (last time was 6 months ago). Allan. (ARRae)
"LyX/Literate programming" bug report and fix
My question is how we submit patches nowadays. I couldn't find the familiar script to diff two source trees... (Yeah, it's being a long time...) Makepatch doesn't exist anymore. Everyone is expected to use cvs to build patches against the latest cvs not against fix releases. Although if you do both (fix release and current) you will make JMarc's job easier. There are some problems with requiring patch submitters to use cvs. This is really only a problem with new files. I have written a patch for GNU diffutils-2.7 to get it to emulate `cvs diff`. This makes diff do similar stuff to what makepatch tried to do but isn't capable of handling with the new cvs-based development. I also have a shell script that you can call so you don't have to remember which options you should give to diff. I have these at: http://www.devel.lyx.org/~rae/code/ So in summary: If you have cvs access but no new files use `cvs diff -p -N -u` if you have no cvs access (using snapshots or releases) _or_ have cvs access but have added new files then get the modified diff and a script called packcvs from the above site and run: packcvs Allan. (ARRae)
Re: "LyX/Literate programming" bug report and fix
Allan Rae wrote: > So in summary: > If you have cvs access but no new files use > `cvs diff -p -N -u` > > if you have no cvs access (using snapshots or releases) _or_ have cvs > access but have added new files then get the modified diff and a script > called packcvs from the above site and run: > packcvs > > Allan. (ARRae) What was wrong with cvs diff -N -u > mypatch.diff and sending mypatch.diff to the list? Garst
