From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24890: 25.1; Several documentation problems Date: Thu, 10 Nov 2016 18:26:15 +0200 Message-ID: <838tsrfgig.fsf@gnu.org> References: <834m3ji36h.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1478798478 5900 195.159.176.226 (10 Nov 2016 17:21:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Nov 2016 17:21:18 +0000 (UTC) Cc: 24890-done@debbugs.gnu.org To: Jorge Morais Neto Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 10 18:21:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4t2D-0000SJ-1K for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Nov 2016 18:21:09 +0100 Original-Received: from localhost ([::1]:47808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4t2D-0002Hk-1z for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Nov 2016 12:21:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4sBt-00015f-VN for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:27:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4sBq-0001Qu-Js for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:27:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37063) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4sBq-0001Qq-GZ for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c4sBq-0000PU-Bg for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2016 11:27:02 -0500 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2016 16:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 24890 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 24890@debbugs.gnu.org, eliz@gnu.org, jorge13515@gmail.com Original-Received: via spool by 24890-done@debbugs.gnu.org id=D24890.14787951841522 (code D ref 24890); Thu, 10 Nov 2016 16:27:02 +0000 Original-Received: (at 24890-done) by debbugs.gnu.org; 10 Nov 2016 16:26:24 +0000 Original-Received: from localhost ([127.0.0.1]:52461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4sBE-0000OU-Fz for submit@debbugs.gnu.org; Thu, 10 Nov 2016 11:26:24 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4sBD-0000OI-6R for 24890-done@debbugs.gnu.org; Thu, 10 Nov 2016 11:26:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4sB4-00017m-UF for 24890-done@debbugs.gnu.org; Thu, 10 Nov 2016 11:26:18 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4sB4-00017h-Qv; Thu, 10 Nov 2016 11:26:14 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4760 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c4sB3-0008Vd-GU; Thu, 10 Nov 2016 11:26:14 -0500 In-reply-to: (message from Jorge Morais Neto on Thu, 10 Nov 2016 12:36:58 -0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125557 Archived-At: > From: Jorge Morais Neto > Date: Thu, 10 Nov 2016 12:36:58 -0200 > Cc: 24890@debbugs.gnu.org > > >> 1) outline-hide-sublevels and outline-hide-other\\ > >> The docstrings and the manual should say that each of these commands reveals > >> everything it does not actively hide. > > > > AFAIU, "everything" here boils down to the top body without a heading, > > if any. Because the fact that all the levels N and above are revealed > > is mentioned in the doc string already, right? > In git (branch emacs-25), the docstring of outline-hide-sublevels is only: > "Hide everything but the top LEVELS levels of headers, in whole buffer. > This also unhides the top heading-less body, if any. > > Interactively, the prefix argument supplies the value of LEVELS. > When invoked without a prefix argument, LEVELS defaults to the level > of the current heading, or to 1 if the current line is not a heading." > > In my understanding, this still does not fully document the behavior > of actively revealing all headers up to level LEVELS. Maybe I'm missing something, but what does "Hide everything but the top LEVELS levels of headers" mean, if not that all the headers of those levels are revealed? > The docstring of outline-hide-other is also incomplete in this sense > because it does not fully document that it actively reveals the body > of the current entry (it then becomes visible even if it was > previously hidden). Once again, I'm at a loss. The doc string says Hide everything except current body and parent and top-level headings. IOW, it hides everything, leaving the current body revealed. How else can this phrase be interpreted? > >> 14) [[info:emacs#Other Repeating Search]]: In my test, "M-s o" does not "Run ‘occur’ > >> using the search string of the last incremental string search." Instead it > >> calls "occur" and asks for the pattern. The pattern can then be yanked with > >> "M-n". > > > > I cannot reproduce this. The feature works for me as documented. Did > > you invoke "M-s o" during the incremental search, i.e. after typing > > "C-s SOME-TEXT"? > The manual says: > Run ‘occur’ using the search string of the last incremental string > search. You can also run ‘M-s o’ when an incremental search is > active; this uses the current search string. > > If I understand English correctly (I am Brazilian) the first sentence > cited above says that if you run an incremental search, exit it (e.g. > by pressing RET), and later type M-s o, it will automatically run > ‘occur’ using the search string of the last incremental string search. To have occur use the last search string, you need to type "M-n" at the prompt. I've now clarified this in the manual. > >> And it should fully describe the behavior when both options are left at > >> their defaults. Currently it does not say what happens by default if no > >> suitable preceding word is found in the buffers accepted by the function > >> pointed out by dabbrev-friend-buffer-function. > > > > Not sure what you mean by the last sentence: did you mean the error > > that is signaled? > I mean the fact that, in that case, "dabbrev searches all the other > buffers, except those named in ‘dabbrev-ignored-buffer-names’, or > matched by ‘dabbrev-ignored-regexps’." (according to > dabbrev-check-all-buffers docstring). That is already in the doc string. Thanks.