Split editor vertically to show code comments on the right

46 views
Skip to first unread message

Michael Guyver

unread,
Jul 31, 2012, 8:10:49 AM7/31/12
to v...@vim.org

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

Tony Mechelynck

unread,
Aug 1, 2012, 11:40:04 AM8/1/12
to vim...@googlegroups.com, Michael Guyver, v...@vim.org
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.

michaelg

unread,
Aug 1, 2012, 3:15:47 PM8/1/12
to vim...@googlegroups.com, Michael Guyver, v...@vim.org
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

Ben Fritz

unread,
Aug 1, 2012, 5:03:34 PM8/1/12
to vim...@googlegroups.com, Michael Guyver, v...@vim.org
"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.
Reply all
Reply to author
Forward
0 new messages