[bug #43122] texi2dvi does not compile enough times to get toc
URL: http://savannah.gnu.org/bugs/?43122 Summary: texi2dvi does not compile enough times to get toc Project: texinfo - GNU documentation system Submitted by: vincentb1 Submitted on: lun. 01 sept. 2014 09:36:59 GMT Category: None Release: Priority: 5 - Normal Severity: 3 - Normal Item Group: None Privacy: Public Open/Closed: Open Assigned to: None Discussion Lock: Any Status: None ___ Details: == Introduction == Hello Karl, Gavin, Eli et ali, Sorry to be again bothering --- I hope that you're not yet fed up with me. == Description of attachments == Please compare attached log0.txt and log1.txt Both are compiling the same metafont-for-beginners-fr.texi document, but log0.txt is using latexmk, while log1.txt is using texi2pdf. Command line is on the 3rd line of each log file and all the other files are in metafont-for-beginners-src-texinfo.zip., so you can try to reproduce the problem. == Description of problem == Now the problem is that tex2pdf does not get the table of content made. I suspect that texi2pdf is scanning for the log to find some specific string whether or not trigger recompilation, and is bothered by the log being in UTF-8 in the case of French (because yes, we French, among many other people, need some accents on letters ;-P ). I think so because issue is specific to metafont-for-beginners-fr.texi: with the original metafont-for-beginners.texi document in English there is no such problem. VBR, Vincent. ___ File Attachments: --- Date: lun. 01 sept. 2014 09:36:59 GMT Name: metafont-for-beginners-src-texinfo.zip Size: 61 ko By: vincentb1 http://savannah.gnu.org/bugs/download.php?file_id=32006 --- Date: lun. 01 sept. 2014 09:36:59 GMT Name: log0.txt Size: 5 ko By: vincentb1 http://savannah.gnu.org/bugs/download.php?file_id=32007 --- Date: lun. 01 sept. 2014 09:36:59 GMT Name: log1.txt Size: 14 ko By: vincentb1 http://savannah.gnu.org/bugs/download.php?file_id=32008 ___ Reply to this item at: http://savannah.gnu.org/bugs/?43122 ___ Message posté via/par Savannah http://savannah.gnu.org/
[bug #43126] Macros defined through @include make a spurious space before @end macro
URL: http://savannah.gnu.org/bugs/?43126 Summary: Macros defined through @include make a spurious space before @end macro Project: texinfo - GNU documentation system Submitted by: vincentb1 Submitted on: lun. 01 sept. 2014 18:15:31 GMT Category: makeinfo Release: Priority: 5 - Normal Severity: 3 - Normal Item Group: None Privacy: Public Open/Closed: Open Assigned to: None Discussion Lock: Any Status: None ___ Details: One more bug today... ;-) This happens with texi2any, when compiling to html. I have attached an example. There are two macros with identical definition (only naming changed in order to avoid erroneous duplication of macro definition). One of the macro is defined in the main file, while the other one is defined through an @include. What I can see, is that when going through the @include the last carriage return before @end macro is not removed, which is erroneous. See Texinfo manual node (texinfo) Defining Macros One can read there: The newline characters after the '@macro' line and before the '@end macro' line are ignored, that is, not included in the macro body. ___ File Attachments: --- Date: lun. 01 sept. 2014 18:15:31 GMT Name: bug_texinfo.tgz Size: 2 ko By: vincentb1 http://savannah.gnu.org/bugs/download.php?file_id=32013 ___ Reply to this item at: http://savannah.gnu.org/bugs/?43126 ___ Message posté via/par Savannah http://savannah.gnu.org/
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Answers inserted below... Date: Sun, 31 Aug 2014 23:37:06 +0100 Subject: Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation' From: gavinsmith0...@gmail.com To: vincent@hotmail.fr CC: 18...@debbugs.gnu.org; bug-texinfo@gnu.org (adding bug-texinfo) On Fri, Aug 22, 2014 at 11:04 PM, Vincent Belaïche vincent@hotmail.fr wrote: Finally, as an EMACS user, it would be more important to me * if docstring could be written in a sort of texinfo-light format (when you create a package or anything you first do docstring, and then you port this to a manual (so having some texinfo-light format from the beginning would reduce the effort) It might be worth asking on emacs-devel about this to see if anyone wants to implement it or has ideas about how it could work. Concerning the info format, what sort of problem I also see --- still in relation to i18n --- is that one should be able to use exactly the same node names whatever the language, so that the same link can be used, and when the manual is compiled to multifile HTML, you have the same file tree whatever the language. Seems like a good idea to me. Would help for links between manuals and for finding pages in other languages. Are there any guidelines about how to translate Texinfo documents? Currently the usual practice is that a translated document is just another document with some -xx ending in the base name (where xx refers to the language, e.g. fr for French). In my opinion an alternative method would be that translated document should rather bare exactly the same name but just be in a language specific directory named xx, with some fall backs to another language (meaning ../oo, where oo refers to the other language) when manual does not exists. I think that the alternative method is closer to what people usually do for Web sites, in which each language is its own tree replica (file/directory names are same, but only file contents differ). What I am meaning is that using the same node names should not imply that when the final user is reading a manual written in non-English he/she has to see the real node names unless he/she copy to clipboard the node address, one should be able to specify along with the node name a node local name to be presented by the viewer Having translated node names isn't as important because there would be translated headers in the contents of files/nodes saying what section we're in. The main use would be the status bar in a browser giving the current node, and pointers or references to other nodes. I understand it is not ideal to read a cross-reference in another language. Maybe anchors with translated node names could be used instead? That would work for everything (cross-references, pointers) apart from the node name that is displayed in a status bar. Maybe makeinfo would have to be modified to recognize that a menu in a node using anchor names is referring to the child nodes properly. Menus are precisely the only place where you don't need any change in Texinfo, as you can do: * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. What I was meaning is that the viewer should be configurable to show either the node path with translated names or true names. In the case of nodes that are not referred by any menu, like the top node, or node accessed only by cross reference, there aren't currently any provision in Texinfo to povide a node name translation. That could be some command @localenodename to give that translation inside the node. Vincent.
Re: [bug #43126] Macros defined through @include make a spurious space before @end macro
On Mon, Sep 1, 2014 at 7:15 PM, Vincent Belaïche invalid.nore...@gnu.org wrote: I have attached an example. There are two macros with identical definition (only naming changed in order to avoid erroneous duplication of macro definition). One of the macro is defined in the main file, while the other one is defined through an @include. What I can see, is that when going through the @include the last carriage return before @end macro is not removed, which is erroneous. See Texinfo manual node I don't know much about what is happening here, but one thing I did notice is that the include file bug_texinfo-macros.texi uses MS-DOS-style line endings (\r\n), while the main file bug_texinfo.texi doesn't. Some of these carriage returns appear in bug_texinfo.html, e.g. ol li UNBREAK^MABLE^M^M /lili UNBREAKABLE /li/ol where ^M is a carriage return character.
Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
On Mon, Sep 1, 2014 at 8:40 PM, Vincent Belaïche vincent@hotmail.fr wrote: Having translated node names isn't as important because there would be translated headers in the contents of files/nodes saying what section we're in. The main use would be the status bar in a browser giving the current node, and pointers or references to other nodes. I understand it is not ideal to read a cross-reference in another language. Maybe anchors with translated node names could be used instead? That would work for everything (cross-references, pointers) apart from the node name that is displayed in a status bar. Maybe makeinfo would have to be modified to recognize that a menu in a node using anchor names is referring to the child nodes properly. Menus are precisely the only place where you don't need any change in Texinfo, as you can do: * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. I can imagine cases where a menu label is something other than the node name, for example if the document author wants to give a more extended description of what the node is about. Anyway, names of targets are not usually hidden (in the standalone Info browser, at least). What I was meaning is that the viewer should be configurable to show either the node path with translated names or true names. In the case of nodes that are not referred by any menu, like the top node, or node accessed only by cross reference, there aren't currently any provision in Texinfo to povide a node name translation. That could be some command @localenodename to give that translation inside the node. Something like this could be done by treating an anchor as a synonym for a node if it refers to byte 0 of the node. If someone selected or followed a reference to such an anchor, its name could be displayed instead of the node. There would still be the problem of how makeinfo would do implicit pointer creation with the right node names.
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
use exactly the same node names whatever the language, so that the same link can be used, and when the manual is compiled to multifile HTML, you have the same file tree whatever the language. Seems Currently the usual practice is that a translated document is just another document with some -xx ending in the base name (where xx refers to the language, e.g. fr for French). True. In my opinion an alternative method would be that translated document should rather bare exactly the same name but just be in a language specific directory named xx, with some fall backs to another language No question that that is a well-known alternative approach. * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. As Gavin says, that is not correct. Both parts of the node name are intended to be shown. The existing use of this feature is to make short menu item abbreviations, e.g., for the sake of completion or just ease of reading. For example, in the Texinfo manual, the HTML Cross References section has a @menu like this: @menu * Link Basics: HTML Xref Link Basics. * Node Expansion:HTML Xref Node Name Expansion. .. Whatever such a hypothetical texinfo-light needs to do, fine. We should think about that separately. It need not affect what Texinfo does. Seems like two very different cases to me. Let's not try to shoehorn existing Texinfo features into things that are far outside their intent and practice. A discussion of such a texinfo-light (not a name I would advocate, either) should presumably take place on emacs-devel, not in a debian bug for Texinfo. k
[bug #43122] texi2dvi does not compile enough times to get toc
Follow-up Comment #1, bug #43122 (project texinfo): thanks for the report, vincent. i'll look into it as soon as i have a chance. (FYI, texi2dvi uses cmp to determine whether the various generated files have changed, in the xref_files_changed fn. But there is a lot of fragility in the whole process, so I'm not surprised it fails sometimes.) ___ Reply to this item at: http://savannah.gnu.org/bugs/?43122 ___ Message sent via/by Savannah http://savannah.gnu.org/
