Write Emmet code In Multiplelines (VsCode) - html

community. I'd like to know how to keep writing emmet code in the next line of VSCode after the command gets just too big. Just to keep organized and be able to see all the instructions.

An option could be that you open another html file in your VScode and make the tab smaller to force the linke break.
I hope that helps you.
However in the documentation it says that a space is a stop symbol where Emmet stops abbreviation parsing.
Here you find the link to the documentation:
The creator of emmet does not recommend writing to long or to complicated emmet abbreviations, because it's quicker to write shorter and simpler emmet code.
Here is a quote of the website:
Abbreviations are not a template language, they don’t have to be “readable”, they have to be “quickly expandable and removable”.
You don’t really need to write complex abbreviations. Stop thinking that “typing” is the slowest process in web-development. You’ll quickly find out that constructing a single complex abbreviation is much slower and error-prone than constructing and typing a few short ones.

Related

Sublime Text 3 Code autoformatting

I've searched high and low, but I can't seem to find a plugin that makes Sublime work similar to how Visual Studio formats my code as I type it.
For example, when I write a for loop, it looks something like this:
for(int i=0;i<value.length;i++) {
//loop body
}
As soon as I complete the loop body, Visual Studio will format it to be much more readable:
for (int i = 0; i < value.length; i++)
{
//loop body
}
Basically, it's just adding spaces around operators in this case, but it does much more. If I write horribly indented HTML/XML code, it corrects the indentation. Arrays and multiline conditionals become much more readable.
Are there any Sublime Text 3 plugins out there that do something similar to this? Everybody seems to highly recommend the "Reindent" command, which works for the HTML/XML formatting, but it doesn't space everything out in a consistent way. JsParen looks good, but it won't work for any other language that I use, namely PHP, and it's for ST2.
CodeFormatter is one possible option for PHP. It uses the PEAR PHP_Beautifier, which you'll need to install separately. There are a bunch of configuration options detailed in the README, so you should be able to find something that suits your needs.
For C/C++/C#/Java code, you can't go wrong with SublimeAStyleFormatter, a formatter that uses the popular AStyle rules. Again, there are many options available, check the .sublime-settings file for details.
HTML-CSS-JS Prettify is what I'm using currently for those languages. It requires node.js to work, so make sure you read through the instructions carefully.
Finally, you may think I'm being facetious, but I'm really not: pay attention to style when you're coding. I work a lot in Python, where the visual presentation of the code is actually part of the syntax. Code is meant to be read, by other developers as well as by machines, and it does no one any good to try and pound out poorly-formatted, unindented code while thinking "I'll just prettify it later." Maybe your formatter doesn't fix all your mistakes, or maybe you forget, or get lazy. If you focus on the look and structure of the code, you can more easily see how the different parts fit together, and perhaps catch some bugs before they can do any harm. Set a clear style guide for yourself, and stick with it. You'll be glad you did.
Open Sublime Text editor.
Press Ctrl + Shift + P.
In the menu select Package Control : install Package
Now select SublimeAStyleFormatter.
After installing the above extension, you may press Ctrl + Alt + F to format your current file.

Mastering CSS and XHTML with Vim

Please point me to some guides on how to master (X)HTML, CSS with Vim. I preffer to create web pages by hands and I decided to go with Vim.
Any useful plugins, tips & tricks, tutorials, how-tos, books, articles?
Thanks!
You'll "master (X)HTML, CSS with Vim" the same way you'd do with any other text editor or language: by working hard, reading books, watching screencasts and keeping up with the news. The editor you choose is totally irrelevant.
That said, here are a few native features and plugins that helped me a lot:
Omnicompletion is Vim's own autocompletion-like feature, except that it's not automatic.
Hit ctrlp or ctrln to complete with a word contained elsewhere in your document.
Hit ctrlxctrlo to display a list of possible completions based on the language.
BEGIN EDIT
Another very very useful feature is "file-path completion", start typing the path to a file and hit <C-x><C-f> to display a menu with possible completions.
Also, the aforementioned features can be automated with plugins, the one I use is AutoComplPop.
END EDIT
Objects allow you to move, select and perform actions on your code in crazy cool ways.
Say you have <div>word</div> with the cursor on o, dit will delete word, cit will delete word and place the cursor between the tags for further editing and so on…
If you know what d, c or v mean, that i roughly means inside and a roughly means around and that t means tag you already have a very powerful tool, there. Vim has other objects very useful for code editing: ", ', (, [, { etc, type :help objects for more.
For me, this feature alone was enough to justify scraping TextMate.
Blockwise Selection does what it says. :help blockwise-visual for more info.
:normalize or :norm is also very useful to prepend or append something to a group of lines.
SnipMate is a plugin inspired by TextMate's snippets system. You type form then hit tab to expand to a complete boilerplate <form> element in which you can move by further hitting tab to edit values and attributes.
Surround takes the objects business to another level by making it possible to add tag pairs around your selection, deleting them or changing them.
If you take the example above, hit cst<p> to change it in a more correct <p>word</p>. To add a pair of tags to word, select it with v then hit S and type the tag you want.
Sparkup is a pretty awesome plugin. Besides that, I normally use both snipMate and delimitMate, though those are useful for coding in any language.
I do it that way. I haven't found that much support for it, so I wrote a little of my own. I keep it on Google code hosting. I also use a version of Vim with Python embedded, and use some Python to extend some functionality. That's in the pycopia.vimlib package.
There is only a little, but hopefully useful stuff. You can start from there.
Install CSS3 syntax plugin.
Install HTML5 syntax plugin.
Install Syntastic syntax checker plugin.
You'll also have to install CSS Lint's CLI tool, since the syntax checker uses it.
There are a lot more plugins related to general development, which you can find in several questions scattered around this website, but the ones above a specifically related to help writing better CSS & HTML.
Emmet. Which was called zencoding a long time ago, is a nice plugin for several editors (including vim) with many features that enables you to code html and css very rapidly.
For example, you can type div.some span.other<ctrl+y> ans you'll get:
<div class="some>
<span class="other>
(cursor here)
</span>
</div>
tl;dr; install this vim setup https://github.com/jameslai/jvim
James Lai wrote an amazing article on Frontend Vim which was 404'ing when I answered this. It has helped me switch from ST2 to VIM so I'm posting it here.
Why I Use VIM as My Editor of Choice for Front End Development
by James Lai
I’ve been using VIM for years, and I just can’t get away from it. While many people like to use Sublime Text 2, and I can’t help but absolutely encourage that, if you’d like to use an editor that can scale with your knowledge, VIM should be your editor of choice.
Easily edit content within tags
As FED’s, we’re constantly editing content within tags. VIM makes this easy with its “tag” text object - t. Here’s a common scenario, you have source code that looks like:
<div>Some content within here</div>
In VIM, to replace the content within that tag, you merely need to press cit. This will change the inner tag and you’ll be left with this:
<div></div>
Easily replace HTML attributes
Similar to the above, we deal with content within quotes all the time, often as attributes within our HTML. You may have something that looks like:
<aside class="one-third author box">
In this scenario, just hit ci". Perhaps the neatest part about this trick, if this was the only content on that line, you don’t even need your cursor anywhere near the quote itself! VIM is intelligent enough to simply empty out the content of the quote regardless of its position in the line, and you’ll be left with:
<aside class="">
Jump back and fourth between where you’ve edited
As FEDs, we are constantly jumping back and fourth between places we’ve previously edited. VIM maintains a “jump list” which is easily navigated by Ctr+O (jumping to previous locations) and Ctr+I (forward). This makes our routine of editing many files simultaneously incredibly painless.
More information on jumps
On a mac? In VIM, you’ve got a proper delete key again
Mac keyboards don’t come with a normal “delete” key - we essentially have a backspace key but it’s labelled delete. Sure, you could reach for funcdelete, but that function key is sure out the the way. Instead, hit x!
Move CSS like a master
Often I’ll need to refactor some CSS and move properties between selectors. With VIM, I can move content from various lines to my cursor position with a simple:
:<linenumber>,<linenumber>m
Common operations like these are made laughably easy with VIM.
Jump to the end or beginning of a line
This is unusually common in my workflow - needing to jump to the end of a line. Perhaps I forgot a semicolon at the end of a CSS property or line of Javascript. To jump to the end of the line, simply hit A and you’re in insert mode at the end of the line. Need to edit at the beginning (not counting tabbing)? Use I.
Edit at the speed of thought
One of the staple concepts of VIM is to prevent needing to reach for your mouse. When I’m in my flow, I never reach for the mouse unless its to interact with a web page I’m working on. Getting good at VIM means your ability to edit and manipulate text nearly approaches how fast you can think of the problem. Because of the concept of text objects, thinking “I want to delete this line” becomes a trivial dd, or deleting a word with daw. As you think about the problem, you more often then not have a easy command to describe to the editor. The ability to get into your flow with VIM is, in my opinion, higher than most other editors.
Easy split windows
Something that completely changed how I developed was learning how to really leverage split windows in VIM. Yes, VIM has split windows, and they’re amazing! Some editors come with this functionality, but it can be cumbersome to use, or difficult to remember to use.
Spits are powerful because we’re often addressing the same item in a number of places. If you’re addressing an element, you’ll often want the HTML file up. If you’re applying styling to it, you’ll want the CSS up, and if you’re applying behaviors, you’ll want the Javascript up as well. Seeing them all at the same time has saved me literally countless headaches in editing. The flow feels very “natural”, not to mention just how awesome your editor will look. Often I’ll have at least 4 splits going at any one time.
A great way to get started is by typing :Vex. This opens a Vertical exploration window. From here you can browse to whatever file you want to, and that file will appear in the split. There’s also the always salacious :Sex command, which will open a horizontal split explorer window.
Vertical Split Windows
More information on splits
More information on the file explorer
Your setup, anywhere
Perhaps one of the most compelling features is the ability to have your customized setup very quickly. I keep my VIM configuration in a GitHub repo, meaning regardless of what machine I’m on, I’m about 2 commands away from having my complete setup ready to go.
…even on remote machines
Front end developers will inevitably work on a remote server at some point. Heck, many of us have local linux boxes in a VM replicating our server environments. You’re going to need an editor, and rather than either fumble around in VIM due to not knowing how to actually make it dance, or using a basic and underpowered editor like nano, getting good at VIM client-side means you’re going to be a master server-side.
Final thoughts
VIM is an amazing editor, and although you may think it’s old, it’s actually more than up to the task for today’s editing. No matter what new editor hits the market, I may try them out to see what innovations are out there, but in the end, I always come back to VIM for all my editing, and I love it.
I use a lot zencoding, so, if you're used with zen-coding try the zenCoding plugin for Vim find it here
If you want to learn more about zen-coding you could read: zen coding vim tutorial

track and display changes in html

I am looking for a tool to display/track changes in text a little bit like it is done on stackoverflow when a question is edited. Does anybody know of a tool to achieve that?
You may want to use diff for that.
If you can use PHP on your server there's a handy pear package to perform the task you require. Here's an example :
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6174867.html
There's actually a actually Javascript implementations outhere as well, not tested though:
http://ejohn.org/projects/javascript-diff-algorithm/
http://aignes.net/
Commercial tool though. I have no idea of a F/OSS alternative.
A copy of my own answer from here.
What about DaisyDiff (Java and PHP vesions available).
Following features are really nice:
Works with badly formed HTML that can be found "in the wild".
The diffing is more specialized in HTML than XML tree differs. Changing part of a text node will not cause the entire node to be changed.
In addition to the default visual diff, HTML source can be diffed coherently.
Provides easy to understand descriptions of the changes.
The default GUI allows easy browsing of the modifications through keyboard shortcuts and links.

WYSIWYG editor vs Hand Code

What are the pros and cons of using a WYSIWYG editor for web page development vs hand coding?
With the exception of just not knowing how to create something by hand coding is there any reasons to use WYSIWYG?
I handcode, but I prefer to work with a wysiwyg editor in tow, and for that reason I'm still using Dreamweaver as an editor. What I'm doing 95% of the time is handcoding inside the Source editor and viewing the results in the preview. Occasionally I'll drop into the wysiwyg editor to move blocks around directly though and when I do I find it invaluable. I never use any of Dreamweavers wizards or generated code and I clean up the html manually too.
I see nothing wrong with this approach, it strikes me as the HTML design equivalent of an IDE prompting to complete functions etc. (intellisense or whatever your IDE may call it)
I also always use a templating system of one form or another so my scripting code is totally separate from html.
The combination with Dreamweaver of the occasional wysiwyg edit (invaluable I find when laying things out or making 'macro' layout changes) and the one click preview has kept me with it despite looking at better tools - Aptana, NetBeans etc. Indeed I would dearly like to move to another system - see this question - preferably something that runs on Ubuntu and strips out the crud in Dreamweaver leaving just the wysiwyg features and possibly an intelligent Javascript editor, but I'm yet to find anything. KompoZer is starting to look promising though.
There are a variety of reasons to use a WYSIWYG editor when creating HTML.
Allows for quick prototyping
Allows designer-y people to be actively involved in front end development
Some WYSIWYG tools will set you up with a clean base to be modified (Dreamweaver's CSS layouts are actually pretty good)
I think the important thing to remember is that after you get it into approximate shape, you should dig into the code and make sure there's nothing weird going on. Nested spans, odd absolute positioning, and (lord almighty) table based layouts count as weird things. Even if you use a WYSIWYG to start with, you should always check that the code is valid and looks the way you would expect it to.
WYSIWYG can be handy if you don't know HTML or just want to whip something together extremely fast. You're not going to get clean code, though. Most WSYIWIG editors still throw out a bunch of unneeded dirty HTML instead of clean solid markup.
Anyone familiar with HTML can usually whip up something just as fast by hand in an HTML editor. And it will be clean, xhtml compliant semantic markup instead of thrown together templates with extraneous crud.
If you set up the template and css properly, you can probably be faster with hand coding than a WSYIWYG editor, as those work against you when you're trying to create properly abstracted css with degradable semantic markup.
If the design isn't terribly important and you're just throwing a website together there's nothing wrong with using a WYSIWYG. Or if you're trying to create a marginally functional mock up for a client it's a good way to get something built quickly.
I develop in ASP.net most of the time, so I'm in VS2008 most of the time; however whenever possible (which is most of the time) I still-hand code....but I do it in VS2008's source mode. When working with ASP.net, theres always somewhat bloated code which you just sort of have to accept (to a point).
However, in my free time, I also do php development, and like hell will I ever not hand-code with php. Plus, its not like VS with the drag and drop stuff.
If you want to be really good at what you do, as in Guru like good, drop the WYSIWYG stuff and start hand coding. The learning curve is steeper, but it makes you better at what you do in a meaningful way.
It comes down to maintainability and changeability. It is usually much easier to change a GUI layout in a GUI editor than by hand.
"Oh you want to move that JTable from this position to this other completely unrelated position". If you have handcoded it, it basically turns out to be a programming job (which for non-trivial layouts might actually be HARD), but if it is in a good GUI editor, it is probably just a matter of point-click-move-release.
People who handcode probably never have had to do that kind of changes :)
The advantages of using a WYSIWYG editor for web development are pretty obvious. Development is much simpler and faster even if you know how to code web since web development requires to know many different languages and can get messy when trying to get them to work together as planned. Real WYSIWYG designers should be able to solve those complexities by allowing you to visually develop on one form in one layer.
The disadvantages of this kind of development paradigms can be that it sometimes limits you, meaning that you are usually constrained within a predefined framework.
Therefore it is important to find a framework that on top of its WYSIWYG development experience is open to extension and customization. Take a look at http://www.visualwebgui.com/.
This is the same type of thing as Glade versus hand coding your Gtk code. I think that you add a level of obfuscation and things that might break when you hand edit your code. However, as Spencer said, if you need to do it and it needs to work; usualy WYSI wil work pretty well and reliably. If you're doing something that you're going to be keeping up to date and be managing for years to come; you should know every piece of code that is in that application/web page.
Really it comes down to your job function. If you're primarily a designer, WYSIWYG editors can be very handy for creating mock-ups for clients, or prototypes that can be handed to developers to code against.
If you're a developer, you'll probably prefer to hand-code.
Most WYSIWYG editors offer a code view and design view which enables you to switch back and forth pretty easily.
My suggestion is to try and learn how to hand-code your site. After years of web development, I find that hand-coding is faster for me than attempting to use a designer. Moreover, as you gain a better understanding of how HTML and CSS work together you'll find that there's very little that can't be done gracefully.
It can be frustrating to learn, but you'll find that you're better for it in the long run.

What is the best way of adding in regularly used blocks of code when marking up in TextMate?

Caveat: I'm relatively new to coding as well as TextMate, so apologies if there is an obvious answer I'm missing here.
I do a lot of HTML/CSS markup, there are certain patterns that I use a lot, for example, forms, navigation menus etc. What I would like is a way to store those patterns and insert them quickly when I need them.
Is there a way to do this using TextMate?
You can do this very easily in TextMate using Snippets. Just add a new snippet in the bundle editor, and set up how you want to trigger it. You can set a key shortcut, or have it pop up when you hit Tab after a certain word/pattern.
There are many things you can do with them—in your case, it would probably be very useful to set so-called "placeholders" in your snippets, which are the parts that change every time (e.g. the names of the fields in the form). Then, as soon as you insert the snippet, you can hit Tab to move between these.
Along with the links provided above, I think you'll find this screencast useful. It gives a run through of some of the tools TextMate's HTML bundle already provides.
It's probably slightly off-topic though, but worth a look nonetheless.
As mentioned prior snippets are what you are looking for.
For reference look here:
http://manual.macromates.com/en/snippets
http://screenflicker.com/mike/code/div-snippets/