From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: texinfo-show-structure and occur Date: Sun, 14 Mar 2010 12:28:36 +0100 Message-ID: <871vfni1ln.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1268567410 7622 80.91.229.12 (14 Mar 2010 11:50:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 14 Mar 2010 11:50:10 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 14 12:50:06 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NqmKb-00069l-E7 for ged-emacs-devel@m.gmane.org; Sun, 14 Mar 2010 12:50:05 +0100 Original-Received: from localhost ([127.0.0.1]:53926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NqmKa-000465-TW for ged-emacs-devel@m.gmane.org; Sun, 14 Mar 2010 07:50:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NqmKV-00045W-2F for emacs-devel@gnu.org; Sun, 14 Mar 2010 07:49:59 -0400 Original-Received: from [140.186.70.92] (port=52620 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NqmKT-00045G-Bu for emacs-devel@gnu.org; Sun, 14 Mar 2010 07:49:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NqmKS-00068N-Bj for emacs-devel@gnu.org; Sun, 14 Mar 2010 07:49:57 -0400 Original-Received: from host55-72-dynamic.45-79-r.retail.telecomitalia.it ([79.45.72.55]:44266 helo=ambire.localdomain) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NqmKR-00068A-UI for emacs-devel@gnu.org; Sun, 14 Mar 2010 07:49:56 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1Nqlzo-0001c3-Tn for emacs-devel@gnu.org; Sun, 14 Mar 2010 12:28:36 +0100 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121946 Archived-At: In Texinfo mode, C-c C-s runs the command `texinfo-show-structure', which uses `occur' to prepare a buffer of section headers. Presently `occur' displays "Searched 1 buffer..." in the echo area, where the "..." is actually 270+ bytes, largely comprising the huge regexp required to identify the section headers. This output is multiline, expanding the echo area until next keypress, and irrelevant to the user as it is an implementation detail only. Furthermore, on next keypress when the echo area size reverts size, the common (for fast-moving Emacs users who are using C-c C-s to answer the question "where am i?" (after which the the next command is `kill-buffer' or `delete-window' (both by default with multi-keypress bindings))) use case produces a flickering effect. To alleviate, i tried first the following: (occur (concat "^\\(?:" (if nodes-too "@node\\>\\|") outline-regexp "\\)")) (message nil) This clears the echo area, but only after having done the deed. The flickering is now inherent, extending the misery to slow-moving users. Likewise the equivalent: (with-temp-message "" (occur (concat "^\\(?:" (if nodes-too "@node\\>\\|") outline-regexp "\\)"))) The more drastic approach: (flet ((message (&rest ignored) nil)) (occur (concat "^\\(?:" (if nodes-too "@node\\>\\|") outline-regexp "\\)"))) DTRT, but it uses `flet' which is frowned upon. So now we start thinking about how to alleviate more invasively (changing `occur'). Obviously `occur' is trying to be friendly, explaining its findings to the user, and we don't want to change that facet. Recognizing its role as an agent for `texinfo-show-structure', perhaps we can consider how to define "agent friendliness". In this case, `texinfo-show-structure' constructs a long regexp to express the idea "section headers". Wouldn't it be nice if `occur' could say: Searched 1 buffer; found NN section headers ? That would be both informative and concise. How about we extend `occur' to accept a variable name (symbol) for the REGEXP argument? In that case, `occur' would use `symbol-value' to get the actual (string) value. The symbol could have property `occur-targets' (or somesuch), to use in the "Searched" message, otherwise the variable name directly. Some scenarios: (let ((interesting (CONSTRUCT-LONG-REGEXP))) (put 'interesting 'occur-targets "interesting items") (occur 'interesting)) |= Searched 1 buffer; found NN interesting items (let ((cool-foo-bits (CONSTRUCT-LONG-REGEXP))) (occur 'cool-foo-bits)) |= Searched 1 buffer; found NN `cool-foo-bits' (defvar foo-cool-bits (CONSTRUCT-LONG-REGEXP)) (put 'foo-cool-bits 'occur-targets "`foo-cool-bits' (see foo.el)") (defun (...) ... (occur 'foo-cool-bits)) |= Searched 1 buffer; found NN `foo-cool-bits' (see foo.el) The last scenario is intended to show some kind of customization hint. It could also be effected by propertizing the string, etc., presuming the user pokes around the *Messages* buffer. For completely embedded agent friendliness, if `occur-targets' is t, `occur' could simply not display the message. What do people think? thi