Configurable profile-opening function

[mpereira]

Hi @lastquestion,

Thanks for this package! It is a great idea, and a much more convenient workflow than manually profiling Emacs.

Do you think it makes sense to make the profile-opening function configurable? Right now, it is hard coded to profiler-report-profile-other-frame.

If it's made configurable, I'd personally configure it to just profiler-report-profile or profiler-report-profile-other-window so that new frames aren't being created. I've found that this could be a source of slowness on my setup.

[lastquestion]

Hello,

Thanks for testing it out and using it in this early phase!! Appreciate.

1. Yes, I think it should be customizable. There are a bunch of profiling related things that ought to be around profiling, sample size, report count saved, whether we should write a file out immediately, etc. Most / all of them should be customizable, and they should have hooks to be able to allow developers to do anything they like.
2. In Make profiling alert message soft (and configurable) #13 , I realized that this package needs to ultimately have TWO modes: "Developer", aka package maintainer, developer, etc; all the knobs, all the power, all the verbosity if wanted. And "Quiet, Normal", which operates like most OS level reporting tools: secretly, and occasionally says "Hey there, wanna send a report to help everyone?". Once I realized this, I think I'm OK with a lot of functionality control "in developer mode".

Given (2), I think:

• a function that can be hooked (not a hook, a -function kinda thing) that if the hook returns t, the default action is not applied for "open profile associated with profiling event" (this UX action will get reparented out of that buffer into a different UI, but still the action is the same). This will allow different UIs to be built one day, or the profile in memory to be adjusted, saved differently, transformed, etc.
• a custom var that allows one of the three profile display functions to be called. I'm an elisp beginner but I believe we can actually defcustom something that gives only those three functions as options, right?

FYI: in #4, we'll get proper UI around profiles, commands, asking for them to be profiled if you apriori know they're gonna be slow, ignoring commands, etc. So customizability around where windows and buffers show up is going to be important.

[lastquestion]

Oh, I'm dumb. The hook isn't necessary, if the defcustom allows any function, then that solves both the "use a different profile" versus "use a completely custom function" perfectly. This should be a small change.

[mpereira]

Yep, a defcustom for the function with a default should be enough afaict.