Re: [bug #43126] Macros defined through @include make a spurious space before @end macro
Gavin Smith a écrit : 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. Dear Gavin et alii, I think that you have put the finger on it: it does not have to do with @include but with line endings. I did the following experiment: * both bug_texinfo.texi and bug_texinfo-macros.texi in Unix file endings = no problem at all for any of the two macros. * both bug_texinfo.texi and bug_texinfo-macros.texi in DOS file endings = problem exists for both macros, that which is in the main file, and that which is in the included file. Conclusion: texi2any macro parser has a problem with handling line endings when it removes the last line end before @end macro. I suspect that if the coding is consistent the same problem exists with removal of the first line ending after @macro. VBR, Vincent.
Re: [bug #43126] Macros defined through @include make a spurious space before @end macro
Vincent Belaïche a écrit : Gavin Smith a écrit : On Mon, Sep 1, 2014 at 7:15 PM, Vincent Belaïche [...] Dear Gavin et alii, I think that you have put the finger on it: it does not have to do with @include but with line endings. I did the following experiment: * both bug_texinfo.texi and bug_texinfo-macros.texi in Unix file endings = no problem at all for any of the two macros. * both bug_texinfo.texi and bug_texinfo-macros.texi in DOS file endings = problem exists for both macros, that which is in the main file, and that which is in the included file. Conclusion: texi2any macro parser has a problem with handling line endings when it removes the last line end before @end macro. I suspect that if the coding is consistent the same problem exists with removal of the first line ending after @macro. VBR, Vincent. Just as a few side comments: * it is probably worth checking whether @rmacro has the same issue * probably the perl script uses some hard-coded \n, rather than some `endofline' property of the file from which the macro was read. * it would be good if it is not mandatory that all files used for a single document have the same format, because in any collaborative project there may be guies with DOS and others with Unix working together (and even the same guy with two different machine, being DOS in the morning, and unix in the afternoon). There is also the following issue that when a doc is under version control, some of the files may be set as binary in the repo for some reason, and others not, so people say on Unix will get consistent line ending, and people say on DOS won't get that because the non-binary files won't have end-of-line conversion by the version control, while others will have it. I do not argue that it is desirable that users are consistent, just suggesting that texi2any could do that at a moderate cost, and that would make life easier for everybody. The only rule should be that *within a same file* you have to be consistent. VBR, Vincent. Vincent.
Re: [bug #43126] Macros defined through @include make a spurious space before @end macro
* it would be good if it is not mandatory that all files used for a single document have the same format, I agree in principle. The only rule should be that *within a same file* you have to be consistent. Maybe not even that. I regularly see files with mixed line endings. It would not seem bad to me to globally remove all CR chars that occur before NL chars before doing anything else with a given input file. In any case, I haven't looked at the code at all for this issue yet. When I can, or if Patrice has time sooner, so much the better ... k
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Just to clarify that I was suggesting three completely different things: One first thing was better support of internationalization for *Manuals*, in that context I was speaking about node name translation for presentation to user (there should remain a node true name that should remain the same whatever the translation. Ok, sorry if I misunderstood the rationale for the menu entries. One second thing was internationalisation for *DocStrings*, in that context I was suggesting that docstring could contain some link to some manual variable or function description, so switching the Help language based on configured locale would just mean switching to the correct manual translation. BTW, replacing docstring by jump to manual is basically what calc already does, with its h f and h k commands. However it does it in a language dependent way because it does not use the position within the node (call it PWTN) in the command/variable index --- maybe the reason for such an implementation is that when this feature was made available in calc,, info was not supporting so well PWTN --- but instead uses only the node pointer, and then seaches some string in the node to find the position. One third thing is that even plain docstring format itself is language dependant. Only for that third item I was suggesting that a better format for docstrings would be some sort of texinfo-light (I think that texinfmt.el already support some lighter texinfo and could be some starting point for adding such a feature). So in a nutshell the evolved docstring would contain some header indicating - is that legacy format - is that texinfo-light format - do we have a pointer to some manual to be used instead when available and sought for at the configured locale location --- note that the pointer needs only to indentify the manual itself, the variable or function name is already known what you do C-h f or C-h k. Vincent. Date: Mon, 1 Sep 2014 21:53:55 + From: k...@freefriends.org To: vincent@hotmail.fr; 18...@debbugs.gnu.org; bug-texinfo@gnu.org Subject: 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
