A widget-based version of find-cmd

[Michael Heerdegen]

Hello,

I like the idea of find-cmd.el but it's worthless to me since I use find
not often enough to remember all the option names, how time specs work
etc.

That's why I plan a widget-based version where the user can compose the
find command by clicking around in a tree of widgets, all guided with
categories to choose from, annotations with doc etc.

I would like to extend find-cmd cause it already has a collection of
syntactical information about find options -- would that be acceptable?

Or would it be a better approach to try to somehow extract the
documentation of the options from the find man page?

Else, I would have to extend find-constituents with the annotations to
show in the selection menus.  The original `find-cmd' behavior would be
untouched, the new widget-based thing would just be an additional
fancy interface.

I'm currently struggling with the widget stuff however, mostly because I
struggle with the documentation.  What I basically need is to define a
widget type that let's you choose from a list of options.  Among them
are combiners like "or" that, when chosen, should provide a widget of
the same type.  My problem is that I run into an infinite recursion.  I
thought I can avoid that by constructing the widget deferred via
:convert-widget but that doesn't help.  Maybe :convert-widget is not for
that purpose (actually, then I don't get the purpose of :convert-widget
from the widget manual).

Here is what I have thrown together so far - the basic widget type
described above has the name "a":

#+begin_src emacs-lisp
;; -*- lexical-binding: t -*-

(require 'widget)
(require 'find-cmd)
(eval-when-compile (require 'wid-edit))

(defvar find-cmd-wg-main-widget nil)

(define-widget 'a 'editable-list
  "Doc..."
  :value "ignore"
  :convert-widget
  (lambda (widget)
    (widget-put
     widget
     :args (cl-flet ((just-true (lambda (_) t))
                     (value-get-1 (lambda (w) (list 'iname 
(widget-field-value-get w)))))
             `((menu-choice
                :args
                ,(append
                  (delq nil
                        (mapcar
                         (pcase-lambda ((and `(,name . ,(or (and (pred listp) 
`(,arity))
                                                            (let arity nil)))
                                             (let name-string (symbol-name 
name))))
                           (ignore name)
                           (and arity
                                (if (zerop arity)
                                    `(choice-item ,name-string)
                                  `(editable-field :menu-tag ,name-string
                                                   :validate ,#'just-true
                                                   :format ,(concat name-string 
": %v")
                                                   :value-get ,#'value-get-1))))
                         find-constituents))
                  ;; (mapcar
                  ;;  (lambda (combiner)
                  ;;    `(a :tag ,(symbol-name combiner)))
                  ;;  '(or and not prune))
                  )))))
    widget))

(let ((buf (generate-new-buffer "*Widget Test*")))
  (pop-to-buffer buf)
  (kill-all-local-variables)
  (let ((inhibit-read-only t))
    (erase-buffer))
  (remove-overlays)
  (setq-local find-cmd-wg-main-widget (widget-create 'a))
  (use-local-map (let ((map (make-sparse-keymap)))
                   (set-keymap-parent map widget-keymap)
                   (define-key map [(control ?c) (control ?c)]
                     (lambda ()
                       (interactive)
                       (message "%s" (apply #'find-cmd (widget-value 
find-cmd-wg-main-widget)))))
                   map))
  (widget-setup))
#+end_src

If you comment out the commented stuff, you get the infinite recursion
problem.

BTW, apropos using C-c C-c, why is cus-edit stealing this key by doing

  (widget-put (get 'editable-field 'widget-type) :keymap custom-field-keymap)

AFAIU the editable-field widget is not only useful for custom?

TIA,

Michael.