Re: enhanced_recursion() and do_event(), can they be redesigned?

[Daniel J S. <dan...@ie...>]

On 02/23/2014 10:35 PM, sfeam wrote:
> On Sunday, 23 February 2014 10:04:42 PM Daniel J Sebald wrote:
>> On 02/23/2014 09:43 PM, sfeam wrote:
>>> On Sunday, 23 February 2014 09:26:26 PM Daniel J Sebald wrote:
>>>> In attempting to modify the qt_term.cpp Qt terminal, I ran into some
>>>> annoying problems with recursive calls, namely enhanced_recursion() and
>>>> do_event().
>>>>
>>>> First, let me summarize a few things:
>>>>
>>>> 1) There are a few uses of the global pointer term->.  My preference
>>>> would be to remove those, but I understand there needs to be a way to
>>>> get some information back to gnuplot core.  It seems to me that putting
>>>> non-const pointers in the API is the best way to do that.  But yes, it
>>>> is sort of the same difference.
>>>
>>> I'm afraid I'm not following you.
>>> A few uses for term->    in what piece of code, exactly?
>>
>> There aren't many cases, but here is one example in qt_term.cpp:
>>
>> // Called just before a plot is going to be displayed.
>> void QtTerminalInterface::qt_graphics(unsigned int v_char)
>> {
>> 	ensureOptionsCreated();
>> 	out<<  GEDesactivate;
>> 	qt_flushOutBuffer();
>> 	connectToServer();
>>
>> 	// Set text encoding
>> 	if (!(codec = qt_encodingToCodec(encoding)))
>> 		codec = QTextCodec::codecForLocale();
>>
>> 	// Set font
>> 	currentFontSize = qt_optionFontSize;
>> 	currentFontName = qt_option->FontName;
>>
>> 	// Set plot size
>> 	if (qt_setSize)
>> 	{
>> 		term->xmax = qt_oversampling*qt_setWidth;
>> 		term->ymax = qt_oversampling*qt_setHeight;
>> 		qt_setSize = false;
>> 	}
>>
>> In a separate thread, the "term->xmax =" will be done asynchronously.
>> Hence a mutex/wait is needed to make sure the code in the separate
>> thread has updated term->xmax and term->max before the core thread can
>> continue onward.
>
> Ah. Now I'm with you.
> Yeah, this is the piece of code that has changed the most in qt
> because nothing seems to work properly on both linux and OSX.
> You are quite correct that term->foo should not be referenced in
> this part of the terminal driver.  It is supposed to return the revised
> font information via an event GP_fontprops.  And it _was_ doing that
> at one point.  I've now lost track of all the work-arounds and what
> exactly they fixed, but certainly it would be good if you can get
> back to the original intent.  You can look at other terminal
> drivers as a model if needed.

OK, thanks.  I'll look that over.  I think that may be the one thing 
that isn't working yet for what I've done, i.e., some text isn't showing 
up probably owing to the core is told the font height is zero.


>>>> So, with that, I'll ask if there is some way of redesigning
>>>> enhanced_recursion() and do_event().
>>>
>>> These have nothing to do with each other, so I don't understand the
>>> question.  Both are part of the core, and are shared by all terminals.
>>
>> What they share is the fact that they go back to the core code and can
>> recursively issue further API calls before the active API returns.
>>
>>
>>>> What is the role of enhanced_recursion()?
>>>
>>> This is the routine that interprets enhanced text markup strings.
>>> It's part of the core text processing.  It is called whenever the
>>> core routines want to output a string in enhanced text mode.
>>
>> What you described sounds more like enhanced_writec(), whereas
>> enhanced_recursion() is issued by the terminal, at least it is for the
>> Qt terminal.
>
> All of those enhanced_foo() routines are part of the text output layer.
> enhanced_recursion() in particular is shared by all terminals and
> lives in term.c.   It is called whenever an enhanced text string is
> output, and then calls itself recursively as the name suggests to
> handle embedded fragments of the text markup.   E.g.
>     "{top_{sub1_{sub2_{sub3}}}}"
> Each left curly bracket triggers a new level of recursion.
> Please leave it alone.

Just wondering if that recursion couldn't be kept to the core.  It looks 
like the things needed (for Qt) to do that recursion are fontName, 
fontSize and enhanced_flush().  I think those are all currently 
accessible through the API.  In any case, I already have that worked out 
so no need to modify anything there.


> Anyhow, what's wrong with recursion?
> I posted an example before of a hot key definition that
> necessarily triggers recursion and works correctly on
> all the terminals I tried.  If there is a piece of the qt
> event code that is not re-entry safe, let's fix that first
> and then worry about whether something else is also problematic.

I can work this out, now that I've thought about it a bit.

Dan