| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I27bd360e3353bf73c58376d3f03a36cad8a1a17b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109978
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Added comment to TEMPLATE.SOURCECODE.HEADER to document published API header files
Change-Id: I28675d53a5aa7f0a01275273b3d95b2209f2ba0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109945
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Vim users: No reason to panic. This does not mean that Emacs users
would suddenly start to split existing (or new) code lines always
before column 100. The default value for fill-column is 70, and that
hasn't forced code lines edited in Emacs to be shorter than that
earlier either.
The primary intent of using a fill-column of 100 (instead of the
default 70) is that when you edit some long (multi-line) comment
block, and you want to reformat ("fill", "reflow") that comment (using
the fill-paragraph command, bound to Meta-Q), lines will be filled up
to column 100, and not just 70, which in most cases would look quite
short.
Unless I am strongly advised not to, I will start adding this to the
mode lines in source files if I remember, as I happen to edit some
comment block in them.
Change-Id: Icfb93dbb22b2db7190fdc9c8ee9518d08e73c7a8
|
|
Bunch of these were setting C++ or Make modes and icky tabs...
Also, reportedly Emacs can figure out to enable python-mode
automatically.
Change-Id: I50072488fb92cb4d27aa3f74f717a28ae3967543
|
|
Change-Id: I548cf17fe2818e8c0fbb4dc356bff7abbe7cc7e6
|
