Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

>>>>> On Sun, 20 Jun 2021 11:56:28 -0400 (EDT), alan@idiocy.org (Alan Third) said:

    Alan> branch: scratch/ns/refactor
    Alan> commit 06d9e723f79390eb6151f521d154b47e1ffa943e
    Alan> Author: Alan Third <alan@idiocy.org>
    Alan> Commit: Alan Third <alan@idiocy.org>

    Alan>     Move NS port toolbar handling to the window

Hi Alan, I tried this branch. I did

emacs -Q
(tool-bar-mode -1)
C-x 5 2

The second frame has the tool-bar disabled, but unlike master the
frame height is greater than the initial frame, and the frame title is
bigger as well, as if its height had not been adjusted after removing
the tool-bar.


[-- Attachment #2: emacs-toolbar.png --]
[-- Type: image/png, Size: 181532 bytes --]

[-- Attachment #3: Type: text/plain, Size: 12 bytes --]


Robert
-- 

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third]

On Wed, Jun 23, 2021 at 02:37:08PM +0200, Robert Pluim wrote:
> >>>>> On Sun, 20 Jun 2021 11:56:28 -0400 (EDT), alan@idiocy.org (Alan Third) said:
> 
>     Alan> branch: scratch/ns/refactor
>     Alan> commit 06d9e723f79390eb6151f521d154b47e1ffa943e
>     Alan> Author: Alan Third <alan@idiocy.org>
>     Alan> Commit: Alan Third <alan@idiocy.org>
> 
>     Alan>     Move NS port toolbar handling to the window
> 
> Hi Alan, I tried this branch. I did

Thanks for trying it.

> emacs -Q
> (tool-bar-mode -1)
> C-x 5 2
> 
> The second frame has the tool-bar disabled, but unlike master the
> frame height is greater than the initial frame, and the frame title is
> bigger as well, as if its height had not been adjusted after removing
> the tool-bar.

What's happening is that the toolbar is set to be visible, but it has
nothing in it, so it shrinks to the toolbar's minimum height.

Can you please try the following, I think it should sort it:

modified   src/nsmenu.m
@@ -1089,10 +1089,10 @@ - (void)menu:(NSMenu *)menu willHighlightItem:(NSMenuItem *)item
 #undef TOOLPROP
     }
 
-  if (![toolbar isVisible])
+  if ([toolbar isVisible] != FRAME_EXTERNAL_TOOL_BAR (f))
     {
       f->output_data.ns->in_animation = 1;
-      [toolbar setVisible: YES];
+      [toolbar setVisible: FRAME_EXTERNAL_TOOL_BAR (f)];
       f->output_data.ns->in_animation = 0;
     }
 
-- 
Alan Third

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Robert Pluim]

>>>>> On Wed, 23 Jun 2021 15:27:42 +0100, Alan Third <alan@idiocy.org> said:
    >> The second frame has the tool-bar disabled, but unlike master the
    >> frame height is greater than the initial frame, and the frame title is
    >> bigger as well, as if its height had not been adjusted after removing
    >> the tool-bar.

    Alan> What's happening is that the toolbar is set to be visible, but it has
    Alan> nothing in it, so it shrinks to the toolbar's minimum height.

    Alan> Can you please try the following, I think it should sort it:

Youʼre on a roll here Alan. That fixes it.

Thanks

Robert
-- 

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third]

On Wed, Jun 23, 2021 at 04:57:34PM +0200, Robert Pluim wrote:
> >>>>> On Wed, 23 Jun 2021 15:27:42 +0100, Alan Third <alan@idiocy.org> said:
>     >> The second frame has the tool-bar disabled, but unlike master the
>     >> frame height is greater than the initial frame, and the frame title is
>     >> bigger as well, as if its height had not been adjusted after removing
>     >> the tool-bar.
> 
>     Alan> What's happening is that the toolbar is set to be visible, but it has
>     Alan> nothing in it, so it shrinks to the toolbar's minimum height.
> 
>     Alan> Can you please try the following, I think it should sort it:
> 
> Youʼre on a roll here Alan. That fixes it.

I've pushed a fix if you want to give it a go.

Plus another couple of patches which probably break something else.
-- 
Alan Third

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Robert Pluim]

>>>>> On Wed, 23 Jun 2021 17:06:12 +0100, Alan Third <alan@idiocy.org> said:

    Alan> On Wed, Jun 23, 2021 at 04:57:34PM +0200, Robert Pluim wrote:
    >> >>>>> On Wed, 23 Jun 2021 15:27:42 +0100, Alan Third <alan@idiocy.org> said:
    >> >> The second frame has the tool-bar disabled, but unlike master the
    >> >> frame height is greater than the initial frame, and the frame title is
    >> >> bigger as well, as if its height had not been adjusted after removing
    >> >> the tool-bar.
    >> 
    Alan> What's happening is that the toolbar is set to be visible, but it has
    Alan> nothing in it, so it shrinks to the toolbar's minimum height.
    >> 
    Alan> Can you please try the following, I think it should sort it:
    >> 
    >> Youʼre on a roll here Alan. That fixes it.

    Alan> I've pushed a fix if you want to give it a go.

    Alan> Plus another couple of patches which probably break something else.

I guess that using the menus being dodgy when displaying a
tramp-visited buffer is normal? Emacs appears to be busy-looping, I
can provide backtrace if you want.

I never use the menus, so itʼs not a big deal to me.

Robert
-- 

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third]

On Thu, Jun 24, 2021 at 03:58:40PM +0200, Robert Pluim wrote:
> >>>>> On Wed, 23 Jun 2021 17:06:12 +0100, Alan Third <alan@idiocy.org> said:
> 
>     Alan> On Wed, Jun 23, 2021 at 04:57:34PM +0200, Robert Pluim wrote:
>     >> >>>>> On Wed, 23 Jun 2021 15:27:42 +0100, Alan Third <alan@idiocy.org> said:
>     >> >> The second frame has the tool-bar disabled, but unlike master the
>     >> >> frame height is greater than the initial frame, and the frame title is
>     >> >> bigger as well, as if its height had not been adjusted after removing
>     >> >> the tool-bar.
>     >> 
>     Alan> What's happening is that the toolbar is set to be visible, but it has
>     Alan> nothing in it, so it shrinks to the toolbar's minimum height.
>     >> 
>     Alan> Can you please try the following, I think it should sort it:
>     >> 
>     >> Youʼre on a roll here Alan. That fixes it.
> 
>     Alan> I've pushed a fix if you want to give it a go.
> 
>     Alan> Plus another couple of patches which probably break something else.
> 
> I guess that using the menus being dodgy when displaying a
> tramp-visited buffer is normal? Emacs appears to be busy-looping, I
> can provide backtrace if you want.
> 
> I never use the menus, so itʼs not a big deal to me.

No, that's not normal... Well, it kind of is... For some reason tramp
+ menus causes problems. It may be because we have to run a whole
bunch of lisp stuff in the NS run loop while updating the contents of
the menus before opening them and that interacts in some way with the
tramp external processes' IO. I've no idea why.

It may ultimately make more sense to take a copy of the menu structure
when Emacs core updates the menus and then update them from that...

If you revert 99adf4b2af is the menu behaviour better, worse or the
same?
-- 
Alan Third

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third]

On Thu, Jun 24, 2021 at 03:05:43PM +0100, Alan Third wrote:
> If you revert 99adf4b2af is the menu behaviour better, worse or the
> same?

Oops, sorry, 982ecc5aa9. I rebased my local copy onto master, so it
doesn't match what you'll be using just now.
-- 
Alan Third

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Robert Pluim]

>>>>> On Thu, 24 Jun 2021 15:07:33 +0100, Alan Third <alan@idiocy.org> said:

    Alan> On Thu, Jun 24, 2021 at 03:05:43PM +0100, Alan Third wrote:
    >> If you revert 99adf4b2af is the menu behaviour better, worse or the
    >> same?

    Alan> Oops, sorry, 982ecc5aa9. I rebased my local copy onto master, so it
    Alan> doesn't match what you'll be using just now.

Yes. Better with that reverted.

Robert
-- 

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third]

On Thu, Jun 24, 2021 at 04:15:25PM +0200, Robert Pluim wrote:
> >>>>> On Thu, 24 Jun 2021 15:07:33 +0100, Alan Third <alan@idiocy.org> said:
> 
>     Alan> On Thu, Jun 24, 2021 at 03:05:43PM +0100, Alan Third wrote:
>     >> If you revert 99adf4b2af is the menu behaviour better, worse or the
>     >> same?
> 
>     Alan> Oops, sorry, 982ecc5aa9. I rebased my local copy onto master, so it
>     Alan> doesn't match what you'll be using just now.
> 
> Yes. Better with that reverted.

Oh well, I'll just delete it then... It seemed to work better here,
but I guess it was just chance.
-- 
Alan Third

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third]

On Thu, Jun 24, 2021 at 04:15:25PM +0200, Robert Pluim wrote:
> >>>>> On Thu, 24 Jun 2021 15:07:33 +0100, Alan Third <alan@idiocy.org> said:
> 
>     Alan> On Thu, Jun 24, 2021 at 03:05:43PM +0100, Alan Third wrote:
>     >> If you revert 99adf4b2af is the menu behaviour better, worse or the
>     >> same?
> 
>     Alan> Oops, sorry, 982ecc5aa9. I rebased my local copy onto master, so it
>     Alan> doesn't match what you'll be using just now.
> 
> Yes. Better with that reverted.

Actually, if it's not too much hassle could you check whether just
commenting out the lines:

  [outerpool release];
  outerpool = [[NSAutoreleasePool alloc] init];

in ns_select fixes the problem, or does the whole commit need
reverted?

The real solution to this problem is, I think, the old threadify all
the things, which is what some of the refactoring in this branch is
intended to make easier.

Or was before I started putting bug fixes in it too. I should rename
it.
-- 
Alan Third

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Robert Pluim]

>>>>> On Thu, 24 Jun 2021 15:32:37 +0100, Alan Third <alan@idiocy.org> said:

    Alan> On Thu, Jun 24, 2021 at 04:15:25PM +0200, Robert Pluim wrote:
    >> >>>>> On Thu, 24 Jun 2021 15:07:33 +0100, Alan Third <alan@idiocy.org> said:
    >> 
    Alan> On Thu, Jun 24, 2021 at 03:05:43PM +0100, Alan Third wrote:
    >> >> If you revert 99adf4b2af is the menu behaviour better, worse or the
    >> >> same?
    >> 
    Alan> Oops, sorry, 982ecc5aa9. I rebased my local copy onto master, so it
    Alan> doesn't match what you'll be using just now.
    >> 
    >> Yes. Better with that reverted.

    Alan> Actually, if it's not too much hassle could you check whether just
    Alan> commenting out the lines:

    Alan>   [outerpool release];
    Alan>   outerpool = [[NSAutoreleasePool alloc] init];

    Alan> in ns_select fixes the problem, or does the whole commit need
    Alan> reverted?

Commenting out just those lines is not enough.

    Alan> The real solution to this problem is, I think, the old threadify all
    Alan> the things, which is what some of the refactoring in this branch is
    Alan> intended to make easier.

The two great problems in computer science are naming, scope creep,
and off-by-one errors

Robert
-- 

Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Robert Pluim]

>>>>> On Thu, 24 Jun 2021 15:05:43 +0100, Alan Third <alan@idiocy.org> said:
    >> I guess that using the menus being dodgy when displaying a
    >> tramp-visited buffer is normal? Emacs appears to be busy-looping, I
    >> can provide backtrace if you want.
    >> 
    >> I never use the menus, so itʼs not a big deal to me.

    Alan> No, that's not normal... Well, it kind of is... For some reason tramp
    Alan> + menus causes problems. It may be because we have to run a whole
    Alan> bunch of lisp stuff in the NS run loop while updating the contents of
    Alan> the menus before opening them and that interacts in some way with the
    Alan> tramp external processes' IO. I've no idea why.

    Alan> It may ultimately make more sense to take a copy of the menu structure
    Alan> when Emacs core updates the menus and then update them from that...

    Alan> If you revert 99adf4b2af is the menu behaviour better, worse or the
    Alan> same?

I donʼt have that commit. Did you mean 982ecc5aa9?

Robert
-- 

Re: scratch/ns/refactor cc9dbaf 4/6: Fix macOS live resize drawing

[Robert Pluim]

>>>>> On Sun, 20 Jun 2021 11:56:28 -0400 (EDT), alan@idiocy.org (Alan Third) said:

    Alan> branch: scratch/ns/refactor
    Alan> commit cc9dbaf2e35fd5b8e5132e68ff459ab75012da45
    Alan> Author: Alan Third <alan@idiocy.org>
    Alan> Commit: Alan Third <alan@idiocy.org>

    Alan>     Fix macOS live resize drawing
    
Hi Alan, I get a crash in redisplay when resizing my second frame
using the mouse. At eval.c:1805 'waiting_for_input' is true, so we
call emacs_abort

Reverting this commit seems to fix it (my current test case is to
visit eval.c, go to line 1805, and then resize the frame).

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff204c392e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff204f25bd libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007fff203d6be5 libsystem_c.dylib`raise + 26
    frame #3: 0x00000001003a956c emacs`terminate_due_to_signal(sig=6, backtrace_limit=40) at emacs.c:437:3
    frame #4: 0x00000001003a9993 emacs`emacs_abort at sysdep.c:2282:3
    frame #5: 0x0000000100357ec8 emacs`ns_term_shutdown(sig=6) at nsterm.m:5471:7
    frame #6: 0x0000000100158a47 emacs`shut_down_emacs(sig=6, stuff=0x0000000000000000) at emacs.c:2736:3
    frame #7: 0x00000001003a9504 emacs`terminate_due_to_signal(sig=6, backtrace_limit=40) at emacs.c:420:11
    frame #8: 0x00000001003a9993 emacs`emacs_abort at sysdep.c:2282:3
  * frame #9: 0x0000000100256090 emacs`signal_or_quit(error_symbol=0x000000000000beb0, data=0x0000000150178c13, keyboard_quit=false) at eval.c:1805:5
    frame #10: 0x00000001003ac2b7 emacs`Fsignal(error_symbol=0x000000000000beb0, data=0x0000000150178c13) at eval.c:1775:3
    frame #11: 0x00000001003ac30d emacs`xsignal(error_symbol=0x000000000000beb0, data=0x0000000150178c13) at lisp.h:4136:3
    frame #12: 0x00000001003ac350 emacs`xsignal3(error_symbol=0x000000000000beb0, arg1=0x000000014fd0dae4, arg2=0x000000000000c6b2, arg3=0x000000000000c6b2) at eval.c:1944:3
    frame #13: 0x00000001002c20d8 emacs`scan_lists(from0=12717, count=-1, depth=-1, sexpflag=true) at syntax.c:2958:3
    frame #14: 0x00000001002c24ef emacs`Fscan_sexps(from=0x000000000000c6b6, count=0xfffffffffffffffe) at syntax.c:3087:10
    frame #15: 0x000000010025d60b emacs`funcall_subr(subr=0x0000000100403810, numargs=2, args=0x00007ffeefbed9d0) at eval.c:3116:19
    frame #16: 0x000000010025c3e5 emacs`Ffuncall(nargs=3, args=0x00007ffeefbed9c8) at eval.c:3039:11
    frame #17: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x000000010502605c, vector=0x0000000105025b9d, maxdepth=0x000000000000001a, args_template=0x0000000000000802, nargs=2, args=0x00007ffeefbee0e0) at bytecode.c:632:12
    frame #18: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x0000000105025b45, syms_left=0x0000000000000802, nargs=2, args=0x00007ffeefbee0d0) at eval.c:3163:10
    frame #19: 0x000000010025d9bf emacs`funcall_lambda(fun=0x0000000105025b45, nargs=2, arg_vector=0x00007ffeefbee0d0) at eval.c:3244:11
    frame #20: 0x000000010025c440 emacs`Ffuncall(nargs=3, args=0x00007ffeefbee0c8) at eval.c:3043:11
    frame #21: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x0000000105248d3c, vector=0x0000000105248d25, maxdepth=0x0000000000000016, args_template=0x0000000000000802, nargs=1, args=0x00007ffeefbee798) at bytecode.c:632:12
    frame #22: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x0000000105248ced, syms_left=0x0000000000000802, nargs=1, args=0x00007ffeefbee790) at eval.c:3163:10
    frame #23: 0x000000010025d9bf emacs`funcall_lambda(fun=0x0000000105248ced, nargs=1, arg_vector=0x00007ffeefbee790) at eval.c:3244:11
    frame #24: 0x000000010025c440 emacs`Ffuncall(nargs=2, args=0x00007ffeefbee788) at eval.c:3043:11
    frame #25: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001056e8a34, vector=0x00000001056e89dd, maxdepth=0x0000000000000012, args_template=0x000000000000080a, nargs=2, args=0x00007ffeefbeee78) at bytecode.c:632:12
    frame #26: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001056e89ad, syms_left=0x000000000000080a, nargs=2, args=0x00007ffeefbeee68) at eval.c:3163:10
    frame #27: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001056e89ad, nargs=2, arg_vector=0x00007ffeefbeee68) at eval.c:3244:11
    frame #28: 0x000000010025c440 emacs`Ffuncall(nargs=3, args=0x00007ffeefbeee60) at eval.c:3043:11
    frame #29: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001056e8d14, vector=0x00000001056e8935, maxdepth=0x000000000000001a, args_template=0x0000000000000406, nargs=1, args=0x00007ffeefbef588) at bytecode.c:632:12
    frame #30: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001056e8905, syms_left=0x0000000000000406, nargs=1, args=0x00007ffeefbef580) at eval.c:3163:10
    frame #31: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001056e8905, nargs=1, arg_vector=0x00007ffeefbef580) at eval.c:3244:11
    frame #32: 0x000000010025c440 emacs`Ffuncall(nargs=2, args=0x00007ffeefbef578) at eval.c:3043:11
    frame #33: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001052e9d74, vector=0x00000001052e8bcd, maxdepth=0x000000000000003e, args_template=0x0000000000000c0a, nargs=3, args=0x00007ffeefbefd58) at bytecode.c:632:12
    frame #34: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001052e8b9d, syms_left=0x0000000000000c0a, nargs=3, args=0x00007ffeefbefd40) at eval.c:3163:10
    frame #35: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001052e8b9d, nargs=3, arg_vector=0x00007ffeefbefd40) at eval.c:3244:11
    frame #36: 0x000000010025c440 emacs`Ffuncall(nargs=4, args=0x00007ffeefbefd38) at eval.c:3043:11
    frame #37: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001052ebdec, vector=0x00000001052e7b95, maxdepth=0x000000000000002e, args_template=0x0000000000000c0e, nargs=3, args=0x00007ffeefbf04c0) at bytecode.c:632:12
    frame #38: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001052e7b65, syms_left=0x0000000000000c0e, nargs=3, args=0x00007ffeefbf04a8) at eval.c:3163:10
    frame #39: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001052e7b65, nargs=3, arg_vector=0x00007ffeefbf04a8) at eval.c:3244:11
    frame #40: 0x000000010025c440 emacs`Ffuncall(nargs=4, args=0x00007ffeefbf04a0) at eval.c:3043:11
    frame #41: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001052ebefc, vector=0x00000001052e7ac5, maxdepth=0x000000000000001e, args_template=0x0000000000000c0a, nargs=2, args=0x00007ffeefbf0b88) at bytecode.c:632:12
    frame #42: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001052e7a95, syms_left=0x0000000000000c0a, nargs=2, args=0x00007ffeefbf0b78) at eval.c:3163:10
    frame #43: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001052e7a95, nargs=2, arg_vector=0x00007ffeefbf0b78) at eval.c:3244:11
    frame #44: 0x000000010025c440 emacs`Ffuncall(nargs=3, args=0x00007ffeefbf0b70) at eval.c:3043:11
    frame #45: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001052bc12c, vector=0x00000001500edead, maxdepth=0x000000000000002a, args_template=0x0000000000000406, nargs=1, args=0x00007ffeefbf1530) at bytecode.c:632:12
    frame #46: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001500edef5, syms_left=0x0000000000000406, nargs=1, args=0x00007ffeefbf1528) at eval.c:3163:10
    frame #47: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001500edef5, nargs=1, arg_vector=0x00007ffeefbf1528) at eval.c:3244:11
    frame #48: 0x000000010025c440 emacs`Ffuncall(nargs=2, args=0x00007ffeefbf1520) at eval.c:3043:11
    frame #49: 0x000000010025cbf3 emacs`run_hook_wrapped_funcall(nargs=2, args=0x00007ffeefbf1520) at eval.c:2776:9
    frame #50: 0x000000010025ca17 emacs`run_hook_with_args(nargs=2, args=0x00007ffeefbf1520, funcall=(emacs`run_hook_wrapped_funcall at eval.c:2772)) at eval.c:2857:14
    frame #51: 0x000000010025cba4 emacs`Frun_hook_wrapped(nargs=2, args=0x00007ffeefbf1520) at eval.c:2791:10
    frame #52: 0x000000010025d50b emacs`funcall_subr(subr=0x00000001004011a0, numargs=2, args=0x00007ffeefbf1520) at eval.c:3094:12
    frame #53: 0x000000010025c3e5 emacs`Ffuncall(nargs=3, args=0x00007ffeefbf1518) at eval.c:3039:11
    frame #54: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001052bc364, vector=0x00000001052bbf55, maxdepth=0x0000000000000042, args_template=0x000000000000080a, nargs=2, args=0x00007ffeefbf1c70) at bytecode.c:632:12
    frame #55: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x00000001052bbf25, syms_left=0x000000000000080a, nargs=2, args=0x00007ffeefbf1c60) at eval.c:3163:10
    frame #56: 0x000000010025d9bf emacs`funcall_lambda(fun=0x00000001052bbf25, nargs=2, arg_vector=0x00007ffeefbf1c60) at eval.c:3244:11
    frame #57: 0x000000010025c440 emacs`Ffuncall(nargs=3, args=0x00007ffeefbf1c58) at eval.c:3043:11
    frame #58: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001056e3f2c, vector=0x000000010505acad, maxdepth=0x000000000000006e, args_template=0x0000000000000802, nargs=2, args=0x00007ffeefbf2498) at bytecode.c:632:12
    frame #59: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x000000010505ac7d, syms_left=0x0000000000000802, nargs=2, args=0x00007ffeefbf2488) at eval.c:3163:10
    frame #60: 0x000000010025d9bf emacs`funcall_lambda(fun=0x000000010505ac7d, nargs=2, arg_vector=0x00007ffeefbf2488) at eval.c:3244:11
    frame #61: 0x000000010025c440 emacs`Ffuncall(nargs=3, args=0x00007ffeefbf2480) at eval.c:3043:11
    frame #62: 0x00000001002c89c3 emacs`exec_byte_code(bytestr=0x00000001056e3fec, vector=0x000000010505a915, maxdepth=0x0000000000000032, args_template=0x0000000000000406, nargs=1, args=0x00007ffeefbf2c20) at bytecode.c:632:12
    frame #63: 0x0000000100260fd0 emacs`fetch_and_exec_byte_code(fun=0x000000010505a8e5, syms_left=0x0000000000000406, nargs=1, args=0x00007ffeefbf2c18) at eval.c:3163:10
    frame #64: 0x000000010025d9bf emacs`funcall_lambda(fun=0x000000010505a8e5, nargs=1, arg_vector=0x00007ffeefbf2c18) at eval.c:3244:11
    frame #65: 0x000000010025c440 emacs`Ffuncall(nargs=2, args=0x00007ffeefbf2c10) at eval.c:3043:11
    frame #66: 0x0000000100255cfa emacs`internal_condition_case_n(bfun=(emacs`Ffuncall at eval.c:3004), nargs=2, args=0x00007ffeefbf2c10, handlers=0x0000000000000030, hfun=(emacs`safe_eval_handler at xdisp.c:2960)) at eval.c:1642:25
    frame #67: 0x000000010004617f emacs`safe__call(inhibit_quit=false, nargs=2, func=0x0000000004852150, ap=0x00007ffeefbf2e60) at xdisp.c:2994:13
    frame #68: 0x0000000100044b84 emacs`safe_call(nargs=2, func=0x0000000004852150) at xdisp.c:3009:12
    frame #69: 0x00000001000461f4 emacs`safe_call1(fn=0x0000000004852150, arg=0x000000000000c2d6) at xdisp.c:3020:10
    frame #70: 0x000000010007e283 emacs`handle_fontified_prop(it=0x00007ffeefbf49e0) at xdisp.c:4326:3
    frame #71: 0x000000010007ca51 emacs`handle_stop(it=0x00007ffeefbf49e0) at xdisp.c:3854:14
    frame #72: 0x000000010008286e emacs`next_element_from_buffer(it=0x00007ffeefbf49e0) at xdisp.c:8907:4
    frame #73: 0x00000001000387e7 emacs`get_next_display_element(it=0x00007ffeefbf49e0) at xdisp.c:7496:15
    frame #74: 0x0000000100056d56 emacs`display_line(it=0x00007ffeefbf49e0, cursor_vpos=32) at xdisp.c:23567:12
    frame #75: 0x0000000100056371 emacs`try_window(window=0x00000001509d2f15, pos=(charpos = 10898, bytepos = 10898), flags=1) at xdisp.c:19494:11
    frame #76: 0x0000000100095145 emacs`redisplay_window(window=0x00000001509d2f15, just_this_one_p=false) at xdisp.c:18904:8
    frame #77: 0x000000010009325d emacs`redisplay_window_0(window=0x00000001509d2f15) at xdisp.c:16618:5
    frame #78: 0x00000001002558da emacs`internal_condition_case_1(bfun=(emacs`redisplay_window_0 at xdisp.c:16616), arg=0x00000001509d2f15, handlers=0x000000010570bb43, hfun=(emacs`redisplay_window_error at xdisp.c:16609)) at eval.c:1502:25
    frame #79: 0x0000000100091afb emacs`redisplay_windows(window=0x00000001509d2f15) at xdisp.c:16598:4
    frame #80: 0x0000000100050eda emacs`redisplay_internal at xdisp.c:16066:5
    frame #81: 0x0000000100054ef9 emacs`redisplay at xdisp.c:15282:3
    frame #82: 0x0000000100363550 emacs`-[EmacsView layoutSublayersOfLayer:](self=0x000000014fae28b0, _cmd="layoutSublayersOfLayer:", layer=0x0000000136474150) at nsterm.m:8063:7
    frame #83: 0x00007fff26d6d8d3 QuartzCore`-[CALayer layoutSublayers] + 326
    frame #84: 0x00007fff26d6d239 QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 619
    frame #85: 0x00007fff26eb907f QuartzCore`CA::Context::commit_transaction(CA::Transaction*, double, double*) + 655
    frame #86: 0x00007fff26d4f0df QuartzCore`CA::Transaction::commit() + 713
    frame #87: 0x00007fff22e3ef5c AppKit`-[NSWindow _setFrameCommon:display:fromServer:] + 3985
    frame #88: 0x0000000100367222 emacs`-[EmacsWindow setFrame:display:](self=0x000000014fae2cb0, _cmd="setFrame:display:", windowFrame=(origin = (x = -0, y = 123), size = (width = 844, height = 902)), displayViews=YES) at nsterm.m:8933:3
    frame #89: 0x00007fff23197a97 AppKit`-[NSWindow(NSWindowResizing) _resizeWithEvent:] + 2600
    frame #90: 0x00007fff2307ec7f AppKit`-[NSTitledFrame attemptResizeWithEvent:] + 177
    frame #91: 0x00007fff2307e9fa AppKit`-[NSThemeFrame handleMouseDown:] + 298
    frame #92: 0x00007fff23111a20 AppKit`-[NSThemeFrame mouseDown:] + 30
    frame #93: 0x00007fff230052ae AppKit`-[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4961
    frame #94: 0x00007fff22f74a98 AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2594
    frame #95: 0x00007fff22f73e56 AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 347
    frame #96: 0x00007fff22f72264 AppKit`-[NSApplication(NSEvent) sendEvent:] + 352
    frame #97: 0x0000000100358407 emacs`-[EmacsApp sendEvent:](self=0x00000001031652d0, _cmd="sendEvent:", theEvent=0x00000001428cba80) at nsterm.m:5644:3
    frame #98: 0x00007fff2324b5fd AppKit`-[NSApplication _handleEvent:] + 65
    frame #99: 0x00007fff22ddb25e AppKit`-[NSApplication run] + 623
Robert
-- 

Re: scratch/ns/refactor cc9dbaf 4/6: Fix macOS live resize drawing

[Alan Third]

On Wed, Jun 23, 2021 at 03:33:22PM +0200, Robert Pluim wrote:
> >>>>> On Sun, 20 Jun 2021 11:56:28 -0400 (EDT), alan@idiocy.org (Alan Third) said:
> 
>     Alan> branch: scratch/ns/refactor
>     Alan> commit cc9dbaf2e35fd5b8e5132e68ff459ab75012da45
>     Alan> Author: Alan Third <alan@idiocy.org>
>     Alan> Commit: Alan Third <alan@idiocy.org>
> 
>     Alan>     Fix macOS live resize drawing
>     
> Hi Alan, I get a crash in redisplay when resizing my second frame
> using the mouse. At eval.c:1805 'waiting_for_input' is true, so we
> call emacs_abort
> 
> Reverting this commit seems to fix it (my current test case is to
> visit eval.c, go to line 1805, and then resize the frame).

Hi Robert, can you try uncommenting the code in layoutSublayersOfLayer
and see if that fixes it?
-- 
Alan Third

Re: scratch/ns/refactor cc9dbaf 4/6: Fix macOS live resize drawing

[Robert Pluim]

>>>>> On Wed, 23 Jun 2021 15:05:32 +0100, Alan Third <alan@idiocy.org> said:
    Alan> Hi Robert, can you try uncommenting the code in layoutSublayersOfLayer
    Alan> and see if that fixes it?

Hi Alan, this seems to do the job:

diff --git i/src/nsterm.m w/src/nsterm.m
index b5bfb242d5..5298466f27 100644
--- i/src/nsterm.m
+++ w/src/nsterm.m
@@ -8056,14 +8056,14 @@ - (void)layoutSublayersOfLayer:(CALayer *)layer
          however I can't understand why it would be different from
          viewWillDraw.  I'll leave this commented out for now, but if
          nobody reports a crash it can be removed.  */
-      // bool owfi = waiting_for_input;
-      // waiting_for_input = 0;
-      // block_input ();
+      bool owfi = waiting_for_input;
+      waiting_for_input = 0;
+      block_input ();

       redisplay ();

-      // unblock_input ();
-      // waiting_for_input = owfi;
+      unblock_input ();
+      waiting_for_input = owfi;
     }
 }
 #endif


Robert
--