Drea devs,
In my new job I'm also working with css files and html-templating with inline php. I just instinctly selected a bit of css and pressed ctrl-e to comment that, but the whole line got commented instead.
A simple line of css: .front #content .element-count-2 #block-block-1 { width: 250px; height: 135px;}
Select the width statement: .front #content .element-count-2 #block-block-1 { [width: 250px;] height: 135px;}
Press ctrl-e
Expected result: .front #content .element-count-2 #block-block-1 { /* [width: 250px;] */ height: 135px;}
Actual result: /* .front #content .element-count-2 #block-block-1 { [width: 250px;] height: 135px;} */
Looks to me like a nice Geany addition! ;)
-H-
Harold Aling wrote:
In my new job I'm also working with css files and html-templating with inline php. I just instinctly selected a bit of css and pressed ctrl-e to comment that, but the whole line got commented instead.
A simple line of css: .front #content .element-count-2 #block-block-1 { width: 250px; height: 135px;} [...]
I know this means breaking your style, but: you can split that over multiple lines with minimal/no impact on file size, and then it is easier to manage when doing such things as commenting out individual rules. e.g.
.front #content .element-count-2 #block-block-1 { width: 250px; height: 135px; }
IMHO also a bit more readable, but I realise that's my personal preference :)
If you do this, and you use spaces not tabs for some (unfathomable) reason, then you can "minify" your CSS to remove redundant white space and comments by using a tool like YUI Compressor:
http://developer.yahoo.com/yui/compressor/
[I have it hooked up to my build menu under key F9, for minifying JavaScript files; you easily could do the same for CSS]
On Wed, Mar 23, 2011 at 23:38, Ross McKay rosko@zeta.org.au wrote:
Harold Aling wrote:
In my new job I'm also working with css files and html-templating with inline php. I just instinctly selected a bit of css and pressed ctrl-e to comment that, but the whole line got commented instead.
A simple line of css: .front #content .element-count-2 #block-block-1 { width: 250px; height: 135px;} [...]
I know this means breaking your style, but: you can split that over multiple lines with minimal/no impact on file size, and then it is easier to manage when doing such things as commenting out individual rules. e.g.
.front #content .element-count-2 #block-block-1 { width: 250px; height: 135px; }
IMHO also a bit more readable, but I realise that's my personal preference :)
True, but that's not my point.
Another example:
<div class="hardcoded-class <?php print $extra_class; ?>"></div>
...and I want to comment out "print $extra_class;"...
-or-
$var = $var1 + $var2 / 10;
...and I want to comment out "/ 10"
There are numerous examples where "comment selection" could be handy, IMHO.
-H-
Harold Aling wrote:
True, but that's not my point.
Another example:
<div class="hardcoded-class <?php print $extra_class; ?>"></div>
...and I want to comment out "print $extra_class;"...
-or-
$var = $var1 + $var2 / 10;
...and I want to comment out "/ 10"
There are numerous examples where "comment selection" could be handy, IMHO.
Fair enough. But I'd prefer context-sensitive commenting before that :)
i.e. when you have a script that is a mix of script types (HTML, CSS, PHP or VBScript, JavaScript) it would be nice if comments worked on the appropriate language for the selected block.
Right now, if you have an ASP and the mode is HTML, any CSS, JavaScript, or VBScript you try to comment out gets <!-- and -->
And similarly, HEREDOC HTML you have in PHP gets /* and */
I don't know how to solve that one, and have yet to peek at the codez for it. But I reckon it is a bigger problem.
There are numerous examples where "comment selection" could be handy, IMHO.
Have a look at the Geanyembrace plugin, its purpose is to "embrace" the selection by inserting specified text before/after it. IIUC its original purpose is HTML marking up. Not sure if it is already configured for comments. Its not documented on the website but has a readme.html.
Fair enough. But I'd prefer context-sensitive commenting before that :)
i.e. when you have a script that is a mix of script types (HTML, CSS, PHP or VBScript, JavaScript) it would be nice if comments worked on the appropriate language for the selected block.
Right now, if you have an ASP and the mode is HTML, any CSS, JavaScript, or VBScript you try to comment out gets <!-- and -->
And similarly, HEREDOC HTML you have in PHP gets /* and */
I don't know how to solve that one, and have yet to peek at the codez for it. But I reckon it is a bigger problem.
Only slightly smaller problem than world peace :-)
There is nothing in Geany that considers the possibility of embedded languages, Geany is based on the paradigm of the filetype, ie one type for the whole file.
The Scintilla HTML lexer does recognise embedded scripts JS, PHP, Python etc, not sure about CSS I didn't check. But there is no way of passing that information back to Geany so it could possibly change the filetype for different segments of the file.
So first you have to find a hack for passing back the language segments from Scintilla or you have to provide them with a patch to include an official way of doing that (or be very persuasive to get them to do it for you).
Then you can change Geany's central paradigm to allow multiple filetypes per file.
Patches welcome :-).
Cheers Lex
-- Ross McKay, Toronto, NSW Australia "Nobody ever rioted for austerity" - George Monbiot _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman wrote:
Only slightly smaller problem than world peace :-)
There are many problems bigger than this minor commenting issue, which is why I've never brought it up before... especially since I've not yet even looked at the code for it :)
[...] So first you have to find a hack for passing back the language segments from Scintilla or you have to provide them with a patch to include an official way of doing that (or be very persuasive to get them to do it for you).
Then you can change Geany's central paradigm to allow multiple filetypes per file.
Much as I suspected. Maybe when the current workload eases I could look into it.
Patches welcome :-).
Indeed :)
Harold Aling wrote:
[...]
<div class="hardcoded-class <?php print $extra_class; ?>"></div>
...and I want to comment out "print $extra_class;"...
Of course, you could always just:
<div class="hardcoded-class <?php // print $extra_class; ?>"></div>