The g_match_info_fetch_pos() function uses a signed value for the match_num
parameter, even though values less than 0 are not valid, so a cast is used.
Add configuration option tab_close_switch_to_mru to allow the user
to choose whether to switch to the most recently used tab or to the
next one after closing the current tab.
Right now the tab switching dialog shows the full
path of the current file. However this dialog is too
narrow and in my case usually displays one directory
per line. This makes it hard to find the base
filename, which is the thing you are most probably
looking for.
This patch displays only the base name - in bold. In
addition, it displays the following three filenames
in the MRU list, each on a new line (not in bold).
This helps to see what file comes next and how many
times one has to press ctrl+tab.
There was one more bug related to the tab switching. When we switch
so many times that we return back to the original document (so we
actually don't switch at all) then the following switch attempt
doesn't switch immediately to the next document.
After spending two hours thinking what is wrong, I gave up and rewrote
the whole thing in a different way. The problem with the previous
implementation was that before you couldn't just look what's in the queue
"now" - you had to imagine what will be inserted there in the next step
because the switch_in_progress variable was set after the first switch
(this is also why I put the long comment why mru_pos = 2 - that is not
clear at all when you first look at it). Also there were some not very
nice "workarounds" like the idle function that was executed after the
switch and removed the double entry on top of the queue.
So with the new implementation things are much simpler IMO. The queue
starts with the current document and the previously opened documments
follow. It's *always* like that, no exceptions. The idle function
is gone and cb_func_switch_tablastused() is simplified too. The rest of
the functionality should be clear from the code.
Signed-off-by: Jiří Techet <techet@gmail.com>
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.
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.
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.
