Loading ...
Sorry, an error occurred while loading the content.

Split editor vertically to show code comments on the right

Expand Messages
  • Michael Guyver
    I occasionally dabble with assembly code and one of the things which can take more time than writing the instructions is keeping your in-line comments (or
    Message 1 of 4 , Jul 31, 2012
    • 0 Attachment

      I occasionally dabble with assembly code and one of the things which can take more time than writing the instructions is keeping your in-line comments (or following line continuation) correctly formatted so that they don't wrap. My preference would be to keep assembly instructions on the left and associated comments on the right, rather than stacked. The problem which I'm trying to solve is having to spend time formatting multi-line comments myself and the trade-off between comprehensive comments and distance between lines of assembly.

      I recently had a thought about splitting the editor screen to implement this automatically. The novel bit is that long, single-line comments could wrap in the right-hand pane. This would, however, mean that they would need to flow faster than the code, so a system which vertically-centres the comment for the current line of assembly would be required, perhaps with a brighter colour than other comments.

      The nice thing is that the code would remain editable in other editors. The code would simply contain (possibly very long) single-line, end-of-line comments. It would work with almost all assembly languages since they generally have a single character (a # or ;) to start a comment. An enhancement would be to recognise escape characters for pseudo line-breaks, tabs, numbered lists or wiki text, etc.

      So to my question: how easy would it be to implement this in vim? I've searched through the archives and seen this (http://www.vim.org/scripts/script.php? script_id=4105) which appears to do something similar - but it's not quite similar enough.

      By way of full disclosure I should add that I'm a complete and utter, total vim-script noob, but I'm willing to hack away if I'm given some pointers on how it could be (reasonably easily) implemented.

      Regards

      Michael

      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Tony Mechelynck
      ... It is possible to have parallel windows scroll together, but usually at the same speed though the position can be adjusted. To keep them in sync one
      Message 2 of 4 , Aug 1, 2012
      • 0 Attachment
        On 31/07/12 14:10, Michael Guyver wrote:
        > I occasionally dabble with assembly code and one of the things which can
        > take more time than writing the instructions is keeping your in-line
        > comments (or following line continuation) correctly formatted so that
        > they don't wrap. My preference would be to keep assembly instructions on
        > the left and associated comments on the right, rather than stacked. The
        > problem which I'm trying to solve is having to spend time formatting
        > multi-line comments myself and the trade-off between comprehensive
        > comments and distance between lines of assembly.
        >
        > I recently had a thought about splitting the editor screen to implement
        > this automatically. The novel bit is that long, single-line comments
        > could wrap in the right-hand pane. This would, however, mean that they
        > would need to flow faster than the code, so a system which
        > vertically-centres the comment for the current line of assembly would be
        > required, perhaps with a brighter colour than other comments.
        >
        > The nice thing is that the code would remain editable in other editors.
        > The code would simply contain (possibly very long) single-line,
        > end-of-line comments. It would work with almost all assembly languages
        > since they generally have a single character (a # or ;) to start a
        > comment. An enhancement would be to recognise escape characters for
        > pseudo line-breaks, tabs, numbered lists or wiki text, etc.
        >
        > So to my question: how easy would it be to implement this in vim? I've
        > searched through the archives and seen this
        > (http://www.vim.org/scripts/script.php? script_id=4105) which appears to
        > do something similar - but it's not quite similar enough.
        >
        > By way of full disclosure I should add that I'm a complete and utter,
        > total vim-script noob, but I'm willing to hack away if I'm given some
        > pointers on how it could be (reasonably easily) implemented.
        >
        > Regards
        >
        > Michael

        It is possible to have parallel windows scroll together, but usually at
        the same "speed" though the position can be adjusted. To keep them in
        sync one would usually ":set nowrap" so that long lines would go
        offscreen rather than wrapping.
        See
        :help :vsplit
        :help 'scrollbind'
        :help 'wrap'

        IMHO it is usually a bad idea to use very long lines in programming
        code. If I were you I would break my comments on successive lines,
        either on full lines above the code they refer to, or on the right side
        with the left side blank if there is a particularly long comment
        extending over several (file) lines (or both): for example in some
        family of well-known languages (which aren't assembly though):

        /*
        * a long comment explaining what the function does, what arguments
        * it takes, what return values are possible, what the side effects
        * (if any) are, etc. etc. etc.
        */
        function foobarbaz(aArgument)
        {
        var foo = getSomething(aArgument); // and here we explain
        // what getSomething does
        // if it isn't obvious

        doSomethingElse(foo); // maybe some more comment
        andSomethingMore(foo); // and some other comment
        }


        Traditionally, code lines would be kept no longer than 80 characters.
        With the screens now available, that width can occasionally be exceeded,
        but within limits: I'd say that a 100-character line is probably OK, a
        1000-character line is not.


        Best regards,
        Tony.
        --
        Binary, adj.:
        Possessing the ability to have friends of both sexes.

        --
        You received this message from the "vim_use" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • michaelg
        Hi Tony, Thanks firstly for taking an interest in the question. I m aware that others may prefer different coding styles and there are varying views on line
        Message 3 of 4 , Aug 1, 2012
        • 0 Attachment
          Hi Tony,

          Thanks firstly for taking an interest in the question. I'm aware that others may prefer different coding styles and there are varying views on line lengths and wrapping. You'll note from my OP that I specifically don't want to spend so much time manually formatting long end-of-line comments - I want to write a plugin which will do it for me. So I'm grateful that you put such time as you did into your answer but I would argue that it misses the point of my original post.

          I have, since posting to this list, been in touch with someone on the subject of vim plugins and he suggested that the following approach might work:

          * Open an .asm file as a normal Vim buffer.
          * Press a key to enter "yourplugin mode". An autocommand could do this for you whenever opening a file automatically.
          * When you enter yourplugin mode, hide the actual .asm file buffer and create two new buffers, foo.asm__CODE and foo.asm__COMMENTS. These buffers will be entirely managed by your plugin.
          * Your plugin will parse foo.asm and fill in these two new buffers appropriately. Assembly is pretty simple so I think you're going to get lucky here and not have to worry about actually *parsing* the ASM -- a simple regex will probably get the job done.
          * When the user saves either of these buffers, both are "saved". The plugin parses their content and renders it back into foo.asm, and then saves that.

          This reflects a concern I had which was that simply concealing part of the line in each pane wasn't going to work. I would welcome any comment on the pros and cons of the above approach, or in fact, any other approach which could deliver this particular feature-request.

          Regards

          Michael

          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • Ben Fritz
          ... simply concealing part of the line in each pane WILL work, I think. You would need to use the conceal feature combined with the :ownsyntax feature to
          Message 4 of 4 , Aug 1, 2012
          • 0 Attachment
            On Wednesday, August 1, 2012 2:15:47 PM UTC-5, michaelg wrote:
            > Hi Tony,
            >
            > Thanks firstly for taking an interest in the question. I'm aware that others may prefer different coding styles and there are varying views on line lengths and wrapping. You'll note from my OP that I specifically don't want to spend so much time manually formatting long end-of-line comments - I want to write a plugin which will do it for me. So I'm grateful that you put such time as you did into your answer but I would argue that it misses the point of my original post.
            >
            > I have, since posting to this list, been in touch with someone on the subject of vim plugins and he suggested that the following approach might work:
            >
            > * Open an .asm file as a normal Vim buffer.
            > * Press a key to enter "yourplugin mode". An autocommand could do this for you whenever opening a file automatically.
            > * When you enter yourplugin mode, hide the actual .asm file buffer and create two new buffers, foo.asm__CODE and foo.asm__COMMENTS. These buffers will be entirely managed by your plugin.
            > * Your plugin will parse foo.asm and fill in these two new buffers appropriately. Assembly is pretty simple so I think you're going to get lucky here and not have to worry about actually *parsing* the ASM -- a simple regex will probably get the job done.
            > * When the user saves either of these buffers, both are "saved". The plugin parses their content and renders it back into foo.asm, and then saves that.
            >
            > This reflects a concern I had which was that simply concealing part of the line in each pane wasn't going to work. I would welcome any comment on the pros and cons of the above approach, or in fact, any other approach which could deliver this particular feature-request.
            >

            "simply concealing part of the line in each pane" WILL work, I think. You would need to use the "conceal" feature combined with the :ownsyntax feature to set up syntax highlighting for each window. Implementation would:

            1. set up two side-by-side windows on the buffer
            2. set scrollbind (and maybe cursorbind) on each window
            3. set a syntax on the first window which highlights the assembly and conceals the comments
            4. set a syntax on the second window which highlights the comments and conceals the code

            I think you'd want to set 'wrap' the same on each window, but I'm not sure how well that works with the conceal feature on scrollbound windows, so maybe you can't use soft wrapping very well.

            --
            You received this message from the "vim_use" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          Your message has been successfully submitted and would be delivered to recipients shortly.