[erlang-questions] Speaking of comments

[Edmond Begumisa]

On Tue, 14 Dec 2010 01:56:24 +1100, Raimo Niskanen  
<raimo+erlang-questions@REDACTED> wrote:

> On Mon, Dec 13, 2010 at 02:04:36PM +0530, Banibrata Dutta wrote:
>> On Wed, Dec 8, 2010 at 8:45 PM, Edmond Begumisa  
>> <ebegumisa@REDACTED
>> > wrote:
>>
>> > I've thought -- now and then, in the back of my mind -- about removing
>> > comments from actual source all-together (for all languages) and  
>> instead,
>> > putting them in companion files that the editor lines up  
>> side-by-side. More
>> > like annotating than just traditional commenting.
>> >
>> >
>> It's an interesting thought, as it removes clutter -- especially so for  
>> a
>> programmer who is already well versed with the code.
>> Most modern editors have features allowing the view to show all comments
>> collapsed, expanded, and some even done so selectively.
>>
>>
>> > Has this sort of thing been done before? Is there a particular editor  
>> that
>> > can give me this out of the box? (I admittedly haven't explored a  
>> large
>> > number of editors)
>> >
>> > Using Erlang as an example, I've secretly wanted something like...
>> >
>> > foo.erl
>> > foo.cts
>> >
>
> Many moons ago at Ericsson there was a hiearchical editor named Exco  
> used.
> Its concept was that you write your code as a specification where each
> heading could be expanded into sub-headings, and at the leaf level
> was the source code. Then you pre-processed your Exco document to
> extract the leaf level, to compile.
>

Sounds painful. But then, I've never been one for specs (I've never worked  
on humongous projects.)

> While editing you expanded/compressed headlines (highlited)
> with simple keystrokes.
>
> This was in the 24x80 VAX and early Unix days, so side-by-side
> panels would have been futile, and color coding was green only.
>
> It would nevertheless be another possibility for your editor suggestion.
> Preprocess the readable document to get the source code.

Ahh, is see. Work backwards. Extract the source from the markup rather  
than the markup from the source. Interesting approach.

It might make source-control a bit tricky though since most tools interact  
at the file level (you normally want to know what changes were made to  
each source file.) Hmmmm... possibly one could commit only the result of  
the preprocessing and not the original mashed documents.

> You could even
> use a specialized comment style in .erl files to get a .erl file that
> displays fine in your special editor yet is readable by itself.
>

Yes, this is an option. Why do I suspect it might be easier for editors to  
implement this using two different files? Especially if it's a feature  
being tacked on-top of existing code.

For example, if a line is added in the middle of a function, you want a  
corresponding change to the annotation. Also, for graphical editors, the  
annotation/comment file could be loaded separately into a separate widget  
with different features (e.g For Komodo Edit, Mozilla's html editor widget  
could come in handy here while the actual source would remain in the  
scintilla source-editor widget.)

- Edmond -

>>
>> Challenge would be to ensure 100% (fail-proof) lock-step update of the  
>> .erl
>> and .cts files in VCS... ideally triggered from a single command.
>>
>>
>> > Then an editor that could give me two panes while keeping the two  
>> files in
>> > sync...
>> >
>> > foo ->  | This function does...
>> >  blah  |   This part is buggy...
>> >  balh  |
>> >
>> > Also, in the right pane, I've wanted nestable trees with flexible  
>> levels of
>> > detail. Heck, why not even rich text? "FIX ME" in bold red. Take it  
>> further:
>> > login-name awareness, source-control/bug-tracker integration (this
>> > programmer said this, that programmer said that.)
>> >
>> > It seems a shame that in 2010, it's still so limiting what we can do  
>> with
>> > comments in our source code!
>> >
>> > - Edmond -
>> >
>> > On Thu, 09 Dec 2010 01:39:42 +1100, David Mercer <dmercer@REDACTED>
>> > wrote:
>> >
>> >  On Tuesday, December 07, 2010, Richard O'Keefe wrote:
>> >>
>> >>  Nesting comments are one of those clever ideas
>> >>> that turn out to be really dumb, because they don't actually work.
>> >>>
>> >>
>> >> I'll bite, mainly because I've sometimes thought nesting comments  
>> would be
>> >> helpful, for instance, when commenting out large blocks of code, but  
>> it is
>> >> rare that I get to work with a language that supports them.  Since  
>> you're
>> >> almost always right about such things, why do you say that they don't
>> >> actually work?
>> >>
>> >> Cheers,
>> >>
>> >> David
>> >>
>> >>
>> >>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/