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
