Re: [Patch] gimmick: show word frequencies in new buffer
On 7.02.05, Andreas Vox wrote: Am 07.02.2005 um 13:37 schrieb Helge Hafting: Perhaps the program shouldn't add the entries at all, just move from word to word and ask wether to add an entry at that point? Good point. OTOH this would have to be repeated with every index word. Maybe an additional function which acts as a kind of search and replace, maybe even with regular expressions? Why not have functions for selecting/unselecting words (like the midnight commander) including (un)select-all, (un)select-regexp-match, inverse-selecting, ... and finally apply an index-selected. It would be nice, if (other than mc) the selection would be remembered if I go to look closer at one word/occurence. So my idea would be 1.) create an index list widget with * index-new: the alphabetically sorted list. * index-edit: a list of existing index insets Have foldable items: * folded: word and number of occurences * unfolded: a button for each occurence showing the section/chapter/figure/table the word occures (we do not have pages at this stage). Pressing the button jumps to the occurence. (I would not use a buffer for this list (as long as LyX can show only one buffer), so that one can see both, the list and the context at the same time.) 2.) Edit the index buffer: Select entries, delete entries, change the ordering, collate entries, create, subitems, ... It would be nice to have a way for muted index entries -- keep them in the list (just in case) but do not show them in the index. 3.) Update the text from the index list: create index insets for selected items (with chosen change params) Günter -- G.Milde web.de
Re: Bugs in LyX 1.3.5
On Mon, Feb 07, 2005 at 09:24:11PM -1000, John Burgess wrote: In the process, I've come across some bugs. John, it's most helpful to us if you file these bugs in http://bugzilla.lyx.org/ (one bug per report please!) thanks, john
Re: [Patch] gimmick: show word frequencies in new buffer
Andreas Vox wrote: Also, make sure this thing does not get in the way of indexing whole phrases, math expressions, images and other stuff that don't show up in a wordlist. Well, I guess it doesn't, but still. Once there is index markup in place the system should handle it conservatively. Nice. :-) I suspected this, but tried to be careful. Sometimes a cumbersome but working solution gets replaced by an easier solution with a few missing points. I was merely making sure that didn't happen here. Finally, and most important: Autoindexing every occurence of some index-worthy word often yields a useless index. Perhaps there are cases where such indexing is mandatory. But for an ordinary book the requirement is not to index every occurence of some word, but the 1,2 or 3 most important places the word occur. Few people want to mess around with word, 1,2,6,8,12-16, 14, 18,19,22, 25-31,36 only to discover that word is thorougly explained on page 14 and 26-28, and all the other references merely mention word briefly. But removing index references from that list using the jump function from below should be easier than the other way round. Maybe I don't understand. We have to go through the entire document anyway, don't we? Your way: Wel look at every occurence of every indexworthy word, which has been added to the index already. Many of them gets removed from the index, because we only want to index a given word in 2-3 places. My way: We look at every occurence of every indexworthy word, and makes a decision wether to index it at this point. Each word gets indexed 2-3 times, the rest of the time we skip to the next place. Either way, the big job is in looking at every occurence of every indexworthy word. I believe that in my case, there is some extra work adding a few indices per word. In your case, I belive there will be more extra work, in removing quite a few indices per word. Good point. OTOH this would have to be repeated with every index word. Repeating over every word is necessary anyway - wther we add or remove indices. Maybe an additional function which acts as a kind of search and replace, maybe even with regular expressions? Sure, that would be nice. Make that, and it'll be instantly popular. :-) The way of index editing I fancy right now would consist of the following functions: 1.) create an initial index from all words minus stop words. Insert the index references and open an index buffer with the alphabetically sorted list. Suggestion: Make the initial wordlist. Have the user prune this (because the stop-word list cannot possibly contain every word we don't want to index. It can only contain common ones like a, the, ...) Then proceed to the next step. 2.) Edit the index buffer: Delete entries, change the ordering, collate entries, create subitems, ... Are you proposing an index buffer that sort of looks like an index page and do the editing there? Such a thing is very nice for adjusting the layout of the index, obviously. One or two columns? font? Heading for each letter? Layout for that header? But I am not so sure it will be useful for the actual indexing. A word that is indexed several places may have one very important place and we want that page number to be set in itralics, for example. I think that is better done by working on the index entry (the existing index entry box that currently doesn't support the fancy stuff, but it could be made into doing that.) The reason? Only by looking at the text can I see wether this is the _important_ entry (say, the definition) or merely some case that I also want to index. 3.) Have a jump function from an entry in the index buffer to the occurence and between occurences, and back. Well, yes, certainly useful. Be aware that a word indexed multiple times on one page only get one entryin the index. 4.) Update the text from the index buffer: delete unwanted index insets, change params of index insets, add new index insets. How would you add a new one? Well, the foo *see* bar type entries would go here, but all other entries refer to some specific page. They do so because they are anchored to some part of the text - surely you know that the actual page number cannot be known inside lyx. Adding a new entry requires that one goes into the text at the approprioate point - but then it is no longer done from your index editor. It is done in the text as always. 5.) Regenerate the index buffer with existing entries, a la makeindex. The index buffer would only be WYSIWYM of the true index: back references to index insets instead of pagenumbers, key and actual text both visible, word frequency as a hint, ... You'll find that page ranges are partially supported already, an index entry that is repeated on several consecutive pages is automatically coalesced to a range. :-) Yeah, but what if you want to index a whole chapter, like Algorithms, p132--211 ? ;-) Sure thing!
Re: [PATCH] UI: matrix partitioning
Martin Vermeer [EMAIL PROTECTED] writes: | +2005-02-08 Martin Vermeer [EMAIL PROTECTED] | + | + * math_gridinset.[hC]: add methods horLine, rmHorLine, | + vertLine, rmVertLine for drawing/deleting partition lines | + in matrix Please use less cryptic names. Spell it out. Both functions and feature names please. -- Lgb
Re: [PATCH] UI: matrix partitioning
On Tue, 2005-02-08 at 15:14, Lars Gullik Bjnnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: | +2005-02-08 Martin Vermeer [EMAIL PROTECTED] | + | + * math_gridinset.[hC]: add methods horLine, rmHorLine, | + vertLine, rmVertLine for drawing/deleting partition lines | + in matrix Please use less cryptic names. Spell it out. Both functions and feature names please. What would you consider legible? delHorLine? deleteHorizontalLineAbove? I'm happy to please :-) - Martin signature.asc Description: This is a digitally signed message part
Re: [PATCH] UI: matrix partitioning
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin What would you consider legible? delHorLine? Martin deleteHorizontalLineAbove? I'm happy to please :-) I would say delete is better than rm because we use that term. And we use HLine too in tabular. So I would propose deleteHLine. JMarc
Re: [PATCH] UI: matrix partitioning
Martin Vermeer [EMAIL PROTECTED] writes: | On Tue, 2005-02-08 at 15:14, Lars Gullik Bjønnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: | +2005-02-08 Martin Vermeer [EMAIL PROTECTED] | + | + * math_gridinset.[hC]: add methods horLine, rmHorLine, | + vertLine, rmVertLine for drawing/deleting partition lines | + in matrix Please use less cryptic names. Spell it out. Both functions and feature names please. | What would you consider legible? delHorLine? deleteHorizontalLineAbove? yeah. but since we have hline in latex we would probably understand that deleteHLineAbove (except that it isn't a hline is it?) | I'm happy to please :-) How nice of you :-) -- Lgb
Re: [Patch] gimmick: show word frequencies in new buffer
Am 08.02.2005 um 14:01 schrieb Helge Hafting: Andreas Vox wrote: But removing index references from that list using the jump function from below should be easier than the other way round. Maybe I don't understand. We have to go through the entire document anyway, don't we? No, I'd use the jump function just to check the context. If I know the conhtext already I can select the references in the index buffer I don't want and delete them. If I don't like a word, I can delete the whole line with all references. Maybe an additional function which acts as a kind of search and replace, maybe even with regular expressions? Sure, that would be nice. Make that, and it'll be instantly popular. :-) As we say around here, we can do one thing and not refrain from the other :-) Then the users can decide what they like best. The way of index editing I fancy right now would consist of the following functions: 1.) create an initial index from all words minus stop words. Insert the index references and open an index buffer with the alphabetically sorted list. Suggestion: Make the initial wordlist. Have the user prune this (because the stop-word list cannot possibly contain every word we don't want to index. It can only contain common ones like a, the, ...) Then proceed to the next step. You can do that in the second step. 2.) Edit the index buffer: Delete entries, change the ordering, collate entries, create subitems, ... Are you proposing an index buffer that sort of looks like an index page and do the editing there? Such a thing is very nice for adjusting the layout of the index, obviously. One or two columns? font? Heading for each letter? Layout for that header? No, I don't want to do physical layout here... The idea is to have all index entries at one place, with a list of all occurences. Then you can collate entries, delete unwanted occurences, edit the actual rendering, introduce subitems ... But I am not so sure it will be useful for the actual indexing. A word that is indexed several places may have one very important place and we want that page number to be set in itralics, for example. I think that is better done by working on the index entry (the existing index entry box that currently doesn't support the fancy stuff, but it could be made into doing that.) The reason? Only by looking at the text can I see wether this is the _important_ entry (say, the definition) or merely some case that I also want to index. It all boils down to how much of the context of each occurance is visible from the index buffer. I thought the jump function would be enough, but maybe the chapter/section number or the surrounding sentence should be visible also. 3.) Have a jump function from an entry in the index buffer to the occurence and between occurences, and back. Well, yes, certainly useful. Be aware that a word indexed multiple times on one page only get one entryin the index. In the index, yes, in the index buffer, no. 4.) Update the text from the index buffer: delete unwanted index insets, change params of index insets, add new index insets. How would you add a new one? Good point. Copy an existing index entry for a new index term? Something like a reverse see? But you are right, that would be the exception. New entries are either generated from the wordlist or manually in the text or with the regexp-insert-index function. Ciao /Andreas
Re: Bugs in LyX 1.3.5
John == John Burgess [EMAIL PROTECTED] writes: John I've been using LyX since v 1.1?. I used it last year to write John an article for JASA (published in the July 2004 issue). It was John actually a test run based on a RevTeX 4 modification for JASA John using LaTeX. I had to write the layout file. Now I'm preparing John an article for the Editor-in-Chief about how to use LyX with John BibTeX for JASA article preparation, including template files. We would be interested to distribute the layout file with LyX... What cls file do you use? John In the process, I've come across some bugs. John Bug 1: Edit = Reconfigure updates only John $HOME/.lyx/textclass.lst. But it doesn't update bstFiles.lst, John clsFiles.lst, and styFiles.lst unless they are first manually John removed. Only textclass.lst is needed for the proper operation of LyX, and the other ones are indeed not regenerated by reconfigure. To update this files (which are only informative) one should use Rescan in the ViewTeX Information dialog. John Bug 2: LyX ignores LaTeX ClassOptions placed in a layout file, John apparently contrary to what is implied in Section 5.3.2 of the John Customization Guide. This is a problem of bad interface (and therefore probably a bug). When one creates a new document, it does use the value of ClassOptions/Other of the class (which is in general article). If you change the class later to revtex4, the options are not changed unless you use the 'Use class defaults' button. I am not sure what the right behaviour should be, since people do not necessarily want to have options changed silently when changing class. John Bug 3: Trying to use Insert = Lists TOC = List of Figures John results in errors. According to the RevTeX Home Page dated 3 John August 2001 (the latest available), \listoffigures is broken, so John the bug may be with LaTeX rather than LyX. It seems indeed to be on the LaTeX side. I do not know how to fix it. John Bug 4: JASA now has new manuscript submission requirements in John which the figures are submitted separately from the text. There John seems to be no way using LyX to omit the figures from the John manuscript (while keeping the captions in a separate list). The package endfloats can do that automatically for you. This should be coded in the latex class file. John But these are messy ways to introduce scientists and engineers John to using LyX in place of what they are using. All except the John dedicated are likely to see LyX and its advantages as taking too John much time, and ignore it. I agree that these problems should be fixed. John Any suggestions before I send what I have to the JASA John Editor-in-Chief would be most welcome. I'm also willing to send John what I have to you, but the above bugs will limit its John usefulness. How much time do you have? JMarc
Re: Patches to update AASTeX support
On Tue, 2005-02-08 at 17:11 +0100, Jean-Marc Lasgouttes wrote: Mike == Mike Ressler [EMAIL PROTECTED] writes: Mike P.S. In the 2nd to last section of Extended (7.6 Non-standard Mike Paragraph Shapes), please put a page break immediately before Mike the section title, so that the funky paragraph is guaranteed to Mike be on one page, not split over two like it is now. Thanks. Hmm, is it really a problem to have it on several pages? Yes, because you lose the flying wing shape effect. Look at the DVI preview - I'll think you'll appreciate my point :-) Thanks for checking in the patches. Mike -- Mike Ressler [EMAIL PROTECTED]
Feature Request: split window DVI viewer with LyX
Regardless of what people say, non-trivial Latex documents involving mathematical notation or code samples almost always require last minute tweaking because the math or code environments don't wrap correctly and make ugly things occur. It would be very useful during the final phases of document preparation, when you do care what the rendered document looks like, to have a debug mode consisting of a split panel window with one side containing the DVI viewer of a constantly updated render of the paper alongside the LyX editor. I guess since some people hate split panel windows, it might be a good idea to have an option to have two separate windows too, as it is now, but with the added synchronization features, such that the rendered paper is constantly automatically updated and the scrolling is locked between the DVI viewer and the LyX editor. So if I need to tweak something I see as I am flipping through the DVI viewer, the LyX editor is automatically scrolled to that part of the document. Currently the DVI viewing behavior is very unproductive as it requires the following process: 1. ctrl-D 2. resize/zoom DVI viewer so that things aren't microscopic 3. page down in DVI viewer to check for ugly things 4. scroll in LyX to corresponding location 5. make changes 6. close DVI viewer 7. goto 1 A split sync'ed panel or sync'ed double window approach would be much more productive, and that is the entire point of LyX to begin with: improve your productivity. I love watching people hand edit Latex documents and spend lots of time figuring out where their syntax error is... that or trying to remember a certain command. I keep telling them to give LyX a try. thanks, luke
Feature Request: Uber Document Class
It would be very useful to have a document class that contained a union of all known environments, so that in the early stages of writing a paper, before you know exactly where you are going to submit it, you could write it in the Uber Document Class and use environments as needed. Then when you needed to actually submit the rendered PDF, you could change the document class to a specific one and the environments would be mapped to existing environments in that corresponding class and if they didn't exist, then a predefined mapping for the target class defined how to emulate the environment. For example, some classes contain some subset of special environments for addresses, phone numbers, email addresses, proofs, lemmas, theorems, corollaries, etc, and since there is no, as far as I know, class that contains all of them, you are forced to guess your best match and then later do allot of manual changes to properly use the final target document class. An Uber Document Class might seem like overkill, but for the very early stages of writing, I think it would be very useful, and in the long run it would improve productivity of writing.
Re: Feature Request: split window DVI viewer with LyX
Luke == Luke Simon [EMAIL PROTECTED] writes: Luke So if I need to tweak something I see as I am flipping through Luke the DVI viewer, the LyX editor is automatically scrolled to that Luke part of the document. LyX 1.4.0 will allow you to click on the xdvi image an have the cursor set on the corresponding part of the lyx document. Luke Currently the DVI viewing behavior is very unproductive as it Luke requires the following process: Luke 1. ctrl-D 2. resize/zoom DVI viewer so that things aren't Luke microscopic 3. page down in DVI viewer to check for ugly things Luke 4. scroll in LyX to corresponding location 5. make changes 6. Luke close DVI viewer 7. goto 1 That is why ViewUpdateDVI exists. It even has a shortcut: Shift-Ctrl-D. Luke A split sync'ed panel or sync'ed double window approach would be Luke much more productive, and that is the entire point of LyX to Luke begin with: improve your productivity. I love watching people Luke hand edit Latex documents and spend lots of time figuring out Luke where their syntax error is... that or trying to remember a Luke certain command. I keep telling them to give LyX a try. The problem is that this is difficult to do. What we have, though, is inline preview of math equations. JMarc
Re: Partitioning lines in matrices
Martin Vermeer wrote: 1) What about getStatus... appears disabled. Can you explain that please? I don't understand the question. Georg
Re: [PATCH] UI: matrix partitioning
Martin Vermeer wrote:
+void MathGridInset::horLine(row_type row)
+{
+if (nrows() == 1)
+return;
+if (row + 1 == nrows())
+--row;
+rowinfo_[row].lines_++;
+}
I don't understand this. I understand that this method adds a line above the
row. I would think that it should look like
void MathGridInset::addHLineAbove(row_type row)
{
if (row == 0)
// Only if we don't want a line above the first row;
return;
if (row = nrows())
return;
rowinfo_[row].lines_++;
}
IMO it should simply return if the line cannot be added.
Another question: What about lines above the first row and below the last? I
believe that this is possible in LaTeX, but how to support it here? I can't
think of a better way than having an addHLineBelow() etc.
And getStatus needs to be updated to disable addHLineAbove if the cursor is
in the first row.
Of course the same things should be done for the other h- and vline methods.
@@ -1100,6 +1140,10 @@
copyRow(cur.row());
else if (s == swap-row)
swapRow(cur.row());
+else if (s == hor-line)
+horLine(cur.row());
+else if (s == delete-hor-line)
+rmHorLine(cur.row());
I would prefer add-hline-above, delete-hline-above etc.
Georg
Crash while Ctrl+click on tabular material
Hello, I pressed (Ctrl or alt, I wasn't really aware) + clicking the mouse on a Tabular Material in Lyx. Lyx crashed. That is the bug report Apple wants me to send back. I send it back to you. (I run a Mac OS X). This little crash doesn't really bother me, and I do not wait for an answer. Cordialement, YZIQUEL Guillaume Date/Time: 2005-02-06 16:23:38 +0100 OS Version: 10.3.4 (Build 7L46) Report Version: 2 Command: LyX Path:/Applications/LyX.app/Contents/MacOS/LyX Version: 1.3.4 (???) PID: 7932 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 0 Crashed: 0 0x 0 + 0 1 com.18james.lyx 0x00869248 0x1000 + 0x868248 2 com.18james.lyx 0x001ec3b0 0x1000 + 0x1eb3b0 3 com.18james.lyx 0x001ec9c4 0x1000 + 0x1eb9c4 4 com.18james.lyx 0x001ec898 0x1000 + 0x1eb898 5 com.18james.lyx 0x0014bdbc 0x1000 + 0x14adbc 6 com.18james.lyx 0x0019b720 0x1000 + 0x19a720 7 com.18james.lyx 0x0019ba58 0x1000 + 0x19aa58 8 com.18james.lyx 0x00119644 0x1000 + 0x118644 9 com.18james.lyx 0xf620 0x1000 + 0xe620 10 com.18james.lyx 0x007eb18c 0x1000 + 0x7ea18c 11 com.18james.lyx 0x008b9fc0 0x1000 + 0x8b8fc0 12 com.18james.lyx 0x003cb268 0x1000 + 0x3ca268 13 com.18james.lyx 0x00262490 0x1000 + 0x261490 14 com.18james.lyx 0x00277fac 0x1000 + 0x276fac 15 com.18james.lyx 0x00277a1c 0x1000 + 0x276a1c 16 com.18james.lyx 0x00296c68 0x1000 + 0x295c68 17 com.apple.HIToolbox 0x92852330 DispatchEventToHandlers + 0x150 18 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 19 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 20 com.apple.HIToolbox 0x928731b4 HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 0x144 21 com.apple.HIToolbox 0x92868ad0 HandleMouseEvent(OpaqueEventRef*) + 0x170 22 com.apple.HIToolbox 0x92862fd4 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 0x1e8 23 com.apple.HIToolbox 0x928523ec DispatchEventToHandlers + 0x20c 24 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 25 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 26 com.18james.lyx 0x00295664 0x1000 + 0x294664 27 com.18james.lyx 0x0040e288 0x1000 + 0x40d288 28 com.18james.lyx 0x00436fa4 0x1000 + 0x435fa4 29 com.18james.lyx 0x00278050 0x1000 + 0x277050 30 com.18james.lyx 0x00869a58 0x1000 + 0x868a58 31 com.18james.lyx 0x001ec99c 0x1000 + 0x1eb99c 32 com.18james.lyx 0x001ec898 0x1000 + 0x1eb898 33 com.18james.lyx 0x0014bdbc 0x1000 + 0x14adbc 34 com.18james.lyx 0x0019b720 0x1000 + 0x19a720 35 com.18james.lyx 0x0019ba58 0x1000 + 0x19aa58 36 com.18james.lyx 0x00119644 0x1000 + 0x118644 37 com.18james.lyx 0xf620 0x1000 + 0xe620 38 com.18james.lyx 0x007eb18c 0x1000 + 0x7ea18c 39 com.18james.lyx 0x008b9fc0 0x1000 + 0x8b8fc0 40 com.18james.lyx 0x003cb268 0x1000 + 0x3ca268 41 com.18james.lyx 0x00262490 0x1000 + 0x261490 42 com.18james.lyx 0x00277fac 0x1000 + 0x276fac 43 com.18james.lyx 0x00277a1c 0x1000 + 0x276a1c 44 com.18james.lyx 0x00296c68 0x1000 + 0x295c68 45 com.apple.HIToolbox 0x92852330 DispatchEventToHandlers + 0x150 46 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 47 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 48 com.apple.HIToolbox 0x928731b4 HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 0x144 49 com.apple.HIToolbox 0x92868ad0 HandleMouseEvent(OpaqueEventRef*) + 0x170 50 com.apple.HIToolbox 0x92862fd4 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 0x1e8 51 com.apple.HIToolbox 0x928523ec DispatchEventToHandlers + 0x20c 52 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 53 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 54 com.18james.lyx 0x00295664 0x1000 + 0x294664 55 com.18james.lyx 0x0040e288 0x1000 + 0x40d288 56 com.18james.lyx 0x00436e44 0x1000 + 0x435e44 57 com.18james.lyx 0x00436d2c 0x1000 + 0x435d2c 58 com.18james.lyx 0x00278154 0x1000 + 0x277154 59 com.18james.lyx 0x001c3198 0x1000 + 0x1c2198 60 com.18james.lyx 0x00090ed4 0x1000 + 0x8fed4 61 com.18james.lyx 0x000d9aec 0x1000 + 0xd8aec 62 com.18james.lyx 0x280c 0x1000 + 0x180c 63 com.18james.lyx 0x2680 0x1000 + 0x1680 PPC Thread State: srr0: 0x srr1: 0x4200f930vrsave: 0x cr: 0x2404 xer: 0x0004 lr: 0x002e27c4 ctr: 0x r0: 0x r1: 0xbfffdb60 r2: 0x0204b200 r3: 0x05415c50 r4: 0x0001 r5: 0x004c r6: 0x0074 r7: 0x514c696e r8: 0x5174 r9: 0x00b485cc r10: 0x504b686d r11: 0x4404 r12:
Re: Feature Request: split window DVI viewer with LyX
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: The problem is that this is difficult to do. What we have, though, is inline preview of math equations. So why don't we add preview for paragraphs? :-) You leave the paragraph, LyX creates a preview for this paragraph, inserting a page break if necessary, and voil! No need for split windows etc. You click into the paragraph again and the usual LyX insets appear. Shouldn't be too difficult, once math preview and cursorUpDown are stable ;-) Ciao /Andreas
Re: Feature Request: Uber Document Class
Luke Simon [EMAIL PROTECTED] writes: It would be very useful to have a document class that contained a union of all known environments, so that in the early stages of writing a paper, before you know exactly where you are going to submit it, you could write it in the Uber Document Class and use environments as needed. Then when you needed to actually submit the rendered PDF, you could change the document class to a specific one and the environments would be mapped to existing environments in that corresponding class and if they didn't exist, then a predefined mapping for the target class defined how to emulate the environment. I don't think a so-called ber-Documentclass would be very helpful. The difficult part is to define the mapping from one environment to another. Once you have that, you could as well switch between classes directly. What I would like is a way that package introduce new layouts into a document. Then you could produce your own modular ber-textclass. For example, some classes contain some subset of special environments for addresses, phone numbers, email addresses, proofs, lemmas, theorems, corollaries, etc, and since there is no, as far as I know, class that contains all of them, you are forced to guess your best match and then later do allot of manual changes to properly use the final target document class. You can try that for yourself now already: Just create a new uber.layout which includes all the layouts you want. You might need to cutpaste a little to avoid certain conflicts, but then there you are. When you change from this class to an unter-textclass you will get errormessages for any paragraph whose layout can't be mapped. BTW, any volunteers who want to enhance this error dialog to allow userdefined mappings? :-) Ciao /Andreas
Re: [PATCH] UI: matrix partitioning
On Tue, 2005-02-08 at 19:25 +0100, Georg Baum wrote:
Martin Vermeer wrote:
+void MathGridInset::horLine(row_type row)
+{
+if (nrows() == 1)
+return;
+if (row + 1 == nrows())
+--row;
+rowinfo_[row].lines_++;
+}
I don't understand this. I understand that this method adds a line above the
row. I would think that it should look like
void MathGridInset::addHLineAbove(row_type row)
{
if (row == 0)
// Only if we don't want a line above the first row;
return;
if (row = nrows())
return;
rowinfo_[row].lines_++;
}
IMO it should simply return if the line cannot be added.
You're even righter than you think: these conditions are not needed when
you think about it, so I just removed all of them.
Another question: What about lines above the first row and below the last? I
believe that this is possible in LaTeX, but how to support it here? I can't
think of a better way than having an addHLineBelow() etc.
No, neither can I. But as there is no support for this in the current
mathed infrastructure, implementing this would go much further than just
fixing a broken UI. For 1.5?
And getStatus needs to be updated to disable addHLineAbove if the cursor is
in the first row.
How? If I look at getStatus for math_gridinset, I see a lot of stuff
commented out. Is this supposed to work at all, and how?
Of course the same things should be done for the other h- and vline methods.
@@ -1100,6 +1140,10 @@
copyRow(cur.row());
else if (s == swap-row)
swapRow(cur.row());
+else if (s == hor-line)
+horLine(cur.row());
+else if (s == delete-hor-line)
+rmHorLine(cur.row());
I would prefer add-hline-above, delete-hline-above etc.
Yes, good proposal.
Georg
New patch attached.
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.671
diff -u -r1.671 ChangeLog
--- lib/ChangeLog 8 Feb 2005 10:41:58 - 1.671
+++ lib/ChangeLog 8 Feb 2005 20:03:36 -
@@ -1,3 +1,9 @@
+2005-02-08 Martin Vermeer [EMAIL PROTECTED]
+
+ * ui/stdmenus.ui: add methods addHLineAbove, deleteHLineAbove,
+ addVLineLeft, deleteVLineLeft for drawing/deleting partition lines
+ in matrix
+
2005-02-08 Mike Ressler [EMAIL PROTECTED]
* layouts/aastex.layout: Updated for AASTeX 5.2
Index: src/mathed/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.468
diff -u -r1.468 ChangeLog
--- src/mathed/ChangeLog 31 Jan 2005 16:29:47 - 1.468
+++ src/mathed/ChangeLog 8 Feb 2005 20:03:37 -
@@ -1,3 +1,9 @@
+2005-02-08 Martin Vermeer [EMAIL PROTECTED]
+
+ * math_gridinset.[hC]: add methods addHLineAbove, deleteHLineAbove,
+ addVLineLeft, deleteVLineLeft for drawing/deleting partition lines in
+ matrix.
+
2005-01-31 Asger Ottar Alstrup [EMAIL PROTECTED]
* math_data.C:
Index: src/mathed/math_gridinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.C,v
retrieving revision 1.154
diff -u -r1.154 math_gridinset.C
--- src/mathed/math_gridinset.C 24 Nov 2004 21:58:41 - 1.154
+++ src/mathed/math_gridinset.C 8 Feb 2005 20:03:37 -
@@ -679,6 +679,30 @@
}
+void MathGridInset::addHLineAbove(row_type row)
+{
+ rowinfo_[row].lines_++;
+}
+
+
+void MathGridInset::deleteHLineAbove(row_type row)
+{
+ rowinfo_[row].lines_ = 0;
+}
+
+
+void MathGridInset::addVLineLeft(col_type col)
+{
+ colinfo_[col].lines_++;
+}
+
+
+void MathGridInset::deleteVLineLeft(col_type col)
+{
+ colinfo_[col].lines_ = 0;
+}
+
+
void MathGridInset::addCol(col_type newcol)
{
const col_type nc = ncols();
@@ -1100,6 +1124,10 @@
copyRow(cur.row());
else if (s == swap-row)
swapRow(cur.row());
+ else if (s == add-hline-above)
+ addHLineAbove(cur.row());
+ else if (s == delete-hline-above)
+ deleteHLineAbove(cur.row());
else if (s == append-column)
for (int i = 0, n = extractInt(is); i n; ++i) {
row_type r = cur.row();
@@ -1120,6 +1148,10 @@
copyCol(col(cur.idx()));
else if (s == swap-column)
swapCol(col(cur.idx()));
+ else if (s == add-vline-left)
+ addVLineLeft(col(cur.idx()));
+ else if (s == delete-vline-left)
+ deleteVLineLeft(col(cur.idx()));
else {
cur.undispatched();
break;
Index: src/mathed/math_gridinset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.h,v
retrieving revision 1.85
diff -u -r1.85 math_gridinset.h
--- src/mathed/math_gridinset.h 19 Jan 2005 15:03:31 - 1.85
+++
Re: Bug 1119: is LyX multithreaded after all?
Martin Vermeer [EMAIL PROTECTED] writes: // FIXME! Should check that the dialog IS an inset dialog. - dialog-show(data); open_insets_[name] = inset; + dialog-show(data); That seems rather clear to me. As I understand (Angus would know) this open_insets_ table keeps track of which insets have their dialog open, so it doesn't try to open the same dialogue a second time. It looked clear to me also, before I scanned the code for uses of getOpenInsets() ... ;-) Before the patch, the first opening process starts before the dialog is registered, and as it takes a little time (especially the first time, when the code has to be loaded into memory), the second click manages to start a second opening process *for the same inset* -- a race condition. I found out that the code for Inset::showDIalog() doesn't use getOpenInsets(), so it shouldn't matter :-( GetOpenInsets() is only used for LFUN_DIALOG_APPLY and LFUN_INSET_APPLY. I still get a crash, but now it's related to the previews... another source of multithreading. So I guess the race condition is there, we just haven't figured out its exact shape yet. Ciao /Andreas
Re: Crash while Ctrl+click on tabular material
Guillaume Yziquel [EMAIL PROTECTED] writes: I pressed (Ctrl or alt, I wasn't really aware) + clicking the mouse on a Tabular Material in Lyx. Lyx crashed. That should be the CTRL key, since that emulates the right mousebutton on Mac. That is the bug report Apple wants me to send back. I send it back to you. (I run a Mac OS X). Not very useful without the debugging symbols (LyX binary was stripped) This could be related to Bug 1119. Can anyone try to reproduce it with 1.3 for Qt? (Try doubleclicking) I can't with my latest patches on 1.4. Ciao /Andreas
Hypertext links in LyX documents
Regarding the ability to create hypertext links in LyX documents (originated in a discussion on the lyx-docs list) Jean-Marc wrote: chr * Link to another part of the same document (this we have chr already, right?) Yes, but this means using a reference that will appear in the printout. This is not like an hypertext reference. chr * Link to another document? chr * Link to another part inside another document? We do not have these, and it is a pity. Do people in general agree that it makes sense to have hypertext links in .lyx-files? Or is this something that doesn't make sense since LyX, assuming LyX is primarily supposed to produced printed documents? The open question is how a hypertext link should be rendered when exporting to a printed target? But... wait a minute, can't PDFs have hypertext links? How are they created in LyX today? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Patch] gimmick: show word frequencies in new buffer
On 7.02.05, Andreas Vox wrote: > Am 07.02.2005 um 13:37 schrieb Helge Hafting: > > Perhaps the program shouldn't add the entries at all, just move from > > word to word and ask wether to add an entry at that point? > > Good point. OTOH this would have to be repeated with every index word. > Maybe an additional function which acts as a kind of search and replace, > maybe even with regular expressions? Why not have functions for selecting/unselecting words (like the midnight commander) including "(un)select-all", "(un)select-regexp-match", "inverse-selecting", ... and finally apply an "index-selected". It would be nice, if (other than mc) the selection would be remembered if I go to look closer at one word/occurence. So my idea would be 1.) create an index list widget with * "index-new": the alphabetically sorted list. * "index-edit": a list of existing index insets Have foldable items: * folded: word and number of occurences * unfolded: a button for each occurence showing the section/chapter/figure/table the word occures (we do not have pages at this stage). Pressing the button jumps to the occurence. (I would not use a buffer for this list (as long as LyX can show only one buffer), so that one can see both, the list and the context at the same time.) 2.) Edit the index buffer: Select entries, delete entries, change the ordering, collate entries, create, subitems, ... It would be nice to have a way for "muted" index entries -- keep them in the list (just in case) but do not show them in the index. 3.) Update the text from the index list: create index insets for selected items (with chosen change params) Günter -- G.Milde web.de
Re: Bugs in LyX 1.3.5
On Mon, Feb 07, 2005 at 09:24:11PM -1000, John Burgess wrote: > In the process, I've come across some bugs. John, it's most helpful to us if you file these bugs in http://bugzilla.lyx.org/ (one bug per report please!) thanks, john
Re: [Patch] gimmick: show word frequencies in new buffer
Andreas Vox wrote: Also, make sure this thing does not get in the way of indexing whole phrases, math expressions, images and other stuff that don't show up in a wordlist. Well, I guess it doesn't, but still. Once there is index markup in place the system should handle it conservatively. Nice. :-) I suspected this, but tried to be careful. Sometimes a cumbersome but working solution gets replaced by an easier solution with a few missing points. I was merely making sure that didn't happen here. Finally, and most important: Autoindexing every occurence of some index-worthy word often yields a useless index. Perhaps there are cases where such indexing is mandatory. But for an ordinary book the requirement is not to index every occurence of some word, but the 1,2 or 3 most important places the word occur. Few people want to mess around with "word, 1,2,6,8,12-16, 14, 18,19,22, 25-31,36" only to discover that "word" is thorougly explained on page 14 and 26-28, and all the other references merely mention "word" briefly. But removing index references from that list using the jump function from below should be easier than the other way round. Maybe I don't understand. We have to go through the entire document anyway, don't we? Your way: Wel look at every occurence of every indexworthy word, which has been added to the index already. Many of them gets removed from the index, because we only want to index a given word in 2-3 places. My way: We look at every occurence of every indexworthy word, and makes a decision wether to index it at this point. Each word gets indexed 2-3 times, the rest of the time we skip to the next place. Either way, the big job is in looking at every occurence of every indexworthy word. I believe that in my case, there is some extra work adding a few indices per word. In your case, I belive there will be more extra work, in removing quite a few indices per word. Good point. OTOH this would have to be repeated with every index word. Repeating over every word is necessary anyway - wther we add or remove indices. Maybe an additional function which acts as a kind of search and replace, maybe even with regular expressions? Sure, that would be nice. Make that, and it'll be instantly popular. :-) The way of index editing I fancy right now would consist of the following functions: 1.) create an initial index from all words minus stop words. Insert the index references and open an index buffer with the alphabetically sorted list. Suggestion: Make the initial wordlist. Have the user prune this (because the stop-word list cannot possibly contain every word we don't want to index. It can only contain common ones like "a", "the", ...) Then proceed to the next step. 2.) Edit the index buffer: Delete entries, change the ordering, collate entries, create subitems, ... Are you proposing an index buffer that sort of looks like an index page and do the editing there? Such a thing is very nice for adjusting the layout of the index, obviously. One or two columns? font? Heading for each letter? Layout for that header? But I am not so sure it will be useful for the actual indexing. A word that is indexed several places may have one very important place and we want that page number to be set in itralics, for example. I think that is better done by working on the index entry (the existing index entry box that currently doesn't support the fancy stuff, but it could be made into doing that.) The reason? Only by looking at the text can I see wether this is the _important_ entry (say, the definition) or merely some case that I also want to index. 3.) Have a jump function from an entry in the index buffer to the occurence and between occurences, and back. Well, yes, certainly useful. Be aware that a word indexed multiple times on one page only get one entryin the index. 4.) Update the text from the index buffer: delete unwanted index insets, change params of index insets, add new index insets. How would you add a new one? Well, the "foo *see* bar" type entries would go here, but all other entries refer to some specific page. They do so because they are anchored to some part of the text - surely you know that the actual page number cannot be known inside lyx. Adding a new entry requires that one goes into the text at the approprioate point - but then it is no longer done from your index editor. It is done in the text as always. 5.) Regenerate the index buffer with existing entries, a la makeindex. The index buffer would only be WYSIWYM of the true index: back references to index insets instead of pagenumbers, key and actual text both visible, word frequency as a hint, ... You'll find that page ranges are partially supported already, an index entry that is repeated on several consecutive pages is automatically coalesced to a range. :-) Yeah, but what if you want to index a whole chapter, like "Algorithms, p132--211" ? ;-)
Re: [PATCH] UI: matrix partitioning
Martin Vermeer <[EMAIL PROTECTED]> writes: | +2005-02-08 Martin Vermeer <[EMAIL PROTECTED]> | + | + * math_gridinset.[hC]: add methods horLine, rmHorLine, | + vertLine, rmVertLine for drawing/deleting partition lines | + in matrix Please use less cryptic names. Spell it out. Both functions and feature names please. -- Lgb
Re: [PATCH] UI: matrix partitioning
On Tue, 2005-02-08 at 15:14, Lars Gullik BjÃnnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > | +2005-02-08 Martin Vermeer <[EMAIL PROTECTED]> > > | + > > | + * math_gridinset.[hC]: add methods horLine, rmHorLine, > > | + vertLine, rmVertLine for drawing/deleting partition lines > > | + in matrix > > > Please use less cryptic names. Spell it out. > > Both functions and feature names please. What would you consider legible? delHorLine? deleteHorizontalLineAbove? I'm happy to please :-) - Martin signature.asc Description: This is a digitally signed message part
Re: [PATCH] UI: matrix partitioning
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> What would you consider legible? delHorLine? Martin> deleteHorizontalLineAbove? I'm happy to please :-) I would say delete is better than rm because we use that term. And we use HLine too in tabular. So I would propose deleteHLine. JMarc
Re: [PATCH] UI: matrix partitioning
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Tue, 2005-02-08 at 15:14, Lars Gullik Bjønnes wrote: >> Martin Vermeer <[EMAIL PROTECTED]> writes: >> >> | +2005-02-08 Martin Vermeer <[EMAIL PROTECTED]> >> >> | + >> >> | + * math_gridinset.[hC]: add methods horLine, rmHorLine, >> >> | + vertLine, rmVertLine for drawing/deleting partition lines >> >> | + in matrix >> >> >> Please use less cryptic names. Spell it out. >> >> Both functions and feature names please. > | What would you consider legible? delHorLine? deleteHorizontalLineAbove? yeah. but since we have hline in latex we would probably understand that deleteHLineAbove (except that it isn't a hline is it?) | I'm happy to please :-) How nice of you :-) -- Lgb
Re: [Patch] gimmick: show word frequencies in new buffer
Am 08.02.2005 um 14:01 schrieb Helge Hafting: Andreas Vox wrote: But removing index references from that list using the jump function from below should be easier than the other way round. Maybe I don't understand. We have to go through the entire document anyway, don't we? No, I'd use the jump function just to check the context. If I know the conhtext already I can select the references in the index buffer I don't want and delete them. If I don't like a word, I can delete the whole line with all references. Maybe an additional function which acts as a kind of search and replace, maybe even with regular expressions? Sure, that would be nice. Make that, and it'll be instantly popular. :-) As we say around here, we can do one thing and not refrain from the other :-) Then the users can decide what they like best. The way of index editing I fancy right now would consist of the following functions: 1.) create an initial index from all words minus stop words. Insert the index references and open an index buffer with the alphabetically sorted list. Suggestion: Make the initial wordlist. Have the user prune this (because the stop-word list cannot possibly contain every word we don't want to index. It can only contain common ones like "a", "the", ...) Then proceed to the next step. You can do that in the second step. 2.) Edit the index buffer: Delete entries, change the ordering, collate entries, create subitems, ... Are you proposing an index buffer that sort of looks like an index page and do the editing there? Such a thing is very nice for adjusting the layout of the index, obviously. One or two columns? font? Heading for each letter? Layout for that header? No, I don't want to do physical layout here... The idea is to have all index entries at one place, with a list of all occurences. Then you can collate entries, delete unwanted occurences, edit the actual rendering, introduce subitems ... But I am not so sure it will be useful for the actual indexing. A word that is indexed several places may have one very important place and we want that page number to be set in itralics, for example. I think that is better done by working on the index entry (the existing index entry box that currently doesn't support the fancy stuff, but it could be made into doing that.) The reason? Only by looking at the text can I see wether this is the _important_ entry (say, the definition) or merely some case that I also want to index. It all boils down to how much of the context of each occurance is visible from the index buffer. I thought the jump function would be enough, but maybe the chapter/section number or the surrounding sentence should be visible also. 3.) Have a jump function from an entry in the index buffer to the occurence and between occurences, and back. Well, yes, certainly useful. Be aware that a word indexed multiple times on one page only get one entryin the index. In the index, yes, in the index buffer, no. 4.) Update the text from the index buffer: delete unwanted index insets, change params of index insets, add new index insets. How would you add a new one? Good point. Copy an existing index entry for a new index term? Something like a reverse "see"? But you are right, that would be the exception. New entries are either generated from the wordlist or manually in the text or with the regexp-insert-index function. Ciao /Andreas
Re: Bugs in LyX 1.3.5
> "John" == John Burgess <[EMAIL PROTECTED]> writes: John> I've been using LyX since v 1.1?. I used it last year to write John> an article for JASA (published in the July 2004 issue). It was John> actually a test run based on a RevTeX 4 modification for JASA John> using LaTeX. I had to write the layout file. Now I'm preparing John> an article for the Editor-in-Chief about how to use LyX with John> BibTeX for JASA article preparation, including template files. We would be interested to distribute the layout file with LyX... What cls file do you use? John> In the process, I've come across some bugs. John> Bug 1: Edit => Reconfigure updates only John> $HOME/.lyx/textclass.lst. But it doesn't update bstFiles.lst, John> clsFiles.lst, and styFiles.lst unless they are first manually John> removed. Only textclass.lst is needed for the proper operation of LyX, and the other ones are indeed not regenerated by reconfigure. To update this files (which are only informative) one should use Rescan in the View>TeX Information dialog. John> Bug 2: LyX ignores LaTeX ClassOptions placed in a layout file, John> apparently contrary to what is implied in Section 5.3.2 of the John> Customization Guide. This is a problem of bad interface (and therefore probably a bug). When one creates a new document, it does use the value of ClassOptions/Other of the class (which is in general article). If you change the class later to revtex4, the options are not changed unless you use the 'Use class defaults' button. I am not sure what the right behaviour should be, since people do not necessarily want to have options changed silently when changing class. John> Bug 3: Trying to use Insert => Lists & TOC => List of Figures John> results in errors. According to the RevTeX Home Page dated 3 John> August 2001 (the latest available), \listoffigures is broken, so John> the bug may be with LaTeX rather than LyX. It seems indeed to be on the LaTeX side. I do not know how to fix it. John> Bug 4: JASA now has new manuscript submission requirements in John> which the figures are submitted separately from the text. There John> seems to be no way using LyX to omit the figures from the John> manuscript (while keeping the captions in a separate list). The package endfloats can do that automatically for you. This should be coded in the latex class file. John> But these are messy ways to introduce scientists and engineers John> to using LyX in place of what they are using. All except the John> dedicated are likely to see LyX and its advantages as taking too John> much time, and ignore it. I agree that these problems should be fixed. John> Any suggestions before I send what I have to the JASA John> Editor-in-Chief would be most welcome. I'm also willing to send John> what I have to you, but the above bugs will limit its John> usefulness. How much time do you have? JMarc
Re: Patches to update AASTeX support
On Tue, 2005-02-08 at 17:11 +0100, Jean-Marc Lasgouttes wrote: > > "Mike" == Mike Ressler <[EMAIL PROTECTED]> writes: > Mike> P.S. In the 2nd to last section of Extended (7.6 Non-standard > Mike> Paragraph Shapes), please put a page break immediately before > Mike> the section title, so that the funky paragraph is guaranteed to > Mike> be on one page, not split over two like it is now. Thanks. > > Hmm, is it really a problem to have it on several pages? Yes, because you lose the "flying wing" shape effect. Look at the DVI preview - I'll think you'll appreciate my point :-) Thanks for checking in the patches. Mike -- Mike Ressler [EMAIL PROTECTED]
Feature Request: split window DVI viewer with LyX
Regardless of what people say, non-trivial Latex documents involving mathematical notation or code samples almost always require last minute tweaking because the math or code environments don't wrap correctly and make ugly things occur. It would be very useful during the final phases of document preparation, when you do care what the rendered document looks like, to have a "debug mode" consisting of a split panel window with one side containing the DVI viewer of a constantly updated render of the paper alongside the LyX editor. I guess since some people hate split panel windows, it might be a good idea to have an option to have two separate windows too, as it is now, but with the added synchronization features, such that the rendered paper is constantly automatically updated and the scrolling is locked between the DVI viewer and the LyX editor. So if I need to tweak something I see as I am flipping through the DVI viewer, the LyX editor is automatically scrolled to that part of the document. Currently the DVI viewing behavior is very unproductive as it requires the following process: 1. ctrl-D 2. resize/zoom DVI viewer so that things aren't microscopic 3. page down in DVI viewer to check for ugly things 4. scroll in LyX to corresponding location 5. make changes 6. close DVI viewer 7. goto 1 A split sync'ed panel or sync'ed double window approach would be much more productive, and that is the entire point of LyX to begin with: improve your productivity. I love watching people hand edit Latex documents and spend lots of time figuring out where their syntax error is... that or trying to remember a certain command. I keep telling them to give LyX a try. thanks, luke
Feature Request: Uber Document Class
It would be very useful to have a document class that contained a union of all known environments, so that in the early stages of writing a paper, before you know exactly where you are going to submit it, you could write it in the "Uber Document Class" and use environments as needed. Then when you needed to actually submit the rendered PDF, you could change the document class to a specific one and the environments would be mapped to existing environments in that corresponding class and if they didn't exist, then a predefined mapping for the target class defined how to emulate the environment. For example, some classes contain some subset of special environments for addresses, phone numbers, email addresses, proofs, lemmas, theorems, corollaries, etc, and since there is no, as far as I know, class that contains all of them, you are forced to guess your best match and then later do allot of manual changes to properly use the final target document class. An Uber Document Class might seem like overkill, but for the very early stages of writing, I think it would be very useful, and in the long run it would improve productivity of writing.
Re: Feature Request: split window DVI viewer with LyX
> "Luke" == Luke Simon <[EMAIL PROTECTED]> writes: Luke> So if I need to tweak something I see as I am flipping through Luke> the DVI viewer, the LyX editor is automatically scrolled to that Luke> part of the document. LyX 1.4.0 will allow you to click on the xdvi image an have the cursor set on the corresponding part of the lyx document. Luke> Currently the DVI viewing behavior is very unproductive as it Luke> requires the following process: Luke> 1. ctrl-D 2. resize/zoom DVI viewer so that things aren't Luke> microscopic 3. page down in DVI viewer to check for ugly things Luke> 4. scroll in LyX to corresponding location 5. make changes 6. Luke> close DVI viewer 7. goto 1 That is why View>Update>DVI exists. It even has a shortcut: Shift-Ctrl-D. Luke> A split sync'ed panel or sync'ed double window approach would be Luke> much more productive, and that is the entire point of LyX to Luke> begin with: improve your productivity. I love watching people Luke> hand edit Latex documents and spend lots of time figuring out Luke> where their syntax error is... that or trying to remember a Luke> certain command. I keep telling them to give LyX a try. The problem is that this is difficult to do. What we have, though, is inline preview of math equations. JMarc
Re: Partitioning lines in matrices
Martin Vermeer wrote: > 1) What about getStatus... appears disabled. Can you explain that please? I don't understand the question. Georg
Re: [PATCH] UI: matrix partitioning
Martin Vermeer wrote:
> +void MathGridInset::horLine(row_type row)
> +{
> +if (nrows() == 1)
> +return;
> +if (row + 1 == nrows())
> +--row;
> +rowinfo_[row].lines_++;
> +}
I don't understand this. I understand that this method adds a line above the
row. I would think that it should look like
void MathGridInset::addHLineAbove(row_type row)
{
if (row == 0)
// Only if we don't want a line above the first row;
return;
if (row >= nrows())
return;
rowinfo_[row].lines_++;
}
IMO it should simply return if the line cannot be added.
Another question: What about lines above the first row and below the last? I
believe that this is possible in LaTeX, but how to support it here? I can't
think of a better way than having an addHLineBelow() etc.
And getStatus needs to be updated to disable addHLineAbove if the cursor is
in the first row.
Of course the same things should be done for the other h- and vline methods.
> @@ -1100,6 +1140,10 @@
> copyRow(cur.row());
> else if (s == "swap-row")
> swapRow(cur.row());
> +else if (s == "hor-line")
> +horLine(cur.row());
> +else if (s == "delete-hor-line")
> +rmHorLine(cur.row());
I would prefer add-hline-above, delete-hline-above etc.
Georg
Crash while Ctrl+click on tabular material
Hello, I pressed (Ctrl or alt, I wasn't really aware) + clicking the mouse on a "Tabular Material" in Lyx. Lyx crashed. That is the bug report Apple wants me to send back. I send it back to you. (I run a Mac OS X). This little crash doesn't really bother me, and I do not wait for an answer. Cordialement, YZIQUEL Guillaume Date/Time: 2005-02-06 16:23:38 +0100 OS Version: 10.3.4 (Build 7L46) Report Version: 2 Command: LyX Path:/Applications/LyX.app/Contents/MacOS/LyX Version: 1.3.4 (???) PID: 7932 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 0 Crashed: 0 <<>> 0x 0 + 0 1 com.18james.lyx 0x00869248 0x1000 + 0x868248 2 com.18james.lyx 0x001ec3b0 0x1000 + 0x1eb3b0 3 com.18james.lyx 0x001ec9c4 0x1000 + 0x1eb9c4 4 com.18james.lyx 0x001ec898 0x1000 + 0x1eb898 5 com.18james.lyx 0x0014bdbc 0x1000 + 0x14adbc 6 com.18james.lyx 0x0019b720 0x1000 + 0x19a720 7 com.18james.lyx 0x0019ba58 0x1000 + 0x19aa58 8 com.18james.lyx 0x00119644 0x1000 + 0x118644 9 com.18james.lyx 0xf620 0x1000 + 0xe620 10 com.18james.lyx 0x007eb18c 0x1000 + 0x7ea18c 11 com.18james.lyx 0x008b9fc0 0x1000 + 0x8b8fc0 12 com.18james.lyx 0x003cb268 0x1000 + 0x3ca268 13 com.18james.lyx 0x00262490 0x1000 + 0x261490 14 com.18james.lyx 0x00277fac 0x1000 + 0x276fac 15 com.18james.lyx 0x00277a1c 0x1000 + 0x276a1c 16 com.18james.lyx 0x00296c68 0x1000 + 0x295c68 17 com.apple.HIToolbox 0x92852330 DispatchEventToHandlers + 0x150 18 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 19 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 20 com.apple.HIToolbox 0x928731b4 HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 0x144 21 com.apple.HIToolbox 0x92868ad0 HandleMouseEvent(OpaqueEventRef*) + 0x170 22 com.apple.HIToolbox 0x92862fd4 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 0x1e8 23 com.apple.HIToolbox 0x928523ec DispatchEventToHandlers + 0x20c 24 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 25 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 26 com.18james.lyx 0x00295664 0x1000 + 0x294664 27 com.18james.lyx 0x0040e288 0x1000 + 0x40d288 28 com.18james.lyx 0x00436fa4 0x1000 + 0x435fa4 29 com.18james.lyx 0x00278050 0x1000 + 0x277050 30 com.18james.lyx 0x00869a58 0x1000 + 0x868a58 31 com.18james.lyx 0x001ec99c 0x1000 + 0x1eb99c 32 com.18james.lyx 0x001ec898 0x1000 + 0x1eb898 33 com.18james.lyx 0x0014bdbc 0x1000 + 0x14adbc 34 com.18james.lyx 0x0019b720 0x1000 + 0x19a720 35 com.18james.lyx 0x0019ba58 0x1000 + 0x19aa58 36 com.18james.lyx 0x00119644 0x1000 + 0x118644 37 com.18james.lyx 0xf620 0x1000 + 0xe620 38 com.18james.lyx 0x007eb18c 0x1000 + 0x7ea18c 39 com.18james.lyx 0x008b9fc0 0x1000 + 0x8b8fc0 40 com.18james.lyx 0x003cb268 0x1000 + 0x3ca268 41 com.18james.lyx 0x00262490 0x1000 + 0x261490 42 com.18james.lyx 0x00277fac 0x1000 + 0x276fac 43 com.18james.lyx 0x00277a1c 0x1000 + 0x276a1c 44 com.18james.lyx 0x00296c68 0x1000 + 0x295c68 45 com.apple.HIToolbox 0x92852330 DispatchEventToHandlers + 0x150 46 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 47 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 48 com.apple.HIToolbox 0x928731b4 HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 0x144 49 com.apple.HIToolbox 0x92868ad0 HandleMouseEvent(OpaqueEventRef*) + 0x170 50 com.apple.HIToolbox 0x92862fd4 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 0x1e8 51 com.apple.HIToolbox 0x928523ec DispatchEventToHandlers + 0x20c 52 com.apple.HIToolbox 0x928525a4 SendEventToEventTargetInternal + 0x174 53 com.apple.HIToolbox 0x92864a34 SendEventToEventTarget + 0x28 54 com.18james.lyx 0x00295664 0x1000 + 0x294664 55 com.18james.lyx 0x0040e288 0x1000 + 0x40d288 56 com.18james.lyx 0x00436e44 0x1000 + 0x435e44 57 com.18james.lyx 0x00436d2c 0x1000 + 0x435d2c 58 com.18james.lyx 0x00278154 0x1000 + 0x277154 59 com.18james.lyx 0x001c3198 0x1000 + 0x1c2198 60 com.18james.lyx 0x00090ed4 0x1000 + 0x8fed4 61 com.18james.lyx 0x000d9aec 0x1000 + 0xd8aec 62 com.18james.lyx 0x280c 0x1000 + 0x180c 63 com.18james.lyx 0x2680 0x1000 + 0x1680 PPC Thread State: srr0: 0x srr1: 0x4200f930vrsave: 0x cr: 0x2404 xer: 0x0004 lr: 0x002e27c4 ctr: 0x r0: 0x r1: 0xbfffdb60 r2: 0x0204b200 r3: 0x05415c50 r4: 0x0001 r5: 0x004c r6: 0x0074 r7: 0x514c696e r8: 0x5174 r9: 0x00b485cc r10: 0x504b686d r11: 0x4404 r12:
Re: Feature Request: split window DVI viewer with LyX
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > The problem is that this is difficult to do. What we have, though, is > inline preview of math equations. So why don't we add preview for paragraphs? :-) You leave the paragraph, LyX creates a preview for this paragraph, inserting a page break if necessary, and voilÃ! No need for split windows etc. You click into the paragraph again and the usual LyX insets appear. Shouldn't be too difficult, once math preview and cursorUp are stable ;-) Ciao /Andreas
Re: Feature Request: Uber Document Class
Luke Simon <[EMAIL PROTECTED]> writes: > > It would be very useful to have a document class that contained a union > of all known environments, so that in the early stages of writing a > paper, before you know exactly where you are going to submit it, you > could write it in the "Uber Document Class" and use environments as > needed. Then when you needed to actually submit the rendered PDF, you > could change the document class to a specific one and the environments > would be mapped to existing environments in that corresponding class and > if they didn't exist, then a predefined mapping for the target class > defined how to emulate the environment. I don't think a so-called Ãber-Documentclass would be very helpful. The difficult part is to define the mapping from one environment to another. Once you have that, you could as well switch between classes directly. What I would like is a way that package introduce new layouts into a document. Then you could produce your own modular "Ãber-textclass". > > For example, some classes contain some subset of special environments > for addresses, phone numbers, email addresses, proofs, lemmas, theorems, > corollaries, etc, and since there is no, as far as I know, class that > contains all of them, you are forced to guess your best match and then > later do allot of manual changes to properly use the final target > document class. You can try that for yourself now already: Just create a new uber.layout which includes all the layouts you want. You might need to cut a little to avoid certain conflicts, but then there you are. When you change from this class to an "unter-textclass" you will get errormessages for any paragraph whose layout can't be mapped. BTW, any volunteers who want to enhance this error dialog to allow userdefined mappings? :-) Ciao /Andreas
Re: [PATCH] UI: matrix partitioning
On Tue, 2005-02-08 at 19:25 +0100, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > +void MathGridInset::horLine(row_type row)
> > +{
> > +if (nrows() == 1)
> > +return;
> > +if (row + 1 == nrows())
> > +--row;
> > +rowinfo_[row].lines_++;
> > +}
>
> I don't understand this. I understand that this method adds a line above the
> row. I would think that it should look like
>
> void MathGridInset::addHLineAbove(row_type row)
> {
> if (row == 0)
> // Only if we don't want a line above the first row;
> return;
> if (row >= nrows())
> return;
> rowinfo_[row].lines_++;
> }
>
> IMO it should simply return if the line cannot be added.
You're even righter than you think: these conditions are not needed when
you think about it, so I just removed all of them.
> Another question: What about lines above the first row and below the last? I
> believe that this is possible in LaTeX, but how to support it here? I can't
> think of a better way than having an addHLineBelow() etc.
No, neither can I. But as there is no support for this in the current
mathed infrastructure, implementing this would go much further than just
fixing a broken UI. For 1.5?
> And getStatus needs to be updated to disable addHLineAbove if the cursor is
> in the first row.
How? If I look at getStatus for math_gridinset, I see a lot of stuff
commented out. Is this supposed to work at all, and how?
> Of course the same things should be done for the other h- and vline methods.
>
> > @@ -1100,6 +1140,10 @@
> > copyRow(cur.row());
> > else if (s == "swap-row")
> > swapRow(cur.row());
> > +else if (s == "hor-line")
> > +horLine(cur.row());
> > +else if (s == "delete-hor-line")
> > +rmHorLine(cur.row());
>
> I would prefer add-hline-above, delete-hline-above etc.
Yes, good proposal.
> Georg
New patch attached.
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.671
diff -u -r1.671 ChangeLog
--- lib/ChangeLog 8 Feb 2005 10:41:58 - 1.671
+++ lib/ChangeLog 8 Feb 2005 20:03:36 -
@@ -1,3 +1,9 @@
+2005-02-08 Martin Vermeer <[EMAIL PROTECTED]>
+
+ * ui/stdmenus.ui: add methods addHLineAbove, deleteHLineAbove,
+ addVLineLeft, deleteVLineLeft for drawing/deleting partition lines
+ in matrix
+
2005-02-08 Mike Ressler <[EMAIL PROTECTED]>
* layouts/aastex.layout: Updated for AASTeX 5.2
Index: src/mathed/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.468
diff -u -r1.468 ChangeLog
--- src/mathed/ChangeLog 31 Jan 2005 16:29:47 - 1.468
+++ src/mathed/ChangeLog 8 Feb 2005 20:03:37 -
@@ -1,3 +1,9 @@
+2005-02-08 Martin Vermeer <[EMAIL PROTECTED]>
+
+ * math_gridinset.[hC]: add methods addHLineAbove, deleteHLineAbove,
+ addVLineLeft, deleteVLineLeft for drawing/deleting partition lines in
+ matrix.
+
2005-01-31 Asger Ottar Alstrup <[EMAIL PROTECTED]>
* math_data.C:
Index: src/mathed/math_gridinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.C,v
retrieving revision 1.154
diff -u -r1.154 math_gridinset.C
--- src/mathed/math_gridinset.C 24 Nov 2004 21:58:41 - 1.154
+++ src/mathed/math_gridinset.C 8 Feb 2005 20:03:37 -
@@ -679,6 +679,30 @@
}
+void MathGridInset::addHLineAbove(row_type row)
+{
+ rowinfo_[row].lines_++;
+}
+
+
+void MathGridInset::deleteHLineAbove(row_type row)
+{
+ rowinfo_[row].lines_ = 0;
+}
+
+
+void MathGridInset::addVLineLeft(col_type col)
+{
+ colinfo_[col].lines_++;
+}
+
+
+void MathGridInset::deleteVLineLeft(col_type col)
+{
+ colinfo_[col].lines_ = 0;
+}
+
+
void MathGridInset::addCol(col_type newcol)
{
const col_type nc = ncols();
@@ -1100,6 +1124,10 @@
copyRow(cur.row());
else if (s == "swap-row")
swapRow(cur.row());
+ else if (s == "add-hline-above")
+ addHLineAbove(cur.row());
+ else if (s == "delete-hline-above")
+ deleteHLineAbove(cur.row());
else if (s == "append-column")
for (int i = 0, n = extractInt(is); i < n; ++i) {
row_type r = cur.row();
@@ -1120,6 +1148,10 @@
copyCol(col(cur.idx()));
else if (s == "swap-column")
swapCol(col(cur.idx()));
+ else if (s == "add-vline-left")
+ addVLineLeft(col(cur.idx()));
+ else if (s == "delete-vline-left")
+ deleteVLineLeft(col(cur.idx()));
else {
cur.undispatched();
break;
Index: src/mathed/math_gridinset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.h,v
retrieving revision 1.85
diff -u -r1.85
Re: Bug 1119: is LyX multithreaded after all?
Martin Vermeer <[EMAIL PROTECTED]> writes: > > // FIXME! Should check that the dialog IS an inset dialog. > - dialog->show(data); > open_insets_[name] = inset; > + dialog->show(data); > > That seems rather clear to me. As I understand (Angus would know) this > open_insets_ table keeps track of which insets have their dialog open, > so it doesn't try to open the same dialogue a second time. It looked clear to me also, before I scanned the code for uses of getOpenInsets() ... ;-) > > Before the patch, the first opening process starts before the dialog is > registered, and as it takes a little time (especially the first time, > when the code has to be loaded into memory), the second click manages to > start a second opening process *for the same inset* -- a race condition. I found out that the code for Inset::showDIalog() doesn't use getOpenInsets(), so it shouldn't matter :-( GetOpenInsets() is only used for LFUN_DIALOG_APPLY and LFUN_INSET_APPLY. I still get a crash, but now it's related to the previews... another source of multithreading. So I guess the race condition is there, we just haven't figured out its exact shape yet. Ciao /Andreas
Re: Crash while Ctrl+click on tabular material
Guillaume Yziquel <[EMAIL PROTECTED]> writes: > I pressed (Ctrl or alt, I wasn't really aware) + clicking the mouse on > a "Tabular Material" in Lyx. Lyx crashed. That should be the CTRL key, since that emulates the right mousebutton on Mac. > That is the bug report Apple > wants me to send back. I send it back to you. (I run a Mac OS X). Not very useful without the debugging symbols (LyX binary was stripped) This could be related to Bug 1119. Can anyone try to reproduce it with 1.3 for Qt? (Try doubleclicking) I can't with my latest patches on 1.4. Ciao /Andreas
"Hypertext" links in LyX documents
Regarding the ability to create "hypertext" links in LyX documents (originated in a discussion on the lyx-docs list) Jean-Marc wrote: > chr> * Link to another part of the same document (this we have > chr> already, right?) > > Yes, but this means using a reference that will appear in the > printout. This is not like an hypertext reference. > > chr> * Link to another document? > chr> * Link to another part inside another document? > > We do not have these, and it is a pity. Do people in general agree that it makes sense to have hypertext links in .lyx-files? Or is this something that doesn't make sense since LyX, assuming LyX is primarily supposed to produced printed documents? The open question is how a hypertext link should be rendered when exporting to a "printed" target? But... wait a minute, can't PDFs have hypertext links? How are they created in LyX today? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
