This is a pretty frequent work pattern of mine:
1. Editing file A
2. Searching for function and opening file B
3. Closing file B because I just wanted to look at the function definition
4. Without this patch I get to the file following the B's tab (which
is just a random file) but my brain expects that I get to A
I know it's possible to kind of simulate the behaviour I want with
the "next to current" placement option but I really don't see a single
advantage of having tabs closed in sequential order. This is also
why I didn't make this behaviour optional. But maybe I miss some
use case of tabs being closed sequentially - just tell me.
Signed-off-by: Jiří Techet <techet@gmail.com>
Replacing spaces used for alignment with tabs would often break the
alignment as tab stop positions were not checked. It's also not
possible to distinguish between a true space and a single aligning
space, so we should ignore all spaces outside of indentation.
Although go to marker commands (or other keybindings) don't work, the
marker margin can still be useful, and improves alignment with the
original sci widget when using the Top & Bottom split.
There is still 3 signed values implicitly converted to unsigned not
fixed, but they aren't really legitimate and would require a behavior
change in some corner cases.
Most noteworthy change is that all build commands IDs and groups are
now unsigned everywhere negative values aren't explicitly handled with
a special meaning. This should not change anything in behavior, only
makes clear the index won't underflow.
These actions were marked as document sensitive but their sensitivity
is already managed by the navqueue, so making them document sensitive
only leads to them being wrongly updated when the document count
changes from or to 0.
So, make them initially insensitive and let the navqueue correctly
handle their later sensitiveness.
This seems required for GtkBuilder to be able to connect signals. However, this change may break Windows
builds. Needs to be tested and worked around if it is the case.
Having C language snippets as global is wrong, moved them to several
language positions. This files low rate of change and lack of ML
interest in putting language specific snippets in it suggests that
it isn't worth fixing the repitition or moving snippets to filetype
files.
Add filetype_get_comment_open_close() to get appropriate start and end
comment markers from a filetype, and use it everywhere these markers
are fetched.
This fixes a crash in editor_insert_multiline_comment() if only single
comments are available (closes#3449635).
Although this doesn't change anything in practice, it started to be a
nightmare trying to deal with compilers warnings about "missing"
initializers, which are generally good but not in that file.
When checking whether a keybinding is already in use before updating
it in the preferences, check against the keybindings the user may have
updated, not the ones that are currently applied.
This fixes changing action A from key K to key L and action B from key
L to key K, which led to conflicts back and forth since when setting B
to K the check found A as a duplicate even after having changed it.
Use a GCC pragma to disable -Wmissing-field-initializers in this file.
This works with both GCC and CLang, and should be harmless on other
compilers since unknown pragmas are supposed to be ignored.
Old implementation was not really fitting the updating needs and had a
bug making symbols disappear if they haven't changed but their parent
did (e.g. when a C++ constructor's signature changed).
New implementation does:
1) walk old tree, updating or removing rows;
2) add remaining tags.
It walks less than (new_tags + old_tags + new_tags) in the worst case,
thanks to some hash table-based caching; and also gets rid of the
"valid" column in the symbols tree, saving a few bytes in memory.
Finally, there is a ~7% performance gain (from 21 to 18ms) upon common
tree updates, sometimes more.
Instead we should use that tab which is under mouse cursor where the user clicked (this might be a
different one than the current document). To be able to do so, we need to handle the right-click signal
per tab not on the GtkNotebook tab area to identify the tab under the mouse cursor.
