It is the profiling itself that is causing the results to be so skewed as
things run longer. I guess the thing to do now is use the linux/gnu
profiler to profile the vim profiler.
During a single run of vim, for the current analysis, 45 profile files are
created; the profile structures are torn d
Is this expected? All the results/table are collected in a single instance
of vim; tried it with "-u NONE". I've run asan and valgrind on
test_filter_map and don't see any leaks. If these results are a surprise, I
can look further. I haven't run the linux/gnu profiler yet. I saw vim's
MEM_PROFILE,
Gary Johnson wrote:
> There seem to be a couple of debug print statements left in
> list_mappings() in map.c, so that when I execute
>
> :verbose abbreviate dt
>
> (I have an abbreviation "dt"), I see at the top of the output:
>
> Seen modifyOtherKeys: true
> Kitty keyboard protoc
Patch 9.0.1418
Problem:The included xdiff code is a bit outdated.
Solution: Sync with the latest git xdiff code. (Yee Cheng Chin,
closes #12181)
Files: src/xdiff/README.txt, src/xdiff/xdiff.h, src/xdiff/xdiffi.c,
src/xdiff/xdiffi.h, src/xdiff/xemit.c, src/xdiff/
There seem to be a couple of debug print statements left in
list_mappings() in map.c, so that when I execute
:verbose abbreviate dt
(I have an abbreviation "dt"), I see at the top of the output:
Seen modifyOtherKeys: true
Kitty keyboard protocol: Cleared
I discovered that these were
On Sun, 19 Mar 2023 17:49:10 +
Bram Moolenaar wrote:
> Ernie Rael wrote:
> > I need to make a change, the most clear (I think) is
> >
> > for (i = 0; i < len; i++, idx++) {
> > // stuff
> >
> > if (cond)
> > continue;
> >
> > // more stuff
> >
