From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: A widget-based version of find-cmd Date: Mon, 03 Jun 2019 15:07:41 -0400 Message-ID: References: <87v9xrfjyj.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="212789"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 03 21:08:06 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hXsJS-000tEQ-LN for ged-emacs-devel@m.gmane.org; Mon, 03 Jun 2019 21:08:06 +0200 Original-Received: from localhost ([127.0.0.1]:39677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hXsJR-0004q4-L7 for ged-emacs-devel@m.gmane.org; Mon, 03 Jun 2019 15:08:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hXsJI-0004po-Oj for emacs-devel@gnu.org; Mon, 03 Jun 2019 15:07:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hXsJG-0003MZ-L0 for emacs-devel@gnu.org; Mon, 03 Jun 2019 15:07:56 -0400 Original-Received: from [195.159.176.226] (port=41550 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hXsJE-0003Cr-CQ for emacs-devel@gnu.org; Mon, 03 Jun 2019 15:07:52 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hXsJA-000spM-Gd for emacs-devel@gnu.org; Mon, 03 Jun 2019 21:07:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:qC7x44Bxxq18uNZbgvLRHWxyg7A= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237228 Archived-At: > 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 think I understand what you're after, but I'd like to clarify: find-cmd lets you build a command using an Elisp expression, so it's meant for use from Elisp code, rather than interactively. Whereas you seem to be considering an interactive use case, right? > I would like to extend find-cmd cause it already has a collection of > syntactical information about find options -- would that be acceptable? Yes, of course. Another direction (complementary rather than opposed to what you're suggesting) would be to extend Elisp's completion so it understands `find-cmd` and hence gives you the valid completion after you type `(find-cmd '(pru TAB` [ Of course, we don't want elisp-mode.el to know about find-cmd.el, we'd instead want this to be modular; could be used for `rx` as well, for example. ] > Or would it be a better approach to try to somehow extract the > documentation of the options from the find man page? That'd be spiffy. > I'm currently struggling with the widget stuff however, mostly because I > struggle with the documentation. I'm sending you all my psychic power. I hope it helps. > 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). I think you're looking for the `lazy` widget. > 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? The Widgets code was written pretty much specifically for Customs, so I'm not surprised if some parts are not cleanly separated. Please mark them with a FIXME or fix them when you bump into them ;-) Stefan