IDEs for editing LESS files / Semantic UI Themes

The thing I'm searching for is:

Code Intelligence for LESS files with the following features:

• Go to definition across files
• Find usages across files

I started my search for an appropriate tool from the Less reference for tools.

Stuff that does that:

• IntelliJ WebStorm

Stuff that does not do that:

• Microsoft Visual Studio Code (aka. VSCode)
• Supports navigation only within file
• Sublime Text 3 + SublimeCodeIntel
• does not recognizes the LESS variables as variables at all.
• I did not try it out in ST2.
• otherwise it should work like this
• Komodo
• Development of feature in progress
• Crunch2
• Does nothing and does not even allow proper try out.
• Brackets
• does not recognizes the LESS variables as variables at all.
• Atom
• they have some nice navigation plugins, called hyperclick with extensions js-hyperclick, and file-hyperclick which are useful, but not working for less variables.

CSS: box-sizing: content-box vs border-box

Sources: http://www.w3schools.com/cssref/css3_pr_box-sizing.asp | https://css-tricks.com/box-sizing/ | http://www.binvisions.com/articles/box-sizing-property-difference-content-border/

Box-sizing

• content-box
• Default. 
• Width or height = content's width or height. Border, padding, or margin are not included

• border-box
• Width or height = content + padding + border width or height. Margin is not included.

• initial
• Sets this property to its default value.
• inherit
• Inherits this property from its parent element.

CSS position: static, relative, absolute and fixed

Sources: W3Schools CSS Layout - The position Property | CSS Tricks Absolute, Relative, Fixed Positioning: How Do They Differ?

• Static
• The default. Positioned according to the normal flow of the page.
• Not affected by the top, bottom, left, and right or z-index properties.
• It is useful when you forcefully want to remove some other positioning that was applied to the element outside of your control.
• Relative
• "Relative to itself". Relative to as if it were positioned as static.
• Affected by the top, bottom, left, right and z-index properties.
• Other content will not be adjusted to fit into any gap left by the element.
• Limits the scope of absolutely positioned child elements.
• 
  
• Absolute
• Positioned relative to the nearest non-static positioned ancestor, or the body if there are no such ancestors. 
• Affected by the top, bottom, left, right and z-index properties. 
• Does not leave a gap in the page where it would normally have been located.
• Does not affect the position of any other same-level element
• 
  
• Fixed
• Positioned relative to the viewport (or window), which means it always stays in the same place even if the page is scrolled.
• Affected by the top, bottom, left, right and z-index properties. 
• Does not leave a gap in the page where it would normally have been located.
• The downside of this element is the usability on different screen-sizes. It does not scroll, so if it does not fit the screen, the content is cropped and unreachable.
• 
  

GIT: the difference between HEAD~1 and HEAD^1

Source: Stackoverflow --> git-rev-parse manual page

^N: Nth parent of the tip of the current branch.
~N: Nth generation first parent of the tip of the current branch.

Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A^0
B = A^   = A^1     = A~1
C = A^2  = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

(emphasis by me)

Force LF line endings on Windows with GIT

The possible git settings for line endings are:

• Checkout Windows-style, commit Unix-style
  Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF.
  Git will not perform any conversion when checking out text files. When committing text files, CRLF will be converted to LF.
  Git will not perform any conversions when checking out or committing text files. 

  git config --global core.autocrlf true

• Checkout as-is, commit Unix-style

  git config --global core.autocrlf input

• Checkout as-is, commit as-is

  git config --global core.autocrlf false

Solution on Stackoverflow:

The proper way to get LF endings in Windows is to first set core.autocrlf to false:

git config --global core.autocrlf false

Now git won’t do any line ending normalization.
If you want files you check in to be normalized, do this:
Set text=auto in your .gitattributes for all files:

* text=auto

And set core.eol to lf:

git config --global core.eol lf

Now you can also switch single repos to crlf (in the working directory!) by running

git config core.eol crlf

After you have done the configuration, you might want git to normalize all the files in the repo. To do this, go to to the root of your repo and run these commands:

git rm --cached -rf .
git diff --cached --name-only -z | xargs -n 50 -0 git add -f

If you now wano also normalize the files in your working directory, run these commands:

git ls-files -z | xargs -0 rm
git checkout .

Personal opinion: 
I set core.autocrlf to input, to make sure that the repo gets LF line endings always.