Re: The minibuffer
On Tue, Mar 04, 2003 at 09:27:36AM +0100, Lars Gullik Bjønnes wrote: > > Someone has been playing with it. > > F.ex. when building dvi there are no messges about the latex run. > > Also after running a command the shortcut just stays there until some > cursor movement. > > Can this be the Timeout patch? Or something else? Is this related in any way to the ci/co bug I have reported? -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: The minibuffer
On Tue, Mar 04, 2003 at 09:27:36AM +0100, Lars Gullik Bj?nnes wrote: > Someone has been playing with it. > > F.ex. when building dvi there are no messges about the latex run. > > Also after running a command the shortcut just stays there until some > cursor movement. Hmm yes. I think it's just that we never give the GUI a chance to redraw. BUT the minibuffer has never worked in a satisfactory. Now it's worse of course ... > Can this be the Timeout patch? Unlikely, but ... The only change I made was to consolidate the run message code, but that was a mechanical transformation only
Re: The minibuffer
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Mar 04, 2003 at 09:27:36AM +0100, Lars Gullik Bj?nnes wrote: | | > Someone has been playing with it. | > | > F.ex. when building dvi there are no messges about the latex run. | > | > Also after running a command the shortcut just stays there until some | > cursor movement. | | Hmm yes. I think it's just that we never give the GUI a chance to | redraw. | | BUT the minibuffer has never worked in a satisfactory. Now it's worse of | course ... | | > Can this be the Timeout patch? | | Unlikely, but ... | | The only change I made was to consolidate the run message code, but | that was a mechanical transformation only Ok, so what happened to this during the last two weeks? -- Lgb
Re: The minibuffer
On Tue, Mar 04, 2003 at 09:48:29AM +0100, Lars Gullik Bj?nnes wrote: > Ok, so what happened to this during the last two weeks? No idea. I haven't the energy to track it down right now ... john
Re: the minibuffer
Angus Leeming <[EMAIL PROTECTED]> writes: | I thought I'd try and move the minibuffer behind the frontends firewall and | so had a look at which functions are used by the "general public". It | transpires that only addSet and getString are used. > | I propose, therefore, getting rid entirely of LyXView::getMiniBuffer() and | replacing it with two boost::functions. The minibuffer can then disappear | from view. > | Any objections? Reasons please... I am not sure how this will look. > | aleem@pneumon:src-> grep -n "getMiniBuffer()" *.C */*.C */*/*.C | lyxfunc.C:827: | owner->getMiniBuffer()->addSet(commandshortcut);lyxfunc.C:830: | owner->getMiniBuffer()->addSet(' ' + commandshortcut); | lyxfunc.C:1050: owner->getMiniBuffer()->getString(MiniBuffer::spaces, | frontends/LyXView.C:118:MiniBuffer * LyXView::getMiniBuffer() const | frontends/xforms/XFormsView.C:81: getMiniBuffer()->redraw(); > | LyXView "owns" the minibuffer and XFormsView derives from LyXView so these | don't count. That means that the only functions of interest are: > | void MiniBuffer::addSet(string const & s1, string const & s2) | { | string const str = text + ' ' + s1 + ' ' + s2; | message(str); | } > | * Note that s2 is NEVER used. Shall I kill it? Yes. | * This command is used to append the command shortcut to the displayed | lyxfunc. Might a better name be "void appendShortCut(string const & sc)"? Isn't it also used internally in the minibuffer? For telling then end of history is reached etc. ? | /** Makes the minibuffer wait for a string to be inserted. | Waits for a string to be inserted into the minibuffer, when | the string has been inserted the signal stringReady is | emitted. | */ | void MiniBuffer::getString(State spaces, | vector const & completion, | vector & history) | { | state_ = spaces; | completion_ = completion; | history_ = &history; | hist_iter = history_->end(); | prepare(); | } > | * Again, I think that this name is confusing. Why not prepareBuffer(...)? or | some such? If you read the comment the same of the funciton is perfectly sane.. IMHO. We use it to get a string (and it is delivered through a signal.) -- Lgb
Re: the minibuffer
On Monday 24 June 2002 10:37 am, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | I thought I'd try and move the minibuffer behind the frontends firewall > | and so had a look at which functions are used by the "general public". It > | transpires that only addSet and getString are used. > | > | I propose, therefore, getting rid entirely of LyXView::getMiniBuffer() > | and replacing it with two boost::functions. The minibuffer can then > | disappear from view. > | > | Any objections? Reasons please... > > I am not sure how this will look. lyxview().minibufferAddSet(...); or isn't this what you mean? > | * This command is used to append the command shortcut to the displayed > | lyxfunc. Might a better name be "void appendShortCut(string const & sc)"? > > Isn't it also used internally in the minibuffer? For telling then end > of history is reached etc. ? No. Maybe it was once, but no more: aleem@pneumon:src-> grep -n addSet minibuffer.* minibuffer.C:355:void MiniBuffer::addSet(string const & s1, string const & s2) minibuffer.h:42:void addSet(string const &, > > | /** Makes the minibuffer wait for a string to be inserted. > | Waits for a string to be inserted into the minibuffer, when > | the string has been inserted the signal stringReady is > | emitted. > | */ > | void MiniBuffer::getString(State spaces, > |vector const & completion, > |vector & history) > | * Again, I think that this name is confusing. Why not prepareBuffer(...)? > | or some such? > > If you read the comment the same of the funciton is perfectly sane.. > IMHO. > We use it to get a string (and it is delivered through a signal.) Well you might call it sane. I'm not going to call it insane, just clumsy. foo::callingFunc() { minibuffer.getString(); } foo::receivingFunc is connected to minibuffer::signalReady. To my eyes, this code suggests that I now have a string to manipulate, whereas actually I have nothing until another foo function is called when the signal is emitted. So, why not reflect this reality in the names: void minibuffer::prepareForInput(...); boost::signal1 minibuffer::inputString; Incidentally, I for one would be happier if the excesssive name calling that's been creeping into this list recently were to creep out again. No, this isn't directed at Lars; I think he's had to bear the brunt of the abuse recently. To my eyes "STFU" helps no-one. Angus
Re: the minibuffer
It seems that the changes Juergen and I did to the minibuffer from Porto has not been included? We did rework all of these methods... Greets, Asger
Re: the minibuffer
Asger Kunuk Alstrup Nielsen <[EMAIL PROTECTED]> writes: | It seems that the changes Juergen and I did to the minibuffer from | Porto has not been included? | We did rework all of these methods... Hmm... I did apply the complete diff... I can check against what I have in the Porto CVS repository. -- Lgb
Re: the minibuffer
On Mon, Jun 24, 2002 at 03:11:43PM +0200, Lars Gullik Bjønnes wrote: > | It seems that the changes Juergen and I did to the minibuffer from > | Porto has not been included? > | We did rework all of these methods... > > Hmm... I did apply the complete diff... > I can check against what I have in the Porto CVS repository. Try that. I had difficulties to apply my last Porto changes to current CVS. This looked as if not every change had made it into CVS... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: the minibuffer
On Monday 24 June 2002 3:02 pm, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > | Asger Kunuk Alstrup Nielsen <[EMAIL PROTECTED]> writes: > | | It seems that the changes Juergen and I did to the minibuffer from > | | Porto has not been included? > | | We did rework all of these methods... > | > | Hmm... I did apply the complete diff... > | I can check against what I have in the Porto CVS repository. > > Some things forgotten. > I'll apply this, unless somebody beats me too it. NOTE! however that > this patch cannot just be applied, it has to be done piece by piece. A large chunk of this appears to be what John applied on Friday (all that BufferView::redraw/repaint stuff). So, if it worked for you in Porto, it should work again. Hoorah! and no, I'm not going to try and apply it. Angus
Re: the minibuffer
On Mon, Jun 24, 2002 at 10:52:51AM +0100, Angus Leeming wrote: > this isn't directed at Lars; I think he's had to bear the brunt of the abuse > recently. To my eyes "STFU" helps no-one. OK OK ! john -- "If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared." - St. Augustine