As long as this works for the windows build (I cannot test here)

I cannot find documentation of this mimetype - and I cannot replicate.
What system has set this?

Not invalid

Not invalid

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

First pass is done, we can revisit to see what needs to be added for 0.8 if anything

Looking at this again I think @netstar is right - an elm_code should not close the file if there is an active instance... By destroying the container you close the file correctly.

looks good to me, thanks for landing @stefan_schmidt

Sorry, pressed the wrong button

The first half was fine but there's some questions about the latter part

This is too complex and the provided patch seems to work fine. Can be revisited later if required

I kinda wonder why this fixes it really. Part of me wonders if we've got an issue in the "elm" setup in elm_code_widget...

As per the email chain recently please be aware that moving code into Eina is also changing it's license. Be careful!

That's merged into efl master now

Quite right, that check is needed

The move issue is no longer visible - perhaps that was due to be basing it off the 1.20 branch?
Other than the one comment inline this looks good.

Looks good to me :)

You're right the freeze is fixed, just the black rectangle remains

@zmike pointed to a workaround in src/lib/ecore_cocoa/ecore_cocoa_window.m (line 121) whereby an additional timer makes direct calls to ecore_main_loop_iterate due to the NSRunLoop having blocked.

I get the same behaviour if I call ecore_main_loop_iterate_may_block(EINA_FALSE) which is even stranger...

It's very close :)

As for a single method it looks like the geom_get, resize, move and show are almost identically grouped in widget_fill_cursor.
I'd say it should be possible to factor that and this patch into a single method.

Sorry, this is not quite there.
The cursor does not move to the correct location.
It seems to size correctly - but if you are not on the top line of the file it will hover in the wrong place (where the topleft was before).

Very close! Thank you for that.

Works nicely here :)

This also occurs on the current stable release.
Of particular note is that if you try again after seeing the black rectangle E can freeze :(

I have not looked into the details but I think this must have created a little duplicate code.
Can we use the same code for when it's set up in the first place and when it's resized through this method?

Cool, setting it to 5 or 10 works well, thanks. I tried 3 and it did the same deadlock

Happy to debug further but I don’t know what would be useful

Yes a good point. I switched to master and have the same issue.
In addition to not being able to switch away I noticed that cpu goes high and fans start spinning - I wonder if that is useful too?

There are no errors on the command line when I force the application to exit remotely.

These lines refer to efl 1.20 not master

The relevant threads appear to be:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
_outbuf_fb_wait (ob=ob@entry=0xd589c0) at modules/evas/engines/drm/evas_outbuf.c:213

Ah I misunderstood sorry.
I had thought it was something else from the description.
If it's not visible then I agree it's not a 1.21 problem.

I actually can't replicate this here - is there a small code snippet that I can use?

Testing on my end suggests that D6483 does fix this issue.

Apologies, it would appear this is now resolved.

It appears to still be the case with that patch applied

Hi @netstar if you're not succeeding I will look - this should really get fixed for 1.21

As an update this does not appear when ECORE_DRM2_ATOMIC_DISABLE is set.
There is a deadlock situation that also does not occur when this is set - may or may not be related.

Oops, sorry - the error is:

Could someone see if this patch fixes it? I cannot currently test master...
I can't see the cause of the second issue - the null seems to be within layout code somehow...

Pretty sure it's not - perhaps @zmike can verify?

The black line changes size in Edi using efl 1.20.9 - is this a regression or is it specific to Ecrire?
I can't imagine how it does not change as it's all part of the underlying text grid.

No

I mentioned before but not on this ticket, so I'll add it for the record.

I'm not sure I agree with not moving the cursor but pasting somewhere that the cursor is not...
The cursor remains where the input is occurring and I'd like to maintain that.

I cannot replicate this in Edi.
Is there a particular font that has been set? Does it happen with all fonts in Ecrire?

This should get fixed

Setting this to normal priority and removing goal as we can't fix this without a major refactor of the widget layout.

Yeah, @zmike is right about that. @segfaultxavi I thought I had a simple example but it turned out the compiler flag had been turned on by an unrelated piece of code that later turned it off...

I'm not sure the cause but the result is that there is documentation outside of the normal guards that hold back those beta APIs.

Can we please change the documentation then? Evas_Object_Vg Is public documentation marked as @since 1.14...

With the current widget setup I cannot find a way to make this work.
The mouse move event is not triggered on the text as the mouse is somehow tied to the background where the drag started.

Looking at some editors (on OS X):

When you right click the cursor jumps to the location so that the operation will happen where expected.
If you are outside the area and there is a long line of text on the last line it does not make sense to paste at the end of it - the content will not appear in the expected position.

Where in the last line? The pointer position may not be after the end of the last line...