Skip to content

Behavior difference in NSAttributeString itemNumberInTextList:atIndex: #293

Open
@fjmilens3

Description

Per Apple documentation, NSAttributeString's itemNumberInTextList:atIndex: should return the index of the item at the specified location within the list.

The current GNUStep implementation instead returns the index position of the list within the lists for the current paragraph style. This gives you the nesting level instead of the item number.

- (NSInteger) itemNumberInTextList: (NSTextList *)list
atIndex: (NSUInteger)location
{
NSParagraphStyle *style = [self attribute: NSParagraphStyleAttributeName
atIndex: location
effectiveRange: NULL];
if (style != nil)
{
NSArray *textLists = [style textLists];
if (textLists != nil)
{
return [textLists indexOfObject: list];
}
}
return NSNotFound;
}

For an example, consider the following list:

  • Alpha
  • Beta
  • Gamma
  • Delta
  • Epsilon

For a text position anywhere in, say, "Delta," Apple's implementation would return 4 as it's the fourth item in the list. The current GNUstep implementation returns 0 as the list is the zeroth item in the paragraph style's lists array.

I've been playing around with this locally but I'd encourage someone else with access to a Mac to verify the difference as well. Note that if you write a test program of your own with Cocoa on recent Macs, you'll probably want to opt-out of TextKit 2 behavior via [textView layoutManager] for an equal comparison to GNUStep.

If it turns out to be a valid bug, some thoughts based on my current, hacky workaround: Get the entire range of the list from rangeOfTextList:atIndex:, iterate over the range looking for newline characters, and basically count paragraphs until it reaches the position we were asked about. You'd also want to check against the lists in each paragraph's style to account for things like nested lists.

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions