From unknown Sun Jun 22 11:32:17 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#4147 <4147@debbugs.gnu.org> To: bug#4147 <4147@debbugs.gnu.org> Subject: Status: 23.1.50: Info-search command strange behaviour Reply-To: bug#4147 <4147@debbugs.gnu.org> Date: Sun, 22 Jun 2025 18:32:17 +0000 retitle 4147 23.1.50: Info-search command strange behaviour reassign 4147 emacs submitter 4147 Jamie Lokier severity 4147 normal tag 4147 patch thanks From jamie@shareable.org Fri Aug 14 20:50:03 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 15 Aug 2009 03:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7F3o1Mk027651 for ; Fri, 14 Aug 2009 20:50:03 -0700 Received: from mx10.gnu.org ([199.232.76.166]:42934) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1McAHJ-0002XH-7F for emacs-pretest-bug@gnu.org; Fri, 14 Aug 2009 23:50:01 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1McAHH-00004w-Ti for emacs-pretest-bug@gnu.org; Fri, 14 Aug 2009 23:50:01 -0400 Received: from mail2.shareable.org ([80.68.89.115]:40005) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1McAHH-0008WO-F0 for emacs-pretest-bug@gnu.org; Fri, 14 Aug 2009 23:49:59 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1McAHF-00084U-NG for emacs-pretest-bug@gnu.org; Sat, 15 Aug 2009 04:49:57 +0100 Date: Sat, 15 Aug 2009 04:49:57 +0100 From: Jamie Lokier To: emacs-pretest-bug@gnu.org Subject: 23.1.50: Info-search command strange behaviour Message-ID: <20090815034957.GA30902@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) In GNU Emacs 23.1.50.1 (i486-pc-linux-gnu, GTK+ Version 2.16.1) of 2009-07-31 on lansones, modified by Debian (emacs-snapshot package, version 1:20090730-1~jaunty1) (= the Ubuntu-PPA Jaunty package at the time of writing) When searching through a manual with the 's' key, which invokes Info-search, it has odd behaviour when the string isn't found. Firstly, sometimes it shows the usual message about not finding the string, but moves point forward by a few characters that have no relationship with the search. Point should remain in the same place. Secondly, sometimes after entering the search regex, instead of searching it says Wrong type argument: stringp, nil. Here's how I can repeat it: Start Emacs with no customisation: emacs -nw -Q Invoke Info, go to the directory: C-h i Search: s blahblah RET => Says it can't find it, and point does not move. Go to the Emacs manual: m Emacs (emacs-snapshot) RET Search: s blahblah RET => Says it can't find it, but moves point forward a few characters. Go back to the Info directory: d Search: s blahblah RET => Says "Wrong type argument: stringp, nil" That's all. It was the point moving that I found particularly odd, when searching repeatedly for a term. First point moved as expected with each "s RET" sequence, but then it carried on moving after there were no more occurrences which was confusing. I noticed the error after returning to the Info directory following that. Thanks, -- Jamie From rudalics@gmx.at Sat Aug 15 03:11:15 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 15 Aug 2009 10:11:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MIXEDBDN,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n7FABDQ4027519 for <4147@emacsbugs.donarmstrong.com>; Sat, 15 Aug 2009 03:11:15 -0700 Received: (qmail invoked by alias); 15 Aug 2009 10:11:07 -0000 Received: from 62-47-35-223.adsl.highway.telekom.at (EHLO [62.47.35.223]) [62.47.35.223] by mail.gmx.net (mp059) with SMTP; 15 Aug 2009 12:11:07 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+X7RguFt2X5RujLDjHPC9N9hMp+JO2DAmEcZbtLz XT67W/RnrBPoRK Message-ID: <4A86898F.6060508@gmx.at> Date: Sat, 15 Aug 2009 12:10:23 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jamie Lokier , 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> In-Reply-To: <20090815034957.GA30902@shareable.org> Content-Type: multipart/mixed; boundary="------------040906040904060109050304" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71,0.72 This is a multi-part message in MIME format. --------------040906040904060109050304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > s blahblah RET > => Says it can't find it, but moves point forward a few characters. I suppose something like the attached patch should cure that. > Go back to the Info directory: > d > > Search: > s blahblah RET > => Says "Wrong type argument: stringp, nil" FWIW this happens because in the (with-current-buffer (marker-buffer Info-tag-table-marker) form `Info-tag-table-marker' is nil and `with-current-buffer' expects either a valid buffer or a string naming a buffer. I don't know how Info tags are handled so I leave this to someone more knowledgeable. > That's all. It was the point moving that I found particularly odd, > when searching repeatedly for a term. First point moved as expected > with each "s RET" sequence, but then it carried on moving after there > were no more occurrences which was confusing. I noticed the error > after returning to the Info directory following that. martin --------------040906040904060109050304 Content-Type: text/plain; name="info.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="info.el.diff" *** info.el.~1.562.~ 2009-07-27 08:09:32.407806900 +0200 --- info.el 2009-08-15 11:18:33.578125000 +0200 *************** *** 1818,1825 **** (signal 'search-failed (list regexp)))) (if (not found) (progn (Info-read-subfile osubfile) - (goto-char opoint) (Info-select-node) (set-window-start (selected-window) ostart))))) (if (and (string= osubfile Info-current-subfile) --- 1818,1825 ---- (signal 'search-failed (list regexp)))) (if (not found) (progn (Info-read-subfile osubfile) (Info-select-node) + (goto-char opoint) (set-window-start (selected-window) ostart))))) (if (and (string= osubfile Info-current-subfile) --------------040906040904060109050304-- From lekktu@gmail.com Thu Oct 22 02:35:31 2009 Received: (at control) by emacsbugs.donarmstrong.com; 22 Oct 2009 09:35:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=AWL,MISSING_SUBJECT, MURPHY_DRUGS_REL8,NOSUBJECT,VALID_BTS_CONTROL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9M9ZTNW004084 for ; Thu, 22 Oct 2009 02:35:31 -0700 Received: by fxm9 with SMTP id 9so9696363fxm.1 for ; Thu, 22 Oct 2009 02:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=8EmqKmTQZFxRHmBqMf0mAHPBq3MFliknc0lztWoJq6Y=; b=HxQYupT4FFltZz1ItMJj0h3XTFYNK5e7ryT0Cek2T3YESYQLNQM8G9V9i2CKiMAEbc EvYuLj8f7w1qApk14qvzihjcYCGQUOU+1DBevO5UhGKLQhzQ6+vBiuihHNGFYaXeeEYe kJYg0CmwEGM5xp9e/Qz4pt4br7Ml4TcpNJkWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Y5ybjjcxlLdLgAFAm7oQwPF4q6enZ/vhDgoBesbKLPsYfKZBy2gNxuVUArd1lZsA9C Mqc9bcUQhekOxrkhuBrM/oRLNjZDm8m0DPtCnEMhvvK6rKfs9H9j6QMJR6VObUwlfUeo 7VB35jQ8OYFrwvpcsbgPdQA8bmjmcb1XFRU14= MIME-Version: 1.0 Received: by 10.239.145.8 with SMTP id q8mr761204hba.122.1256204124158; Thu, 22 Oct 2009 02:35:24 -0700 (PDT) From: Juanma Barranquero Date: Thu, 22 Oct 2009 11:35:04 +0200 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 reassign 4326 emacs,ns merge 4261 4434 merge 1589 3359 4207 merge 3829 4077 tags 4781 + patch tags 4747 + patch tags 4579 + patch tags 4471 + patch tags 4434 + patch tags 4234 + patch tags 4221 + patch tags 4147 + patch tags 4144 + patch tags 4139 + patch tags 4023 + patch tags 4736 + moreinfo unreproducible tags 4547 + notabug tags 4451 + notabug tags 4448 + moreinfo tags 4427 + moreinfo tags 4373 + notabug tags 4360 + notabug tags 4271 + moreinfo tags 4236 + moreinfo tags 4143 + moreinfo unreproducible tags 4120 + moreinfo unreproducible tags 4070 + moreinfo unreproducible severity 4422 wishlist severity 4396 minor severity 4394 minor severity 4341 wishlist severity 4300 minor severity 4263 minor severity 4178 minor severity 4172 wishlist severity 4110 wishlist severity 4056 wishlist close 4772 close 4700 close 4599 close 4515 close 4463 close 4445 close 4395 close 4334 close 4289 close 4219 quit From juri@jurta.org Fri Dec 4 18:08:49 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 5 Dec 2009 02:08:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nB528lWZ021123 for <4147@emacsbugs.donarmstrong.com>; Fri, 4 Dec 2009 18:08:48 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.30.133.cable.starman.ee [82.131.30.133]) by mx1.starman.ee (Postfix) with ESMTP id 87E153F422F; Sat, 5 Dec 2009 04:08:42 +0200 (EET) From: Juri Linkov To: martin rudalics Cc: Jamie Lokier , 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> Date: Sat, 05 Dec 2009 02:48:27 +0200 In-Reply-To: <4A86898F.6060508@gmx.at> (martin rudalics's message of "Sat, 15 Aug 2009 12:10:23 +0200") Message-ID: <877ht2ryys.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> s blahblah RET >> => Says it can't find it, but moves point forward a few characters. > > I suppose something like the attached patch should cure that. This patch works only when initially point was in the Top node, and fails in other nodes. The odd behavior when point moves forward by a few characters is caused by breadcrumbs inserted to the Info buffer (the distance point moves forward is the length of the breadcrumbs string). Setting `Info-breadcrumbs-depth' to 0 fixes this problem. But it is difficult to fix this when `Info-breadcrumbs-depth' > 0. >> Go back to the Info directory: >> d >> Search: >> s blahblah RET >> => Says "Wrong type argument: stringp, nil" > > FWIW this happens because in the > > (with-current-buffer (marker-buffer Info-tag-table-marker) > > form `Info-tag-table-marker' is nil and `with-current-buffer' expects > either a valid buffer or a string naming a buffer. I don't know how > Info tags are handled so I leave this to someone more knowledgeable. For unknown reasons, `Info-current-subfile' is not nil in `dir'. I'll take care of this bug. -- Juri Linkov http://www.jurta.org/emacs/ From juri@jurta.org Sat Dec 5 11:52:45 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 5 Dec 2009 19:52:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nB5JqhBl022234 for <4147@emacsbugs.donarmstrong.com>; Sat, 5 Dec 2009 11:52:45 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.97.127.cable.starman.ee [82.131.97.127]) by mx1.starman.ee (Postfix) with ESMTP id D9F1C3F425C; Sat, 5 Dec 2009 21:52:35 +0200 (EET) From: Juri Linkov To: 4147@debbugs.gnu.org Cc: martin rudalics , Jamie Lokier Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> Date: Sat, 05 Dec 2009 21:50:22 +0200 In-Reply-To: <877ht2ryys.fsf@mail.jurta.org> (Juri Linkov's message of "Sat, 05 Dec 2009 02:48:27 +0200") Message-ID: <87k4x1b7vd.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> s blahblah RET >>> => Says it can't find it, but moves point forward a few characters. > > The odd behavior when point moves forward by a few characters > is caused by breadcrumbs inserted to the Info buffer (the distance > point moves forward is the length of the breadcrumbs string). To fix this one idea is to remove the breadcrumbs line on leaving from the node, so breadcrumbs in all nodes located above the current node will not affect the point position. And in the case of getting the current point position, subtract the length of breadcrumbs in the current node. > Setting `Info-breadcrumbs-depth' to 0 fixes this problem. > But it is difficult to fix this when `Info-breadcrumbs-depth' > 0. > >>> Go back to the Info directory: >>> d >>> Search: >>> s blahblah RET >>> => Says "Wrong type argument: stringp, nil" > > For unknown reasons, `Info-current-subfile' is not nil in `dir'. > I'll take care of this bug. This part of the bug report is fixed now. -- Juri Linkov http://www.jurta.org/emacs/ From juri@jurta.org Tue Dec 8 12:18:44 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 8 Dec 2009 20:18:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nB8KIfPs031141 for <4147@emacsbugs.donarmstrong.com>; Tue, 8 Dec 2009 12:18:44 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.33.167.cable.starman.ee [82.131.33.167]) by mx1.starman.ee (Postfix) with ESMTP id 122AD3F42BB for <4147@emacsbugs.donarmstrong.com>; Tue, 8 Dec 2009 22:18:35 +0200 (EET) From: Juri Linkov To: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> Date: Tue, 08 Dec 2009 22:12:33 +0200 In-Reply-To: <87k4x1b7vd.fsf@mail.jurta.org> (Juri Linkov's message of "Sat, 05 Dec 2009 21:50:22 +0200") Message-ID: <87bpi9uszm.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>> s blahblah RET >>>> => Says it can't find it, but moves point forward a few characters. >> >> The odd behavior when point moves forward by a few characters >> is caused by breadcrumbs inserted to the Info buffer (the distance >> point moves forward is the length of the breadcrumbs string). > > To fix this one idea is to remove the breadcrumbs line on leaving > from the node, so breadcrumbs in all nodes located above the current > node will not affect the point position. And in the case of getting > the current point position, subtract the length of breadcrumbs in > the current node. Another idea I've considered is using point positions relative to the beginning of the node. But to be able to fix this for Isearch in Info we have to change semantics of Isearch variables like `isearch-other-end', to use relative point positions. This is too much trouble too. The only sane way I see to fix this problem is: 1. not to insert breadcrumbs to the Info buffer; 2. display breadcrumbs in the header line; 3. not to hide next/prev/up navigation links in the first line of the node. `Info-use-header-line' could provide an additional value `breadcrumbs' that does this and set it by default. If this is acceptable, I can prepare a patch. -- Juri Linkov http://www.jurta.org/emacs/ From juri@jurta.org Mon Dec 14 13:55:50 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 14 Dec 2009 21:55:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBELtm9E008965 for <4147@emacsbugs.donarmstrong.com>; Mon, 14 Dec 2009 13:55:50 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.94.164.cable.starman.ee [82.131.94.164]) by mx1.starman.ee (Postfix) with ESMTP id 7207B3F41DE for <4147@emacsbugs.donarmstrong.com>; Mon, 14 Dec 2009 23:55:43 +0200 (EET) From: Juri Linkov To: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> Date: Mon, 14 Dec 2009 23:54:16 +0200 In-Reply-To: <87bpi9uszm.fsf@mail.jurta.org> (Juri Linkov's message of "Tue, 08 Dec 2009 22:12:33 +0200") Message-ID: <87fx7d6x4j.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 1. not to insert breadcrumbs to the Info buffer; > > 2. display breadcrumbs in the header line; > > 3. not to hide next/prev/up navigation links in the first line > of the node. > > `Info-use-header-line' could provide an additional value `breadcrumbs' > that does this and set it by default. It seems better to leave next/prev/up navigation links in the header line because on a long node it's more convenient to use navigation links in the header because it doesn't scroll with the node buffer. This suggests to put navigation links and breadcrumbs in the header line on two lines. But when I tried to do this, the header line displays ^J for the newline instead of displaying two lines. Is this a limitation of the Emacs display engine? -- Juri Linkov http://www.jurta.org/emacs/ From rudalics@gmx.at Mon Dec 14 15:00:12 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 14 Dec 2009 23:00:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nBEN09Q1016264 for <4147@emacsbugs.donarmstrong.com>; Mon, 14 Dec 2009 15:00:11 -0800 Received: (qmail invoked by alias); 14 Dec 2009 23:00:02 -0000 Received: from 62-47-38-65.adsl.highway.telekom.at (EHLO [62.47.38.65]) [62.47.38.65] by mail.gmx.net (mp064) with SMTP; 15 Dec 2009 00:00:02 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+e46kzeQ+er+gb9tnteP5gXOdyzFWbLqinuu9763 6U0Apz43fHvF42 Message-ID: <4B26C372.9090008@gmx.at> Date: Tue, 15 Dec 2009 00:00:02 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov , 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> In-Reply-To: <87fx7d6x4j.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 > This suggests to put navigation links and breadcrumbs in the header line > on two lines. But when I tried to do this, the header line displays > ^J for the newline instead of displaying two lines. > > Is this a limitation of the Emacs display engine? I suppose you could cause some harm if you were able to work around that limitation ;-) martin From juri@jurta.org Mon Dec 14 15:59:40 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 14 Dec 2009 23:59:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBENxcu5022899 for <4147@emacsbugs.donarmstrong.com>; Mon, 14 Dec 2009 15:59:40 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.94.164.cable.starman.ee [82.131.94.164]) by mx1.starman.ee (Postfix) with ESMTP id 429F13F41D0; Tue, 15 Dec 2009 01:59:31 +0200 (EET) From: Juri Linkov To: martin rudalics Cc: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> Date: Tue, 15 Dec 2009 01:56:22 +0200 In-Reply-To: <4B26C372.9090008@gmx.at> (martin rudalics's message of "Tue, 15 Dec 2009 00:00:02 +0100") Message-ID: <87r5qx155l.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> This suggests to put navigation links and breadcrumbs in the header line >> on two lines. But when I tried to do this, the header line displays >> ^J for the newline instead of displaying two lines. >> >> Is this a limitation of the Emacs display engine? > > I suppose you could cause some harm if you were able to work around that > limitation ;-) Just the opposite is true: this limitation causes harm to users ;-) For example, tabbar.el that uses the header line is overwritten by Info's header line. But with more than one header line they would be able to coexist peacefully. -- Juri Linkov http://www.jurta.org/emacs/ From eliz@gnu.org Mon Dec 14 20:06:46 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 15 Dec 2009 04:06:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout20.012.net.il (mtaout20.012.net.il [80.179.55.166]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBF46iBp014885 for <4147@emacsbugs.donarmstrong.com>; Mon, 14 Dec 2009 20:06:45 -0800 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KUO00400DOE1R00@a-mtaout20.012.net.il> for 4147@emacsbugs.donarmstrong.com; Tue, 15 Dec 2009 06:05:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.160.137]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KUO002PVE0VE4D0@a-mtaout20.012.net.il>; Tue, 15 Dec 2009 06:05:20 +0200 (IST) Date: Tue, 15 Dec 2009 06:07:25 +0200 From: Eli Zaretskii Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour In-reply-to: <87fx7d6x4j.fsf@mail.jurta.org> X-012-Sender: halo1@inter.net.il To: Juri Linkov , 4147@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83ocm07ude.fsf@gnu.org> References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> > From: Juri Linkov > Date: Mon, 14 Dec 2009 23:54:16 +0200 > Cc: > > This suggests to put navigation links and breadcrumbs in the header line > on two lines. But when I tried to do this, the header line displays > ^J for the newline instead of displaying two lines. > > Is this a limitation of the Emacs display engine? The display code assumes there's only one ``glyph row'' in the header line, yes. And likewise in the mode line. From rudalics@gmx.at Tue Dec 15 00:16:46 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 15 Dec 2009 08:16:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nBF8Git0006464 for <4147@emacsbugs.donarmstrong.com>; Tue, 15 Dec 2009 00:16:46 -0800 Received: (qmail invoked by alias); 15 Dec 2009 08:16:38 -0000 Received: from 62-47-56-110.adsl.highway.telekom.at (EHLO [62.47.56.110]) [62.47.56.110] by mail.gmx.net (mp001) with SMTP; 15 Dec 2009 09:16:38 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19rQppOfXtrwvcKfseXFh8xUrKEg3zhyFMWZwpHuR myKI0xQ+9yx19g Message-ID: <4B2745E5.2050108@gmx.at> Date: Tue, 15 Dec 2009 09:16:37 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> In-Reply-To: <87r5qx155l.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.83 > For example, tabbar.el that uses the header line is overwritten > by Info's header line. But with more than one header line > they would be able to coexist peacefully. If you can come up with a mechanism to put the contents of the header line in a separate buffer I can easily write some code which displays that buffer in an attached window - if necessary, with automatic height adjustment. martin From juri@jurta.org Tue Dec 15 17:05:03 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 16 Dec 2009 01:05:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBG151id017573 for <4147@emacsbugs.donarmstrong.com>; Tue, 15 Dec 2009 17:05:02 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.94.242.cable.starman.ee [82.131.94.242]) by mx1.starman.ee (Postfix) with ESMTP id 720023F4174; Wed, 16 Dec 2009 03:04:55 +0200 (EET) From: Juri Linkov To: martin rudalics Cc: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> Date: Wed, 16 Dec 2009 02:45:51 +0200 In-Reply-To: <4B2745E5.2050108@gmx.at> (martin rudalics's message of "Tue, 15 Dec 2009 09:16:37 +0100") Message-ID: <87my1johye.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> For example, tabbar.el that uses the header line is overwritten >> by Info's header line. But with more than one header line >> they would be able to coexist peacefully. > > If you can come up with a mechanism to put the contents of the header > line in a separate buffer I can easily write some code which displays > that buffer in an attached window - if necessary, with automatic height > adjustment. It seems very easy to put the contents of the header line in a separate buffer. Do you intend to display that buffer using some mechanism other than the header line? I'm afraid this won't work for tabbar.el that relies on the header line. -- Juri Linkov http://www.jurta.org/emacs/ From rudalics@gmx.at Tue Dec 15 23:53:26 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 16 Dec 2009 07:53:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nBG7rOsG027150 for <4147@emacsbugs.donarmstrong.com>; Tue, 15 Dec 2009 23:53:25 -0800 Received: (qmail invoked by alias); 16 Dec 2009 07:53:18 -0000 Received: from 62-47-61-127.adsl.highway.telekom.at (EHLO [62.47.61.127]) [62.47.61.127] by mail.gmx.net (mp051) with SMTP; 16 Dec 2009 08:53:18 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18Ulw8NJR0U17qDBSMDjLWrUUtcXonA6soF3p3m65 VESfEaeG8uYZWI Message-ID: <4B2891EC.4070500@gmx.at> Date: Wed, 16 Dec 2009 08:53:16 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> In-Reply-To: <87my1johye.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 > It seems very easy to put the contents of the header line in a separate > buffer. Do you intend to display that buffer using some mechanism other > than the header line? I'm afraid this won't work for tabbar.el that relies > on the header line. I never looked at tabbar.el so I can't tell. But suppose you can make it work that whatever it displays via `header-line-format' goes to a separate buffer - and obviously relays back any user input on that buffer's contents to the tabbar dispatcher which is the harder part. Then we could display that buffer in a window attached to some other window including a frame's root window. That way tabbar wouldn't interfere any more with other modes using the header line like info or ruler-mode. Also, tabs could be displayed on the left or right of a window. Moreover, users could choose between a one-tabbar-per-frame and a one-tabbar-per-window setting. In the former case the tabbar would vanish only when tabbars are switched off or the frame gets deleted, just like the toolbar. In the latter case, a tabbar would disappear whenever the associated window gets deleted. martin From juri@jurta.org Wed Dec 16 01:33:49 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 16 Dec 2009 09:33:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out3.starman.ee [85.253.0.5]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBG9Xlhl006124 for <4147@emacsbugs.donarmstrong.com>; Wed, 16 Dec 2009 01:33:49 -0800 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.94.242.cable.starman.ee [82.131.94.242]) by mx1.starman.ee (Postfix) with ESMTP id 4AA223F41E6; Wed, 16 Dec 2009 11:33:41 +0200 (EET) From: Juri Linkov To: martin rudalics Cc: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> Date: Wed, 16 Dec 2009 11:17:59 +0200 In-Reply-To: <4B2891EC.4070500@gmx.at> (martin rudalics's message of "Wed, 16 Dec 2009 08:53:16 +0100") Message-ID: <87hbrrgvq1.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > I never looked at tabbar.el so I can't tell. But suppose you can make > it work that whatever it displays via `header-line-format' goes to a > separate buffer - and obviously relays back any user input on that > buffer's contents to the tabbar dispatcher which is the harder part. I think no need to relay back because a keymap click in a "header-line" window will call a function that updates `header-line-format' whose new content will be displayed in this window anyway. > Then we could display that buffer in a window attached to some other > window including a frame's root window. That way tabbar wouldn't > interfere any more with other modes using the header line like info or > ruler-mode. Also, tabs could be displayed on the left or right of a > window. This means we need extra buffer per every header-line. > Moreover, users could choose between a one-tabbar-per-frame and a > one-tabbar-per-window setting. In the former case the tabbar would > vanish only when tabbars are switched off or the frame gets deleted, > just like the toolbar. In the latter case, a tabbar would disappear > whenever the associated window gets deleted. I don't understand how do you intend to ensure that the tabbar of the selected window doesn't disappear if the user types `C-x 1' (`delete-other-windows')? -- Juri Linkov http://www.jurta.org/emacs/ From rudalics@gmx.at Wed Dec 16 07:04:12 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 16 Dec 2009 15:04:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, SARE_MLB_Stock6 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nBGF4A8W010915 for <4147@emacsbugs.donarmstrong.com>; Wed, 16 Dec 2009 07:04:12 -0800 Received: (qmail invoked by alias); 16 Dec 2009 15:04:04 -0000 Received: from 62-47-34-13.adsl.highway.telekom.at (EHLO [62.47.34.13]) [62.47.34.13] by mail.gmx.net (mp014) with SMTP; 16 Dec 2009 16:04:04 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+e2SFAEyeebVT5m7Pj9lE672yPQAYzO44ky4a/D/ elEIOUAq/ucoVc Message-ID: <4B28F6E2.8020000@gmx.at> Date: Wed, 16 Dec 2009 16:04:02 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> In-Reply-To: <87hbrrgvq1.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 > I think no need to relay back because a keymap click in a "header-line" > window will call a function that updates `header-line-format' whose new > content will be displayed in this window anyway. But you want to display the buffer the tab stands for in the other window and not in the window where the tab appears. That has to be handled. > This means we need extra buffer per every header-line. Yes. > I don't understand how do you intend to ensure that the tabbar > of the selected window doesn't disappear if the user types > `C-x 1' (`delete-other-windows')? Windows code can investigate all sorts of window parameters - in the present case there would be parameters like "nodelete", "noresize", "nosplit" and "noother" say. Now consider a configuration like this -------------------- | T | |--------------------| | W | | | | | | | | | -------------------- where T is the tabbar window and W the window (live or internal) the tabbar is attached to. These windows share a parent window which doesn't contain any other window. The tabbar window T would have nodelete 'this ... the only way to delete T is via `delete-window' with T as argument or `delete-other-windows' with any but T or W as argument. C-x 1 invoked with either T or W selected will fill the frame with T and W and delete all other windows. C-x 0 in T deletes T but leaves W alone. noresize 'vertical ... means T cannot be resized vertically. nosplit 'parent ... means C-x 2 on T will split the parent window of T and W instead. noother t ... means `other-window' will skip T. There should be a special command to cycle through the attached windows of W and back to W though. But `other-window' and its clients should not try to pick a window like T. The window W would have nodelete 'parent ... means C-x 0 in W will delete both T and W. C-x 1 in W means only W and T will be left on their frame. We could add the twist that on a frame containing W and T only C-x 1 in W deletes T. nosplit 'parent ... is as above. Note that parameter values like 'parent are transitive so you can attach, for example, another window on the left like: ------------------------- | S | T | | |--------------------| | | W | | | | | | | | | | | | | ------------------------- and have C-x 0 in W delete S, T and W (provided there is another window left), C-x 0 in S or T behave as usual, and C-x 1 in S, T or W delete all windows but S, T and W. martin From drew.adams@oracle.com Wed Dec 16 11:21:39 2009 Received: (at 4147) by emacsbugs.donarmstrong.com; 16 Dec 2009 19:21:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBGJLb5g010066 for <4147@emacsbugs.donarmstrong.com>; Wed, 16 Dec 2009 11:21:39 -0800 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nBGJLFqh031775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Dec 2009 19:21:17 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.1/Switch-3.4.1) with ESMTP id nBGJLNA7012068; Wed, 16 Dec 2009 19:21:23 GMT Received: from abhmt002.oracle.com by acsmt356.oracle.com with ESMTP id 1059625701260991279; Wed, 16 Dec 2009 11:21:19 -0800 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Dec 2009 11:21:19 -0800 From: "Drew Adams" To: "'martin rudalics'" , <4147@debbugs.gnu.org>, "'Juri Linkov'" References: <20090815034957.GA30902@shareable.org><4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org><87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org><87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at><87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at><87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at><87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> Subject: RE: bug#4147: 23.1.50: Info-search command strange behaviour Date: Wed, 16 Dec 2009 11:21:21 -0800 Message-ID: <7997E65B52EF4DDE9E6F8032A6CD2EB7@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp+aV9bZ1M+G3ReR1KpEWvHb6hyywABNdiQ In-Reply-To: <4B28F6E2.8020000@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4B293334.0148:SCFMA4539814,ss=1,fgs=0 I don't really want to dive into this thread. I'll just note that it seems, from a superficial look, like you guys might be getting a bit far afield. ;-) The bug was about `s' in Info moving point when the search string is not found. The problem is apparently that it moves forward the length of some breadcrumbs. Juri proposed a couple of approaches to fixing that which sounded reasonable to me, the simplest seemingly to just back up the length of the breadcrumbs afterward (or perhaps use point minus that length to begin with). Sure, maybe things are not quite as simple as that - I haven't looked into it. But it seems like you are now off into the deep woods, redesigning plenty of things. Maybe you headed off the simple track when Juri said this: The only sane way I see to fix this problem is: 1. not to insert breadcrumbs to the Info buffer; 2. display breadcrumbs in the header line; 3. not to hide next/prev/up navigation links in the first line of the node. It's not obvious to me why that would be the only sane approach. Or the simplest, to fix this (minor) problem. From there you went on to multiple-line header lines, display engine limitations, interactions with tab bars, new design/implementation for header lines using special windows and buffers, etc. Are you just having fun, or is this really how you will approach fixing this bug? ;-) I don't mean to suggest that your efforts are misguided. As I said, I haven't followed this closely at all, and you guys are both solid and you know what you're doing. I'd just suggest that you _might_ want to take a step back and reconsider what the problem and goal are. HTH. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 17 19:31:36 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 00:31:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLQkq-0006Gc-JA for submit@debbugs.gnu.org; Thu, 17 Dec 2009 19:31:36 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLQSX-0005XD-Gb for 4147@debbugs.gnu.org; Thu, 17 Dec 2009 19:12:41 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.182.cable.starman.ee [82.131.31.182]) by mx1.starman.ee (Postfix) with ESMTP id EB4CF3F4126; Fri, 18 Dec 2009 02:12:31 +0200 (EET) From: Juri Linkov To: martin rudalics Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> Date: Fri, 18 Dec 2009 01:34:14 +0200 In-Reply-To: <4B29E99D.9060501@gmx.at> (martin rudalics's message of "Thu, 17 Dec 2009 09:19:41 +0100") Message-ID: <87fx79dwy9.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Debbugs-Envelope-To: 4147 X-Mailman-Approved-At: Thu, 17 Dec 2009 19:31:35 -0500 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > The windows handling code would allow to add to/remove from any number > of header/footer windows to a single main window. What I currently > don't have is a suitable divider - header windows won't have a modeline, > I presume. A divider is not necessary when buffers in the header windows are displayed with the `header-line' face. With this face they will clearly stand out from the main window. Currently I tried to experiment with the header window but immediately was thrown back by the presence of the modeline. With the modeline this looks very ugly. Do you know how to remove the modeline from the header window? I see some code in Emacs used for compatibility with XEmacs uses a property `has-modeline-p', but it seems this is only for frames, not windows. -- Juri Linkov http://www.jurta.org/emacs/ From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 02:32:29 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 07:32:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLXK9-0002ne-3E for submit@debbugs.gnu.org; Fri, 18 Dec 2009 02:32:29 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLWL4-0002H1-88 for 4147@emacsbugs.donarmstrong.com; Fri, 18 Dec 2009 01:29:22 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.103.cable.starman.ee [82.131.31.103]) by mx1.starman.ee (Postfix) with ESMTP id 5A33B3F4110; Thu, 17 Dec 2009 04:07:29 +0200 (EET) From: Juri Linkov To: "Drew Adams" Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <7997E65B52EF4DDE9E6F8032A6CD2EB7@us.oracle.com> Date: Thu, 17 Dec 2009 03:31:50 +0200 In-Reply-To: <7997E65B52EF4DDE9E6F8032A6CD2EB7@us.oracle.com> (Drew Adams's message of "Wed, 16 Dec 2009 11:21:21 -0800") Message-ID: <87tyvq2wa9.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Debbugs-Envelope-To: 4147 X-Mailman-Approved-At: Fri, 18 Dec 2009 02:32:26 -0500 Cc: 4147@debbugs.gnu.org, martin rudalics X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > Juri proposed a couple of approaches to fixing that which sounded > reasonable to me, the simplest seemingly to just back up the length of > the breadcrumbs afterward (or perhaps use point minus that length to > begin with). Sure, maybe things are not quite as simple as that - > I haven't looked into it. Of course, things are not simple. First, there is no single place where to put code to execute on leaving a node. This place is needed to add code to remove breadcrumbs from the current node on leaving it because otherwise breadcrumbs in all nodes above the current node will add their lengths to the point's position in the current node. A second problem is that all Info functions assume that point at the cursor corresponds to the file position. Finding all places in Info that use point and recalculating the point's position based on the length of the breadcrumbs is a big task. Basically, this means redesigning of the Info browser. If you think this is simple, then please send a patch that fixes this bug. ;-) > I don't mean to suggest that your efforts are misguided. As I said, > I haven't followed this closely at all, and you guys are both solid > and you know what you're doing. I'd just suggest that you _might_ want > to take a step back and reconsider what the problem and goal are. The goal is to design a new window infrastructure that supports window groups. This is necessary for ECB and also solves many related problems like using multiple header lines and tabbar, etc. Now is the right time to think about new design. This bug was just an incentive to do this. -- Juri Linkov http://www.jurta.org/emacs/ From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 02:32:29 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 07:32:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLXK9-0002nX-0K for submit@debbugs.gnu.org; Fri, 18 Dec 2009 02:32:29 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLWL4-0002Gy-83 for 4147@emacsbugs.donarmstrong.com; Fri, 18 Dec 2009 01:29:22 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.103.cable.starman.ee [82.131.31.103]) by mx1.starman.ee (Postfix) with ESMTP id 0631C3F410B; Thu, 17 Dec 2009 04:07:26 +0200 (EET) From: Juri Linkov To: martin rudalics Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> Date: Thu, 17 Dec 2009 03:30:32 +0200 In-Reply-To: <4B28F6E2.8020000@gmx.at> (martin rudalics's message of "Wed, 16 Dec 2009 16:04:02 +0100") Message-ID: <87my1ibip3.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Debbugs-Envelope-To: 4147 X-Mailman-Approved-At: Fri, 18 Dec 2009 02:32:26 -0500 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org >> This means we need extra buffer per every header-line. > > Yes. However, it's not clear how to combine header lines from different modes for the same buffer (e.g. Info, ruler, and tabbar) - whether to put them on separate lines in one buffer displayed in one header window, or to display them in separate windows and buffers, i.e. one extra buffer/window for every mode - one header buffer/window for the ruler, one for the tabbar, etc. > Windows code can investigate all sorts of window parameters - in the > present case there would be parameters like "nodelete", "noresize", > "nosplit" and "noother" say. I think you design of using window parameters is clean and flexible. -- Juri Linkov http://www.jurta.org/emacs/ From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 02:33:13 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 07:33:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLXKr-0002ok-8H for submit@debbugs.gnu.org; Fri, 18 Dec 2009 02:33:13 -0500 Received: from acsinet14.oracle.com ([141.146.126.236]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLVm9-000229-Ka for 4147@emacsbugs.donarmstrong.com; Fri, 18 Dec 2009 00:53:18 -0500 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by acsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id nBHFSEc9019558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <4147@emacsbugs.donarmstrong.com>; Thu, 17 Dec 2009 15:28:14 GMT Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nBHFS5vI002885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Dec 2009 15:28:06 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nBHD4kC6018326; Thu, 17 Dec 2009 15:28:32 GMT Received: from abhmt005.oracle.com by acsmt357.oracle.com with ESMTP id 1082268591261063600; Thu, 17 Dec 2009 09:26:40 -0600 Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Dec 2009 07:26:39 -0800 From: "Drew Adams" To: "'Juri Linkov'" References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at><877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org><87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org><4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org><4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org><4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org><4B28F6E2.8020000@gmx.at><7997E65B52EF4DDE9E6F8032A6CD2EB7@us.oracle.com> <87tyvq2wa9.fsf@mail.jurta.org> Subject: RE: bug#4147: 23.1.50: Info-search command strange behaviour Date: Thu, 17 Dec 2009 07:26:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tyvq2wa9.fsf@mail.jurta.org> Thread-Index: Acp+vbXyKGFtt+DBRfubVub7uU433QAbyu1w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4B2A4E03.001E:SCFMA4539814,ss=1,fgs=0 X-Debbugs-Envelope-To: 4147 X-Mailman-Approved-At: Fri, 18 Dec 2009 02:33:12 -0500 Cc: 4147@debbugs.gnu.org, 'martin rudalics' X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > The goal is to design a new window infrastructure that supports window > groups. This is necessary for ECB and also solves many > related problems like using multiple header lines and tabbar, etc. > Now is the right time to think about new design. This bug was just > an incentive to do this. Thanks for your explanation. In that case, I'd suggest that emacs-devel is the right place to discuss such redesign. IOW, leave the bug unfixed until the requisite design change allows fixing it, and discuss the design change in the dev mailing list, not just in this bug thread. Just a suggestion. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 02:41:01 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 07:41:01 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLXSP-0002uh-M7 for submit@debbugs.gnu.org; Fri, 18 Dec 2009 02:41:01 -0500 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NLXQN-0002tc-GY for 4147@debbugs.gnu.org; Fri, 18 Dec 2009 02:38:55 -0500 Received: (qmail invoked by alias); 18 Dec 2009 07:38:51 -0000 Received: from 62-47-63-248.adsl.highway.telekom.at (EHLO [62.47.63.248]) [62.47.63.248] by mail.gmx.net (mp070) with SMTP; 18 Dec 2009 08:38:51 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/PXeFvJkPPNVNc0Q08KRJzqWonc+wNE4pHiF7FgC oUsGR/PP6UIPnn Message-ID: <4B2B318A.7010300@gmx.at> Date: Fri, 18 Dec 2009 08:38:50 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> In-Reply-To: <87fx79dwy9.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 X-Debbugs-Envelope-To: 4147 X-Mailman-Approved-At: Fri, 18 Dec 2009 02:41:00 -0500 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > A divider is not necessary when buffers in the header windows are displayed > with the `header-line' face. With this face they will clearly stand out > from the main window. In many cases a divider is not needed. However, with undistinguishable faces it might be good to have one. BTW, how are tabs displayed on text-only terminals? Also, what additional support is needed to display a toolbar in a header window? > Currently I tried to experiment with the header window but immediately was > thrown back by the presence of the modeline. With the modeline this looks > very ugly. Do you know how to remove the modeline from the header window? Does (setq mode-line-format nil) not do that? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 04:19:47 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 09:19:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLYzz-0003wV-QM for submit@debbugs.gnu.org; Fri, 18 Dec 2009 04:19:47 -0500 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NLYzy-0003wQ-IY for 4147@emacsbugs.donarmstrong.com; Fri, 18 Dec 2009 04:19:46 -0500 Received: (qmail invoked by alias); 17 Dec 2009 08:19:42 -0000 Received: from 62-47-51-73.adsl.highway.telekom.at (EHLO [62.47.51.73]) [62.47.51.73] by mail.gmx.net (mp047) with SMTP; 17 Dec 2009 09:19:42 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19cRaJDlVxcpT4vvKQ+oOn1xapjKDY4oVXylGz/xe iBj4EaR4AVOxKa Message-ID: <4B29E99D.9060501@gmx.at> Date: Thu, 17 Dec 2009 09:19:41 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> In-Reply-To: <87my1ibip3.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > However, it's not clear how to combine header lines from different modes > for the same buffer (e.g. Info, ruler, and tabbar) - whether to put them > on separate lines in one buffer displayed in one header window, or to display > them in separate windows and buffers, i.e. one extra buffer/window for every > mode - one header buffer/window for the ruler, one for the tabbar, etc. As a rule of thumb I think we should continue to handle a mode like `ruler-mode' via `header-line-format' because that mode should hardly ever need more than one line and is always tied to a live window. Also as designer of `ruler-mode' I'd probably dislike sharing a window with a mode like tabbar that is not directly related to the current buffer, uses a different design for displaying its objects, a different overlay or text properties approach, ... Tabs should go to a separate header window that would also stay around when the user switches to another buffer in the associated main window. And we could easily attach a tabs window to an internal window like the root window of a frame thus always spanning the entire width of a frame. That is, a tabs window attached to a single live window would list the buffers the user is supposed to switch to in that window. A tabs window attached to a group of windows would list the buffers the user is supposed to switch to in that group. A tabs window attached to the frame root window would list all buffers to switch to in that frame. (IMHO the by far most difficult part of tabbars is to choose a good strategy for which buffers should appear first in a sequence of tabs.) So we should probably try to identify the non-conflicting users of the current header-line-format approach (I suppose Info and ruler-mode are non-conflicting) and decide what to do with the rest. That is, decide whether those want separate windows or share one header window with other modes. As far as Info and the problem at hand are concerned a separate Info header window might be useful. But we should coordinate this with any speedbar window showing the info titles on the left of the main window and must handle cloned Info buffers correctly. The windows handling code would allow to add to/remove from any number of header/footer windows to a single main window. What I currently don't have is a suitable divider - header windows won't have a modeline, I presume. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 09:37:24 2009 Received: (at 4147) by debbugs.gnu.org; 18 Dec 2009 14:37:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLdxL-0007sD-Sg for submit@debbugs.gnu.org; Fri, 18 Dec 2009 09:37:23 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLZQW-0004fB-8H for 4147@debbugs.gnu.org; Fri, 18 Dec 2009 04:47:12 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KUU00L00DP2EK00@a-mtaout22.012.net.il> for 4147@debbugs.gnu.org; Fri, 18 Dec 2009 11:46:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.160.137]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KUU00GAZDU2XOI0@a-mtaout22.012.net.il>; Fri, 18 Dec 2009 11:46:51 +0200 (IST) Date: Fri, 18 Dec 2009 11:49:01 +0200 From: Eli Zaretskii Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour In-reply-to: <87fx79dwy9.fsf@mail.jurta.org> X-012-Sender: halo1@inter.net.il To: Juri Linkov , 4147@debbugs.gnu.org Message-id: <831vis7gtu.fsf@gnu.org> References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> X-Debbugs-Envelope-To: 4147 X-Mailman-Approved-At: Fri, 18 Dec 2009 09:37:23 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > From: Juri Linkov > Date: Fri, 18 Dec 2009 01:34:14 +0200 > Cc: 4147@debbugs.gnu.org > > Currently I tried to experiment with the header window but immediately was > thrown back by the presence of the modeline. With the modeline this looks > very ugly. Do you know how to remove the modeline from the header window? Does it help to set mode-line-format to nil? From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 21:42:28 2009 Received: (at 4147) by debbugs.gnu.org; 19 Dec 2009 02:42:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLpH1-0007Ae-Rc for submit@debbugs.gnu.org; Fri, 18 Dec 2009 21:42:27 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLpH0-0007AU-78 for 4147@debbugs.gnu.org; Fri, 18 Dec 2009 21:42:27 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.96.cable.starman.ee [82.131.31.96]) by mx1.starman.ee (Postfix) with ESMTP id 8CA103F412F for <4147@debbugs.gnu.org>; Sat, 19 Dec 2009 04:42:16 +0200 (EET) From: Juri Linkov To: 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> Date: Sat, 19 Dec 2009 02:45:52 +0200 In-Reply-To: <87fx79dwy9.fsf@mail.jurta.org> (Juri Linkov's message of "Fri, 18 Dec 2009 01:34:14 +0200") Message-ID: <87d42bpv3b.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Debbugs-Envelope-To: 4147 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org --=-=-= [I'm not sure whether all sent mails in this thread already arrived after the transition period, but let's hope that nothing will be lost.] Meanwhile, I wrote a small proof of concept that works surprisingly well. All next/prev/up navigations links work from the "header-line" window without additional efforts thanks to the following existing code in Info-next/Info-prev/Info-up: (or (eq major-mode 'Info-mode) (pop-to-buffer "*info*")) that after clicking on a link in the "header-line" window moves the current focus from the "header-line" window to the window with the Info buffer. (The links are not yet displayed as blue underlined text, but nevertheless work well). The breadcrumbs links don't do this, so they currently don't work. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: inline; filename=test.el Content-Transfer-Encoding: quoted-printable (defun Info-update-header-line-window () (interactive) (let ((win-orig (selected-window)) (win-header-line (get-window-with-predicate (lambda (window) (equal (buffer-name (window-buffer window)) " *Info-header-line*"))))) (if win-header-line (select-window win-header-line) (setq win-orig (split-window-vertically)) (switch-to-buffer (get-buffer-create " *Info-header-line*"))) (erase-buffer) (fit-window-to-buffer nil 2 1) (setq window-size-fixed 'height) (setq mode-line-format nil) (setq cursor-type nil truncate-lines t) (set (make-local-variable 'face-remapping-alist) '((default header-line))) (insert (with-selected-window win-orig (concat (get-text-property (point-min) 'header-line) "\n" (buffer-substring (save-excursion (goto-char (point-min)) (forward-line 1) (point)) (save-excursion (goto-char (point-min)) (forward-line 2) (point)))))) (goto-char (point-min)) (select-window win-orig))) (defadvice Info-fontify-node (around my-Info-fontify-node act) ad-do-it (Info-update-header-line-window)) --=-=-= -- Juri Linkov http://www.jurta.org/emacs/ --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 21:42:28 2009 Received: (at 4147) by debbugs.gnu.org; 19 Dec 2009 02:42:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLpH2-0007Ag-1R for submit@debbugs.gnu.org; Fri, 18 Dec 2009 21:42:28 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLpH0-0007AV-8B for 4147@debbugs.gnu.org; Fri, 18 Dec 2009 21:42:27 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.96.cable.starman.ee [82.131.31.96]) by mx1.starman.ee (Postfix) with ESMTP id 4CA3F3F4143; Sat, 19 Dec 2009 04:42:17 +0200 (EET) From: Juri Linkov To: martin rudalics Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <4B2B318A.7010300@gmx.at> Date: Sat, 19 Dec 2009 02:30:01 +0200 In-Reply-To: <4B2B318A.7010300@gmx.at> (martin rudalics's message of "Fri, 18 Dec 2009 08:38:50 +0100") Message-ID: <873a37ofva.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > In many cases a divider is not needed. However, with undistinguishable > faces it might be good to have one. In this case we could display Ersatz divider, e.g. the bottom line of the upper window fontified with a different face. > BTW, how are tabs displayed on text-only terminals? They are correctly displayed as text lines. > Also, what additional support is needed to display a toolbar in > a header window? Using the same design, a toolbar could be displayed in a separate window above the header window. -- Juri Linkov http://www.jurta.org/emacs/ From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 19 04:09:30 2009 Received: (at 4147) by debbugs.gnu.org; 19 Dec 2009 09:09:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLvJa-0001BJ-1n for submit@debbugs.gnu.org; Sat, 19 Dec 2009 04:09:30 -0500 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NLvJX-0001BE-Jt for 4147@debbugs.gnu.org; Sat, 19 Dec 2009 04:09:28 -0500 Received: (qmail invoked by alias); 19 Dec 2009 09:09:23 -0000 Received: from 62-47-42-2.adsl.highway.telekom.at (EHLO [62.47.42.2]) [62.47.42.2] by mail.gmx.net (mp070) with SMTP; 19 Dec 2009 10:09:23 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18UkjRzPgMUZpM6Xn3X9Jtu0j9M18u9DOlyhoE9gy ScpDwT0uD63CdO Message-ID: <4B2C9842.5050505@gmx.at> Date: Sat, 19 Dec 2009 10:09:22 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <4B2B318A.7010300@gmx.at> <873a37ofva.fsf@mail.jurta.org> In-Reply-To: <873a37ofva.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > In this case we could display Ersatz divider, e.g. the bottom line > of the upper window fontified with a different face. Anyway it would be nice to have horizontal dividers by default so an application could suppress displaying the mode-line more easily. >> BTW, how are tabs displayed on text-only terminals? > > They are correctly displayed as text lines. And how would we do the Ersatz divider stuff there? > Using the same design, a toolbar could be displayed in a separate window > above the header window. I never looked at the toolbar code. Is there anything that mandates the existence of one single toolbar on an Emacs frame? Especially for Info buffers it would be nice to have a toolbar window right above the Info window. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 19 04:09:38 2009 Received: (at 4147) by debbugs.gnu.org; 19 Dec 2009 09:09:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLvJi-0001BW-Bm for submit@debbugs.gnu.org; Sat, 19 Dec 2009 04:09:38 -0500 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NLvJg-0001BP-9E for 4147@debbugs.gnu.org; Sat, 19 Dec 2009 04:09:36 -0500 Received: (qmail invoked by alias); 19 Dec 2009 09:09:32 -0000 Received: from 62-47-42-2.adsl.highway.telekom.at (EHLO [62.47.42.2]) [62.47.42.2] by mail.gmx.net (mp013) with SMTP; 19 Dec 2009 10:09:32 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19/csNym6V/6s98KkQ5HRhjZM5et/si3B4tXhaUFp ZJGaPQObE/1CII Message-ID: <4B2C984B.3000703@gmx.at> Date: Sat, 19 Dec 2009 10:09:31 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov , 4147@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <87d42bpv3b.fsf@mail.jurta.org> In-Reply-To: <87d42bpv3b.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 X-Debbugs-Envelope-To: 4147 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > All next/prev/up navigations links work from the "header-line" window > without additional efforts thanks to the following existing code in > Info-next/Info-prev/Info-up: > > (or (eq major-mode 'Info-mode) (pop-to-buffer "*info*")) Would this work with cloned Info buffers? In any case `pop-to-buffer' is way too fragile to be generally useful. > that after clicking on a link in the "header-line" window moves the > current focus from the "header-line" window to the window with the > Info buffer. (The links are not yet displayed as blue underlined text, > but nevertheless work well). The code should suppress displaying scrollbars in header-windows. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 20 20:01:00 2009 Received: (at 4147) by debbugs.gnu.org; 21 Dec 2009 01:01:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMWdv-0001Vx-VW for submit@debbugs.gnu.org; Sun, 20 Dec 2009 20:01:00 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMWds-0001Vm-Te for 4147@debbugs.gnu.org; Sun, 20 Dec 2009 20:00:57 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.149.cable.starman.ee [82.131.31.149]) by mx1.starman.ee (Postfix) with ESMTP id 3FA473F40BA; Mon, 21 Dec 2009 03:00:46 +0200 (EET) From: Juri Linkov To: martin rudalics Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <4B2B318A.7010300@gmx.at> <873a37ofva.fsf@mail.jurta.org> <4B2C9842.5050505@gmx.at> Date: Mon, 21 Dec 2009 02:34:38 +0200 In-Reply-To: <4B2C9842.5050505@gmx.at> (martin rudalics's message of "Sat, 19 Dec 2009 10:09:22 +0100") Message-ID: <878wcxp349.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org >> In this case we could display Ersatz divider, e.g. the bottom line >> of the upper window fontified with a different face. > > Anyway it would be nice to have horizontal dividers by default so an > application could suppress displaying the mode-line more easily. > >>> BTW, how are tabs displayed on text-only terminals? >> >> They are correctly displayed as text lines. > > And how would we do the Ersatz divider stuff there? For example, with the `inverse-video' face attribute, like we do for the `mode-line' face. >> Using the same design, a toolbar could be displayed in a separate >> window above the header window. > > I never looked at the toolbar code. Is there anything that mandates > the existence of one single toolbar on an Emacs frame? The toolbar is represented by a propertized string created by `build_desired_tool_bar_string'. It is only the frame parameter `tool_bar_window' that mandates one toolbar per frame. > Especially for Info buffers it would be nice to have a toolbar window > right above the Info window. It could be created by the same means as the header-line window. -- Juri Linkov http://www.jurta.org/emacs/ From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 20 20:01:00 2009 Received: (at 4147) by debbugs.gnu.org; 21 Dec 2009 01:01:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMWdw-0001Vz-7h for submit@debbugs.gnu.org; Sun, 20 Dec 2009 20:01:00 -0500 Received: from smtp-out3.starman.ee ([85.253.0.5] helo=mx1.starman.ee) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMWds-0001Vn-Td for 4147@debbugs.gnu.org; Sun, 20 Dec 2009 20:00:57 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.31.149.cable.starman.ee [82.131.31.149]) by mx1.starman.ee (Postfix) with ESMTP id A6AAE3F40C1; Mon, 21 Dec 2009 03:00:46 +0200 (EET) From: Juri Linkov To: martin rudalics Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour Organization: JURTA References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <87d42bpv3b.fsf@mail.jurta.org> <4B2C984B.3000703@gmx.at> Date: Mon, 21 Dec 2009 02:36:59 +0200 In-Reply-To: <4B2C984B.3000703@gmx.at> (martin rudalics's message of "Sat, 19 Dec 2009 10:09:31 +0100") Message-ID: <87tyvlm9bp.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org >> All next/prev/up navigations links work from the "header-line" window >> without additional efforts thanks to the following existing code in >> Info-next/Info-prev/Info-up: >> >> (or (eq major-mode 'Info-mode) (pop-to-buffer "*info*")) > > Would this work with cloned Info buffers? In any case `pop-to-buffer' > is way too fragile to be generally useful. Actually, it works with cloned Info buffers as well due to some magic of defining a key binding like (define-key keymap [header-line mouse-1] 'Info-next) where `header-line' defines that a mouse click operates on the original window instead of the header-line window where a link was clicked. >> that after clicking on a link in the "header-line" window moves the >> current focus from the "header-line" window to the window with the >> Info buffer. (The links are not yet displayed as blue underlined text, >> but nevertheless work well). > > The code should suppress displaying scrollbars in header-windows. Do you know how to suppress scrollbars on a per window/buffer basis? -- Juri Linkov http://www.jurta.org/emacs/ From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 21 03:22:07 2009 Received: (at 4147) by debbugs.gnu.org; 21 Dec 2009 08:22:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMdWp-00053D-55 for submit@debbugs.gnu.org; Mon, 21 Dec 2009 03:22:07 -0500 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NMdWa-00052q-Ix for 4147@debbugs.gnu.org; Mon, 21 Dec 2009 03:22:05 -0500 Received: (qmail invoked by alias); 21 Dec 2009 08:21:47 -0000 Received: from 62-47-45-114.adsl.highway.telekom.at (EHLO [62.47.45.114]) [62.47.45.114] by mail.gmx.net (mp044) with SMTP; 21 Dec 2009 09:21:47 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/j9xA69v7jc5kItdmRU/KyC1L2VrDE9TYtT1ZvMS ASizmpLc9YPoCa Message-ID: <4B2F301A.8010208@gmx.at> Date: Mon, 21 Dec 2009 09:21:46 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <4B2B318A.7010300@gmx.at> <873a37ofva.fsf@mail.jurta.org> <4B2C9842.5050505@gmx.at> <878wcxp349.fsf@mail.jurta.org> In-Reply-To: <878wcxp349.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > The toolbar is represented by a propertized string created by > `build_desired_tool_bar_string'. It is only the frame parameter > `tool_bar_window' that mandates one toolbar per frame. The one toolbar per frame concept is built into most toolbar handling routines like note_tool_bar_highlight and some "if drawing a tool-bar window, draw it over the internal border at the top of the window" stuff I don't understand completely yet. All these look fairly trivial though at first glance. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 21 03:22:11 2009 Received: (at 4147) by debbugs.gnu.org; 21 Dec 2009 08:22:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMdWt-00053N-BX for submit@debbugs.gnu.org; Mon, 21 Dec 2009 03:22:11 -0500 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NMdWg-00052r-Az for 4147@debbugs.gnu.org; Mon, 21 Dec 2009 03:22:10 -0500 Received: (qmail invoked by alias); 21 Dec 2009 08:21:54 -0000 Received: from 62-47-45-114.adsl.highway.telekom.at (EHLO [62.47.45.114]) [62.47.45.114] by mail.gmx.net (mp060) with SMTP; 21 Dec 2009 09:21:54 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19Uv+oA6SdU954BMIsf/MmbnF6Ya/PZd+eesJXo1C tEtKJcS8NxIlVf Message-ID: <4B2F3021.4060405@gmx.at> Date: Mon, 21 Dec 2009 09:21:53 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> <4B28F6E2.8020000@gmx.at> <87my1ibip3.fsf@mail.jurta.org> <4B29E99D.9060501@gmx.at> <87fx79dwy9.fsf@mail.jurta.org> <87d42bpv3b.fsf@mail.jurta.org> <4B2C984B.3000703@gmx.at> <87tyvlm9bp.fsf@mail.jurta.org> In-Reply-To: <87tyvlm9bp.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 X-Debbugs-Envelope-To: 4147 Cc: 4147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org > Do you know how to suppress scrollbars on a per window/buffer basis? Good question: For a particular window use (set-window-scroll-bars window 0) see Elisp manual section 38.14 "Scroll Bars". The same section also says that it's possible to control scrollbars for indiviudal buffers by setting `scroll-bar-mode' but I don't see how. So you have to use something like (setq vertical-scroll-bar nil) which takes effect only after a buffer gets displayed the next time. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 23:42:06 2011 Received: (at 4147-done) by debbugs.gnu.org; 6 Oct 2011 03:42:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBeqU-0004IX-0i for submit@debbugs.gnu.org; Wed, 05 Oct 2011 23:42:06 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBeqR-0004IQ-2P for 4147-done@debbugs.gnu.org; Wed, 05 Oct 2011 23:42:04 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RBeqK-0007mC-Bw; Wed, 05 Oct 2011 23:41:56 -0400 From: Glenn Morris To: 4147-done@debbugs.gnu.org Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour References: <20090815034957.GA30902@shareable.org> X-Spook: War on Terrorism fundamentalist ARPA industrial X-Ran: YWJKa:utAzP~=kC<6G(^2a]Lf;^P'#mF3d_%;y=wm (Jamie Lokier's message of "Sat, 15 Aug 2009 04:49:57 +0100") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 4147-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) Version: 23.2 Jamie Lokier wrote: > Start Emacs with no customisation: > emacs -nw -Q > > Invoke Info, go to the directory: > C-h i > > Search: > s blahblah RET > => Says it can't find it, and point does not move. > > Go to the Emacs manual: > m Emacs (emacs-snapshot) RET > > Search: > s blahblah RET > => Says it can't find it, but moves point forward a few characters. I see this in 23.1 but not 23.2, so it looks like this was fixed. From unknown Sun Jun 22 11:32:17 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 03 Nov 2011 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator