Opened 14 years ago

Closed 12 years ago

#63 closed defect (fixed)

Narrowing a window scrolls left edge

Reported by: gz Owned by: rme
Priority: minor Milestone:
Component: IDE Version:
Keywords: Cc:


Making the editor window narrower scrolls (horizontally) a few pixels off the screen, at least the first time you do it.

Note this is different from Ticket #45 which is about vertical positioning.

Change History (8)

comment:1 Changed 14 years ago by gb

  • Priority changed from major to minor

If anyone thinks that this is major, feel free to change the priority back.

Ticket:45 is just the way that some private selection-centering methods work; it behaves exactly the same way in TextEdit? and every other Mac application that I'm aware of.

I'm not sure that I understand the bug description here well enough to be able to reproduce it. If anyone can, it'd be useful to know whether the observed and undesirable behavior is somehow unique to OpenMCL's IDE.

comment:2 Changed 14 years ago by gz

To reproduce:

  • Open cocoa-editor.lisp
  • grab the window grow control and drag it horizontally to the left about half an inch (i.e. make the window half an inch narrower)
  • let go the mouse.

The text jumps left a pixel or two when I let go of the mouse. I can grab the horizontal scroll bar and move it left to get the pixel back.

comment:3 Changed 14 years ago by rme

  • Owner changed from gb to rme
  • Status changed from new to assigned

comment:4 Changed 14 years ago by rme

The story with this appears to be the same as ticket:45. This is built-in appkit behavior, it looks like.

One way to avoid this is to enable the "wrap lines to window" preference. Of course, then you don't get a horizontal scroll bar, but things don't move around quasi-randomly either.

comment:5 Changed 14 years ago by rme

(From ticket:69)

Open cocoa-editor.lisp. Scroll down so that the first def-cocoa-default line is on the screen. Move insertion point to start of that line. Type ctl-space ctl-n. The whole text area moves a pixel or two to the left.

comment:7 Changed 12 years ago by gb

And apparently again in ticket:483.

Presumably also reported on lots of other Cocoa editor bug tracking systems, since it seems to be intentional (if undesirable) behavior of some internal NSTextView method.

I have no idea of how to avoid it; it seems to annoy enough people that it may be worth using an Apple Support Incident on.

I believe that both horizontal (if enabled) and vertical scrolling can occur after a resize, don't know of anything that we're doing or not doing that causes this, and don't know how many duplicates of this bug we already have.

comment:8 Changed 12 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

I believe that this and ticket:45 describe different aspects of the same behavior, where some ...resize... method in NSTextView decides that the selection should be centered after the view is resized; it winds up calling #/setOrigin: on the containing scroll-view's content-view (an NSClipView.)

We use a custom subclass of NSClipView and extend the #/setOrigin: method (so that we can compute transient attributes as we scroll through the buffer); in r12125, out implementation of this method does nothing (and doesn't actually scroll) if it's called when "live resize" is active, and that seems to work around this.

Note: See TracTickets for help on using tickets.