Scroll bars on macOS builds

Scroll bars on macOS builds

[Angelo Graziosi]

It seems I do not see the scroll bars on macOS builds even if in my init.el I have (for a long time) 

(horizontal-scroll-bar-mode 1)

also the vertical bar is absent and with buffers with a lot of lines the only way to know in which "position" one is along the buffer is to read the indication on the mode line, xy%. 

Being a GUI build, one expects to get a GUI indication of this, with the vertical scroll bar, for example...

I build master monthly on macOS 10.13.6, the last version I can use on this MBP, and configuring with

./configure --with-ns \
            --without-dbus \
            --without-pop \
            --with-modules


Happy New Year!

Ciao,
 Angelo.

Re: Scroll bars on macOS builds

[Alan Third]

On Fri, Dec 31, 2021 at 10:58:51PM +0100, Angelo Graziosi wrote:
> It seems I do not see the scroll bars on macOS builds even if in my
> init.el I have (for a long time)
> 
> (horizontal-scroll-bar-mode 1)
> 
> also the vertical bar is absent and with buffers with a lot of lines
> the only way to know in which "position" one is along the buffer is
> to read the indication on the mode line, xy%.

It looks fine here. Do you see the scroll bars if you run "emacs -Q"?
-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

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

> Il 02/01/2022 15:20 Alan Third ha scritto:
> 
>  
> On Fri, Dec 31, 2021 at 10:58:51PM +0100, Angelo Graziosi wrote:
> > It seems I do not see the scroll bars on macOS builds even if in my
> > init.el I have (for a long time)
> > 
> > (horizontal-scroll-bar-mode 1)
> > 
> > also the vertical bar is absent and with buffers with a lot of lines
> > the only way to know in which "position" one is along the buffer is
> > to read the indication on the mode line, xy%.
> 
> It looks fine here. Do you see the scroll bars if you run "emacs -Q"?

No, see Emacs-Q.png in the tarball. I started Emacs with

cd /MyApps/Emacs.app/Contents/MacOS
./Emacs -Q

The other image (Emacs-Dock.png) in the tarball refers to Emacs started from the Dock.

Emacs was built this morning from master (01615b24da97bdb5cc4eaec5792da8238dab9942). See my OP for configure options used. My build script creates a tarbal with the Emacs.app folder which I then install in /MyApps. As I wrote the OS is 10.13.6.

I think I had scroll bars in previous builds. For this reason I had put

(horizontal-scroll-bar-mode 1)

in my init.el. But, now, I have lost the tarball for old build and I cannot check them.

[-- Attachment #2: emacs-screenshots.tar.gz --]
[-- Type: application/x-gzip, Size: 78225 bytes --]

Re: Scroll bars on macOS builds

[Alan Third]

On Sun, Jan 02, 2022 at 07:41:38PM +0100, Angelo Graziosi wrote:
> > Il 02/01/2022 15:20 Alan Third ha scritto:
> > 
> >  
> > On Fri, Dec 31, 2021 at 10:58:51PM +0100, Angelo Graziosi wrote:
> > > It seems I do not see the scroll bars on macOS builds even if in my
> > > init.el I have (for a long time)
> > > 
> > > (horizontal-scroll-bar-mode 1)
> > > 
> > > also the vertical bar is absent and with buffers with a lot of lines
> > > the only way to know in which "position" one is along the buffer is
> > > to read the indication on the mode line, xy%.
> > 
> > It looks fine here. Do you see the scroll bars if you run "emacs -Q"?
> 
> No, see Emacs-Q.png in the tarball. I started Emacs with
> 
> cd /MyApps/Emacs.app/Contents/MacOS
> ./Emacs -Q
> 
> The other image (Emacs-Dock.png) in the tarball refers to Emacs started from the Dock.
> 
> Emacs was built this morning from master (01615b24da97bdb5cc4eaec5792da8238dab9942). See my OP for configure options used. My build script creates a tarbal with the Emacs.app folder which I then install in /MyApps. As I wrote the OS is 10.13.6.
> 
> I think I had scroll bars in previous builds. For this reason I had put
> 
> (horizontal-scroll-bar-mode 1)
> 
> in my init.el. But, now, I have lost the tarball for old build and I cannot check them.

Do the scrollbars work if you click where they should be?

Can you try loading a theme with a dark background (wombat, for
example)? They might be displaying as white on white. I don't think
they should do that themselves, but I have seen that sort of thing
before.

Failing that, do they ever appear? For example when resizing the
frame do they flicker in and out of existence or anything?

-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 04/01/2022 12:08 Alan Third ha scritto:
> 
>  
> On Sun, Jan 02, 2022 at 07:41:38PM +0100, Angelo Graziosi wrote:
> > > Il 02/01/2022 15:20 Alan Third ha scritto:
> > > 
> > >  
> > > On Fri, Dec 31, 2021 at 10:58:51PM +0100, Angelo Graziosi wrote:
> > > > It seems I do not see the scroll bars on macOS builds even if in my
> > > > init.el I have (for a long time)
> > > > 
> > > > (horizontal-scroll-bar-mode 1)
> > > > 
> > > > also the vertical bar is absent and with buffers with a lot of lines
> > > > the only way to know in which "position" one is along the buffer is
> > > > to read the indication on the mode line, xy%.
> > > 
> > > It looks fine here. Do you see the scroll bars if you run "emacs -Q"?
> > 
> > No, see Emacs-Q.png in the tarball. I started Emacs with
> > 
> > cd /MyApps/Emacs.app/Contents/MacOS
> > ./Emacs -Q
> > 
> > The other image (Emacs-Dock.png) in the tarball refers to Emacs started from the Dock.
> > 
> > Emacs was built this morning from master (01615b24da97bdb5cc4eaec5792da8238dab9942). See my OP for configure options used. My build script creates a tarbal with the Emacs.app folder which I then install in /MyApps. As I wrote the OS is 10.13.6.
> > 
> > I think I had scroll bars in previous builds. For this reason I had put
> > 
> > (horizontal-scroll-bar-mode 1)
> > 
> > in my init.el. But, now, I have lost the tarball for old build and I cannot check them.
> 
> Do the scrollbars work if you click where they should be?

I did this test a few days ago and it looks as if the scroll bars are "hidden"... This seems to confirm I had them in old builds..

> Can you try loading a theme with a dark background (wombat, for
> example)? They might be displaying as white on white. I don't think
> they should do that themselves, but I have seen that sort of thing
> before.
> 
> Failing that, do they ever appear? For example when resizing the
> frame do they flicker in and out of existence or anything?

..I cannot do other tests because the MBP had the battery that was growing up so I had to take it to maintenance.. :-( 

It will be a while before I get back to using it. (I asked also to change the HD into SSD..)

Ciao,
 Angelo.

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 04/01/2022 12:08 Alan Third ha scritto:
> 
> Do the scrollbars work if you click where they should be?
> 

It looks as if they are hidden, at least for what would be the vertical scroll bar...

> Can you try loading a theme with a dark background (wombat, for
> example)? They might be displaying as white on white. I don't think
> they should do that themselves, but I have seen that sort of thing
> before.

No, I tried wombat all the other themes.

> 
> Failing that, do they ever appear? For example when resizing the
> frame do they flicker in and out of existence or anything?

No, no flicker nor scroll bars...

This is the summary of configure output:

----------------------------------------------------------------
Configured for 'x86_64-apple-darwin17.7.0'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               clang -O2
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    nextstep
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                NONE
  Where do we find X Windows libraries?                   NONE
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   no
  Does Emacs use -ljpeg?                                  no
  Does Emacs use -ltiff?                                  no
  Does Emacs use a gif library?                           no 
  Does Emacs use a png library?                           yes -L/opt/local/lib -lpng16
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lwebp?                                  yes
  Does Emacs use -lsqlite3?                               yes
  Does Emacs use cairo?                                   no
  Does Emacs use -llcms2?                                 yes
  Does Emacs use imagemagick?                             no
  Does Emacs use native APIs for images?                  yes (ns)
  Does Emacs support sound?                               no
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use a file notification library?             yes (kqueue)
  Does Emacs use access control lists?                    yes 
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              no
  Does Emacs use HarfBuzz?                                no
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs use -lsystemd?                               no
  Does Emacs use -ljansson?                               yes
  Does Emacs use the GMP library?                         no
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     yes
  Does Emacs support Xwidgets?                            no
  Does Emacs have threading support in lisp?              yes
  Does Emacs support the portable dumper?                 yes
  Does Emacs support legacy unexec dumping?               no
  Which dumping strategy does Emacs use?                  pdumper
  Does Emacs have native lisp compiler?                   no
  Does Emacs use version 2 of the the X Input Extension?  no
----------------------------------------------------------------

Re: Scroll bars on macOS builds

[Alan Third]

On Wed, Jan 12, 2022 at 01:12:05AM +0100, Angelo Graziosi wrote:
> 
> > Il 04/01/2022 12:08 Alan Third ha scritto:
> > 
> > Do the scrollbars work if you click where they should be?
> > 
> 
> It looks as if they are hidden, at least for what would be the vertical scroll bar...
> 
> > Can you try loading a theme with a dark background (wombat, for
> > example)? They might be displaying as white on white. I don't think
> > they should do that themselves, but I have seen that sort of thing
> > before.
> 
> No, I tried wombat all the other themes.

It sounds like either they're not being drawn at all, or they're being
drawn in the wrong place (outside the frame bounds). I have no
immediate ideas why either should happen.

Are you comfortable using a debugger? If so it would be good if you
could step through ns_set_vertical_scroll_bar and check if it's
drawing the scrollbars, and if so where it's drawing them.

-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 22/01/2022 12:33 Alan Third <alan@idiocy.org> ha scritto:
> 
>  
> On Wed, Jan 12, 2022 at 01:12:05AM +0100, Angelo Graziosi wrote:
> > 
> > > Il 04/01/2022 12:08 Alan Third ha scritto:
> > > 
> > > Do the scrollbars work if you click where they should be?
> > > 
> > 
> > It looks as if they are hidden, at least for what would be the vertical scroll bar...
> > 
> > > Can you try loading a theme with a dark background (wombat, for
> > > example)? They might be displaying as white on white. I don't think
> > > they should do that themselves, but I have seen that sort of thing
> > > before.
> > 
> > No, I tried wombat all the other themes.
> 
> It sounds like either they're not being drawn at all, or they're being
> drawn in the wrong place (outside the frame bounds). I have no
> immediate ideas why either should happen.
> 
> Are you comfortable using a debugger? 

No, I am afraid..

All I can say is that the frame is drawn as if they are there.

When I visit a buffer with many lines and long wrapped lines, holding mouse-1 pressed and dragging where they should be, the result is as if they are there. For example, long wrapped lines become not wrapped exactly as on Windows build where scroll bars are visible...

Re: Scroll bars on macOS builds

[Tim Cross]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 22/01/2022 12:33 Alan Third <alan@idiocy.org> ha scritto:
>> 
>>  
>> On Wed, Jan 12, 2022 at 01:12:05AM +0100, Angelo Graziosi wrote:
>> > 
>> > > Il 04/01/2022 12:08 Alan Third ha scritto:
>> > > 
>> > > Do the scrollbars work if you click where they should be?
>> > > 
>> > 
>> > It looks as if they are hidden, at least for what would be the vertical scroll bar...
>> > 
>> > > Can you try loading a theme with a dark background (wombat, for
>> > > example)? They might be displaying as white on white. I don't think
>> > > they should do that themselves, but I have seen that sort of thing
>> > > before.
>> > 
>> > No, I tried wombat all the other themes.
>> 
>> It sounds like either they're not being drawn at all, or they're being
>> drawn in the wrong place (outside the frame bounds). I have no
>> immediate ideas why either should happen.
>> 
>> Are you comfortable using a debugger? 
>
> No, I am afraid..
>
> All I can say is that the frame is drawn as if they are there.
>
> When I visit a buffer with many lines and long wrapped lines, holding mouse-1
> pressed and dragging where they should be, the result is as if they are there.
> For example, long wrapped lines become not wrapped exactly as on Windows build
> where scroll bars are visible...

Could this be due to a macOS setting? I know that macOS has a couple of
options relating to when scroll bars become visible, including one where
they are hidden until you start to scroll. 

Re: Scroll bars on macOS builds

[Brahimi Saifullah]

Alan Mackenzie <acm@muc.de> writes:

> With the current state of the git branch, flymake on a .el file now
> seems to be working for me.

Yes, Flymake is working perfectly now.

I did notice an issue with the warning for unused forms:

    value returned from (#<symbol + at 2> 1 1) is unused
    (from byte-compiling a file that consists of "(+ 1 1)")

I expect that the symbol should be used, not the symbol with
positions.  But it looks like this just got fixed a few hours ago
in master while my build was from before the merge.


While further testing this I also found a couple problems relating to
unused function arguments -- I'm unsure if they have anything to do with
the latest round of changes or not.

First, a bug:

    (defun f (a b c)
  ; ^^^ Warning: Unused lexical argument `a'
  ;      Warning: Unused lexical argument `b'

    "A B C."
    (+ 1 1))
  ; ^^^ Warning: Unused lexical argument `c'

You should be able to reproduce it by copying the above function
somewhere and byte compiling (sans the).

If the function consists of a single form, the position returned for
the last "unused lexical argument" will wrongly point to it.  In this
example, the warning about C being unused will instead point to `+'.

The second issue is that, even when the unused lexical argument warnings
work correctly, they always point to the "defun," and not to the actual
argument in question.  Not the end of the world of course, but it would
be nice for them to be more accurate.


> Again, many thanks for the help.

And thanks for the work you've done, faulty warning
positions had always been an annoyance of mine :)

Re: Scroll bars on macOS builds

[Alan Third]

On Sat, Jan 22, 2022 at 04:06:19PM +0100, Angelo Graziosi wrote:
> 
> > Il 22/01/2022 12:33 Alan Third <alan@idiocy.org> ha scritto:
> > It sounds like either they're not being drawn at all, or they're being
> > drawn in the wrong place (outside the frame bounds). I have no
> > immediate ideas why either should happen.
> > 
> > Are you comfortable using a debugger? 
> 
> No, I am afraid..
> 
> All I can say is that the frame is drawn as if they are there.
> 
> When I visit a buffer with many lines and long wrapped lines,
> holding mouse-1 pressed and dragging where they should be, the
> result is as if they are there. For example, long wrapped lines
> become not wrapped exactly as on Windows build where scroll bars are
> visible...

Ah, I misunderstood your previous message, then.

It sounds like they are there, because scroll events are only sent to
Emacs from the EmacsScroller object itself, so you're definitely
clicking on a scroller, it's just not being drawn.

What system appearance do you use? Dark?
-- 
Alan Third

Re: Scroll bars on macOS builds

[Alan Third]

On Sun, Jan 23, 2022 at 10:06:08AM +1100, Tim Cross wrote:
> 
> > When I visit a buffer with many lines and long wrapped lines, holding mouse-1
> > pressed and dragging where they should be, the result is as if they are there.
> > For example, long wrapped lines become not wrapped exactly as on Windows build
> > where scroll bars are visible...
> 
> Could this be due to a macOS setting? I know that macOS has a couple of
> options relating to when scroll bars become visible, including one where
> they are hidden until you start to scroll. 

It shouldn't be that as it requires a very specific setup in the OS
window, and we aren't able to provide that.

It could be some other setting, though.
-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 23/01/2022 21:06 Alan Third ha scritto:
> 
>  
> On Sat, Jan 22, 2022 at 04:06:19PM +0100, Angelo Graziosi wrote:
> > 
> > > Il 22/01/2022 12:33 Alan Third ha scritto:
> > > It sounds like either they're not being drawn at all, or they're being
> > > drawn in the wrong place (outside the frame bounds). I have no
> > > immediate ideas why either should happen.
> > > 
> > > Are you comfortable using a debugger? 
> > 
> > No, I am afraid..
> > 
> > All I can say is that the frame is drawn as if they are there.
> > 
> > When I visit a buffer with many lines and long wrapped lines,
> > holding mouse-1 pressed and dragging where they should be, the
> > result is as if they are there. For example, long wrapped lines
> > become not wrapped exactly as on Windows build where scroll bars are
> > visible...
> 
> Ah, I misunderstood your previous message, then.
> 
> It sounds like they are there, because scroll events are only sent to
> Emacs from the EmacsScroller object itself, so you're definitely
> clicking on a scroller, it's just not being drawn.
> 
> What system appearance do you use? Dark?

Do you mean in macOS? No, never changed the appearance; in any case it is not dark, I do not use dark things... If you, instead, mean Emacs I sent the screenshots.. Are you seen them?

Tim Cross wrote
> Could this be due to a macOS setting?

I did not change the settings and all other apps (browser, terminals etc.) *do have* scroll bars! Usually te bars are visible when the window has enough text. I am sure that in past builds also Emacs had scroll bars...

Re: Scroll bars on macOS builds

[Angelo Graziosi]

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


> Il 23/01/2022 22:31 Angelo Graziosi  ha scritto:
> I am sure that in past builds also Emacs had scroll bars...

So I rebuilt Emacs-27 and as you can see from the attached screenshots it DO HAVE scrollbars! I started is as

  ./Emacs.app/Contents/MacOS/Emacs -q

The vertical scrollbar is *always* visible and the horizontal scrollbar is visible when activated with Options - Show/Hide - Scroll Bar - Horizontal

So it seems that changes in master have broken this feature...

Maybe we have to open a bug report..

[-- Attachment #2: Emacs-27_on_macOS-10.13.6.tar.gz --]
[-- Type: application/x-gzip, Size: 189174 bytes --]

Re: Scroll bars on macOS builds

[Alan Third]

On Sun, Jan 23, 2022 at 11:23:12PM +0100, Angelo Graziosi wrote:
> 
> > Il 23/01/2022 22:31 Angelo Graziosi  ha scritto:
> > I am sure that in past builds also Emacs had scroll bars...
> 
> So I rebuilt Emacs-27 and as you can see from the attached screenshots it DO HAVE scrollbars! I started is as
> 
>   ./Emacs.app/Contents/MacOS/Emacs -q
> 
> The vertical scrollbar is *always* visible and the horizontal scrollbar is visible when activated with Options - Show/Hide - Scroll Bar - Horizontal
> 
> So it seems that changes in master have broken this feature...
> 
> Maybe we have to open a bug report..

Can you try changing line 7198 in nsterm.m from

  [self setWantsLayer:YES];

to

  [self setWantsLayer:NO];

?

-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

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

> Il 26/01/2022 00:01 Alan Third ha scritto:
> 
> 
> Can you try changing line 7198 in nsterm.m from
> 
>   [self setWantsLayer:YES];
> 
> to
> 
>   [self setWantsLayer:NO];
> 
> ?

Emacs crashes at startup. I have rebuilt Emacs from current master and from master-20220111 with your suggestions but it wont start!

Attached the bug report it want to send to Apple people...

[-- Attachment #2: bug_emacs.log.bz2 --]
[-- Type: application/x-bzip2, Size: 18220 bytes --]

Re: Scroll bars on macOS builds

[Alan Third]

I'm afraid all I can suggest for now is trying to find a commit that
worked and doing a git bisect to find the actual commit that causes
the problem, because I can't see anything obvious in the logs for last
month that would've caused it.

If it was broken since, like, the middle of the year I'd strongly
suspect the change to using the custom layer, but it seems likely it
was only in the last couple of months it's happened?
-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 26/01/2022 00:01 Alan Third <alan@idiocy.org> ha scritto:
> 
> but it seems likely it was only in the last couple of months it's happened?

I think no, it seems older. Tried to build six month older commit and it shows the same defect..

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Alan Third  ha scritto:
> 
> I'm afraid all I can suggest for now is trying to find a 
> commit that worked and 
> doing a git bisect to find the actual commit that causes 
> the problem, because 
> I can't see anything obvious in the logs for last month 
> that would've caused it.

I don't have a Emacs source setup from git, don't want, don't have time...

What I did is this: from the web interface, https://git.savannah.gnu.org/cgit/emacs.git/log, I searched for:

author Alan

then tried some build (from the emacs-COMMIT.tar.gz) and found that

1)
commit: d2d3fc39295953b4db5bdd7a21d513a87d3d00f0
Alan Third 2021-07-26 23:12:31 +0100
Convert fringe bitmaps to vectors on NS port

builds and HAS scrollbars;

-----------------------------

2)
commit: a4d2c88cdee90a3e4863a62c4ff69896d0c1a347
Alan Third 2021-07-31 11:13:05 +0100
Simplify macOS drawing code

builds and DOES NOT HAVE scrollbars

Obviously, there could be other commits between the above which could have broken the scrollbars..

Re: Scroll bars on macOS builds

[Alan Third]

On Wed, Jan 26, 2022 at 06:07:24PM +0100, Angelo Graziosi wrote:
> > Il 26/01/2022 00:01 Alan Third ha scritto:
> > 
> > 
> > Can you try changing line 7198 in nsterm.m from
> > 
> >   [self setWantsLayer:YES];
> > 
> > to
> > 
> >   [self setWantsLayer:NO];
> > 
> > ?
> 
> Emacs crashes at startup. I have rebuilt Emacs from current master and from master-20220111 with your suggestions but it wont start!
> 
> Attached the bug report it want to send to Apple people...

Actually, can you try this again, but remove the call to flushWindow
in unlockFocus (line 7902)? I've a feeling that's a GNUstep method
that's accidentally crept into the Cocoa code.

-- 
Alan Third

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 27/01/2022 20:59 Alan Third ha scritto:
> 
>  
> On Wed, Jan 26, 2022 at 06:07:24PM +0100, Angelo Graziosi wrote:
> > > Il 26/01/2022 00:01 Alan Third ha scritto:
> > > 
> > > 
> > > Can you try changing line 7198 in nsterm.m from
> > > 
> > >   [self setWantsLayer:YES];
> > > 
> > > to
> > > 
> > >   [self setWantsLayer:NO];
> > > 
> > > ?
> > 
> > Emacs crashes at startup. I have rebuilt Emacs from current master and from master-20220111 with your suggestions but it wont start!
> > 
> > Attached the bug report it want to send to Apple people...
> 
> Actually, can you try this again, but remove the call to flushWindow
> in unlockFocus (line 7902)? I've a feeling that's a GNUstep method
> that's accidentally crept into the Cocoa code.

I have built current master with patch (do you mean it?) below and it works, i.e. scrollbars are visible!

--- nsterm.m.orig	2022-01-27 22:26:12.000000000 +0100
+++ nsterm.m	2022-01-27 22:44:59.000000000 +0100
@@ -7195,7 +7195,7 @@
      on resize.  Unfortunately it also means the frame will not be
      automatically marked for display, but we can do that ourselves in
      resizeWithOldSuperviewSize.  */
-  [self setWantsLayer:YES];
+  [self setWantsLayer:NO];
   [self setLayerContentsRedrawPolicy:
           NSViewLayerContentsRedrawOnSetNeedsDisplay];
   [self setLayerContentsPlacement:NSViewLayerContentsPlacementTopLeft];
@@ -7899,7 +7899,6 @@
   else
     {
       [super unlockFocus];
-      [super flushWindow];
     }
 #endif
 }

Re: Scroll bars on macOS builds

[Angelo Graziosi]

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

In any case, the patch below breaks tabbar package from MELPA: I cannot switch buffer clicking on the left-right arrows the package uses to this end. The mouse pointer changes correctly from "arrow" shape to "hand" shape when over those arrows but clicking does not have any effect, the tabs with buffers name should scroll. I DOES NOT scroll.. 

I attached the screenshot of that element of the tabbar package from MELPA...


> Il 27/01/2022 23:10 Angelo Graziosi  ha scritto:
> 
> I have built current master with patch (do you mean it?) below and it works, i.e. scrollbars are visible!
> 
> --- nsterm.m.orig	2022-01-27 22:26:12.000000000 +0100
> +++ nsterm.m	2022-01-27 22:44:59.000000000 +0100
> @@ -7195,7 +7195,7 @@
>       on resize.  Unfortunately it also means the frame will not be
>       automatically marked for display, but we can do that ourselves in
>       resizeWithOldSuperviewSize.  */
> -  [self setWantsLayer:YES];
> +  [self setWantsLayer:NO];
>    [self setLayerContentsRedrawPolicy:
>            NSViewLayerContentsRedrawOnSetNeedsDisplay];
>    [self setLayerContentsPlacement:NSViewLayerContentsPlacementTopLeft];
> @@ -7899,7 +7899,6 @@
>    else
>      {
>        [super unlockFocus];
> -      [super flushWindow];
>      }
>  #endif
>  }

[-- Attachment #2: melpa-tabbar-arrows-NOTOK.png --]
[-- Type: image/png, Size: 9787 bytes --]

Re: Scroll bars on macOS builds

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have no opinion about this specific change.
I note that (1) MacOS is not a high priority for us, and
(2) it's not part of our mission to maintain compatibility
with MELPA packages.

We can cooperate with the developers of specific packages that are
currently in MELPA if they cooperate with us too.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Scroll bars on macOS builds

[Alan Third]

On Sat, Jan 29, 2022 at 04:43:23PM +0100, Angelo Graziosi wrote:
> In any case, the patch below breaks tabbar package from MELPA: I cannot switch buffer clicking on the left-right arrows the package uses to this end. The mouse pointer changes correctly from "arrow" shape to "hand" shape when over those arrows but clicking does not have any effect, the tabs with buffers name should scroll. I DOES NOT scroll.. 
> 
> I attached the screenshot of that element of the tabbar package from MELPA...
> 
> 
> > Il 27/01/2022 23:10 Angelo Graziosi  ha scritto:
> > 
> > I have built current master with patch (do you mean it?) below and it works, i.e. scrollbars are visible!
> > 
> > --- nsterm.m.orig	2022-01-27 22:26:12.000000000 +0100
> > +++ nsterm.m	2022-01-27 22:44:59.000000000 +0100
> > @@ -7195,7 +7195,7 @@
> >       on resize.  Unfortunately it also means the frame will not be
> >       automatically marked for display, but we can do that ourselves in
> >       resizeWithOldSuperviewSize.  */
> > -  [self setWantsLayer:YES];
> > +  [self setWantsLayer:NO];
> >    [self setLayerContentsRedrawPolicy:
> >            NSViewLayerContentsRedrawOnSetNeedsDisplay];
> >    [self setLayerContentsPlacement:NSViewLayerContentsPlacementTopLeft];
> > @@ -7899,7 +7899,6 @@
> >    else
> >      {
> >        [super unlockFocus];
> > -      [super flushWindow];
> >      }
> >  #endif
> >  }

I can't see any way that patch could affect the ability to click on
something. I could understand it perhaps breaking some visual feedback
or something, but the actual click detection has nothing to do with
how the frame is drawn at all.

I'm completely lost with this now.

-- 
Alan Third

Re: Scroll bars on macOS builds

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> In any case, the patch below breaks tabbar package from MELPA: I
> cannot switch buffer clicking on the left-right arrows the package
> uses to this end. The mouse pointer changes correctly from "arrow"
> shape to "hand" shape when over those arrows but clicking does not
> have any effect, the tabs with buffers name should scroll. I DOES NOT
> scroll..
>
> I attached the screenshot of that element of the tabbar package from
> MELPA...

I don't know anything about this specific bug, but the NS port already
supports native tab bars, and you should use that instead.

Just enable `tab-bar-mode'.

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 30/01/2022 13:37 Alan Third ha scritto:
> 
>  
> On Sat, Jan 29, 2022 at 04:43:23PM +0100, Angelo Graziosi wrote:
> > In any case, the patch below breaks tabbar package from MELPA: I cannot switch buffer clicking on the left-right arrows the package uses to this end. The mouse pointer changes correctly from "arrow" shape to "hand" shape when over those arrows but clicking does not have any effect, the tabs with buffers name should scroll. I DOES NOT scroll.. 

> I can't see any way that patch could affect the ability to click on
> something. I could understand it perhaps breaking some visual feedback
> or something, but the actual click detection has nothing to do with
> how the frame is drawn at all.

..reverting the patch the tabs scroll again end the scrollbars are "invisible"...

> 
> I'm completely lost with this now.

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 30/01/2022 13:50 Po Lu  ha scritto:
> 
>  
> Angelo Graziosi writes:
> 
> > In any case, the patch below breaks tabbar package from MELPA: I
> > cannot switch buffer clicking on the left-right arrows the package
> > uses to this end. The mouse pointer changes correctly from "arrow"
> > shape to "hand" shape when over those arrows but clicking does not
> > have any effect, the tabs with buffers name should scroll. I DOES NOT
> > scroll..
> >
> > I attached the screenshot of that element of the tabbar package from
> > MELPA...
> 
> I don't know anything about this specific bug, but the NS port already
> supports native tab bars, and you should use that instead.
> 
> Just enable `tab-bar-mode'.

I know that but never understood how they work and how to reproduce the setup I have with tabbar. Maybe when I will have some time I will give it another try...

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 30/01/2022 05:19 Richard Stallman ha scritto:
> 
>  
> I have no opinion about this specific change.
> I note that (1) MacOS is not a high priority for us, and
> (2) it's not part of our mission to maintain compatibility
> with MELPA packages.

Understanding why an app does not work as expected on a platform helps also  to reduce bugs on other platforms.

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 30/01/2022 13:37 Alan Third ha scritto:
> 
>  
> On Sat, Jan 29, 2022 at 04:43:23PM +0100, Angelo Graziosi wrote:
> > In any case, the patch below breaks tabbar package from MELPA: I cannot switch buffer clicking on the left-right arrows the package uses to this end. The mouse pointer changes correctly from "arrow" shape to "hand" shape when over those arrows but clicking does not have any effect, the tabs with buffers name should scroll. I DOES NOT scroll.. 
> > 
> > I attached the screenshot of that element of the tabbar package from MELPA...
> > 
> > 
> > > Il 27/01/2022 23:10 Angelo Graziosi  ha scritto:
> > > 
> > > I have built current master with patch (do you mean it?) below and it works, i.e. scrollbars are visible!
> > > 
> > > --- nsterm.m.orig	2022-01-27 22:26:12.000000000 +0100
> > > +++ nsterm.m	2022-01-27 22:44:59.000000000 +0100
> > > @@ -7195,7 +7195,7 @@
> > >       on resize.  Unfortunately it also means the frame will not be
> > >       automatically marked for display, but we can do that ourselves in
> > >       resizeWithOldSuperviewSize.  */
> > > -  [self setWantsLayer:YES];
> > > +  [self setWantsLayer:NO];
> > >    [self setLayerContentsRedrawPolicy:
> > >            NSViewLayerContentsRedrawOnSetNeedsDisplay];
> > >    [self setLayerContentsPlacement:NSViewLayerContentsPlacementTopLeft];
> > > @@ -7899,7 +7899,6 @@
> > >    else
> > >      {
> > >        [super unlockFocus];
> > > -      [super flushWindow];
> > >      }
> > >  #endif
> > >  }
> 
> I can't see any way that patch could affect the ability to click on
> something. I could understand it perhaps breaking some visual feedback
> or something, but the actual click detection has nothing to do with
> how the frame is drawn at all.

With Emacs native tabs the patch works better...

Re: Scroll bars on macOS builds

[Angelo Graziosi]

> Il 03/02/2022 14:47 Angelo Graziosi ha scritto:
> 
>  
> > Il 30/01/2022 13:37 Alan Third ha scritto:
> > 
> >  
> > On Sat, Jan 29, 2022 at 04:43:23PM +0100, Angelo Graziosi wrote:
> > > In any case, the patch below breaks tabbar package from MELPA: I cannot switch buffer clicking on the left-right arrows the package uses to this end. The mouse pointer changes correctly from "arrow" shape to "hand" shape when over those arrows but clicking does not have any effect, the tabs with buffers name should scroll. I DOES NOT scroll.. 
> > > 
> > > I attached the screenshot of that element of the tabbar package from MELPA...
> > > 
> > > 
> > > > Il 27/01/2022 23:10 Angelo Graziosi  ha scritto:
> > > > 
> > > > I have built current master with patch (do you mean it?) below and it works, i.e. scrollbars are visible!
> > > > 
> > > > --- nsterm.m.orig	2022-01-27 22:26:12.000000000 +0100
> > > > +++ nsterm.m	2022-01-27 22:44:59.000000000 +0100
> > > > @@ -7195,7 +7195,7 @@
> > > >       on resize.  Unfortunately it also means the frame will not be
> > > >       automatically marked for display, but we can do that ourselves in
> > > >       resizeWithOldSuperviewSize.  */
> > > > -  [self setWantsLayer:YES];
> > > > +  [self setWantsLayer:NO];
> > > >    [self setLayerContentsRedrawPolicy:
> > > >            NSViewLayerContentsRedrawOnSetNeedsDisplay];
> > > >    [self setLayerContentsPlacement:NSViewLayerContentsPlacementTopLeft];
> > > > @@ -7899,7 +7899,6 @@
> > > >    else
> > > >      {
> > > >        [super unlockFocus];
> > > > -      [super flushWindow];
> > > >      }
> > > >  #endif
> > > >  }
> > 
> > I can't see any way that patch could affect the ability to click on
> > something. I could understand it perhaps breaking some visual feedback
> > or something, but the actual click detection has nothing to do with
> > how the frame is drawn at all.
> 
> With Emacs native tabs the patch works better...

I spoke too soon. 

With that patch Emacs DOES NOT work at ALL! Just clicking the tabs in tab-line works. 

Clicking to type text move the cursor there (but it does not blink) and what I typed is not inserted, as if it is unresponsive...

I have built the same source with and without the patch...