krzyzanowskim

The NSTextViewportLayoutControllerDelegate.textViewportLayoutControllerDidLayout(_:) documentation states that

Layout information on textViewportLayoutController is up-to-date at the point of this call.

however it is easy to put the NSTextViewportLayoutController in a state where after calling textViewportLayoutControllerDidLayout, the value of viewportRange is nil (unexpected) and value of the property viewportBounds is .zero

The TextKit2 sample application found at https://developer.apple.com/documentation/uikit/using-textkit-2-to-interact-with-text makes that assumption as well, and in few places force unwrap the value of viewportRange, that leads to runtime crashes.

This behavior is also discussed in Developer Forum thread about TextKit2 viewport relocation: https://developer.apple.com/forums/thread/761364?answerId=800516022#800516022

How to reproduce:

krzyzanowskim

import Foundation
import Cocoa

class DummyTextCheckingClient: NSObject, NSTextCheckingClient, NSTextInputClient {
    func handle(_ textCheckingResult: NSTextCheckingResult, for string: String, in range: NSRange, types checkingTypes: NSTextCheckingTypes, options: [NSSpellChecker.OptionKey : Any] = [:], orthography: NSOrthography?, wordCount: Int) {}
    func string(at index: Int, effectiveRange: NSRangePointer?) -> String? { return nil }
    func conversationIdentifier() -> Any? { return nil }
    func documentURL() -> URL? { return nil }
    func documentRange() -> NSRange { return NSRange(location: 0, length: 0) }
    func isEditable() -> Bool { return false }

krzyzanowskim

import SwiftUI

@main
struct TravelPhotographyApp: App {
    var body: some Scene {
        WindowGroup {
            RootView()
        }
        .commands {
            TextEditingCommands()

krzyzanowskim

import Foundation

let msg = """
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

krzyzanowskim

The documentation to the NSTextSelectionDataSource.enumerateCaretOffsetsInLineFragmentAtLocation:usingBlock regarding location parameter is not correct.

Online version https://developer.apple.com/documentation/uikit/nstextselectiondatasource/enumeratecaretoffsetsinlinefragment(at:using:)?language=objc

Documentations says: location - The NSTextLocation to start from.

however it is not where the enumeration starts. It is the location used to determine which line fragment to enumerate. The enumeration start from the line fragment location instead.

krzyzanowskim

NSTextFinder documentation for the findBarContainer property says:

When the find bar is to be shown, NSTextFinder invokes showFindBarView: on the findBarContainer object, passing the view for the find bar, which it should display somewhere that is associated appropriately with the content being searched.

however that method is never ever called. There's little use of that method found on the Internet, and the only instance I found in Mozilla codebase, that suggest that maybe was called in the past. That would mean this is regression bug.

macOS 15.2 (24C101) Xcode 16.2 (16C5032a)

krzyzanowskim

import AsyncAlgorithms

final class AsyncChannelObserverToken {
    private let task: Task<Void, Error>
    fileprivate init(_ task: Task<Void, Error>) {
        self.task = task
    }

    func cancel() {
        if !task.isCancelled {

krzyzanowskim

#!/bin/sh

# SETUP
# 
# create executable file ~/.lessfilter with the content of this file
# chmod u+x ~/.lessfilter
#
# setup less by adding lines below to ~/.zshrc
# ```
# export LESSOPEN="| ~/.lessfilter %s"

krzyzanowskim

import Foundation

let dirURL = URL(filePath: "/Users/marcinkrzyzanowski/Downloads/filewrappertest.test")

// cleanup
try? FileManager.default.removeItem(at: URL(filePath: "/Users/marcinkrzyzanowski/Downloads/filewrappertest.test/COPY.png"))

let fw = try FileWrapper(url: dirURL)
// fw.fileWrappers // ["IMG_0736.png": <NSFileWrapper: 0x6000023a8420>]

krzyzanowskim

NSTextList is Equatable because NSObject is always Equatable, however if anyone expect that may compare two instances of NSTextList that is false. This is because NSTextList.isEqual() do return true value for equal instances. This situation makes impossible to eg. compare NSParagraphStyle instances with testLists property as it will always fail. This situation seems easy fixable and will significanlty improve testability of the codebases (eg. mine)

        do {
            let a = NSTextList(markerFormat: .disc, options: 0) // Equatable
            let b = NSTextList(markerFormat: .disc, options: 0) // Equatable
            let c = a == b        // false
            let co = a.isEqual(b) // false
        }