emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Virtual Info files and nodes


From: Stefan Monnier
Subject: Re: Virtual Info files and nodes
Date: Wed, 01 Jul 2009 17:02:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)

> 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.

If you could explain that somewhere in a comment in info.el, that would
be swell.  I have always found info.el's code a bit delicate to modify
because of these special cases with special meanings which are difficult
to predict.

>> 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.

I know, but for a static file, the affected code was more confined.

> 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))

Yes, that's exactly what I was alluding to.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]