Re: Embedding: The State of the Art, and a Proposal

"Bo Peng" <[EMAIL PROTECTED]> writes: > You would then realize why I said 'the technical side is clear'. Ah, you mean "he is wrong, I am right"? I see we are going forward. JMarc PS: I really think attitude is the key here, not technical details.

Re: Embedding: The State of the Art, and a Proposal

Andre Poenitz wrote: On Thu, May 15, 2008 at 09:30:14AM -0400, rgheck wrote: I want quickly to summarize where I think this discussion is now. There are two proposals on the table, one due to Bo and one due (more or less) to me. The details of these have been described elsewhere. Rig

Re: Embedding: The State of the Art, and a Proposal

> no. i steped in just as complete outsider seduced by the 'summary' keyword > in subject to know whats the better solution and what i would vote in case > it will be some poll. my fail probably that i put down questions out of > misunderstanding of the proposals - but anyway - on my question i got

Re: Embedding: The State of the Art, and a Proposal

Bo Peng wrote: > > So a possible solution of that dilemma would be to leave the issue > > to some third person to solve in a way he likes and live with the > > result or improve on that result,. > > This was exactly what I was proposing, but people did not want to step > in, I guess for social rea

Re: Embedding: The State of the Art, and a Proposal

> So a possible solution of that dilemma would be to leave the issue > to some third person to solve in a way he likes and live with the > result or improve on that result,. This was exactly what I was proposing, but people did not want to step in, I guess for social reasons because the technical

Re: Embedding: The State of the Art, and a Proposal

On Thu, May 15, 2008 at 09:30:14AM -0400, rgheck wrote: > > I want quickly to summarize where I think this discussion is now. > > There are two proposals on the table, one due to Bo and one due (more or > less) to me. The details of these have been described elsewhere. Right. So a possible solut

Re: Embedding: The State of the Art, and a Proposal

Bo Peng wrote: I want quickly to summarize where I think this discussion is now. I would just like to point out that 1. Without a bundled mode, there is no change for existing documents in my approach. And there's no change for existing documents in my approach either, unless you dec

Re: Embedding: The State of the Art, and a Proposal

> I want quickly to summarize where I think this discussion is now. I would just like to point out that 1. Without a bundled mode, there is no change for existing documents in my approach. 2. Individual embedding allows continuous use of external files. Individual embedding is not chosen only fo

Embedding: The State of the Art, and a Proposal

I want quickly to summarize where I think this discussion is now. There are two proposals on the table, one due to Bo and one due (more or less) to me. The details of these have been described elsewhere. Many of the apparent differences between the approaches are just implementation details.

Re: 2 bugs and a proposal

Angus Leeming <[EMAIL PROTECTED]> writes: > > > Questions: > > > 1. Does it make sense to preview anything other than Input? > > > > Uh, yes. But this very much depends on the document in question. > > See a few examples on the homepage. > > Other obvious c

Re: 2 bugs and a proposal

On Wednesday 31 July 2002 9:29 pm, David Kastrup wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > Lars Gullik Bjønnes wrote: > > > | 3. Would people like a Preview of such Input? > > > > > > sure. > > > > Oh my god! It works! See attached! > > This is all a secret plot from envious Emacs use

Re: 2 bugs and a proposal

Angus Leeming <[EMAIL PROTECTED]> writes: > Lars Gullik Bjønnes wrote: > > > | 3. Would people like a Preview of such Input? > > > > sure. > > Oh my god! It works! See attached! This is all a secret plot from envious Emacs users that want LyX development to stall by incurring a lethal eye can

Re: 2 bugs and a proposal

Lars Gullik Bjønnes wrote: > | 3. Would people like a Preview of such Input? > > sure. Oh my god! It works! See attached! The InsetInclude::PreviewImpl and InsetFormula::PreviewImpl are very similar so I'll try and factor the common code into a base class. Questions: 1. Does it make sense t

Re: 2 bugs and a proposal

Angus Leeming <[EMAIL PROTECTED]> writes: | Attached are snapshots of the LyX screen and resultant dvi output. > | 1. Why does the Caption environment think that it's "senseless" when | clearly it isn't? It never really checks outside the current inset if it is inside a float or not. | 2. Why

2 bugs and a proposal

Attached are snapshots of the LyX screen and resultant dvi output. 1. Why does the Caption environment think that it's "senseless" when clearly it isn't? 2. Why is the blue border of the second minipage not drawn around its contents. 3. Would people like a Preview of such Input? Angus dvi

Re: A proposal for better sub/super script handling in mathed

On Thu, Nov 29, 2001 at 07:33:11PM +0100, Andre Poenitz wrote: ... > From: Andre Poenitz <[EMAIL PROTECTED]> > Date: Thu, 29 Nov 2001 19:33:11 +0100 > To: Martin Vermeer <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: A proposal for better sub/super scrip

Re: A proposal for better sub/super script handling in mathed

On Fri, Nov 30, 2001 at 01:38:15PM +0200, Dekel Tsur wrote: > Doesn't 'math-insert ^' already has the same effect as the proposed > math-superscript ? ... looks so, doesn't it? Andre' -- André Pönitz .. [EMAIL PROTECTED]

Re: A proposal for better sub/super script handling in mathed

On Thu, Nov 29, 2001 at 07:33:11PM +0100, Andre Poenitz wrote: > On Thu, Nov 29, 2001 at 03:35:45PM +0200, Martin Vermeer wrote: > > Also minibuffer commands could then be defined in LyXAction.C, > > Yes. > > > like "math-subscript" and "math-superscript". Making it straightforward > > also to a

Re: A proposal for better sub/super script handling in mathed

On Thu, Nov 29, 2001 at 03:35:45PM +0200, Martin Vermeer wrote: > Also minibuffer commands could then be defined in LyXAction.C, Yes. > like "math-subscript" and "math-superscript". Making it straightforward > also to add them to the math panel. > > Just my modest proposal, as someone who just

A proposal for better sub/super script handling in mathed

Hi, having studied this messy business a little more, I have come to the conclusion that the first thing to do would be a clean-up in the sense of adding the functions LFUN_SUBSCRIPT and LFUN_SUPERSCRIPT to commandtags.h. Currently the routine MathCursor::interpret in math_cursor.C handles th

Re: a proposal...

On Sat, 11 Mar 2000, Angus Leeming wrote: > // the print form > fl_set_input(fd_form_print->input_printer, lyxrc->printer.c_str()); > where lyxrc is a global LyXRC variable and the call [...] > Ultimately, therefore, create_forms() creates a vector of > Dialogs, one of which is

Re: a proposal...

> I propose that the Dialogs constructor be modified to: > Dialogs(LyXFunc * lyxfunc, LyXRC const & lyxrc ) LyXRC is global so I don't think it should be passed to any function. I am not sure about the Correct Position of LyXFunc. I have a feeling that the current relation to LyXViews is n

a proposal...

Bear with me on this one. It isn't difficult, just long! The current version of LyXGUI contains the following code LyXGUI::init() { ... create_forms(); ... // the print form fl_set_input(fd_form_print->input_printer, lyxrc->printer.c_str()); } where l