Re: TRAMP User Manual problems with Texinfo 5.0

[Patrice Dumas]

On Sat, Feb 23, 2013 at 12:15:11PM +0200, Eli Zaretskii wrote:
> 
> If it's important, I can trace through the C makeinfo and report what
> exactly happens there.  Let me know.

I don't think this will be needed, I think the difference that remains
is that in C makeinfo @set and @clear are completly removed from the 
output, as is done by the new implementation for @ifclear, for example, 
but not for @clear and @set.

> This produces the same output with makeinfo 4.13a.  With makeinfo 5.0,
> it mostly works, but there are still a few problems:
> 
>   . There are many warnings like this:
> 
>     tramp.texi:481: warning: @set should only appear at a line beginning 
> (possibly involving @xxx)
> 
>     tramp.texi:481: warning: @set should not appear in @file (possibly 
> involving @xxx)
> 
>     tramp.texi:481: warning: @set should not appear in @file (possibly 
> involving @xxx)
> 
>     tramp.texi:1188: warning: @set should not appear in @kbd (possibly 
> involving @xxx)
> 
>     tramp.texi:2345: warning: @set should not appear in @item (possibly 
> involving @xxx)

Those have been fixed in svn.

>   . There are some errors:
> 
>     tramp.texi:2457: misplaced { (possibly involving @xxx)
>     tramp.texi:2457: misplaced }
>     tramp.texi:2457: misplaced {
>     tramp.texi:2457: misplaced }
>     tramp.texi:2459: too many columns in multitable item (max 1)
>     tramp.texi:2460: too many columns in multitable item (max 1)
>     tramp.texi:2484: misplaced { (possibly involving @xxx)
>     tramp.texi:2484: misplaced }
>     tramp.texi:2484: misplaced {
>     tramp.texi:2484: misplaced }

Indeed, this error remains, this is linked with 

  @multitable address@hidden, , melancholia.danann.net,}} address@hidden, , 
192.168.0.1,}}

and the fact that this is expanded as a multi-line with @set and @clear
which then leads to failures because @multitable arguments should be on
a line.


>   . @item @trampfn{, , melancholia, .emacs} and similar constructs
>     (see tramp.texi around line 3230) produce this:
> 
>     '/'
>        melancholia:.emacs
> 
>     instead of this:
> 
>     `/melancholia:.emacs'

This is a similar issue as above.  The svn version, consistently with
leaving the @set in the output, also has a warning:
tramp.texi:2327: warning: @set should not appear in @item (possibly involving 
@xxx)


The following is the @multitable issue from above:

>   . The text between lines 2453 and 2491, starting with "If you, for
>     example, type" and ending with "Now you can choose" produces
>     something weird, probably because there are extra @ifset
>     conditionals there.  Here's the diff against v4.13:


The next issue is completly different, and arises because at some point
there is a @set with an incorrect name, here should be along

  @set x$(whoami)

There are other similar issues reported by the svn version:
  tramp.texi:978: bad name for @set (possibly involving @xxx)
that correspond to something like
  @trampfn{smb,
   daniel%BIZARRE, melancholia, /daniel$$/.emacs}
that is expanded as a 

  @set xdaniel%BIZARRE

The restrictions on @set/@clear flags are indeed new, they are
documented in the manual in @set @value:

    A "flag" (aka "variable") is an identifier consisting of
  alphanumerics, '-', and '_'.  However, it is best to use only letters
  and numerals in a flag name, not '-' or '_'--they will work in some
  contexts, but not all, due to limitations in TeX.

So, to 'solve' this issue, this specification should be changed.

>   . This call:
> 
>     emacsclient @trampfn{ssh, $(whoami), $(hostname --fqdn), $1}
> 
>     is converted to "emacsclient /ssh:$(hostname --fqdn):$1", omitting
>     the "$(whoami)@" part.

Thus, I think tht most of the issues should be alleviated by removing
completly @set and @clear from the expanded tree, as is done for
@ifclear for example.  Should I do that?

The issue that will remain will be the use of non alphanumeric characters 
in @set and @clear.  Should we change what is specified in the manual?



I'll answer to the customization/documentation issues in a separate
mail.

-- 
Pat