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
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
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
@code{þ} þ
to see what I mean. Below a possible fix.
Thanks, looks fine to me. Installed.
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
- 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
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
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
* 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
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
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.
It's the classic bug of using a va_list after being destroyed.
Thanks much Andreas, I installed the fix.
#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
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
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
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
In current CVS, file texinfo.txi, node `Inserting a Backslash': The
example is wrong, describing @comma.
Oops :).
Thanks.
- \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
-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
If you want to change dir file interpretation, IMHO the most important
people to talk to are the Emacs maintainers.
k
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
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
A diff against the latest CVS version of the info directory is
attached.
I applied it. Thanks.
k
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
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
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
@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
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
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
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.
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
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
* 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
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
@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
Update of bug #35793 (project texinfo):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
(accepted, replying on list)
___
Reply
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
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
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
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
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
+ 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
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
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
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
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
after the @code{@@end
titlepage} (@pxref{titlepage}) and before any sectioning command.
Will do, thanks.
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
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
___
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 :).
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
- 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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
Update of bug #35184 (project texinfo):
Open/Closed:Open = Closed
Status: In Progress = Fixed
___
Follow-up Comment #2:
confirmed fixed,
For html, it is only
('.png', '.jpg')
Surely jpeg and gif should be there too?
Thanks,
k
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
Update of bug #33041 (project texinfo):
Open/Closed:Open = Closed
Status:None = Invalid
___
Follow-up Comment #4:
The general rule is
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
- 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
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
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
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
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
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)
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
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
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
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
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
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
Update of bug #33704 (project texinfo):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?33704
___
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
- 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.
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
Update of bug #33374 (project texinfo):
Open/Closed:Open = Closed
Status:None = Fixed
___
Follow-up Comment #1:
Hi Jonathan -- thank
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
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
Update of bug #33329 (project texinfo):
Open/Closed:Open = Closed
Status:None = Fixed
___
Follow-up Comment #1:
Hi Hilmar -- I
Update of bug #33243 (project texinfo):
Open/Closed:Open = Closed
Status:None = Wont Fix
___
Follow-up Comment #1:
Thanks for the
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
+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
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
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
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
[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
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.
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
401 - 500 of 1358 matches
Mail list logo
