From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Virtual Info files and nodes Date: Wed, 01 Jul 2009 03:01:02 +0300 Organization: JURTA Message-ID: <871vp1uufd.fsf@mail.jurta.org> References: <87ws6wnj3s.fsf@mail.jurta.org> <87prcnhn4i.fsf@mail.jurta.org> <87zlbq389k.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246409408 27552 80.91.229.12 (1 Jul 2009 00:50:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jul 2009 00:50:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 01 02:50:02 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MLo1Q-00080T-OH for ged-emacs-devel@m.gmane.org; Wed, 01 Jul 2009 02:50:01 +0200 Original-Received: from localhost ([127.0.0.1]:50903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLo1Q-0001mr-3t for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2009 20:50:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLo0P-0000ZE-2x for emacs-devel@gnu.org; Tue, 30 Jun 2009 20:48:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLo0J-0000Sm-RR for emacs-devel@gnu.org; Tue, 30 Jun 2009 20:48:56 -0400 Original-Received: from [199.232.76.173] (port=47452 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLo0J-0000SN-M7 for emacs-devel@gnu.org; Tue, 30 Jun 2009 20:48:51 -0400 Original-Received: from smtp-out3.starman.ee ([85.253.0.5]:37149 helo=smtp-gw1.starman.ee) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLo0J-0002MR-2d for emacs-devel@gnu.org; Tue, 30 Jun 2009 20:48:51 -0400 Original-Received: from mx2.starman.ee (mx2.starman.ee [62.65.192.17]) by smtp-gw1.starman.ee (Postfix) with ESMTP id 4C9D727C83; Wed, 1 Jul 2009 03:48:47 +0300 (EEST) X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Original-Received: from mail.starman.ee (82.131.29.94.cable.starman.ee [82.131.29.94]) by mx2.starman.ee (Postfix) with ESMTP id 17DB33F404A; Wed, 1 Jul 2009 03:48:41 +0300 (EEST) In-Reply-To: (Stefan Monnier's message of "Tue, 30 Jun 2009 22:13:49 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111844 Archived-At: >>>>> - Why check (stringp filename) in Info-virtual-file? Isn't it an >>>>> error to call it with something else than a string. >>>> Really only nil can be expected now, >>> Can it? In which circumstance? >> `filename' can be nil when `Info-virtual-fun' is called with non-nil >> `nodename' > > That part is obvious enough. > >> to check for a node name when a file name is irrelevant - >> its argument value is nil in this case. > > But again: is that ever the case? > I'd think a node name can only be meaningful when accompagnied by a filename. There are valid calls with filename=nil where nil means the current Info file: in Info-find-node-2 filename=nil means to not re-read the current Info file, other places rely on the value nil returned from Info-find-file when its argument filename is nil since this function checks for (stringp filename). So the same check should be also in Info-virtual-fun because a call to Info-virtual-fun is outside of branches that check for a non-string filename in Info-find-file and Info-find-node-2. >> This is done in the next version below with other fixes including the >> handling of "dir": > > Thanks, looks fairly good now. I just worry a little bit about binding > inhibit-read-only around the call to (Info-virtual-call virtual-fun > filename nodename no-going-back) since that may involve a lot of code > that accesses other buffers. Maybe (setq buffer-read-only nil) would be > a better choice here. This code was a copy from a branch that reads a static Info file. But this could be different like: (let ((filename (or filename Info-current-file))) (setq buffer-file-name nil) (setq buffer-read-only nil) (erase-buffer) (setq Info-current-file filename) (Info-virtual-call virtual-fun filename nodename no-going-back) (set-marker Info-tag-table-marker nil) (setq buffer-read-only t) (set-buffer-modified-p nil) (set (make-local-variable 'Info-current-node-virtual) t)) -- Juri Linkov http://www.jurta.org/emacs/