js.c only allowed keywords 'function' 'Function' or 'Object' after
'new' but js syntax allows any constructor function:
var name = new constructor_function( args );
ie an identifier where js.c allowed only keywords.
So changed js.c to allow any identifier as well as the keywords.
C-style multiline comments, used among others in C, C++ and Java, are
often continued on next lines with an additional space followed by an
asterisk:
1. /* first comment line
2. * continuation line (asterisk is aligned with previous line)
3. * last line */
This fools the indentation with detection because lines 2 and 3 from
the above example have an extra space in what is considered being the
line indentation. In this example, the algorithm would detect an
indentation width of 5 rather than 4, because here most lines have an
indent of 5 -- although they actually have an indent of 4 plus a space
for alignment. This is not a problem in most situations because there
generally are fewer comment continuation lines than actual code lines
which have a indent multiple of the actual indent width, but with some
code with a lot of comments (e.g. short functions with verbose
documentation comments) this might start to fool the algorithm and
give wrong, annoying, results.
So, try to detect these continuation lines and avoid taking them into
account.
When scrolling the keybinding list to display a particular row, which
is used to display a particular plugin's keybindings, consistently
scroll so the row is on the top left. This makes it easier to see the
row in question since it's always at the same location, and it shows
more child keybindings.
This imports Scintilla commit 06f36a3217229ec2c2a360e370ae1b07597ce7b6
from HG, "Fix crashes with SelectionText instances that did not have \0
terminators."
In the file properties dialog there are a few label for which the
default value is never visible to the user, and then don't need to be
translated. These strings are only useful to recognize and select the
label in e.g. Glade UI.
Remove most obvious calls to our very own deprecated Scintilla wrapper
functions sci_get_text(), sci_get_text_range() and
sci_get_selected_text().
Some calls are still left, but they either really benefit from these
functions or the fix would be more complex.
Function symbols_get_context_separator() returns the symbol
separator for the language, but some languages do not have
symbol context separators, for example markup languages like
Asciidoc. To prevent the symbols pane wrongly detecting and
acting on a valid character sequence as a separator, return a
non-printing character which should not occur.
Options "" and NULL not used as they break some code and would
need an ABI bump.
Other languages can be added as they are identified.
When switching the current notebook tab, we need to take only visible
pages into account. If we don't and we try switching to an invisible
page, nothing happens.
In practice, the issue is visible on the message window notebook if one
of the tabs are hidden due to one of the "msgwin_*_visible" settings.
At commit 160e5e stamp was changed from a gchar[512] to a gchar*
but the copy loop still used stamp and sizeof(stamp) as the buffer.
Now gchar[512] buffer is used again.
Asciidoc overloads lines of dash (-) for heading underline and
open block delimiting (--). This made the parser recognise list
continuation blocks as headings. Now requires more than two
underline characters for a heading.
They used to be because their parent menu item (Editor) was
document-sensitive but now they are in the top of the View
menu they need to be invdividually made so.
TODO: should they really be/have been document-sensitive? They
can still change the pref without a document open and their
equivalent options in the Preferences dialog are not
document-sensitive? Same goes for existing "Change Font" item.
Rationale:
----------
* Existing View menu already contained Editor-related options
like "Change Font" and Zoom controls, so it makes sense to
group all of the View-related items together.
* Anecdotally, some users have been unable to easily discover
the Color Schemes changer dialog because it was nested under
a submenu.
* Distinction between "Editor" (Scintilla) and "Editor" (All
of Geany) is likely non-obvious to most users, especially
new users exploring the menus.
* There's not very many items to cause scrolling on low-res
monitors, and the View menu still has less items than the
Document menu.