Instead of passing the file descriptor to the child, and have the child close it, we set FD_CLOEXEC on the file descriptor in the parent process.
While it limits the window in which another thread can fork() and cause the file descriptor to be “leaked”, it doesn’t eliminate the problem.
The current options are:
-b/--benchmark Run benchmarks instead of tests.
-m/--measure Measure time of each test. This disables concurrency.
-r/--repeat <n> Number of times to repeat each test/benchmark.
-v/--verbose Be verbose.
-h/--help Show this help.
-V/--version Show version number.
The Find object is assigned to a variable with (guarded) static storage, so the initializer of the Find object will run with a lock on the guarded variable, which turns out to be shared with all other guarded variables.
When setting up the window controller, from the Find object’s initializer, we create a “recent folders” menu which hold icons with SCM badges.
When creating these SCM icons, blocks are scheduled (asynchronously) to “fetch status”. These asynchronous blocks will need to lock the same mutex as we currently have locked (because we haven’t yet left the initializer).
The issue is that we also schedule synchronous blocks on the same queue, and that’s why we get a deadlock, because those can’t run before the asynchronous blocks have finished, yet those are waiting on the global lock that our main thread has currently obtained.
Fixes#874.
Currently this is implemented in OakTextView which means that it doesn’t work for macros. Some refactoring is in order so that the implementation can be shared (lack of sharing has to do with how OakTextView reports status to Find dialog or via tool tips, and macros want none of that).
There is also no check to see if the current state of the editor is the result of a find operation, i.e. you can invoke “replace” regardless of wether or not “find” was the last action.
Finally, doing a multi-file search and using “find next” at the end of one document, which brings you to the first match of next document (part of the results), will not update “captures” from a potential regular expression search, meaning that if you then do “replace”, and your replacement string is a format string that references the match (via $1-n) then it will not be correctly expanded.
Closes#104.
Previously there was a single replace action and the options would indicate if it was a “replace all”, this mimics the “find” (which can be a “find all”) but since single match replacement is somewhat different than a “replace all”, as the former may need to know the captures from a previous find action, it makes sense to factor out these things as different actions.
This is work in progress but I don’t think any functionality is missing compared to previous commit, although some functionality might be less polished, e.g. the action buttons don’t properly enable/disable and the height of the results list gets lost when hiding it.
Some of the stuff that has changed / improved:
* The find/replace text fields adjust their height to encompass the content (closes#94). Presently though the initial height of the ontrols is one line regardless of content (but they should adjust on first edit).
* You can use Save All (⌥⌘S) to save affected files after Replace All (closes#558).
* The key equivalents / actions available in the Find dialog is now easier to find via the action pop-up, which also has enables accessibility.
* Using Next (⌘G) or Previous (⇧⌘G) with search results will move selection up/down.
* Using Find All with ‘in’ set to ‘Selection’ will find and select all matches in the current document, which fixes#425, though it might be more desirable to show the results in the find dialog (like Find All does for a document or folder).
This enables VoiceOver user to see the document view as a single
element and interact with it (i.e. inspect its subelements) only when
needed by using the VO-Shift-down shortcut (and stop interacting with
it using VO-Shift-up shortcut). This makes the element structure more
hierarchical where at the top level are only major user interface
components, so that it's easier for orientation. It also prevents
unrelated UI elements to be sequential as VoiceOver by default orders
elements by the visual order (top-down, left-right) rather then
the order in the AXChildren array. For example in this case,
the bottom status bar of the document window gets separated from
the bottom toolbar of the file browser, unlike the situation before
grouping when both bars were adjacent to the VoiceOver user.
This fixes semantics of the button and thus also its
accessibility. The macro recording button represents state - more
specifically a boolean state, so it has to be a NSToggleButton (or
its specialization). Then the button is presented to the VoiceOver
user as an AXCheckbox - that is a checkbox with on and off value -
which is exactly what the button's function is. Examples of this in
system apps is e.g. the "Play" button in QuickTime Player, which is
also an AXCheckbox ("Pause" is then simply an unchecked "Play"
checkbox).
VoiceOver reads an AXValue for a pop-up button - that is the selected
item. But button's title does not set an AXValue, as it probably is
not a menu item. So change the code set to the title by setting a
single menu item with that title.
This fixes accessibility of the pop-up when accessing its value before
it is first popped up. It makes the code consistent with setGrammarName:
which works fine (that's how I discovered how to fix it).
When enabled the height of the document is increased by the height of the view port, which means the last lines of the document are not anchored to the bottom of the view port but can e.g. be centered.
Closes#513.
We now try to find a scrollable view under the mouse, and if any scrolling was done, we reject the gesture as a “go back/forward” event.
Additionally we reject gestures with a duration of more than 0.2 seconds.
Maybe fixes#854.
When a C++ exception is thrown from code invoked via a menu item then the menu item dispatcher will catch the exception and abort, this means the report doesn’t show the actual exception or contain any of the involved code.
By logging the key event in the report we should be able to deduce what action was invoked.
Adding info to diagnostic reports “documentation” from http://mjtsai.com/blog/2013/02/27/application-specific-crash-report-information/
