gnus-url-mailto broken on foo+bar@somewhere.invalid

gnus-url-mailto broken on foo+bar@somewhere.invalid

[Reiner Steib]

Hi,

mailto links like `mailto:foo+bar@somewhere.invalid' aren't handled
correctly by `gnus-url-mailto'.  `gnus-url-mailto' calls
`gnus-url-unhex-string' and the first line in this function translates
"+" to " ":

ELISP> (gnus-url-unhex-string "foo+bar@somewhere.invalid")
"foo bar@somewhere.invalid"
ELISP> (mm-subst-char-in-string ?+ ?  "foo+bar@somewhere.invalid")
"foo bar@somewhere.invalid"

What is the best fix for this?  Adding an additional optional
argument[1], say "allow-plus" to `gnus-url-unhex-string' and call
(gnus-url-unhex-string url nil t) in `gnus-url-mailto'?

Bye, Reiner.

[1]
- (defun gnus-url-unhex-string (str &optional allow-newlines)
+ (defun gnus-url-unhex-string (str &optional allow-newlines allow-plus)
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Karl Pflästerer]

On 26 Aug 2003, Reiner Steib <- 4.uce.03.r.s@nurfuerspam.de wrote:

> What is the best fix for this?  Adding an additional optional
> argument[1], say "allow-plus" to `gnus-url-unhex-string' and call
> (gnus-url-unhex-string url nil t) in `gnus-url-mailto'?

I'm not sure.  At first sight it looks ugly.  I looked at the function
(here is part of the code):

    ;; Fixme: Do it like QP.
    (defun gnus-url-unhex-string (str &optional allow-newlines)
      "Remove %XX, embedded spaces, etc in a url.
    If optional second argument ALLOW-NEWLINES is non-nil, then allow the
    decoding of carriage returns and line feeds in the string, which is normally
    forbidden in URL encoding."
      (setq str (or (mm-subst-char-in-string ?+ ?  str) "")) ; why `or'?

Two questions?
(a) What's meant with the comment?
(b) What is the substitution good for?


   KP

-- 
   Mary had a little lambda,
   Its syntax white as snow,
   And every program Mary wrote,
   She wrote in Lisp, you know.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> mailto links like `mailto:foo+bar@somewhere.invalid' aren't handled
> correctly by `gnus-url-mailto'.  `gnus-url-mailto' calls
> `gnus-url-unhex-string' and the first line in this function
> translates "+" to " ":

I'm wondering if the "+" -> " " substitution is bogus not just for
mailto: but for all URI types.  I can't find anything in RFC 2396
stating that this substitution should be performed.

I guess that code should just be removed from `gnus-url-unhex-string'.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Benjamin Riefenstahl]

Hi Jesper,

Jesper Harder <harder@myrealbox.com> writes:
> I'm wondering if the "+" -> " " substitution is bogus not just for
> mailto: but for all URI types.  I can't find anything in RFC 2396
> stating that this substitution should be performed.
>
> I guess that code should just be removed from
> `gnus-url-unhex-string'.

It is in the HTML spec, see <http://www.w3.org/TR/html401/interact/
forms.html> and in RFC 1630 (which is only informational).
Both indicate that the "+" substitution only applies to the query part
of an http:// URL.

benny

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Reiner Steib]

On Tue, Aug 26 2003, Karl Pflästerer wrote:

>     ;; Fixme: Do it like QP.
>     (defun gnus-url-unhex-string (str &optional allow-newlines)
>       "Remove %XX, embedded spaces, etc in a url.
>     If optional second argument ALLOW-NEWLINES is non-nil, then allow the
>     decoding of carriage returns and line feeds in the string, which is normally
>     forbidden in URL encoding."

JFTR: Beside in `gnus-url-mailto' and in `gnus-url-parse-query-string'
(that is only used in `gnus-url-mailto'), `gnus-url-unhex-string' is
only used for info and customize URLs.  It's never used for http URLs.
Ah, there's one occurance in `nnwfm.el'[2], which is not mentioned in
the manual.

>       (setq str (or (mm-subst-char-in-string ?+ ?  str) "")) ; why `or'?
>
> Two questions?
> (a) What's meant with the comment?

ShengHuo[1] changed the line like this:

-  (setq str (or str ""))
+  (setq str (or (mm-subst-char-in-string ?+ ?  str) ""))

Wild guess: No error if `str' is nil?  The comment was added later; I
couldn't find a ChangeLog entry for it.

> (b) What is the substitution good for?

The reason AFAICS are info URLs like <info://gnus/Starting+Up>.  It
has been introduced along with this ChangeLog entry (see patch
below[1]):

,----[ 1 ]
| 2001-08-17 22:00:00  ShengHuo ZHU  <zsh@cs.rochester.edu>
| 
| 	* gnus.el (gnus-info-find-node): Take an argument.
| 
| 	* gnus-art.el (gnus-button-handle-info): New function.
| 	(gnus-url-unhex-string): Replace "+" with " ".
`----

Bye, Reiner.

[1]
--8<---------------cut here---------------start------------->8---
--- gnus-art.el.~6.103~	Tue Aug 26 21:12:16 2003
+++ gnus-art.el.~6.104~	Tue Aug 26 21:07:59 2003
@@ -4697,7 +4697,7 @@
 
 ;;; Internal Variables:
 
-(defcustom gnus-button-url-regexp "[...]mailto\\):[...]"
+(defcustom gnus-button-url-regexp "[...]mailto\\|info\\):[...]"
   "Regular expression that matches URLs."
   :group 'gnus-article-buttons
   :type 'regexp)
@@ -4716,6 +4716,9 @@
     ("\\(<URL: *\\)mailto: *\\([^> \n\t]+\\)>" 0 t gnus-url-mailto 2)
     ("mailto:\\([-a-zA-Z.@_+0-9%=?]+\\)" 0 t gnus-url-mailto 1)
     ("\\bmailto:\\([^ \n\t]+\\)" 0 t gnus-url-mailto 1)
+    ;; This is info
+    ("\\binfo:\\(//\\)?\\([^'\">\n\t ]+\\)" 0 t
+     gnus-button-handle-info 2)
     ;; This is how URLs _should_ be embedded in text...
     ("<URL: *\\([^<>]*\\)>" 0 t gnus-button-embedded-url 1)
     ;; Raw URLs.
@@ -5086,6 +5089,18 @@
      (group
       (gnus-button-fetch-group url)))))
 
+(defun gnus-button-handle-info (url)
+  "Fetch an info URL."
+  (if (string-match 
+       "^\\([^:/]+\\)?/\\(.*\\)"
+       url)
+      (gnus-info-find-node
+       (concat "(" (or (gnus-url-unhex-string (match-string 1 url))
+		       "Gnus") 
+	       ")" 
+	       (gnus-url-unhex-string (match-string 2 url))))
+    (error "Can't parse %s" url)))
+
 (defun gnus-button-message-id (message-id)
   "Fetch MESSAGE-ID."
   (save-excursion
@@ -5142,7 +5157,7 @@
 If optional second argument ALLOW-NEWLINES is non-nil, then allow the
 decoding of carriage returns and line feeds in the string, which is normally
 forbidden in URL encoding."
-  (setq str (or str ""))
+  (setq str (or (mm-subst-char-in-string ?+ ?  str) ""))
   (let ((tmp "")
 	(case-fold-search t))
     (while (string-match "%[0-9a-f][0-9a-f]" str)
--8<---------------cut here---------------end--------------->8---

[2] ;;; nnwfm.el --- interfacing with a web forum
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Reiner Steib]

On Wed, Aug 27 2003, Benjamin Riefenstahl wrote:

> Jesper Harder <harder@myrealbox.com> writes:
>> I'm wondering if the "+" -> " " substitution is bogus not just for
>> mailto: but for all URI types.  I can't find anything in RFC 2396
>> stating that this substitution should be performed.

For mailto it's not useful, AFAICS.  See also my reply to Karl
(<news:v9brub5j6z.fsf@marauder.physik.uni-ulm.de>).

>> I guess that code should just be removed from
>> `gnus-url-unhex-string'.

This would break info links like <info://gnus/Starting+Up>.

> It is in the HTML spec, see <http://www.w3.org/TR/html401/interact/
> forms.html> and in RFC 1630 (which is only informational).
> Both indicate that the "+" substitution only applies to the query part
> of an http:// URL.

In Gnus, `gnus-url-unhex-string' is not used for http URLs, so we
don't need to care about this yet.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Karl Pflästerer]

On 27 Aug 2003, Reiner Steib <- 4.uce.03.r.s@nurfuerspam.de wrote:

> On Tue, Aug 26 2003, Karl Pflästerer wrote:

>>     ;; Fixme: Do it like QP.
>>     (defun gnus-url-unhex-string (str &optional allow-newlines)
>>       "Remove %XX, embedded spaces, etc in a url.
>>     If optional second argument ALLOW-NEWLINES is non-nil, then allow the
>>     decoding of carriage returns and line feeds in the string, which is
>>     normally forbidden in URL encoding."

[...]
>> Two questions?
>> (a) What's meant with the comment?

> ShengHuo[1] changed the line like this:

> -  (setq str (or str ""))
> +  (setq str (or (mm-subst-char-in-string ?+ ?  str) ""))

> Wild guess: No error if `str' is nil?  The comment was added later; I
> couldn't find a ChangeLog entry for it.

Sorry I was not clear enough.  I meant the first comment `Fixme ..'.
What's meant here?  If we change something maybe we could do it right
and follow the hint of that comment (as dark as it may be at the
moment).

>> (b) What is the substitution good for?

> The reason AFAICS are info URLs like <info://gnus/Starting+Up>.  It
> has been introduced along with this ChangeLog entry (see patch
> below[1]):

If that would be the only reason it should be easy to solve as it's
(X)Emacs internal.  
But according to <m3d6erjpi3.fsf@seneca.benny.turtle-trading.net> there
may be other reasons.  Can someone shed some light on this?

   KP

-- 
Männer der Wissenschaft! Man sagt ihr viele nach, 
aber die meisten mit Unrecht.  
                             Karl Kraus 'Aphorismen'

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

>> Jesper Harder <harder@myrealbox.com> writes:
>
>>> I'm wondering if the "+" -> " " substitution is bogus not just for
>>> mailto: but for all URI types.  I can't find anything in RFC 2396
>>> stating that this substitution should be performed.
>
> For mailto it's not useful, AFAICS.  See also my reply to Karl
>
>>> I guess that code should just be removed from
>>> `gnus-url-unhex-string'.
>
> This would break info links like <info://gnus/Starting+Up>.

Yes, but that notation is our own invention, I think.

Instead of introducing yet another syntax for info URL's, wouldn't it
be nicer to support the two (incompatible, *sigh* [1]) forms that are
already used elsewhere -- from url(7)

   info - Info page documentation
       info:virtual-filename
       info:virtual-filename#nodename
       info:(virtual-filename)
       info:(virtual-filename)nodename

       This scheme refers to online info reference pages (generated
       from texinfo files), a documentation format used by programs
       such as the GNU tools.  This URI scheme is unique to Unix-like
       systems (such as Linux) and is not currently registered by the
       IETF.  As of this writing, GNOME and KDE differ in their URI
       syntax and do not accept the other's syntax.  The first two
       formats are the GNOME format; in nodenames all spaces are
       written as underscores.  The second two formats are the KDE
       format; spaces in nodenames must be written as spaces, even
       though this is forbidden by the URI standards.  It's hoped that
       in the future most tools will understand all of these formats
       and will always accept underscores for spaces in nodenames.  In
       both GNOME and KDE, if the form without the nodename is used
       the nodename is assumed to be "Top".  Examples of the GNOME
       format are <info:gcc> and <info:gcc#G++_and_GCC>.  Examples of
       the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>.


[1] Someone should write an infomational RFC about the info: scheme.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Kai Großjohann]

Jesper Harder <harder@myrealbox.com> writes:

> Instead of introducing yet another syntax for info URL's, wouldn't it
> be nicer to support the two (incompatible, *sigh* [1]) forms that are
> already used elsewhere -- from url(7)
>
>    info - Info page documentation
>        info:virtual-filename
>        info:virtual-filename#nodename
>        info:(virtual-filename)
>        info:(virtual-filename)nodename

What's incompatible about them?  If a file name happens to start with
"(", you're in trouble, but I think most info file names don't.

It should be easy to grok both variants.
-- 
Two cafe au lait please, but without milk.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> Instead of introducing yet another syntax for info URL's, wouldn't it
>> be nicer to support the two (incompatible, *sigh* [1]) forms that are
>> already used elsewhere -- from url(7)
>>
>>    info - Info page documentation
>>        info:virtual-filename
>>        info:virtual-filename#nodename
>>        info:(virtual-filename)
>>        info:(virtual-filename)nodename
>
> What's incompatible about them?

No, you're right.  They aren't incompatible, just different.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Wed, Aug 27 2003, Benjamin Riefenstahl wrote:
>
>> Jesper Harder <harder@myrealbox.com> writes:
>>> I'm wondering if the "+" -> " " substitution is bogus not just for
>>> mailto: but for all URI types.  I can't find anything in RFC 2396
>>> stating that this substitution should be performed.
>
> For mailto it's not useful, AFAICS.
>
>>> I guess that code should just be removed from
>>> `gnus-url-unhex-string'.
>
> This would break info links like <info://gnus/Starting+Up>.

OK, I removed + -> " " from `gnus-url-unhex-string' and put it in
`gnus-button-handle-info-url' instead.

There's now also support for GNOME and KDE style Info URLs.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Reiner Steib]

On Thu, Sep 04 2003, Jesper Harder wrote:

> OK, I removed + -> " " from `gnus-url-unhex-string' and put it in
> `gnus-button-handle-info-url' instead.

Thanks.

> There's now also support for GNOME and KDE style Info URLs.

Another idea: For GNOME and KDE users it might be nice to have
`gnus-button-info-handler' (similar to `gnus-button-man-handler' and
`browse-url-browser-function') ...

  :type '(choice (function-item :tag "Emacs" ...)
		 (function-item :tag "GNOME" ...)
		 (function-item :tag "KDE" ...)
		 (function :tag "Other"))

...  and use this in `gnus-info-find-node'.

Maybe someone is interested in implementing it.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Another idea: For GNOME and KDE users it might be nice to have
> `gnus-button-info-handler' (similar to `gnus-button-man-handler' and
> `browse-url-browser-function') ...

Yeah, although I can't imagine why anyone using Emacs would want to
use the GNOME or KDE offerings -- they are pretty awful compared with
Emacs Info.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Simon Josefsson]

Jesper Harder <harder@myrealbox.com> writes:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> Another idea: For GNOME and KDE users it might be nice to have
>> `gnus-button-info-handler' (similar to `gnus-button-man-handler' and
>> `browse-url-browser-function') ...
>
> Yeah, although I can't imagine why anyone using Emacs would want to
> use the GNOME or KDE offerings -- they are pretty awful compared with
> Emacs Info.

I actually use them sometime, because they have a reload button, which
is handy if you are writing documentation.  C-h i C-x k RET C-u C-h i
/file/to/manual RET and then finding the spot you are working on is
harder then clicking on reload.

Hm.  Perhaps info has this feature too, but I haven't found it and I
looked for 'reload', 'reread' etc.  But I'd bet that if there is a key
binding, I will learn it soon, thanks to this list. :)

Reloading info files (was: gnus-url-mailto broken on foo+bar@somewhere.invalid)

[Reiner Steib]

On Thu, Sep 04 2003, Simon Josefsson wrote:

> Jesper Harder <harder@myrealbox.com> writes:
>> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
[...]
>> Yeah, although I can't imagine why anyone using Emacs would want to
>> use the GNOME or KDE offerings -- they are pretty awful compared with
>> Emacs Info.

I even don't know why anyone uses GNOME or KDE. ;-)

> I actually use them sometime, because they have a reload button, which
> is handy if you are writing documentation.  C-h i C-x k RET C-u C-h i
> /file/to/manual RET and then finding the spot you are working on is
> harder then clicking on reload.
>
> Hm.  Perhaps info has this feature too, but I haven't found it and I
> looked for 'reload', 'reread' etc.  But I'd bet that if there is a key
> binding, I will learn it soon, thanks to this list. :)

I couldn't find anything like this the last time I tried.  What about
the following:

(defun rs-info-reload ()
  "Reload current info node."
  (interactive)
  (let ((file Info-current-file)
	(node Info-current-node)
	(point (point)))
    (kill-buffer "*info*")
    (Info-find-node file node)
    (goto-char point)))
(define-key Info-mode-map [(control c) (r)] 'rs-info-reload)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> I actually use them sometime, because they have a reload button, which
> is handy if you are writing documentation.  C-h i C-x k RET C-u C-h i
> /file/to/manual RET and then finding the spot you are working on is
> harder then clicking on reload.
>
> Hm.  Perhaps info has this feature too, but I haven't found it and I
> looked for 'reload', 'reread' etc.  But I'd bet that if there is a key
> binding, I will learn it soon, thanks to this list. :)

`C-c RET C-b' (`makeinfo-buffer') is really nifty.  It runs makeinfo,
opens the resulting info file, and jumps to the node where point was
in the texinfo file.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Frank Schmitt]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> mailto links like `mailto:foo+bar@somewhere.invalid' aren't handled
> correctly by `gnus-url-mailto'.  `gnus-url-mailto' calls
> `gnus-url-unhex-string' and the first line in this function translates
> "+" to " ":

There's an other case where gnus-url-mailto fails: It doesn't decode
encoded "html-characters" and 8bit characters encoded with the
&...;-sgml-syntax like in
"mailto:Paul%20Kr&auml;mer%20&lt;foo@schlurps.de&gt;"

On Emacs 21 this is quite easy to fix: There's 

(defun iso-sgml2iso (from to &optional buffer)
 "Translate SGML entities in the region to ISO 8859-1 characters.
The entities used are from \"ISO 8879:1986//ENTITIES Added Latin 1//EN\".
Optional arg BUFFER is ignored (for use in `format-alist')."

Happily waiting for us. However this does only convert sgml-Umlauts to
iso-chararacters, it doesn't handle the html special-characters, we'd
have to either change the function before using it, or handle

 < <=> &lt;
 > <=> &gt;
 & <=> &amp;
 " <=> &quot;

specially.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Simon Josefsson]

Jesper Harder <harder@myrealbox.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I actually use them sometime, because they have a reload button, which
>> is handy if you are writing documentation.  C-h i C-x k RET C-u C-h i
>> /file/to/manual RET and then finding the spot you are working on is
>> harder then clicking on reload.
>>
>> Hm.  Perhaps info has this feature too, but I haven't found it and I
>> looked for 'reload', 'reread' etc.  But I'd bet that if there is a key
>> binding, I will learn it soon, thanks to this list. :)
>
> `C-c RET C-b' (`makeinfo-buffer') is really nifty.  It runs makeinfo,
> opens the resulting info file, and jumps to the node where point was
> in the texinfo file.

Ah, that looks useful, thanks!  Thanks also to Reiner.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Jesper Harder]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> There's an other case where gnus-url-mailto fails: It doesn't decode
> encoded "html-characters" and 8bit characters encoded with the
> &...;-sgml-syntax like in
> "mailto:Paul%20Kr&auml;mer%20&lt;foo@schlurps.de&gt;"

Do you mean in plain text or HTML email?

In plain text SGML entities have no special meaning, so the above is
just an invalid URL.  For HTML this is something the HTML renderer
(w3, w3m etc.)  should translate.

Re: gnus-url-mailto broken on foo+bar@somewhere.invalid

[Frank Schmitt]

Jesper Harder <harder@myrealbox.com> writes:

> Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:
>
>> There's an other case where gnus-url-mailto fails: It doesn't decode
>> encoded "html-characters" and 8bit characters encoded with the
>> &...;-sgml-syntax like in
>> "mailto:Paul%20Kr&auml;mer%20&lt;foo@schlurps.de&gt;"
>
> Do you mean in plain text or HTML email?
>
> In plain text SGML entities have no special meaning, so the above is
> just an invalid URL.  For HTML this is something the HTML renderer
> (w3, w3m etc.)  should translate.

Upps, forget it. I thought webbrowsers liko Opera and Firebird wouldn't decode
the sgml-entities before sending the mailto-link to Gnus, but they do.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Reloading info files

[Kevin Ryde]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
> (defun rs-info-reload ()
>   "Reload current info node."

You can enhance that by saving point as line+column, and the window
position as a line, to stop it jumping around too much on small
changes in the re-read text.  Code below from the emacs cvs.


;; It's perhaps a bit nasty to kill the *info* buffer to force a re-read,
;; but at least it keeps this routine (which is only for the benefit of
;; makeinfo-buffer) out of the way of normal operations.
;;
(defun Info-revert-find-node (filename nodename)
  "Go to an info node FILENAME and NODENAME, re-reading disk contents.
When *info* is already displaying FILENAME and NODENAME, the window position
is preserved, if possible."
  (pop-to-buffer "*info*")
  (let ((old-filename Info-current-file)
	(old-nodename Info-current-node)
	(pcolumn      (current-column))
	(pline        (count-lines (point-min) (line-beginning-position)))
	(wline        (count-lines (point-min) (window-start)))
	(old-history  Info-history)
	(new-history (and Info-current-file
			  (list Info-current-file Info-current-node (point)))))
    (kill-buffer (current-buffer))
    (Info-find-node filename nodename)
    (setq Info-history old-history)
    (if (and (equal old-filename Info-current-file)
	     (equal old-nodename Info-current-node))
	(progn
	  ;; note goto-line is no good, we want to measure from point-min
	  (beginning-of-buffer)
	  (forward-line wline)
	  (set-window-start (selected-window) (point))
	  (beginning-of-buffer)
	  (forward-line pline)
	  (move-to-column pcolumn))
      ;; only add to the history when coming from a different file+node
      (if new-history
	  (setq Info-history (cons new-history Info-history))))))