Re: How use vim to view info page?

[Karl Berry]

export MANPAGER=col -b -x | vim -R -c 'set ft=man' -

Is there a similar thing for info, so that I can view info page also with 
vim?

About all I can tell you is that you can dump an Info manual foobar by
running info --subnodes foobar.  I'm not familiar with vim, so I don't
know if anyone has done something so that vim can read that, or the
.info file(s) directly, or whatever ... maybe someone else here does.

Best,
Karl

Re: [bug-recutils] Doc patch

[Karl Berry]

3. The existing Texinfo manual (at least the one on www.gnu.org) says:

Good point.  I'll modify the text.

4. The GNU Coding standards should have a section this and general
   matters of typographical

The Texinfo manual tries to say what is and isn't good
style/conventional for GNU manuals in particular.  I don't want to try
to extract, let alone repeat, that information.

Maybe a @Gnu{} macro should be defined in some common header?

Definitely not.  1) There are no common headers.  2) Macros suck.
3) There is nothing special about GNU as a name, the same would apply
to any all-capitals abbreviation; so there's no point in defining
something special for it.  

Thanks,
k

Re: Commas in @example environment

[Karl Berry]

It doesn't seem to be possible to insert a comma within a @example 
environment.

Hi John,

Need failing code please, the basic idea certainly works for me.  There
is nothing special about commas in an example environment, or anywhere
except when parsing arguments.

k

Re: EC font support missing for @code

[Karl Berry]

  @code{þ} þ

to see what I mean.  Below a possible fix.

Thanks, looks fine to me.  Installed.

Re: non-obvious help needed

[Karl Berry]

In @verbatim, # is not taken into account, 

I knew we went back and forth on that, and didn't look it up :(.

generate Texinfo ... and therefore not use all the Texinfo features

Sure, but going to a lot of trouble to disable -- and such other basic
things seems nonsensical to me.  The result will look lousy.  It is not
rocket science to take care of such things during a conversion.  And if
one doesn't want to be bothered, then my answer remains: don't bother
using Texinfo.  We're not here to produce substandard documentation.
There are plenty of complaints already about how basic Texinfo is.

Whatever.

k

Re: non-obvious help needed

[Karl Berry]

- may be escaped as @minus{}

For the record, the Info result will be the same (-), but not the TeX
result.  A minus sign is not a hyphen.

Another thing you'll have to take care of ...

Indeed.  Another approach would be to put the whole document in
@verbatim.  That would just leave the @asis{#}.

If one doesn't actually want to use Texinfo features, there is no
purpose I can see in creating Texinfo documents.

k

Re: in Info space after *note required for cross ref?

[Karl Berry]

Here are some precise questions and my answers ...

texi2any


1) Should texi2any warn about an empty label as in @ref{node, , @ }
(yes, at least when generating Info)

I'd say always warn.  (If not error.  Such a construct is uselessly
confusing.  We don't want downstream readers to have to handle such
craziness.)

2) Should texi2any warn about an empty label in menu, such as
...
(yes, always)

Agreed, always warn.

3) Should texi2any warn about a case with no space after and or 
before : in menu
* a:vvv.
(no)

I agree, I guess there is no need.  The Menu Parts node doesn't
explicitly say there has to be a space after the colon, so maybe no
change is required, although I suppose we could say something like a
space is conventional but not technically required.

k

Re: in Info space after *note required for cross ref?

[Karl Berry]

Info reader
---
Should the following cross-refs be followed:

*note a:vvv.
*note a :vvv.
*note a : vvv.

In other words, ignore whitespace around the :.  Ok.

*note : vvv,
*note :vvv,
*note: vvv,
*note:vvv.

Allow an empty label?  I don't see any reason for it.

*note-vvv.
*note-vvv::

No.

(yes, yes, yes, ?, ?, no, no, no, no)

I agree, with no's for the ?'s.

And following menu entries:

* a:vvv.
* :vvv
(yes, ?)

? = no.

Sergey?

k

Re: CVS Texinfo fails to build the Autoconf manual (from git)

[Karl Berry]

 * Macro arguments cannot cross lines.
 
 Is that restriction limited to a per-argument basis (but you can have
 newlines between arguments), or is it global to the entire macro call?

My guess is that it is per-argument.  Maybe Karl can comment on that.

I couldn't get the current texinfo.tex to fail with newlines in the
arguments.  They come out as spaces or newlines, depending on the
environment.  Whether that's actually what one wants is another
question.  My little test file is below ... I don't doubt there are more
complicated cases where it might fail.

Anyway, I gather the practical problem is solved.  Glad for that.

k

\input texinfo
@setfilename mac-argnl.info

@macro mymac {a, b}
\a\ + \b\
@end macro

@example
Hello @mymac{uu,
vv}.
Hello @mymac{x
x,
yy}.
@end example

@bye

Re: defxx regression in docbook output cvs texinfo

[Karl Berry]

Hi Per,

What do you see as the role of DocBook in the texinfo project?
Is it just another output format you'd like to support, or do
you see it as strategic?

Certainly not strategic.  Of course we want it to be good as it can be,
in principle, but neither Patrice nor I (especially I :) are anything
like Docbook experts.  (I've received much conflicting advice about what
to do with it over the years, which probably accounts for some of
whatever strangenesses there are.)

if you want fancier or customized output, go via DocBook.

For people (like you, I guess) who know how to hack docbook, that is
fine.  Whatever works.

For HTML output, the new makeinfo release should be able to customize
virtually anything anyone would want to.  In fact, that is one of the
principal reasons we went this route, to have texi2html-level
customizations in the original texinfo.

In the future, we will have a latex backend, which should make it
possible for non-docbookers to play with PDF/DVI output as desired.

Best,
k

Re: Case insensitive file systems

[Karl Berry]

See also --transliterate-file-names, 

Since it came up: that feature is about (in practice) node names written
in Cyrillic.  It was originally proposed and implemented by Sergey to
avoid having the HTML filenames be nothing but long __xx sequences.

http://www.gnu.org/software/texinfo/manual/texinfo/html_node/HTML-Xref-8_002dbit-Character-Expansion.html
(I've fixed up the English there by now.)

In any case, it has nothing to do with the case folding/preserving madness.

k

Re: segfault in info from CVS when pressing h

[Karl Berry]

It's the classic bug of using a va_list after being destroyed.

Thanks much Andreas, I installed the fix.

Re: segfault in info from CVS when pressing h

[Karl Berry]

#2 0x0040ac84 in text_buffer_vprintf
 (buf=buf@entry=0x62f270, format=0x423098 %s\n,
 ap=ap@entry=0x7fffe0e8) at info-utils.c:

$ echo h /tmp/h
$ info --restore=/tmp/h 
also crashes here for me, on x86_64-linux (but not i386-linux).
It is not immediately obvious to me where the problem is :(.

Perhaps it is related to my putting explicit initializations into
infokey.c and window.c a few days ago, although it shouldn't be.

Sergey, any chance ... ?

Thanks,
k

Re: info not showing anything with certain build flags

[Karl Berry]

Hi Norbert,

to go to the Top dir file again showed nothing.
After removing the hardening flags it worked again, so I assume that is 
is related to that. The way we are compiling is wiht

FYI: we are finally getting close enough to a texinfo pretest that I
tried your hardening recipe for compiling on an x86_64-linux machine,
and info worked normally.  So I think whatever the problem was, Sergey
has fixed it in the current sources.

Of course, you should still confirm this after we actually have the
pretest and/or release out.

k

Re: in Info space after *note required for cross ref?

[Karl Berry]

Hi Patrice and all,

should there be a mandatory space after a *note to have the
remaining be considered as a cross reference? 

I believe so.  Because I believe all versions of makeinfo and even
texinfo-format-buffer generated such spaces.  Anyone know something to
the contrary?

That is should
  *note-something:: 
be a cross reference to `-something'?  

I think not.  Is there a way to generate the *note for an xref without
the space?

Also would an empty label be accepted, that is something along
 *note: a node name.
or 
 *note : a node name.

Same answer.  I don't know any way to generate such constructs.  Does
anyone? So I'm inclined to consider such weird borderline cases invalid.

As a side note, regarding the space after the :, I think that it should
be optional.

Again, is there any way to actually get such output (with a space)?
If not, why complicate/over-generalize?


I guess all this means, once we reach a conclusion,
1) the new makeinfo should only warn about @strong{Note} when the result
   is actually ambiguous, as occasioned the whole discussion, and
2) the standalone Info reader should get smarter about recognizing such
   things, and
3) our Info reference documentation should get some more details, since
   it doesn't explain the whitespace requirements (or lack thereof) much.

No need to wait until 2) is done before doing 1), and
I'm sure Sergey would like some examples to do 2), which I expect you'll
construct as test cases for 1) anyway.

Do you agree, Patrice?

k

Re: makeinfo --html xref problem (spaces?)

[Karl Berry]

Hi Joel,

Yes, I can easily believe that hyphens vs. spaces in node names have
bugs in makeinfo 4.13.  (I don't think there is any huge systematic
error such that all cross references fail.)

Any release planned in the near future?

Yes, for some definition of near.  After years of work (mostly by
Patrice), I dearly hope that at least a first pretest will be out this
summer.

Best,
Karl

Re: doc bug

[Karl Berry]

In current CVS, file texinfo.txi, node `Inserting a Backslash': The
example is wrong, describing @comma.

Oops :).

Thanks.

Re: [PATCH] texinfo.tex: remove reference to undefined macro \p

[Karl Berry]

-  \ifx\p\space\else\addtokens{\filename}{\PP}%
-\advance\filenamelength by 1
-  \fi
+  \addtokens{\filename}{\PP}%
+  \advance\filenamelength by 1

Agreed, installed, thanks.
(Now we'll see if we are both missing some obscure point. :)

k

Re: fix build of texinfo with automake 1.12

[Karl Berry]

-AM_INIT_AUTOMAKE([1.10.1 readme-alpha dist-lzma])
+AM_INIT_AUTOMAKE([1.10.1 readme-alpha])

Thanks.  Already fixed (changed to dist-xz) in the development sources.

Best,
Karl

Re: info: INFOPATH interpretation severely flawed

[Karl Berry]

If you want to change dir file interpretation, IMHO the most important
people to talk to are the Emacs maintainers.

k

Re: building makeinfo for android

[Karl Berry]

Hi Corbin,

Sorry for the delayed reply.

Please tell me if I should submit this to a different one of the mailing

No, you sent it to the right place.  I've never been very familiar with
the cross-compiling niceties, basically just integrating patches from
others.  In any case, I think the bottom line is that you'll be a lot
better off waiting for a pretest (hopefully coming in the
not-impossibly-distant future), and/or building from the development
sources, rather than worrying about 4.13.  Which predates the existence
of Android.

But anyway, here are some brief replies:

Does the make flow not build libgnu.a automatically?

Sure, generally it does.  Why it didn't in your case is not immediately
apparent to me.

 index.c:52: error: 'mbscasecmp' undeclared here (not in a function)

 I don't see where mbscasecmp.h is being included by any file.  How
 is this not normally a problem?

index.c includes mbswidth.h, which probably defined mbscasecmp at the
time, on the systems people tried anyway.  I don't recall that ever
being reported before.  I suspect it is due to gnulib rearrangements.

 ./sys/time.h:23: error: stray '@' in program
 What normally fills in those @PRAGMA@ lines in the gnulib files?

configure and/or make.  Again I suspect the gnulib update you did has
left you with a mix of old and new gnulib stuff.

 I had to update which config.guess and config.sub I used, but I have had
 to do that for just about everything I have built for Android.

Sure.  The config.* and other infrastructure files in 4.13 were current
as of the time of the 4.13 release, of course ...

Best,
Karl

Re: some @-command constructs not accepted on section lines

[Karl Berry]

So constructs that are not allowed in @shortcaption may trigger a
warning/error when they appear in @caption and there is no
@shortcaption.  However, the implementation would not be that easy.
Do you think I should work on it nevertheless?

I see no great need.

k

Re: Bug#656659: info not showing anything with certain build flags

[Karl Berry]

A diff against the latest CVS version of the info directory is
attached.

I applied it.  Thanks.

k

Re: info not showing anything with certain build flags

[Karl Berry]

Does anyone have an idea why this might happen?

Not out of my head.  And Sergey's main server (gnu.org.ua) apparently
developed hardware woes, so I doubt he'll be able to answer anything
Texinfo-related quickly.

(I tried compiling current sources, but that didn't work out, 

Sergey has made a ton of changes since info 4.13.  Really need to work
from the development sources.  I can try compiling with your options at
some point.

(BTW, it is explicitly not a goal for Texinfo, or GNU packages in
general, to compile with -Wall, although some individual maintainers
choose to do so.  I doubt that's relevant to the problem at hand,
anyway.)

karl

Re: Bad anchors in HTML's Table of Contents

[Karl Berry]

See for example recutils's manual:
https://www.gnu.org/software/recutils/manual/recutils.html

Thanks for the report.  It's fixed in the development sources.

karl

Re: texi2pdf vs texi2dvi --pdf

[Karl Berry]

Hi Norbert,

I think you missed one point ... thumbpdf didn't have real problems,

I was simply reacting to the error messages you reported, since I didn't
have anything else to go on.

I also have the feeling that it comes from the fact that texi2pdf
is run two times, and the second time some cmd line options are 
not properly passed, or something is not properly called ...

Sorry to say that I'm still not clear on what bug you are reporting,
what you expect to happen, or how it's related to Texinfo.  So I have no
idea either.  Let me know if you figure out what to do :).

I can only suggest the obvious: trying running the TL'09 and TL'11
versions in parallel with -x to look for the relevant differences.  Or
maybe the relevant differences are in thumbpdf.sty, or pdftexconfig.tex,
or ... who knows ...

karl

@ctrl

[Karl Berry]

@ctrl should not be a command at all.  See the NEWS for 3.8 (1996),
below.  All that C makeinfo does with (some of) them is say @CMD is
obsolete.  I think we can safely remove them all at this point, unless
you think otherwise.

Thanks,
k

* Deprecate these obsolete commands, to be removed in the next release:
@ctrl
@infoinclude
@iappendix @iappendixsection @iappendixsec @iappendixsubsec
  @iappendixsubsubsec
@ichapter @isection @isubsection @isubsubsection
@iunnumbered @iunnumberedsec @iunnumberedsubsec @iunnumberedsubsubsec
@setchapterstyle
@titlespec

Re: some @-command constructs not accepted on section lines

[Karl Berry]

You mean precisely in section titles and figure captions?  

I'm not sure what I mean precisely :), but it would certainly be a good
step to warn just in figure titles.

for warning to appear in shortcaption,
a warning should also appear in 

Indeed, I doubt @verb works in any of those commands in texinfo.tex.
Nor do I see that it needs to work in any of them, logically speaking.
So I think it would be good to warn in all those cases.

in figure captions it is harder, as captions are
set up as accepting anything.

Which makes sense.  Let me check about @verb in figure captions in
texinfo.tex.  I was thinking of @shortcaption before.

Thanks,
k

Re: @node in TeX ignored if not associated with a sectioning command

[Karl Berry]

in general, letting the user choose between a 
node and an anchor is better in my opinion.

In theory, given the language as it stands today, I can agree.

In practice, however, I have no desire to bend over backwards to
implement something that no one has ever needed or wanted, and is not a
practice that we want to recommend to document authors in the first
place.  If it would take me ten minutes to do in texinfo.tex, then fine,
but it's more complicated than that and has great potential to break all
kinds of existing stuff.  Not going to go there.

I'll review the text for the manual.

k

Re: texi2pdf vs texi2dvi --pdf

[Karl Berry]

Package thumbpdf Warning: Missing driver name.

I didn't look, but I doubt texi2dvi actually works with thumbpdf,
given the name.  DVI ... PDF ... not the same thing :).

Package thumbpdf Warning: Compressed PDF objects of PDF 1.5 are not
supported.

Well, this seems clear enough.  thumbpdf.sty is not part of Texinfo,
as you know ...

I surmise it is related to us (that's TL us, rather than Texinfo us :)
switching the default PDF output version to 1.5 in TL 2010, remember?
From pdftexconfig.tex:

% As of TeX Live 2010, we output PDF 1.5 by default, so we can enable
% more compression.  To change this for the installation, comment out or
% delete these lines and remake the formats.  To change it for a
% particular LaTeX document, \RequirePackage{pdf14} early.
% 
\pdfminorversion=5
\pdfobjcompresslevel=2

I don't know what we can do.  I hope Heiko has an idea.

karl

Re: @node in TeX ignored if not associated with a sectioning command

[Karl Berry]

In my opinion, @node should be treated similarly with an @anchor, so a
lone mode should not be problematic.

Well, it could be done (though it's not exactly trivial), but I'm not
sure I agree.  @anchor was invented precisely to mark an arbitary
location that can be referred to.  I don't see particular usefulness in
doing the same with @node.  Especially since it has never worked and no
one has ever asked for it.  Am I missing something?

As for the manual, I don't think it explicitly addressed this question.
I rewrote the paragraph at the end of the node node (not committed
yet):

  @TeX{} uses @code{@@node} names and chapter-structuring names in
  combination in the output for cross references.  For this reason, you
  must write @code{@@node} lines in a Texinfo file that you intend to
  format for printing, even if you do not intend to format it for Info;
  and conversely, you must include a chapter-structuring command after a
  node for it to be a valid cross-reference target.  You can use
  @code{@@anchor} (@pxref{anchor,, @code{@@anchor}}) to make
  cross-references to an arbitrary position in a document.  (Cross
  references, such as the one at the end of this sentence, are made with
  @code{@@xref} and related commands; see @ref{Cross References}.)

It's too complicated, but I think that's the information we want to
convey.

I'd suggest having makeinfo warn when it encounters a reference to a
node without a chapter-structuring command, but I guess that would
effectively disallow documents with only nodes, which doesn't seem like
a good idea.

Wdyt?

Thanks,
Karl

Re: dot in node not accepted in Info in menu entry

[Karl Berry]

The real issue is with Info

Indeed.  In general, it seems to me that if Emacs Info can handle a
weirdly-named node correct, standalone Info ought to also.

Sergey?

k

Re: dot in node not accepted in Info in menu entry

[Karl Berry]

* generate. w::
should be followed as the `generate. w' node.  Currently it doesn't
work.  

It does work in Emacs Info (21.3).  So I guess this is for the
standalone reader only.

k

Re: Misplaced parenthesis in `@frenchspacing' VAL: Control sentence spacing

[Karl Berry]

Subject: Misplaced parenthesis in `@frenchspacing' VAL: Control sentence
spacing

Thanks Tim, will apply.

On your other question (ok, different list, but whatever :):

@command RET to be startled by No index entries containing `@command'.

I've had that experience too.

Is this a side-effect of the index sorting, a philosophi-
cal issue or a simple oversight?

The first.  The original principal author of the manual (Bob Chassell),
made a separate command index precisely so that they could be sorted by
their first letters, and not all appear under @.  That is, there's no
way in Texinfo to index @foo and have it sorted as foo.

One can imagine extensions to Texinfo indexing to do this, as makeindex
et al., but it's never actually been done.  Texinfo indexing in general
has always been pretty simplistic.  Lots of TODO entries there ...

best,
karl

Re: some @-command constructs not accepted on section lines

[Karl Berry]

@lbracechar{} 
@lbracechar{}

Should be no problem with those.

@abbr{CCC, rrr} @abbr{CCC} @abbr{DDD}
@image{image_file}

Will see.

@verb{. @ {} . .}

It wouldn't surprise me if it turns out to be impossible to handle @verb.
It seems unnecessary.

Anyway, I'll look and get back.  I'm sorry I've been so laggard, other
projects coming to fruition have had to take precedence the last days :(.

Thanks,
karl

[bug #35793] patch: make @value work in the filename argument of @xref and friends

[Karl Berry]

Update of bug #35793 (project texinfo):

 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

(accepted, replying on list)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?35793

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #35793] patch: make @value work in the filename argument of @xref and friends

[Karl Berry]

Hi Samuel,

The fact that @value doesn't currently work in the filaname argument
to @xref and friends is a problem for me, so I made this patch 

Thanks :).  It seems to me that \skipspaces should not be needed at all,
but your change does the job in my tests, so fine.

(I've signed copyright assignment papers which I *think* should
cover this, but it was a while ago so I don't remember very
clearly.)

The copyright papers you signed were only for gdb, as far as I can tell.
However, this change is so small (two lines of code and two lines of
comment) that we don't need papers.  I installed it.

Thanks,
Karl

Re: texinfo.tex trailing white space in lines

[Karl Berry]

Hi Paul,

Subject: texinfo.tex trailing white space in lines

No, I do not want to change it.  The trailing whitespace is actually
useful for me.  I've already explained at length to Jim and don't want
to reiterate the whole thing.

when this is applied to texinfo.tex (as was just done to glibc's copy)

Well, that is simply a mistake.

I've wasted so much time over this trivial issue that is now being
propagated into every corner of GNU.  Far, far, more than was ever
caused by having the trailing whitespace in the first place for the last
20+ years.

Sorry, but this is extremely frustrating to me.

karl

Re: [bug #35614] mobile-phone friendly HTML output

[Karl Berry]

Hi,

The HTML generated by makeinfo (texinfo 4.13) is hard to read from mobile

It is discouraging that the completely generic HTML we output cannot be
read sensibly without introducing new settings.  Good thing new systems
are so advanced.

1. Device-width aware HTML.
   Simple, just inserting follow meta tags will be enough:
   (See also https://github.com/h5bp/mobile-boilerplate)

  meta name=HandheldFriendly content=True
  meta name=MobileOptimized content=320
  meta name=viewport content=width=device-width
  meta http-equiv=cleartype content=on

What does that 320 actually mean?  I hope it is not a pixel count.
https://github.com/h5bp/mobile-boilerplate/wiki/The-Markup doesn't
explain.  (There is way too much unrelated stuff in that project for me
to want to delve further.)

   it will be grateful if there is a way to insert custom meta.

Indeed.  I kind of think there is already, in the development makeinfo
-- Patrice?

   I'm not expecting this will be hard coded into texinfo, rather,

Not hardcoded, but I surmise we should make a configuration variable to
output such recommended boilerplate stuff, since presumably it will
change over time.

2. Reader feature in Safari 5.x.
[...]
Replace every occurrence of body and /body in html.c,
makeinfo.c, and node.c into bodyarticle and /articlebody.

Well, it would seem that could be done with @html, then.  Anyway, since
the iphone is so ridiculously nonfree, I don't think we should insert
any support for it into the distribution.

Thanks for the report.

Best,
karl

Re: [SPAM] Re: [SPAM] Re: texi2html oddity on findex/item combination

[Karl Berry]

This should be fixed.

Great.

As a side note, index entries before @item are used in the 
texinfo manual itself...

Yes, and I don't plan to change it :).
As I said, it has pretty much always been the recommended convention.

Thanks,
k

Re: [bug #35543] add DOCTYPE to HTML output

[Karl Berry]

I have noticed on monotone documentation uses too small fonts. It
turned out to be a problem with standards vs quirks mode. It appears
that adding a DOCTYPE to the generated HTML fixes this. The attached
patch does just that.

Thanks for the report and patch, but ...

I can only surmise it's actually a problem with the browser and/or if
something special is being done by monotone.  The HTML we generate is
(intentionally) very plain and there is no reason why it should be too
small.  It isn't for me, in general.

In any case, the development code does generate a doctype, so I guess we
can hope that whatever is going on will be fix itself eventually.

Best,
Karl

Re: [SPAM] Re: [SPAM] Re: texi2html oddity on findex/item combination

[Karl Berry]

+ we will have an empty bullet with texi2html since it will
 never get upgraded.

As I understand it, texi2html will still be updated, more or less.  But
not before texinfo, so it doesn't help you.

I could put it on our internal machines that generate the html.

Another, perhaps less-intrusive solution, would be to post-process out
the bullet with sed/perl/whatever.

Of course, any testing against the development version would be
appreciated.  I hope we'll make at least a prerelease in the
not-impossibly-distant future ...

Best,
Karl

Re: [SPAM] Re: [SPAM] Re: texi2html oddity on findex/item combination

[Karl Berry]

XML, Info, Plaintext, rawtext, plaintexinfo, textcontent, in 
my opinion, do not need it.  This only leaves HTML and 
DocBook that would need it.

I agree.

Thanks,
k

Re: [SPAM] Re: texi2html oddity on findex/item combination

[Karl Berry]

Patrice,

 
http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/c_user_420.html#Configuring-a-System-Library-Support-Definitions

FWIW, I see the extra bullet in my current seamonkey.

@item
@findex CONFIGURE_MALLOC_STATISTICS

Can't we please make this continue to work the other way around?  I feel
like that is what just about every existing manual does, so it would be
very bad to break it.  Like, just pretend that index entries before an
item were actually written after them.  And, this can happen with every
item, not just the first.  I remember we talked about this long ago ...

At one time, I think index entries after the item didn't work with TeX
(caused extra space in the output).

Anyway, I can't say I've reviewed what C makeinfo does.  Or current
texinfo.tex for that matter.

Thanks,
k

Re: FAIL: accentenc

[Karl Berry]

1 of 23 tests failed
Please report to bug-texinfo@gnu.org

Thanks for the report.  I expect things are ok in the development sources.

Best,
Karl

Re: texi2dvi outputs toc commands on stdout for @include files

[Karl Berry]

Hi Patrice,

the line that should be writen in the .toc file is written to stdout
...
@numchapentry{chap}{1}{}{2}

This happens because @contents occurs after @top.  That's never been
supported -- @contents has to be outside all of the other material,
either at the beginning or the end, not in the middle.  Reduced test case:

\input texinfo.tex
@setfilename t.info
@top top
@contents
@chapter chap
@bye

I suppose texinfo.tex could detect this and issue an error instead of
just weird output, but it doesn't seem too critical.  On the other hand,
it would be nice for makeinfo to output a warning :).

Thanks,
k

Re: texi2dvi outputs toc commands on stdout for @include files

[Karl Berry]

after the @code{@@end
 titlepage} (@pxref{titlepage}) and before any sectioning command.

Will do, thanks.

Re: [bug #35395] bad picture path with --html and --without --no-split

[Karl Berry]

do not test any longer the presence of some path in --output=FILE 

The problem with not testing for the file is that then there is no way
to know whether it is .png, .jpg, or what.  And we need to know to
construct the final img (or whatever).  And we don't want to force
specifying an extension in the @image command, either.

 with --html, w/o --no-split, and w/o --image-link-prefix :
 prepend `../'

As I've said before: I recognize that that matches the common practice.
But I still don't see any overriding need to hardwire that convention
into the program (and documentation).  It seems to me that
IMAGE_LINK_PREFIX does the job in the simplest and most complete way.

k

[bug #35451] \ paths in texi2any

[Karl Berry]

Update of bug #35451 (project texinfo):

 Summary: texi2any does not place output in the right place
under MSWindows =  paths in texi2any 
  Item Group: bug = enhancement

___

Follow-up Comment #1:

(changed subject.)

as discussed, the best approach is probably to convert paths at the beginning
of the program, and a patch to do so would be welcome.

k


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?35451

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #35395] bad picture path with --html and --without --no-split

[Karl Berry]

Indeed, I do that a lot.  This is inherited from texi2html, though, 
so I figured there was something magical in perl regexp to consider
\ as / automatically.  Looks like it was wrong...

No, it would crazy to automatically make the meaning of \ and / in
regexps platform-dependent :).

In general, / works fine on Windows as a separator.  I'm not sure why
it's not working here, but I don't think it's our job to worry about it.
Vincent, if you need it to work, I think you should prepare the patch.
Sorry.

k

Re: [bug #35395] bad picture path with --html and --without --no-split

[Karl Berry]

I think we should just declare \ paths to be known not to work.
Trying to support them seems like madness to me.  It will complicate
things everything.

k

Re: [bug #35395] bad picture path with --html and --without --no-split

[Karl Berry]

- provide a new command line option --link-prefix that allows the user to
force some prefix for relative links

My initial reaction is that it would be better as a configuration
variable than a command line option.

I think I agree with Patrice that the default behavior should be simple
and not depend on other options/variables.  If the document says
@image{somedir/foo}
then the output should be img src=PREFIXsomedir/foo.png
where PREFIX is specified by the variable.  Is there any rational
alternative?

Although this means the prefix has to be manually set to ../ in the case
of split output and shared images, that seems a small price to pay.
(And gendocs.sh could do it, to handle the usual GNU manual style,
although virtually no manuals have images, anyway.)

Thanks,
Karl

[bug #35395] bad picture path with --html and --without --no-split

[Karl Berry]

Follow-up Comment #1, bug #35395 (project texinfo):

hi Vincent -- i agree it's a problem, but if you have @image{img/somepicture},
i don't see how makeinfo can guess anything else.  granted that the usual
organization on www.gnu.org is like you describe, it's not universal.  and
usually, there are no images at all.  guessing something different for split
vs. non-split output seems like a morass to me.

however, what i can imagine is to have some config var that would alter the
output img locations.  patrice, i know we've talked about this a little. 
did we ever do anything :)?

thanks,
k


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?35395

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #35395] bad picture path with --html and --without --no-split

[Karl Berry]

Follow-up Comment #3, bug #35395 (project texinfo):

if complete image paths means absolute, then i certainly agree we don't
want to use absolute file names in the output.  but that doesn't mean there
couldn't be an option to alter what relative path is output.  

Specifically. for the case Vincent is talking about (which is the most common
scenario I've seen), what's needed is to prefix ../ to what the user
supplied, for split output only.  it corresponds to an output layout like
this:

foo.html
html_node/index.html
img/bar.img

i don't propose hardcoding the particular case of prepending ../ as a
configuration variable, but perhaps there could be a way to specify a prefix,
suffix, and/or general transformation of the image directory supplied by the
user.  maybe a way to specify a perl expression that is applied before it is
output?

wdyt?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?35395

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: makeinfo should quote 'like this' instead of `like this'

[Karl Berry]

These features can be turned off with a flip of a variable or two.

Please elucidate.  That is not even remotely close to my experience.

As you may recall from my various emacs bug reports over the last few
years, I have spent many, many hours trying to turn off Emacs's
newfangled colorization, use of different fonts, fancy formatting in
general (in all areas), with a distinct lack of success.

Info is just one of the places where the obvious things like
(global-font-lock-mode -1) do not even begin to do the job.

k

Re: makeinfo should quote 'like this' instead of `like this'

[Karl Berry]

Hi John,

Why?

Because rms accepted the proposal of Bruno/Paul/Jim/et al. to make the
GNU coding standards recommend '...' over `...'.

I didn't see that argument.  Where was it?

bug-gnulib, but I didn't offer any real arguments.  Being a TeX person,
I just hate the undirected quotes and I get so tired of being told that
` = grave is the standard that I don't want to talk about it any more.

I see no convincing reason to change.  

The reason they advanced is that essentially all current fonts render `
as a grave accent.  (This choice by the font people is the original sin,
IMHO.)  Therefore `...' looks weird to anyone who hasn't hacked their
fonts (as I have :).

the agreement in GNU has always been that 0x60 means opening single quote.

As far as I followed things, their argument is that nowadays no one
except GNU (and TeX) uses ` to mean left quote, so we should join the
world.  I confess that I find some validity in that.

As far as I can tell, they aren't persuadable, and I doubt rms will
change his decision now, but feel free to write any of the above if you
like.

karl

Re: makeinfo should quote 'like this' instead of `like this'

[Karl Berry]

A better alternative might be for makeinfo to create info files
containing the utf-8 directed quotes, 

If the user says to use UTF-8, that happens now.  We certainly don't
want to use UTF-8 quotes in otherwise 7-bit-ASCII Info/plaintext output.

A related question: how does/should makeinfo+info handle non-ascii
characters in the source?  For example if I'm writing documentation
in Norwegian.  Is the info output supposed to be locale-specific?

The question is not the language so much as the encoding.
(make)info doesn't convert between encodings, if that's the question.

If you put @documentencoding ISO-8859-1 in Texinfo, say, makeinfo puts a
Local Variables: section in the Info file specifying that coding: value.

[Most of you know my opinion in this matter: info as a *file* format
should be killed dead and replaced by some variant of [X]HTML.  

For that to happen, Emacs has to stop reading Info files and start
reading the XML output.  I am not aware of anyone working on that, but
then, I probably wouldn't be.  Probably rms would have to retire before
any such change has a prospect of succeeding :).

Right now, Emacs (post-21) tries to read semantics in Info files and
remove the colons from menus, xrefs, etc., and do all manner of fontish
things.  I think that's the worst of both worlds, but then, no one asked
me :).

karl

Re: makeinfo should quote 'like this' instead of `like this'

[Karl Berry]

Paul -- I dislike copying two big lists, so I'm just going to reply
here.

I am of course fully aware of the coding standards change.
I agree that @file and the like might as well generate '...' now in
Info/plaintext output, given the mandated change.  Patrice, wdyt?

To go all the way, makeinfo would have to change an input ASCII ` to an
output ASCII ', when just regular text is `quoted'.  That just seems so
bizarre to me.  I cannot argue that there is any other way to be
compliant, though.  Sigh.

like, I can try to code up a patch along these lines.

Since C makeinfo has been abandoned, there is no use in doing anything
with it.  (If you meant you would hack the new Perl tp/ code, that's a
different story, but I suspect changing @file/etc. will be trivial for
Patrice.  Even I could probably manage it. :)

Best,
karl

Re: makeinfo should quote 'like this' instead of `like this'

[Karl Berry]

In HTML, those quotes are ldquo; and rdquo; in 
the default case.  Is it ok?  

Not [lr]squo?  Always been traditional to use single quotes for @file
etc.

become U+2018 and U+2019 if enable-encoding is set and 
@documentlanguage utf-8 is set too (as discussed recently).

Yes, fine.  But the question at hand is about the info/plaintext output
for @file when enable-encoding is *not* set, and/or utf-8 is not
specified,.  Up till now, makeinfo in all its forms has output `foo'.
But I guess we have to now change to 'foo'.

Can do too, even though I don't really like that.  

I hate this whole move to undirected quotes, personally.
But I already lost that argument.

So, should I proceed with ` becoming ' in ascii in info/Plaintext
output?

I fear so.  I can't see any convincing reason for us to refuse.

Currently, in html, ' is changed to rsquo; and ` to lsquo; except if
in @code/@example.  I think that it should be kept that way.  

I agree.  Inside @code/@example is different.
And that output is already controllable with @codequote*, so fine.

For now, ' and ` are not transformed to unicode points, like --- --
`` '' are in text/plaintext/info if enable-encoding is set and
@documentlanguage utf-8 is set too.  They are in DocBook, to U+2019
and U+2018.  That would seem rather logical to also transform ' and
` to unicode U+2019 and U+2018 in that case too.

I agree.

The XML output should do those transformations too?

Thanks,
k

Re: MS-Windows build of Texinfo

[Karl Berry]

solve a compiler warning in building makeinfo 

C makeinfo is abandoned, so there's no use in worrying about that one.

Sergey, can you look at installing Eli's changes in info?

karl

[bug #35308] location of pointer after following cross-manual xref

[Karl Berry]

URL:
  http://savannah.gnu.org/bugs/?35308

 Summary: location of pointer after following cross-manual
xref
 Project: texinfo - GNU documentation system
Submitted by: karl
Submitted on: Sat 14 Jan 2012 07:01:13 AM PST
Category: None
 Release: 
Priority: 5 - Normal
Severity: 3 - Normal
  Item Group: None
 Privacy: Public
 Open/Closed: Open
 Assigned to: gray
 Discussion Lock: Any
  Status: None

___

Details:

Sergey, here is another trivial thing:

$ info ./xref5.info  # attached
f RET# follow link to emacs

observe that point is at the first E in The Emacs Editor.  This is an odd
location to end up at.  It seems like it should be either be the T or the
newline before the title.  (Emacs 23 info puts it on that newline, older Emacs
on the F of File:, which also seems ok to me.)

If the xref is changed to have a node name, i.e., Top, the location in
emacs.info after following is different.  Seems like that shouldn't matter.

here's the texinfo:

\input texinfo
@setfilename xref5.info

@node Top
@xref{,,, emacs, The GNU Emacs Manual}.
@bye


Thanks,
karl



___

File Attachments:


---
Date: Sat 14 Jan 2012 07:01:13 AM PST  Name: xref5.info  Size: 173B   By: karl

http://savannah.gnu.org/bugs/download.php?file_id=24818

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?35308

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: texinfo-tex-4.13a: texi2dvi fails to diagnose error

[Karl Berry]

Hi Eric, Jim,

(Back on this mail from two months ago, sorry.)

 echo '\input texinfo.tex @bye' txiversion.tex
Ouch - this is a non-portable use of echo.  You CANNOT expect backslashes
to make it through echo, but should use printf instead.

Excuse my skepticism, but on what platform(s) does echo '\i' fail to
pass the \?  It's been used here since inception (1992, I guess) and no
one has ever reported a problem.  Indeed, for many years it worked when
printf could not be assumed.  (Of course these days printf would be ok.)

I know the standard escapes such as '\r' can't be used portably, but
that's not the case here.

I was surprised to find that texi2dvi was failing with no diagnostic.

Thanks for reporting that, Jim.  Looks to me like it was breakage
unknowingly introduced by someone forcing me to use set -e.  (Aside:
curmudgeon that I am, I hate set -e, even though everyone else seems to
love it.  Just seen so many warts introduced to placate it.  Like this
one.  Sigh.)

if (
  ...
  printf %s\\n '\input texinfo.tex @bye'  txiversion.tex
  $TEX txiversion.tex /dev/null txiversion.out 2txiversion.err
); then

Ok, I munged that into place, thanks Eric.  Hope if (...) is portable
(in reality) as an if condition.  Never tried that before.

k

Re: [PATCH] build: Add --disable-man-pages option

[Karl Berry]

Sorry, I'm not inclined to complicate my configure script with an option
that I can't plausibly document in order to placate your build system.
Presumably you can install the patch as part of your build.

k

texi2dvi --output and --clean

[Karl Berry]

Hi Akim,

It used to be that  texi2dvi --output someoutfile  implied passing
--clean.  That was eliminated at some point in (I'm assuming) your
massive rewrites.  Right now, if the call is
  texi2dvi --output some.out foo.tex
the output remains in foo.dvi and is not moved to some.out.

The comment at --output now reads:
-o | --out  | --output)
  shift
  # Make it absolute, just in case we also have --clean, or whatever.
  oname=`absolute $1`;;

which seems that it was intentional to no longer imply --clean.
But why?  Do you have any recollection?  Or maybe I am reading too much
into that comment.  The --help string was never changed, and has always
said implies --clean.

It is easy enough to restore implying clean (if tidy has not been
specified, I suppose).  It is also feasible, I think, to make --output
work in --build=local mode, e.g., my initial attempt at a patch below.

If you have any insight, that would be great.  Otherwise, I guess I'll
go back to implying --clean.

Also ... do you still use texi2dvi for processing latex documents in all
those fancy ways?  Hevea, tex4ht, etc.?  Just wondering.

Thanks,
karl


--- texi2dvi.~1.169.~   2012-01-07 09:16:18.0 -0800
+++ texi2dvi2012-01-07 16:43:46.0 -0800
@@ -681,6 +681,8 @@ move_to_dest ()
 {
-  # If we built in place, there is nothing to install, leave.
-  case $tidy:$oname in
-false:) return;;
-  esac
+#  echo move_to_dest $*, tidy=$tidy, oname=$oname
+
+#  # If we built in place, there is nothing to install, leave.
+#  case $tidy:$oname in
+#false:) return;;
+#  esac
 
@@ -699,5 +701,8 @@ move_to_dest ()
   destfile=$destdir/$file;;
-  *:*)destfile=`output_base_name $file`
+  true:*) destfile=`output_base_name $file`
   destdir=`dirname $destfile`;;
+  false:*) destfile=$oname
+   destdir=`dirname $destfile`;;
 esac
+ 
 # We want to compare the source location and the output location,

Re: htmlxref.cnf [was Re: broken links in Texinfo manual on www.gnu.org]

[Karl Berry]

How about the attached patch?

Definitely, thanks.  Looks like things I missed or have been added since
I went hunting.

+GDBM = http://www.gnu.org.ua/software/gdbm/manual

SSI errors at the top of bottom of that page, FWIW.  Also, the font size
is overly large in my browser.  (Larger than what I have in my preferences.)

k

Re: broken links in Texinfo manual on www.gnu.org

[Karl Berry]

This is the normal way for one GNU manual to cite another, but it's
not working on the web.  What's a good way to fix this?  

Just to wrap this up: indeed, Patrice and I invented the whole htmlxref
mechanism to solve cross-manual references.  It was tons of fun exhuming
usable urls for all the GNU manuals I could find, I can tell you.

I've been using it from Texinfo CVS to generate new versions of maintain
and standards.  Maybe I used it for the latest libc, too, I can't
remember, but don't think so :(.  I have not regenerated the Texinfo or
other manuals, hence those links remain broken.  Life goes on.

k

[bug #35184] cursor position of r command

[Karl Berry]

Update of bug #35184 (project texinfo):

 Open/Closed:Open = Closed 
  Status: In Progress = Fixed  

___

Follow-up Comment #2:

confirmed fixed, thanks.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?35184

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: Include paths for makeinfo

[Karl Berry]

For html, it is only 
  ('.png', '.jpg')

Surely jpeg and gif should be there too?

Thanks,
k

Re: Include paths for makeinfo

[Karl Berry]

Hi John,

Makeinfo doesn't seem to honour the -I flag when searching for the 
subject of @image

Hmm, makeinfo 4.13 does use the -I args to search for images, or so it
looks from the code.

Can you show us your actual failing example with the filenames and
cmdline args involved?

karl

[bug #33041] French translation: typo fixes

[Karl Berry]

Update of bug #33041 (project texinfo):

 Open/Closed:Open = Closed 
  Status:None = Invalid

___

Follow-up Comment #4:

The general rule is that translation changes for Texinfo must go through the
translation project, http://translationproject.org.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33041

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: local header name assigned to system header float.h

[Karl Berry]

It may be harmless to have a local header with the same name as a
system header, or it is not.

Thanks for the suggestion.  I suppose I can imagine vague circumstances
where it might cause a problem, although it never has in practice.
Meanwhile, it doesn't matter, since the C implementation of makeinfo has
been discontinued and will no longer be maintained or distributed.

Best,
karl

Re: Colon in @pxref, automake.texi

[Karl Berry]

- the documentation of texinfo does not state to avoid colon in the 
third parameter of @pxref

You're right that there is nothing about that particular case in the doc
(that I could find either).  I'll add something.

- texinfo forgets to escape the colon?

Unfortunately there is no escape mechanism for special chars in
node/xref/anchor/etc. names.  A design flaw since day 1 of Texinfo, that
perhaps we will fix one of these years, but not this one.

Thanks,
karl

Re: CVS-source build failiture

[Karl Berry]

 And one more question - may I use BDS PCRE library, which is not
 part of GNU, to contribute to GNU?

I may not be the best person to answer that, but it is quite frequent
in the GNU project to use software coming from outside of the GNU

That is true enough in general, but in the particular case of PCRE, it's
unlikely to work well.  GNU Grep tried to use PCRE for a while and it
turned out to be so problematic that it had to be removed.  As for
Texinfo, I don't see the need.  illusionoflife, if you're talking about
some other package, you should ask the developers of that package.

Best,
karl

texinfo-devel list

[Karl Berry]

Patrice told me there was a desire expressed at the GHM to see more of
our discussion about the new implementation.  I set up a new (public)
list texinfo-devel for it, so he and I will talk more there from now on.

karl

Re: texinfo not cross compiling

[Karl Berry]

I have tried various ways on my system which is a derivative of CLFS
and the ROCK linux project.

The only thing that is special about Texinfo and cross-compiling is the
need to build some of the tools with the native compiler.  Below is what
we have in configure.ac.  I've never attempted cross-compilation myself,
so don't have any good advice.  Sorry.

karl


# We need to run some of our own binaries, most notably makedoc, but as
# long as we have this process, we also use our own makeinfo and
# install-info.
#
# This means that if we are cross compiling, we have to configure the
# package twice: once with the native compiler (this is done in a
# subdirectory $native_tools), and once with the cross compiler.
# The former is invoked automatically here, with --host=$build.
# $native_tools is also added to SUBDIRS in the main Makefile.am,
# so that make compiles the native tools first.
#
if test $cross_compiling = no; then
  native_tools=
else
  native_tools=tools
  test -d $native_tools || mkdir $native_tools
  confdir=`(cd $srcdir;pwd)`
  # Make sure the secondary configure won't fail with
  # error: source directory already configured.
  rm -f config.status
  AC_MSG_NOTICE([[Doing configure of native tools (${build}).]])
  cd $native_tools || exit 1
  # Run secondary configure in alternate environment or
  # it gets the wrong CC etc.
  # env -i gives this build host configure a clean environment;
  # consequently, we have to re-initialize $PATH.
  env -i CC=$BUILD_CC AR=$BUILD_AR RANLIB=$BUILD_RANLIB \
  PATH=$PATH \
  tools_only=1 \
${confdir}/configure --build=${build} --host=${build} \
 --disable-rpath --disable-nls
  cd .. || exit 1
  AC_MSG_NOTICE([[Continuing with main configure (${host}).]])
fi

Re: Texinfo macros and m4

[Karl Berry]

Hi Ralf,

rw Any chance to get you to reconsider this decision?

I am not wedded to m4 specifically.  I just want something that works.

In short: I am well aware m4 has plenty of issues, but at least it is a
known quantity.  I've used it successfully with nontrivial TeX project
-- its use in documents is/would be far less complex, typically, than
autoconf m4 usage is.

To set the context:
1) very few Texinfo documents need macros at all.
2) of those that do need macros, @macro will continue to be available,
   and will suffice in many cases.
3) so we are talking about a tiny fraction of documents -- in reality,
   groff and lilypond are the only ones which come to mind.  In any
   case, people who work on such complex documents are not going to be
   afraid of delving into m4 peculiarities, nor find it easier to delve
   into Texinfo peculiarities.

I expect usage will grow over the years, as usage of @macro has.  Going
with m4 has the advantage that macro expansion is separated from
Texinfo.  Someone could conceivably put their own hacks into their own
personal m4, or invoke a completely different program -- it's none of
our business :).

that avoids issues from the present @macro): what makes this infeasible?

A new macro scheme could in theory be devised.  I thought of using m4
because, well, in principle, specifying a new macro feature is hard, as
we have seen with @macro.  We'll surely end up with the same quoting
issues, etc.  I don't want to repeat the same mistake of whitewashing
over the complexity.  Nor do I want to reinvent m4, which is what I
think it would eventually come to.

Also, in practice, specifying and implementing a new macro feature would
take a significant effort; time which could be better spent elsewhere.

Pointers appreciated.

It's been discussed on the mailing lists many times over the years, but
without any definitive resolution.  I have no urls at hand, sorry.

eliz I guess Karl hopes that Texinfo won't come anywhere near the
complex uses of m4 that autoconf does.

Well, I don't kid myself that Werner won't find complex uses for m4 :).
But the point is, at least a) it's not a moving target like @macro,
and b) debugging and fixing becomes completely separable from Texinfo.

In any case, I personally welcome your input wrt this issue.  TIA.

Fully agreed.

Most of the problems are on the TeX side

Personally, I would say that most of the problems are with the design :).

But it is true that there is a fundamental TeX problem regarding newline
processing, conflicting with the fact that newlines-as-delimiter is a
critical part of the Texinfo language.  I won't bother going into the
TeXnicalities (again), instead I will just reiterate Eli's statement:

In any case, the replacement macro-processor will have to be run by
texi2xxx and produce TeX output without any trace of macros.  

Exactly.  Whatever the new macro facility is, whether m4 or something
homegrown, it will *not* be processed by texinfo.tex.  That would be of
no value whatsoever.

There's a possibility to run the Texinfo input through makeinfo -E

There is (it was rms's idea), but as you say, it never worked well
enough in practice to be useful, unfortunately (or we wouldn't be having
this discussion).

Come to think about it, what Texinfo needs is very similar to cpp.

For the reasons you cite, at least, I don't think cpp is a serious
contender.

If there is any other general-purpose macro expansion program in the
same area as m4 and cpp, I'd like to know.  I can't think of any.

Best,
karl

Re: backslash no longer works in indices

[Karl Berry]

This is *really* disappointing!  

Yes, I know.  Sorry.

To be completely truthful, I also am continually disappointed ... by the
extremely extensive use of @macro -- going far, far, far, beyond
anything that was ever envisioned.  Brian hacked a @macro command into
makeinfo without (evidently) thinking at all about the implications for
texinfo.tex, or indeed the line-orientation of Texinfo syntax, for which
it is fundamentally unsuited.  Now we remain stuck with it all these
years later.  I am very sorry that I ever agreed to promulgate it.  If I
had had more willpower I would have refused in the first place and done
something more workable.

My general advice is to abandon your ever-expanding use of @macro and
change your Makefiles to preprocess through m4.

Maybe it makes sense to introduce a
  @backslash

Yes, I thought about that too.  It makes sense, but even that turned out
to be not exactly easy to get right in all contexts.

karl

Re: texi2pdf and image width

[Karl Berry]

Hi Reinhold,

However, it seems that an image needs to be smaller than the actual text 
width.

I don't think so.  I see a discrepancy only because of PDF/PostScript
points vs. TeX points.  Adobe points (big points = bp in TeX) are
72/inch.  TeX points are 72.27/inch (= pt in TeX, the traditional
printer's point ... recall that TeX predates PostScript :).

1bp = 1.00375pt.

Your image is 455bp wide = 456.70625pt.
The TeX \hsize = 455.24408pt.

The complaint is 
Overfull \hbox (1.46217pt too wide) in paragraph at lines 9--9

Subtracting, we see 456.70625 - 455.24408 = 1.46217.

QED.


In other words, make your images be 453.543288bp and they will fit.
Though if I were you, I would stick to 453.5 and sacrifice the extra
.04bp to avoid errors from possible rounding somewhere along the line.


To check in another way, I also ran with @loggingall and looked at the
resulting output.  The line in question is:

.\hbox(38.1425+0.0)x455.24408
..\pdfrefximage(38.1425+0.0)x456.70625
..\penalty 1
..\glue(\parfillskip) 0.0 plus 1.0fil
..\glue(\rightskip) 0.0

There is no glue there making the line overfull.  It's all due to the
image.

Best,
karl

Re: Difficulties with texi2dvi. Help, please!

[Karl Berry]

Hi Alan,

! Font \circle=lcircle10 not loadable: Metric (TFM) file not found.

Your distro should provide this font, which has been a standard part of
(La)TeX for a couple of decades.  I suggest you complain.  (Or you can
install the native TeX Live to avoid leaving yourself at the mercy of
your distro's decisions.)

Anyway, assuming you don't actually care about typesetting Texinfo's
@cartouche stuff, you download the TFM file from
http://mirror.ctan.org/fonts/latex/tfm/lcircle10.tfm

Best,
Karl

Texinfo macros and m4

[Karl Berry]

Werner and all,

Regarding macros in general.  I've been trying, and I have become
skeptical that there is any way to devise a new Texinfo macro command
that does not run afoul of many of the same issues. In particular, TeX
cannot precisely control behavior at newlines, and newline-delimited
commands are a big part of Texinfo.  Highly unfortunate.

Patrice and I haven't had a chance to discuss this in detail yet, but at
present it seems to me that the most robust plan would be to simply
provide an option to run the document through m4 before Texinfo.  That
would provide a completely defined solution, with far more features than
we would ever want to do in Texinfo, and should seemingly be
straightforward to do -- more straightforward than implementing another
macro command ourselves, at least.  And it could be implemented in
texi2dvi as well as makeinfo(/texi2any), which is a benefit.

Aside from a cmdline option, it also occurs to me that we could support
a magic string on the \input texinfo line that the processors could
detect, so that the need for m4 would be self-specified in the file.
E.g.,
\input texinfo   @c -*-texinfo-*- `m4needed'

(Since `...' is the standard m4 quoting.  Of course such a string can be
anything.)

Wdyt?

k

Re: backslash no longer works in indices

[Karl Berry]

there has been an backwards incompatible
change within texinfo.tex (to follow the documentation) 

I don't recall for sure, but I think it's far more likely that I wrote a
new item in the documentation to describe the behavior.  I can say for
sure that no one changed texinfo.tex to explicitly make this behavior
happen -- it is endemic to TeX macro processing and it never behaved any
other way since the @macro support in texinfo.tex was written.

If I could change it to make @funindex \q work, I would, but it's not
feasible.

the CVS version of makeinfo 

As I've said before, the C implementation of makeinfo is dead and rotting.
Ignore its existence in CVS.

Patrice, can you check how TP behaves with @funindex \\q?

Werner/Phil, I'm afraid there is no good answer for your document with
the software as it stands now.  Sorry.

k

Re: backslash no longer works in indices

[Karl Berry]

Regarding backslashes and @macro, here is a reduced example file
producing the same error.

\input texinfo
@setfilename backmac

@macro funindex {TEXT}
@findex \TEXT\
@end macro

@funindex \q
@printindex fn
@bye

It took me a while to remember, but this is actually documented not to
work.  In the Invoking Macros node of the manual:

In addition to the comma, characters that need to be quoted in macro
arguments are curly braces and backslash.

There is also a caveat:

Unfortunately, this has not been reliably implemented in TeX.  When
macros are used in the argument to other commands, for example, errors
or incorrect output (the `\' escape being included literally) are
likely to result.

Nevertheless, if I change the @funindex arg from \q to \\q, I get the
expected output, an index entry for \q.  So as long as the macro
invocations and definitions don't get even more complicated, I guess we
aren't running afoul of the caveat.  (This by way of warning. :)

Although we all wish that user-defined macros could have the same
behavior as normal commands, they don't and never will, in their current
form.

Best,
k

Re: cartouche collides with heading

[Karl Berry]

the first cartouche collides with the heading.

Does this patch (not yet committed) solve the problem in your real file?
(It fixes the test file, thanks much for the reduction.)

k

--- texinfo.tex.~1.347.~2011-07-08 08:58:52.0 -0700
+++ texinfo.tex 2011-08-14 17:23:58.0 -0700
@@ -6275,2 +6274,8 @@ end
   \let\nonarrowing = t%
+  %
+  % If this cartouche directly follows a sectioning command, we need the
+  % \parskip glue (backspaced over by default) or the cartouche can
+  % collide with the section heading.
+  \ifnum\lastpenalty1 \vskip\parskip \fi
+  %
   \vbox\bgroup

[bug #33704] feature request: --viewer=CMD option to texi2dvi

[Karl Berry]

Update of bug #33704 (project texinfo):

 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33704

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #33704] feature request: --viewer=CMD option to texi2dvi

[Karl Berry]

Follow-up Comment #1, bug #33704 (project texinfo):

Hi Hilmar,

I predict this is a slippery slope.  Although your patch as it stands is
clearly simple and noncontroversial, it is a foot in the door.  Next people
will want to specify arguments.  Then they'll want to have a configuration
file so the right viewer is automatically invoked.  Then they'll want to
connect to a running browser to see HTML.  Then ...

I base this on what I've seen happen with the texdoc program.  But its whole
purpose is to display documentation, so the complications have to be dealt
with.  The purpose of texi2dvi is to convert Texinfo to DVI(|PDF), not display
the result.  It is not a TeX environment.

I think I will pass on this one.  Thanks anyway.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33704

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: texi2dvi 4.13 makes invalid use of egrep

[Karl Berry]

-  echo $command_line_filename | $EGREP '^(/|[A-Za-z]:/)' 6 \
+  echo $command_line_filename | LC_ALL=C $EGREP '^(/|[A-Za-z]:/)' 6 \

Very well, I installed the change.  Thanks.

Re: [bug #33373] makeinfo adds a spurious period for @pxref before closing parenthesis

[Karl Berry]

Hi Sergey,

An *unbalanced* ')' 

So parsing for node names would then depend on whether parens in the
*text* are balanced?  I totally disagree :)!  The content of the text
should not influence command parsing.

 Finally, I think such a change would mean changing Info readers,

Yeah, and we don't want to do that for something this tiny.  That game
is not worth the candle.

The change I want to make to Info format is find some way of handling
arbitrary node names (including periods, commas, colons) in all
contexts.  Probably with ^@^H markers like @image.  Although this will
also break current Info readers, at least then they won't be broken on
existing documents, only new ones that use the new feature.

Best,
k

[bug #33374] local as function name is questionable sh syntax

[Karl Berry]

Update of bug #33374 (project texinfo):

 Open/Closed:Open = Closed 
  Status:None = Fixed  

___

Follow-up Comment #1:

Hi Jonathan -- thank you very much for the careful explanation and patch.  I
installed it.  

I also took this opportuntity to upload the current texi2dvi to ftp.gnu.org in
the probably-vain hope that distros will pick it up before the next full
release.  As far as I know, the present script should work fine with earlier
releases and has lots of bug fixes over what was in 4.13.

Thanks again.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33374

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #33373] makeinfo adds a spurious period for @pxref before closing parenthesis

[Karl Berry]

Hi again Hilmar,

http://savannah.gnu.org/bugs/?33373
Summary: makeinfo adds a spurious period for @pxref before
closing parenthesis

Thanks for the report, I don't think I agree that the period is
spurious.  It unambiguously indicates the end of the node name.  If it
wasn't there, we would also have to consider ) as marking the end of a
node name, that is, ) would not be allowed in node names.  That seems a
much worse outcome.  I see the reftex manual has node names with parens.

I see that the Texinfo manual (Node Line Requirements) currently says
that parens are not allowed in node names.  I think that's because of
cross-manual xrefs and menu entries that use parens to specify the Info
file name.  I don't want to add another case where parens are special.
I should probably relax the text in the manual.

Finally, I think such a change would mean changing Info readers, which
is a non-starter.


Patrice, do you have any thoughts on this?

Best,
Karl

[bug #33329] @noindent sometimes ignored

[Karl Berry]

Follow-up Comment #3, bug #33329 (project texinfo):

Hi Hilmar: as I said, the bug is not present in the Perl implementation. 
Therefore I did not fix in the C implementation (I have no intention of
continuing to redundantly maintain the C).  Therefore there is no patch. 
Sorry.

karl




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33329

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #33329] @noindent sometimes ignored

[Karl Berry]

Update of bug #33329 (project texinfo):

 Open/Closed:Open = Closed 
  Status:None = Fixed  

___

Follow-up Comment #1:

Hi Hilmar -- I confirm the bug in the makeinfo C implementation, but it does
not exist in the Perl implementations, so ... fixed for the next release :). 
The bug is not present in texinfo.tex.

Thanks,
karl



___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33329

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #33243] Patch to makeinfo error display

[Karl Berry]

Update of bug #33243 (project texinfo):

 Open/Closed:Open = Closed 
  Status:None = Wont Fix   

___

Follow-up Comment #1:

Thanks for the suggestion, but I'm not going to uglify messages for the sake
of unspecified IDEs (which should be smart enough to recognize error
messages, anyway).  The GNU coding standards say nothing about requiring the
word error:.

Best,
Karl


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33243

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: release?

[Karl Berry]

Hi Brian,

Hi, is it worth making a snapshot texinfo release 

I don't want to.  This problem would recur forever.

update when there is a new release (they don't seem to use the
texinfo.tex at ftp.gnu.org).

Then the distros should fix their processes.  What's on ftp.gnu.org is
the official release.  That's why it's there.

karl

Re: texinfo Makefile.am

[Karl Berry]

+dist-hook:
+   tar -C $(srcdir) -c -f - --exclude CVS tp | tar -C $(distdir) -x -f -

Why do we want tp in the dist at this point?  As far as I understand
from Patrice, it's not ready.  And when it is ready, it will be merged
into the configure stuff in the standard way.

And yes, there are lots and lots of tests for make distcheck to go
through.  I don't know if it's feasible or desirable to omit the
lengthiest ones.  I'm sure I will want to figure that out when we get to
the glorious day of actually making a new distribution :).

Thanks,
k

Re: [SPAM] Re: [bug #32975] install-info: `(null) --help'

[Karl Berry]

 texi2html (this will imply registering a separate translation domain at
 TP), 

As Patrice says, that doesn't sound right.  texi2html is not (will not
be) something separate from Texinfo.

I guess that the best extension would be .pm for init files, 

Sounds fine to me.

Thanks,
k

Re: spurious %s

[Karl Berry]

Hi Erwin,

In this case I can remove the %s from the po-file. Is it enough the
remove them from the most recent version (4.13)?

Sure.  Thanks!

karl

[bug #32975] install-info: `(null) --help'

[Karl Berry]

Follow-up Comment #9, bug #32975 (project texinfo):

I would prefer to continue to keep .po files in the repository.  My basic
guideline is that I don't want autogen.sh to have do anything over the
network, but just use local files.  In the past, I had such limited bandwidth
there was no realistic option; that's no longer the case, but I still find it
much more comprehensible to do it this way.  I know it is completely different
from the do-everything-possible-at-bootstrap-time approach of coreutils, etc. 
Just call me a stick in the mud.

Meanwhile, coordinator@tp hasn't answered me yet about the spurious %s's. 
(It's only been a day or two, though.) Sergey, are you involved with the TP as
a translator, by any chance?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?32975

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #32975] install-info: `(null) --help'

[Karl Berry]

[As a side note, using traditional email is much easier than this tracker.
Looks like I am stick in the mud too:))]

I couldn't agree more.  I hate typing replies in the sv trackers.

OK, I'll commit the changed ones, then ...
running `LC_ALL=ru_RU install-info' no longer causes coredump).

Well, yay :).

 Sergey, are you involved with the TP as a translator, by any chance? 
Yes, I am.

So maybe you could update the ru.po for texinfo in your capacity as
translator?  In your copious free time of course.

Thanks,
just-another-stick-karl

[bug #32975] install-info: `(null) --help'

[Karl Berry]

Follow-up Comment #7, bug #32975 (project texinfo):

Hi Sergey -- please do fix error() and fatal() (and anything else) to be
standard stdarg stuff, instead of the weird KR varargs-ish approach rms took
20 years ago.  fixing makevars would be great too, thanks.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?32975

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #32975] install-info: `(null) --help'

[Karl Berry]

Follow-up Comment #3, bug #32975 (project texinfo):

1. There have certainly been other changes to the .po since 2005.  But that
shouldn't stop us from removing the now-spurious %s.

2. But we maintainers are told in no uncertain terms that changes to
translation files should be made through the translation project, not just
willy-nilly hacked in.  At least we should try.  I'll write coordinator@tp.

3. I wonder if gettext can diagnose this situation.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?32975

___
  Message sent via/by Savannah
  http://savannah.gnu.org/