Add ability to prevent certain mode's buffers from being stored

[shipmints]

e.g., *eshell* buffers are restorable just fine whereas *shell* buffers are not (among others, e.g., python process buffers https://github.com/alphapapa/burly.el/issues/30).

I apologize if bookmarks can already do this but I can't find where. I'm not really sure what a good solution is beyond crafting a default noop bookmark-handler that can be associated with modes that do not support bookmarks or advice around bookmark-default-handler. Or an activities configuration option that would take a list of buffer name regexp patterns and another list of modes to ignore, perhaps modeled after the way ibuffer-saved-filter-groups works?

Related: #30 #39 #40

[shipmints]

Related to bookmark restoration issues, it would be nice if the buffer created by activities--error-buffer were dismissable by pressing "q" as occur buffers are along with many others.

[alphapapa]

I'm not sure what the problem is here. Buffers whose major modes can't be bookmarked are already handled by showing a buffer explaining the problem.

If you propose to do something else for those buffers, that would introduce what seems to me like significant extra complexity, because we would have to decide what to do in their staid, how to decide which buffers to do that for, and how to define it.

To me, it's questionable whether that's even a good idea, because the idea is for all buffers to be restored properly; those that can't yet be restored are just waiting for someone to write the bookmark code, which is usually simple. And when that hasn't happened yet, well, I just bury the warning-message buffer or revert the activity. So to add all that extra code for a case that I hope will become less prevalent over time...I'm reluctant to do that.

Related to bookmark restoration issues, it would be nice if the buffer created by activities--error-buffer were dismissable by pressing "q" as occur buffers are along with many others.

Sure, that would be a trivial change. Patches welcome? =)

[shevvek]

Personally, I would really just like an option that instead of the error, a fresh buffer in the appropriate mode is created. I don't really even necessarily want the state of a REPL to persist, I just want a fresh one in the right place in my layout when I open an activity. And some modes like imenu-list generate their state live regardless so there is no need to restore state.

Here's some wrapping code that achieves this behavior:

(defvar dyn-mode-name-alist
  '(("*ielm*" . ielm)
    ("*Ilist*" . imenu-list-major-mode)))

(defun recreate-buffer-on-activities-error (orig-fun activities-buffer)
  (let* ((buf (funcall orig-fun activities-buffer))
         (buf-name (buffer-name buf)))
    (if (and buf
             (string-prefix-p "*Activities (error):" buf-name))
        (let* ((buf-restore-name (string-trim buf-name
                                              "*Activities (error): "
                                              "*"))
               (mode-cmd (alist-get buf-restore-name dyn-mode-name-alist
                                    nil nil #'equal)))
          (if mode-cmd
              (let ((new-buf (get-buffer-create buf-restore-name)))
                (with-current-buffer new-buf
                  (funcall mode-cmd)
                  new-buf))
            buf))
      buf)))

(advice-add 'activities--name-buffer
            :around #'recreate-buffer-on-activities-error)

It would be a bit more robust if the activities-buffer struct had a field for the major mode rather than needing to determine that based on the buffer name.