-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open relative paths under the working directory #2
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`bundle install` dies otherwise. (At least for me; I'm using Bundler 1.0.2.)
This reduces absolute path noise in the buffer list, status line, tab line, etc., for the usual no-arg case of opening files in the working directory. It falls back to the previous absolute path behavior for files outside the working directory.
Thanks Matthew. At first glance looks good, so will merge in once I've had a chance to review it more closely later today. To be honest I'd never even noticed the issue you bring up here (the joys of having a ridiculously wide screen) but I can definitely see the rationale. Cheers, |
wincent
added a commit
that referenced
this pull request
Jul 4, 2022
So I can see backtraces on Arch: yay -S gdb Core dump files get written to `/var/lib/systemd/coredump/`, owned as root, and zstd-compressed, so to read them, you have to do something like: # unzstd /var/lib/systemd/coredump/core.nvim.1000.008a013d9f0d4e769d9dbcfdd9d9584a.13538.1656944479000000.std # chmod 666 /var/lib/systemd/coredump/core.nvim.1000.008a013d9f0d4e769d9dbcfdd9d9584a.13538.1656944479000000 $ gdb nvim /var/lib/systemd/coredump/core.nvim.1000.008a013d9f0d4e769d9dbcfdd9d9584a.13538.1656944479000000 (gdb) bt Which shows (excerpted): Core was generated by `nvim'. Program terminated with signal SIGSEGV, Segmentation fault. warning: Section `.reg-xstate/13538' in core file too small. #0 match_thread (thread_args=0x55d4e0213230) at matcher.c:393 393 haystack_t *match = args->corpus->haystacks[i]; [Current thread is 1 (Thread 0x7fcda9b93740 (LWP 13538))] (gdb) bt #0 match_thread (thread_args=0x55d4e0213230) at matcher.c:393 #1 0x00007fcda9e0f5ff in commandt_matcher_run (matcher=0x55d4e07eb9e0, needle=0x7fcda9e110f7 "stuff") at matcher.c:211 #2 0x00007fcda9e0fb28 in commandt_temporary_demo_function () at matcher.c:312 #3 0x00007fcda9bce309 in lj_vm_ffi_call () at buildvm_x86.dasc:2701 #4 0x00007fcda9bf3b5e in lj_ccall_func (L=<optimized out>, cd=<optimized out>) at /build/luajit/src/luajit-2.0-4c2441c/src/lj_ccall.c:1167 ...
wincent
added a commit
that referenced
this pull request
Jul 7, 2022
I'm on macOS right now, so not sure how this will look in GCC, but at least with clang/lldb we find the smoking gun pretty directly here. First, without `-O0` lldb --file nvim (lldb) r Process 33400 stopped * thread #3, stop reason = EXC_BAD_ACCESS (code=1, address=0x7669746967750013) frame #0: 0x0000000103411c08 commandt.so`commandt_calculate_match + 52 commandt.so`commandt_calculate_match: -> 0x103411c08 <+52>: ldr x8, [x8, #0x8] 0x103411c0c <+56>: adds x8, x8, #0x1 0x103411c10 <+60>: cset w8, eq 0x103411c14 <+64>: mov w9, #0x1 Target 0: (nvim) stopped. (lldb) bt * thread #3, stop reason = EXC_BAD_ACCESS (code=1, address=0x29) * frame #0: 0x0000000103411c08 commandt.so`commandt_calculate_match + 52 frame #1: 0x0000000103413174 commandt.so`match_thread + 252 frame #2: 0x00000001be24826c libsystem_pthread.dylib`_pthread_start + 148 Same with `-O0`: Process 33773 stopped * thread #3, stop reason = EXC_BAD_ACCESS (code=1, address=0x7669746967750093) frame #0: 0x0000000103411c08 commandt.so`commandt_calculate_match(haystack=0x766974696775008b, matcher=0x0000600002166800) at match.c:132:38 129 matchinfo_t m; 130 /* long i; */ 131 float score = 1.0; -> 132 int compute_bitmasks = haystack->bitmask == UNSET_BITMASK; 133 m.haystack = haystack; 134 m.needle_p = matcher->needle; 135 m.needle_length = matcher->needle_length; Target 0: (nvim) stopped.
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi, Wincent --
Command-T is amazing. Thank you very much!
I wonder if you would consider this patch to Controller#accept_selection:
Presently, Command-T always opens files by absolute path, solidly supporting browsing outside Vim's working directory. However, for files inside the working directory, this strategy adds unnecessary absolute path noise to the buffer list, status line, tab line, etc.
This patch corrects that problem, opening relative paths under the working directory and falling back to absolute ones otherwise.
All the best, -- Matthew