I've been using BBEdit (and Textwrangler before) for quite some time, but one thing bugs me - the uncommenting block option seems to eat one space each time you use it. This makes it useless since it breaks the indentation.
Also I don't get the difference between "Un/Comment Block" and "Un/Comment Lines", they seem to be doing the same thing, with this weird behaviour as well.
You can easily check this by hitting multiple times Cmd+/, on a block of indented code, e.g:
nodes:
keypair:
type: cloudify.openstack.nodes.KeyPair
properties:
use_external_resource: true
resource_id: { get_input: key_pair_name }
private_key_path: { get_input: private_key_path }
Eventually whole block will get straightened out. Why is that happening?
I went through every possible option related to indentation but couldn't eliminate it.
I'm using BBEdit v12.6.
EDIT: Just noticed this happens for YAML code file (.yaml), but not for Python, for example.
For languages which don't support a block-comment syntax (e.g. /*...*/ vs // in C), "Un/Comment Block" and "Un/Comment Lines" are functionally the same.
There are some ...curiosities involving how spaces are managed after line comment delimiters. If the declared delimiter for the language has trailing spaces, BBEdit tries to figure out what you wanted to do. Some languages care and some don't; and sometimes the outcome has relevance to the language's syntax. It's an area for future study. :-)
Related
I have a .html file that is working perfectly fine but for some reason Sublime 3 decides that it has invalid code, check the image below:
Any idea why that's happening and how to fix it without having to modify the code?
The HTML5 spec states (my emphasis):
Comments must start with the four character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS (<!--). Following this sequence, the comment may have text, with the additional restriction that the text must not start with a single > (U+003E) character, nor start with a U+002D HYPHEN-MINUS character (-) followed by a > (U+003E) character,
nor contain two consecutive U+002D HYPHEN-MINUS characters (--),
nor end with a U+002D HYPHEN-MINUS character (-). Finally, the comment must be ended by the three character sequence U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN (-->).
So that's why it's complaining. As to how to fix it without changing the code, that's trickier.
Your contention that it works is no different really to C developers wondering why they need to worry about undefined behaviour because the code they wrote works fine. The fact that it works fine in one particular implementation is not relevant to portable code.
My advice is to actually change the code. It's not valid, after all, and any browser (current or future) would be well within its rights to simply reject it.
As an aside after some historical digging, it appears this is not allowed because SGML, on which HTML was based, had slightly different rules regarding comment.
On sensing the <!-- token, the parser was switched to a comment mode where > characters were actually allowed within the comment. If the -- sequence was encountered, it changed to a different mode where the > would end the comment.
In fact, it appears to have been a toggle switch between those two modes, so something like <!-- >>>>> -- xyzzy -- >>>>> --> was possible, but putting a > where the xyzzy would end the comment.
XML, for one, didn't adopt this behaviour and HTML has now modified it to follow the "don't use -- within comments at all" rule, the reason being that hardly anyone knew that the comments behaved in the SGML way, causing some pain :-)
I'm using Vim's SmartTabs plugin to alingn C code with tabs up to the indentation level, then spaces for alignment after that. It works great for things like
void fn(int a,
________int b) {
--->...
Tabs are --->, spaces are _. But it doesn't seem to work so well for cases like
--->if(some_variable >
--->--->some_other_variable) {
--->...
In the case above, Vim inserts tabs on the second line inside the parentheses. Is there a way I can modify what Vim sees as a continuation line to include cases like this, so I get:
--->if(some_variable >
--->___some_other_variable) {
--->...
If there's an indentation style that would both allow flexible indentation width according to one's preferences, and consistent alignment, your suggested scheme would be it. Unfortunately, this style requires some basic understanding of the underlying syntax (e.g. whether some_other_variable is part of the line-broken conditional (→ Spaces) or a function call within the conditional (→ Tab)), and this makes implementing it difficult.
I'm not aware of any existing Vim plugin. The 'copyindent' and 'preserveindent' options help a bit, but essentially you have to explicitly insert the non-indent with Space yourself (and probably :set list to verify).
I don't know about that other Editor, but the situation is similar for most other inferior code editors. Without good automatic support, this otherwise elegant style will have a hard time gaining acceptance. I would love to see such a plugin for Vim.
Whenever I try to use a snippet (using snipMate) after a word, without a space, it does not work. So I have to hit space, type my snippet, hit tab, and then eliminate the space. Is there a better way of doing this? Is there a way to get the snipppets to work even immediately after a word? Here is what I mean:
let us say my snippet is this:
snippet test
<some code>${1}</code>${2}
typical use:
hello test[TAB]
turns into this:
hello <some code>|</code>
but if I try this:
hellotest[TAB]
it turns into this:
hellotest_____
the _ being white space. Is there a way to fix this?
Vim abbreviations can be of three types (full-id, end-id, and non-id, cp. :help abbreviations), which help solve this problem. snipMate, however, allows all non-whitespace characters for snippet names, and therefore has to rely on whitespace for separation.
You have to modify the parsing of the snippet name, in plugin/snipMate.vim, it's in the function TriggerSnippet():
let word = matchstr(getline('.'), '\S\+\%'.col('.').'c')
There's no setting to that effect if that's what you ask. You will have to look at the source and do the change there yourself, I'm afraid.
Also, it can probably seen as a limitation but it's definetely not a bug so what you are after is an improvement, not a "fix". My advice, though, is to use it as it was designed: having triggers work even if they are part of another word makes no sense at all. Spaces are the most natural way of separating ideas and words.
Does anybody have her vim setup in a way that uses hard tabs as indentation characters, but does use spaces for alignment? The problem I have is that when starting a continuation line like in
if (condition1 && (anotherlongcondition || /* <-- Here I insert a newline */
|-------|------- whatever /* some additional alignment added automatically */
, then cin (which is a must for me) adds some alignment just the way I prefer positionally, but this alignment is created using as much hard tabs as possible and filling the rest with spaces (as I tried to visualize).
So, in short, cin doesn't really seem to distinguish between indentation and alignment. I'd really like that all the added alignment in the example above is spaces. This way the alignment would be preserved correctly when switching ts temporarily.
To make it clear again, I'd like to be able to write the following code, never pressing <TAB> or <SPACE> in front of the first non-blank character in any line (and not doing any manual shifting or whatever):
void foo(int bar)
{
|-------somestatement;
|-------if (somecondition && (someothercondition ||
|------- whatevercomesnext))
|-------|-------dosomething;
}
I have already tried out ctab.vim, but it focuses on editing an aligned line with soft tabs, which seems silly to me because manual alignment is a task which affords 1-step refinement and not tab-width-step refinement. I did not change the way cin uses mixed tabs and spaces for alignment.
I have not managed to find any built-in way to accomplish that. Perhaps still, there is one? Anyway, I doubt that there's a plugin that does that. Although I admittedly don't vim-script myself and may not have enough experience, I must say that most plugins I tried out only messed up my editor configuration...
In addition to your :set cino=(1, you may also be interested in the 'preserveindent' and 'copyindent' options if you've not encountered them already. They don't completely solve your problem, but they do go some way towards helping.
Okay, sorry for the question. I've finally found some good material for it.
http://vim.1045645.n5.nabble.com/Indent-with-tabs-align-with-spaces-td1183279.html
To sum up, currently vim is not flexible enough for this to be done comfortably.
My workaround currently is using :set cinoptions=(1 which adds only one alignment unit when starting a continuation line. This way, I can be sure that the added alignment is a space (as long as I did not :set ts=1, at least) and add the nice amount of spaces manually. This is still ok in terms of speed and seems to be the least distracting behaviour to me!
^M is the dos carriage return that's left after each line when you move a file from a Windows box to a *NIX box. I know how to remove it. I am curious to know is there any other reason besides aesthetics that it should be removed from a PHP script.
The PHP script runs fine with it in. Normally, I would remove it without hesitation, but don't want to have my name next to each line in an svn blame command. (besides the point).
Question: Is there a reason in regards to functionality of why it should be remove other than aesthetics? It doesn't seem to break anything to keep it in. (Give me a good reason plz)
All in all, it should be fine. Other languages are picky about their line endings; I've seen it cause issues in Perl scripts, for example. But for PHP, i've never seen it matter much.
One occasion where it could conceivably matter is in multi-line strings, where the extra chars would make it through to the output. This might matter if your output is not HTML or XML. But JS shouldn't be particular about extraneous CRs, and HTML and XML will generally treat any whitespace the same as a single space (or in many cases, disregard whitespace altogether). Textareas and <pre> elements and such might end up with extra whitespace in them. That's about the only issue i can think of.