Something that has always burned me up in programming, not just VB, is how inefficient it is to make multi-line comments. I'm not exactly a neat freak, but I do like comments to all be about the same length, around 80 characters including leading whitespace. But, to do this, I have to manually control how long the comments are. And the really frustrating part is when the change to only a few words requires an unreasonable amount of work.
I have found many questions on StackOverflow asking about multi-line commenting, but none to actually address this feature.
Wouldn't it make sense to have a commenting feature in VB, Eclipse, etc. to enter a a mini word processing mode mode that would low simple features like word wrap that would format the comment automatically? Is there one available that I'm just missing?
Or am I just being lazy? But, if it is a good idea, how can it be suggested to Microsoft, Eclipse.org, and others.
The only way to do multi-line comments in VB.NET is to do a lot of single line comments.
Really, the only option you have is the single tick (') in front of a line.
You can use Ctrl+K, Ctrl+C and Ctrl+K, Ctrl+U to comment or uncomment selected lines of text. In C# you can use /* ... */ to comment an entire block of code.
Look for more information on Custom Writing
Related
Prettier (VSCode) does a great job beautifying my code on save.
There is one feature that I consider important in code formatting which I can't find in Prettier.
I want to align chars =, :, =>, etc., in multiple lines like this VSCode plugin does.
The universal answer to questions like "How can I make Prettier format my code in such a way that ...?" is "You can't."
Prettier's purpose is to facilitate collaboration in projects and teams by taking care of code style, not to be a customizable code formatter that does whatever the user wants. In other words, the formatting it produces isn't really customizable, and this is intentional. Read more here. If you need that degree of control over formatting, you're likely not the target audience for Prettier.
This specific code style (alignment) that you want to have is considered diff-unfriendly (e.g., see here or here). Prettier's line breaking algorithm by itself has similar problems (e.g, adding one argument to a call might lead to a multiline diff if the line becomes too long), but they're inevitable, so Prettier's strategy is to compensate for that by avoiding other diff-unfriendly things.
You could always utilise the Alt key or Code Maid to clean up.
If you hold the Alt Key and drag down then you can highlight the spacing to either remove or align your code.
How can you work with the two sides of a bilingual/parallel text?
I know how to run diff and ediff on a text to spot little differences, but a bilingual text will have two completely different sides (expect for the paragraphs, number of chapters and other structural elements like notes). End of line and end of paragraph are certainly useful to mark the units of the two sides.
Is it possible to open two buffers, side by side, and tell what matches what?
This is a hard problem but I dug up an old blog post I read awhile ago that is relevant (and even mentions emacs for preprocessing):
https://languagefixation.wordpress.com/2011/02/09/how-to-create-parallel-texts-for-language-learning-part-1/
Especially check out part2
Beyond that, my suggestion is twofold:
1) Operate on small parts at a time (a chapter or less) and not an entire book
2) Utilize alignment tools available to generate metadata which emacs uses to just 'prettify' the buffer
As there's no existing solution (that I know of or can find), you'll have to get dirty with elisp and create a major or minor mode to colorize matching segments and/or navigate segments.
Quick Hack
However, I hacked some elisp together that takes preprocessed text and uses emacs concept of 'paragraph' and 'sentence' to colorize the buffer; it's a little verbose so I stuck it in a gist:
https://gist.github.com/terranpro/3175bb9f3ed00b3a145c
It's pretty ugly but should give you a start; just run it once in each of the text buffers. But be aware that you'll need to have the text already ready in terms of emacs' paragraphs and sentences (two spaces after a period!!). Hope it gives you a decent starting point.
I know I risk asking a speculative question, however, inspired by this recent question I wonder which editor does the best job of syntax highlighting Perl. Being well aware of the difficulties (impossibilities) of parsing Perl I know there will not be a perfect case. Still I wonder if there is a clear leader in faithful representation.
N.B. I use gedit and it works fine, but with known issues.
Komodo Edit does a good job and also scans your modules (including those installed via CPAN) and does well at generating autocomplete data for them.
I'm a loyal vim user and rarely encounter anything odd with the native syntax.vim, except for these cases (I'll edit in more if/when I find them; others please feel free also):
!!expression is better written !!!!expression (everything after two ! is rendered as a comment quoted string; four ! brings everything back to normal)
m## or s### renders everything after the # as a comment; I usually use {} as a delimiter when avoiding / for leaning toothpick syndrome
some edge cases for $hash{key} where key is not a simple alphanumeric string - although it's safer to enclose such key names in '' anyway so as to not have to look up the exact cases for when a bareword is treated as a key name
I haven't used it, but Padre should be good since it's written in Perl. IIRC It uses PPI for parsing
jEdit...with the tweaks that I have amassed over the years. It's got the most customizable syntax highlighting I've ever seen.
I use Emacs in CPerl mode. I think it does a terrific job, although similar to Ether's answer, it's not perfect. What's more, I usually use Htmlize to publish highlighted code to the web. It's kind of annoying to use fancier forums like this one that do their own syntax highlighting, since it's not really any easier and the results aren't as good.
I know different methods of introducing multi-line comments in Perl. But I want to know why it doesn't have something simpler multi-line comment feature such /* comment */, which would make it much easier.
I currently follow http://www.perlmonks.org/?node_id=560985 to achieve multi-line comments. Are there any plans to include this feature in Perl anytime soon?
C-style comments come with a variety of difficult problems, including the inability to comment-out comments. Additionally, convenient syntax for one-line encourages concise writing, which makes your code easier to read. The absence of 10-line "Author: ... Input: ... Output: ... Favorite Color: ..." blocks that you see from time to time in C and C++ is another benefit.
Multi-line comments encourage long writing that is better expressed more concisely or as documentation, so this is what Perl encourages with its # and =pod operators (respectively).
Finally, if you are having trouble with Perl's style of commenting, you should configure your editor to edit programs, not text. In Emacs, if you start writing something like # this is a comment that is getting longer and longer and longer and oh my goodness we are out of space on this line what to do now and type M-q, Emacs will automatically insert the # at the beginning of each line that it creates.
If you just want to comment-out a block of code, then you need look no further than M-x comment-region and M-x uncomment-region, which will comment out the region in pretty-much any language; including Perl.
Don't stress about the syntax of comments; that's the computer's job!
There was a discussion regarding this on the perl6-language#perl.org mailing list. Although in the end the discussion was inconclusive, the summary posted here makes for interesting reading.
As with any multiline comment structure, there will be a "open" and a "close" comment condition, and that leads to problems with nested comments.
for example, C uses /* as the open and */ as the close. How does a multiline comment system handle comments within comments? C will fail if you try to comment a block that is already commented.
Note that line-based comments (e.g. c++ // comments) do not suffer this problem.
Simplicity is in the eye of the beholder. That said, there are already a number of ways to do multi-line comments. First, void string literals:
q{This text won't do anything.
Neither will this.};
This has the unfortunate side effect of triggering a warning:
Useless use of a constant in void context at - line 4.
Another option is using a heredoc in void context - for some reason this doesn't cause a warning:
<<ENDCOMMENT;
Foo comment bar.
ENDCOMMENT
As you can see, the problem isn't the lack of syntax as such (python doc comments look vaugely similar to the q{} method in fact) - it's more just that the community of perl programmers has settled on line comments using # and POD. Using a different method at this point will just confuse people who have to read your code later.
I'm using C# and VB.NET.
I often (every days...) add comments to existing source files. When I check-in these files, I would like to have my merge tool to ignore any changes made to comments - I just want to be sure that I did not change the code.
I use WinMerge and Team Foundation Control Server (yes, no chance : Subversion was not an option when I accepted this job :o). Both of them can ignore white spaces but cannot ignore comments. Result : I have to carefully look at all the changes that I have made to each file before checking them in. And this is pretty cumbersome.
(Well, since most of my co-workers do not comment at all -- hey, they use pretty long namespace/class/methods/property/type/constant names that tell it all, guys ! -- it's a lot of work.)
Any suggestions ?
All the best,
Sylvain.
BeyondCompare has a filter for ignoring "unimportant" changes and comments belong to that category by default.
Compare++ has an option "Ignore comment changes" and "Ignore pure formatted changes" which should honor your request.
You said you used WinMerge - well it has the ability to filter out comments.
However it only works for comments that are on a separate line, so for example:
int i; // comment
will be detected as different from
int i;
It sounds like you're using commenting as a tool to understand the code as you work with it. That's an interesting idea, the equivalent of highlighting a book or taking notes. But you need to make sure you strip out all these transient comments before working with others.
Before comparing or promoting, run your source files through a filter program that strips the comment. This could be a one-liner perl script.
To make it easier, use a distinctive pattern for your non-permanent comments, to make them easier to filter out (and to distinguish between these transient comments, and comments you really want to leave in the source). E.g. if you were writing in C++, always comment using
//Sylvain: this is my comment here.
or some other pattern that is even easier to grep for.
If the content of the comments are not something you care about, and do not matter, why not delete them?
If well documented code that is readable and understandable is part of what you create, why not review changes to that meta-data?
Adding comment to your code is smell that your code is hard to read, code should be self describing, like someone has said that , good code is like good joke, it does not need to be explained. It is better to change your variable name, put section of your code into a subroutine. Re factoring is better than commenting. Even you find a tool to solve you commenting problem, it does not solve the real problem that is make you code easy to understand.