Quick-breakpoints are not configurable

[fzwo]

When clicking on the sidebar while holding cmd+shift, a logging breakpoint is quickly created. This always has a log action with text "%B %H". It would be nice to make this configurable.

[sjmills]

In addition, it'd be great if I could emulate the old Xcode breakpoint features where I could create any number of my own breakpoint templates, then assign them by right-clicking in the source or the breakpoint/line number ribbon and choose one from a submenu in the contextual menu. This is another feature I've submitted to Apple for them to re-add. Why they took it away is beyond comprehension.

[fzwo]

Do you have a video or other documentation of this feature handy?

[sjmills]

I quick search found one screenshot that shows a little bit of how powerful Xcode's breakpoints used to be. See the first answer here: http://stackoverflow.com/questions/4931959/how-do-you-add-a-breakpoint-in-xcode

Here's an old Xcode book that mentions breakpoint templates (hopefully this url works correctly): https://books.google.com/books?id=2-rM9yP7_hUC&pg=PA388&lpg=PA388&dq=xcode+builtin+breakpoints&source=bl&ots=_AZSDICqpO&sig=5MjOMitzC2E6G-U2Zpq9Chg8i8c&hl=en&sa=X&ved=0ahUKEwiE0OWz_6zMAhXEWx4KHR_XBmwQ6AEIHjAA#v=onepage&q=xcode%20builtin%20breakpoints&f=false

Ah, and here's Apple's old docs for Xcode before they crippled breakpoints. Page 36 talks about breakpoint templates, and page 20 lists the menu items in the Gutter Shortcut Menu: https://developer.apple.com/legacy/library/documentation/DeveloperTools/Conceptual/XcodeDebugging/Xcode_Debugging.pdf

I had a number of custom breakpoint templates that I often used, like one that played sound Tink and continued, one that played sound Pop and continued, one that logged the breakpoint name and continued, etc.

[fzwo]

Sounds very useful indeed!

I'm not sure when I'll find the time to do this, though. Being a (relatively) new father, my evenings are now shorter than they used to be :)

Of course, I'd be more than happy if you'd like to submit a pull request with your own implementation for this feature. If you choose to do that (and it's highly recommended as an avenue for growth as a dev), I'll help you as best I can.

[sjmills]

If it were easier to access and extend Xcode, I'd jump in. But every time I try, it takes half a day to filter through all the google hits that are still valid and figure it all out. Maybe some day.

[fzwo]

I see you've made a fork regardless. It's not as hard as you may think; it's just a bit scary at first, and time-consuming.

If you wish to try your hand, here are a few tips to get started:

Get class-dump, and run this script to get header files for all of Xcode: https://gist.github.com/fzwo/dc0533fe1ab6a124bd00

Then, create an empty Xcode project and add all these files to it. Open Quickly (Cmd+Shift+O) will help you find things.

Another way to gain even more insight is to get the Hopper disassembler (there is a free trial, I think), which will even allow you to look into the implementation of things. In Hopper, use Cmd+Shift+O and navigate to the binary inside Xcode.app that you want to inspect (you get the name and path from the header files from the class-dump script above). Cmd+Return on a method will give you relatively readable pseudocode.

If you build and run this plug-in, a new instance of Xcode will be run in the debugger. Use breakpoints and the debugger console to feel your way around.

Another, super cool tool is f-script with the f-script anywhere injection. It's a little awkward to get it to run, and you'll need to disable system integrity protection. But it will allow you to just click on views and see their class and variables and methods, and execute methods right in the running program you're inspecting (in this case, Xcode).

I'll talk more about this stuff at iOSDevUK in September, and also probably write a more in-depth guide sometime this year.