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.
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).
