bugGNU Octave - Bugs: bug #33208, Texinfo requires no spaces in the...

 
 

bug #33208: Texinfo requires no spaces in the beginning of lines

Submitted by:  Søren Hauberg <hauberg>
Submitted on:  Mon 02 May 2011 03:29:28 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: Wont FixAssigned to: None
Originator Name: Søren HaubergOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 29 Jul 2013 06:50:29 PM UTC, comment #7:

Agreed, until this actually becomes a problem we can close it.

Rik <rik5>
Project Administrator
Mon 29 Jul 2013 05:14:57 PM UTC, comment #6:

It's a couple years later and all Octave docstrings are still working with the latest versions of Texinfo 5.x. If compatibility with new Texinfo was all this bug report was about, I think it's moot and can be closed until there is a concrete problem.

Mike Miller <mtmiller>
Project Administrator
Sat 07 May 2011 02:49:36 PM UTC, comment #5:

We only have to worry about different line endings (CR, CRLF, LF) because we try to be compatible with Matlab which allows files with the incorrect line endings (for example, someone transfers a file with CRLF to a Unixy system but doesn't convert the line endings as they should have). I would much prefer to just tell people that they should translate their files as that would simplify things for us, but...

In any case, the get_help_text function ultimately works by calling the parser to read the file, and it already should be doing the CR or CRLF -> LF translation, so you should be OK looking only fr LF. You can test this assumption by creating files that use CR only or CRLF in addition to LF on a Unixy system, or LF or CR only on a Windowsy system, or CRLF or LF only on an Fruity (specifically Apple) system. All should give you a doc string with LF for the line ending. Internally, that's all Octave should have to work with.

John W. Eaton <jwe>
Project Administrator
Sat 07 May 2011 09:12:32 AM UTC, comment #4:

The attached patch works for me, but I doubt that it is the best way to fix the issue:

1. It searches for "\n " -- does that also work on systems where a line break also needs a carriage return?

2. The repeatedly shortens the help text string. Is this too inefficient or does that not really matter (this code is not performance sensitive).

Søren

(file #23364)

Søren Hauberg <hauberg>
Sat 07 May 2011 08:49:07 AM UTC, comment #3:

The issue does not seem to be fixed. Try running

get_help_text ("help")

then you'll see the help text for the "help" function. As you can see the first character of all lines except the first is a space.

Søren Hauberg <hauberg>
Fri 06 May 2011 04:55:14 PM UTC, comment #2:

Can this issue be closed? gethelp.cc is stripping the leading space which means Octave does produce Texinfo-compliant code.

Rik <rik5>
Project Administrator
Mon 02 May 2011 03:45:09 PM UTC, comment #1:

When Octave generates the scripts/DOCSTRINGS file, it strips out leading comment characters and the first space (if any). See the scripts/gethelp.cc program.

I don't think you want to strip out all leading spaces because doing that will screw up any by-hand formatting in @verbatim blocks. It seems simpler to me to impose a one-space-is-discarded rule on docstring authors rather than trying to make the code too complex to solve a problem that can just be avoided by following some fairly simple rules.

John W. Eaton <jwe>
Project Administrator
Mon 02 May 2011 03:29:28 PM UTC, original submission:

Hi

While working on improving syntax highlighting for Gedit, Carnë Draug noticed that Texinfo actually requires that all commands start at the beginning of a line. The Octave help system does not match this requirement.

The Octave help system works by stripping the comment signs (# or %) from the block containing the help text and passing the result to the makeinfo program. Most Texinfo help texts look something like this:

When the ##'s are removed there is still a space left in the beginning of each line. Currently, this is working just fine as the makeinfo accepts the extra space most of the time. However, the next version of makeinfo will either give an error or a warning if such a space exists. Therefore, I think we should fix the issue before it hits us.

I am, however, unsure about the solution. Should we simply change 'get_help_text' to strip all spaces in the beginning of lines? Or perhaps only the first space? Or perhaps something smarter?

Søren

Søren Hauberg <hauberg>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #23364:  get_help_text.patch added by hauberg (501B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by carandraug
  • -unavailable- added by hauberg (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 29 Jul 2013 06:50:29 PM UTCrik5StatusNeed Info=>Wont Fix
      Open/ClosedOpen=>Closed
    Sat 07 May 2011 09:12:32 AM UTChaubergAttached File-=>Added get_help_text.patch, #23364
    Fri 06 May 2011 04:55:14 PM UTCrik5StatusNone=>Need Info
    Mon 02 May 2011 03:35:33 PM UTCcarandraugCarbon-Copy-=>Added carandraug

    Back to the top


    Powered by Savane 3.1-cleanup1