Problem: opening oil as a float requires users to remap every entry
point (`-`, `:Oil`, startup autocmd) individually. There is no single
flag to make float the default everywhere.
Solution: add `default_to_float = false` to config. When `true`,
`M.open()` delegates to `M.open_float()` (covers `:Oil` and all keymap
invocations), and a `VimEnter` hook replaces the initial directory
buffer with a float when starting Neovim on a directory (e.g. `nvim .`).
No recursion risk — `open_float()` calls `vim.cmd.edit()` directly and
never goes through `M.open()`.
Based on: stevearc/oil.nvim#298
Problem: running `nvim oil-ssh://host/` from the command line sometimes
emits "Oil split could not find parent window" immediately on startup.
The `WinNew` autocmd that transfers oil window vars to new splits fires
during startup before `BufEnter` has set `oil_did_enter` on any window,
so the parent search finds nothing and warns.
Solution: guard the callback with `vim.v.vim_did_enter ~= 1` so it is
silently skipped during the pre-`VimEnter` startup phase. After
`VimEnter` the split-transfer logic runs unchanged. `vim_did_enter` is
already used in `setup()` for the same startup-completion check.
Based on: stevearc/oil.nvim#325
* fix(view): reapply column highlights after paste and buffer edits
Problem: Column extmarks (icon color, per-character permissions) are
applied via `util.set_highlights` only during `render_buffer`. Neovim
does not duplicate extmarks on yank/paste, so lines inserted via `yyp`
or `p` render without any column highlights.
Solution: Store `col_width` and `col_align` in `session[bufnr]` after
each render. Add `M.reapply_highlights` which re-parses all buffer
lines, reconstructs the column chunk table, and re-applies extmarks via
`util.set_highlights`. Wire it to a `TextChanged` autocmd (guarded by
`_rendering[bufnr]` to skip oil's own `nvim_buf_set_lines` calls).
* fix(view): resolve LuaLS warnings in `reapply_highlights`
* feat(config): add per-host/bucket extra args for SSH, S3, and FTP
Problem: `extra_scp_args`, `extra_s3_args`, and `extra_curl_args` are
global — there's no way to pass adapter-specific args only to a single
host or bucket (e.g. `-O` for a Synology NAS that requires legacy SCP
protocol, or `--endpoint-url` for an R2 bucket).
Solution: add `ssh_hosts`, `s3_buckets`, and `ftp_hosts` config tables
that map exact hostnames/bucket names to per-target arg lists. Per-target
args are appended after the global args at call time. The `scp()` helper
in `ssh.lua` accepts a `hosts` list so cross-host copies deduplicate
host lookups. `create_s3_command` in `s3fs.lua` extracts the bucket from
the command args with no call-site changes needed. `resolved_curl_args`
in `ftp.lua` is called by both `curl()` and `ftpcmd()`.
Based on: stevearc/oil.nvim#607
* fix(view): reapply column highlights after paste and buffer edits
Problem: Column extmarks (icon color, per-character permissions) are
applied via `util.set_highlights` only during `render_buffer`. Neovim
does not duplicate extmarks on yank/paste, so lines inserted via `yyp`
or `p` render without any column highlights.
Solution: Store `col_width` and `col_align` in `session[bufnr]` after
each render. Add `M.reapply_highlights` which re-parses all buffer
lines, reconstructs the column chunk table, and re-applies extmarks via
`util.set_highlights`. Wire it to a `TextChanged` autocmd (guarded by
`_rendering[bufnr]` to skip oil's own `nvim_buf_set_lines` calls).
* fix(view): resolve LuaLS warnings in `reapply_highlights`
* fix(view): reapply column highlights after paste and buffer edits
Problem: Column extmarks (icon color, per-character permissions) are
applied via `util.set_highlights` only during `render_buffer`. Neovim
does not duplicate extmarks on yank/paste, so lines inserted via `yyp`
or `p` render without any column highlights.
Solution: Store `col_width` and `col_align` in `session[bufnr]` after
each render. Add `M.reapply_highlights` which re-parses all buffer
lines, reconstructs the column chunk table, and re-applies extmarks via
`util.set_highlights`. Wire it to a `TextChanged` autocmd (guarded by
`_rendering[bufnr]` to skip oil's own `nvim_buf_set_lines` calls).
* fix(view): resolve LuaLS warnings in `reapply_highlights`
* feat(ftp): add FTP/FTPS adapter via curl
Problem: canola has no way to browse or edit files on FTP servers,
despite the adapter system being designed for exactly this pattern.
curl speaks FTP natively, including FTPS (FTP over TLS), and requires
no new dependencies.
Solution: implement `lua/oil/adapters/ftp.lua` with `oil-ftp://` and
`oil-ftps://` schemes. Parses Unix and IIS LIST output, supports
`size`, `mtime`, and `permissions` columns, and implements the full
adapter API (list, read_file, write_file, render_action, perform_action).
Same-host renames use RNFR/RNTO; cross-host and local↔FTP copies use
curl download/upload through a tmpfile. Adds `extra_curl_args` config
option and documents the adapter in `doc/oil.txt`.
Based on: stevearc/oil.nvim#210
* docs(upstream): mark #210 fixed in #167
* fix(ftp): use python3 ftplib for control-channel FTP operations
Problem: DELE, RMD, MKD, and RNFR/RNTO were implemented using
curl --quote, which requires a subsequent LIST or STOR to trigger
the FTP connection. That data-channel operation hangs on slow or
busy servers, making every mutation appear stuck.
Solution: replace the curl --quote approach with a python3 ftplib
one-liner for all control-channel operations. ftplib executes DELE,
RMD, MKD, RNFR/RNTO, and SITE CHMOD without opening a data channel,
so they complete instantly. The curl wrapper is retained for LIST,
read_file, and write_file, which genuinely need a data channel.
* fix(ftp): use nil entry ID so cache assigns unique IDs
Problem: `M.list` returned entries as `{0, name, type, meta}`.
`cache.store_entry` only assigns a fresh ID when `entry[FIELD_ID] == nil`;
passing 0 caused every entry to be stored as ID 0, all overwriting
each other. `get_entry_by_id(0)` then always returned the last-stored
entry, breaking navigation (always opened the same file), rename
(wrong entry matched), and create (wrong diff).
Solution: change the placeholder from 0 to nil, matching how
`cache.create_entry` itself builds entries.
* fix(ftp): use ftp.rename() for RNFR/RNTO and raw Python lines in ftpcmd
Problem: `ftpcmd` wrapped every command in `ftp.voidcmd()`, which
expects a final 2xx response. `RNFR` returns 350 (intermediate),
so `voidcmd` raised an exception before `RNTO` was ever sent,
causing every rename to fail with '350 Ready for destination name'.
Solution: change `ftpcmd` to accept raw Python lines instead of FTP
command strings, then use `ftp.rename(src, dst)` for the rename case.
`ftplib.rename` handles the 350 intermediate response correctly
internally. All other callers now wrap their FTP commands in
`ftp.voidcmd()` explicitly.
* fix(ftp): recursively delete directory contents before RMD
Problem: FTP's RMD command fails with '550 Directory not empty'
if the directory has any contents. Unlike the S3 adapter which uses
`aws s3 rm --recursive`, FTP has no protocol-level recursive delete.
Solution: emit a Python rmtree helper inside the ftpcmd script that
walks the directory via MLSD, recursively deletes children (DELE for
files, rmtree for subdirs), then sends RMD on the now-empty directory.
* fix(ftp): give oil-ftps:// its own adapter name to prevent scheme clobbering
Problem: both oil-ftp:// and oil-ftps:// mapped to the adapter name
'ftp', so config.adapter_to_scheme['ftp'] was set to whichever scheme
pairs() iterated last — non-deterministic. init.lua uses
adapter_to_scheme[adapter.name] to reconstruct the parent URL, so
roughly half the time it injected 'oil-ftps://' into ftp:// buffer
navigation, causing the ssl-reqd error on '-' press.
Solution: register oil-ftps:// under adapter name 'ftps' via a
one-line shim that returns require('oil.adapters.ftp'). Now
adapter_to_scheme['ftp'] = 'oil-ftp://' and
adapter_to_scheme['ftps'] = 'oil-ftps://' are both stable.
* fix(ftp): percent-encode path in curl FTP URLs
Problem: filenames containing spaces (or other URL-unsafe characters)
caused curl to fail with "Unknown error" because the raw path was
concatenated directly into the FTP URL.
Solution: add `url_encode_path` to encode non-safe characters (excluding
`/`) before building the curl URL in `curl_ftp_url`.
* fix(ftp): fix STARTTLS, error visibility, and robustness
Problem: `curl_ftp_url` emitted `ftps://` (implicit TLS) for
`oil-ftps://` URLs, causing listing to fail against STARTTLS servers
while Python mutations worked — the two paths spoke different TLS
modes. curl's `-s` flag silenced all error output, producing "Unknown
error" on any curl failure. File creation used `/dev/null` (breaks on
Windows, diverges from S3). The Python TLS context didn't honour
`--insecure`/`-k` from `extra_curl_args`. Deleting non-empty dirs on
servers without MLSD gave a cryptic `500 Unknown command`.
Solution: Always emit `ftp://` in `curl_ftp_url`; TLS is enforced
solely via `--ssl-reqd`, making STARTTLS consistent between curl and
Python. Add `-S` to expose curl errors. Replace `/dev/null` with
`curl -T -` + `stdin='null'` (matches `s3fs` pattern). Mirror
`--insecure`/`-k` into the Python SSL context. Wrap `mlsd()` in
try/except with a clear actionable message. Add `spec/ftp_spec.lua`
with 28 unit tests covering URL parsing, list parsing, and curl URL
building. Update `doc/oil.txt` to document STARTTLS and MLSD.
* ci: format
* fix(ftp): resolve LuaLS type warnings in `curl` wrapper and `parse_unix_list_line`
* docs(upstream): consolidate stevearc/oil.nvim#325 into #164
Problem: upstream #325 (spurious "could not find parent window" warning
on startup) was still marked open in the tracker.
Solution: created canola.nvim#164 to track the `WinNew`/`BufEnter`
race condition and updated the tracker status.
* docs(upstream): triage stevearc/oil.nvim#280 as not actionable
Problem: upstream #280 (vim-projectionist support) was still marked
open. `BufNewFile` does not fire for oil-created files because the
file already exists on disk by the time it is opened.
Solution: the `OilFileCreated` user event is the correct hook point.
Added an `oil-recipe-file-templates` recipe documenting both a simple
template approach and a precise vim-projectionist shim via
`OilFileCreated`. Updated the tracker status.
* docs(upstream): close PR #721 as not actionable
`OilFileCreated` already covers the use case addressed by the
`create_hook` draft PR.
Problem: upstream #325 (spurious "could not find parent window" warning
on startup) was still marked open in the tracker.
Solution: created canola.nvim#164 to track the `WinNew`/`BufEnter`
race condition and updated the tracker status.
Problem: `mutation_in_progress` and `buffers_locked` are module-level
locals in `mutator/init.lua` and `view.lua`. When a trash test times
out mid-mutation, these flags stay true and `reset_editor()` never
clears them. Subsequent tests' `save()` calls bail on
`mutation_in_progress`, silently skipping mutations so
`OilMutationComplete` never fires — causing cascading 10s timeouts.
Solution: Add `mutator.reset()` to clear leaked mutation state, and
call it from `reset_editor()` when `is_mutating()` is true. A 50ms
event loop drain lets in-flight libuv callbacks settle before the
reset. Baseline: 4/10 sequential passes. After fix: 49/50 parallel
passes with zero timing overhead on the happy path (~2.4s).
* docs(upstream): mark #675 as duplicate of #117 (#124)
* docs(upstream): mark #617 fixed via cherry-picked #618
Problem: Issue #617 (filetype-based icon detection) was still listed as
`open` in the upstream tracker despite being addressed by PR #618.
Solution: Update status to `fixed — cherry-picked (#618)`. Verified
with manual testing that `use_slow_filetype_detection` correctly detects
shebangs in extensionless files.
* docs(upstream): mark #675 as duplicate of #117
Problem: Issue #675 (move file into folder by renaming) was listed as
`open` despite being a duplicate of #117, the primary tracking issue
for move-by-rename (46 upvotes). Upstream already closed#675 as such.
Solution: Update status to `duplicate of #117`.
* fix(float): support `close = false` for floating oil windows
Problem: `select` with `close = false` was broken for floating oil
windows. The float auto-close autocmd would always close the window
when focus left, and there was no mechanism to preserve it.
Solution: Add `oil_keep_open` window flag set when `close = false` is
used on a float. The auto-close autocmd checks this flag before closing.
On file select, focus returns to the original window behind the float
so the file opens there, then focus restores to the float.
* docs(upstream): mark stevearc/oil.nvim#399 as fixed (#159)
Problem: upstream issue #444 requests customizable opening behavior
(float, split, preview on startup).
Solution: mark as not actionable. The existing API (`oil.open`,
`oil.open_float`, `oil.open_split`, `oil.open_preview`) covers every
use case. A community member provided working solutions and the
reporter confirmed satisfaction.
Problem: upstream issue #335 requests preventing navigation above a
root directory to avoid accidental deletions.
Solution: mark as not actionable. The confirmation prompt and
`delete_to_trash` option already address the underlying concern.
0 reactions, reporter never followed up after stevearc's suggestion.
Problem: upstream issue #351 requests recovering deleted files from
Vim registers after saving the deletion.
Solution: mark as not actionable. The correct workflow is to move
before saving (enter target dir, paste, save once). The confirmation
prompt and `delete_to_trash` option already provide recovery safety
nets. stevearc explicitly declined implementing this.
Problem: upstream issue #396 requests custom preview renderers per
file type (images, PDFs, etc.).
Solution: mark as not actionable. The preview window is a normal
Neovim buffer — `BufReadCmd` autocmds already handle custom rendering
for any filetype across all of Neovim, not just oil. stevearc
explicitly declined adding a callback API for this.
docs: add paste-file-from-clipboard recipe (stevearc/oil.nvim#156)
Problem: users on macOS want to copy a file in Finder and paste it
into an oil directory. The parser rejects absolute paths, but a
recipe-level solution avoids touching the mutation pipeline entirely.
Solution: add `oil-recipe-paste-file-from-clipboard` recipe that reads
the system clipboard, resolves it as a file path, and copies it into
the current oil directory via `vim.uv.fs_copyfile`.
Problem: upstream issue #303 (preview in float window mode) is tracked
as open, but was implemented upstream in PR #403 (`59b3dab`) and is
already present in canola.
Solution: mark as fixed with reference to upstream PR #403 and the
`config.float.preview_split` config option it introduced.
docs(upstream): consolidate move issues #117, #289, #675, #707, #708 into #32
Problem: five upstream issues/PRs all describe the same feature —
moving files into new directories by editing the filename with path
separators — but were tracked separately.
Solution: update canola.nvim#32 with a proper description consolidating
all of them, and point all tracker entries at #32.
docs(upstream): consolidate session issues #232, #664, #678 into #149
Problem: three upstream issues (#232, #664, #678) all stem from the
same root cause — `buftype='acwrite'` interacting poorly with session
save/restore.
Solution: create canola.nvim#149 to track session restore
compatibility and mark all three upstream issues as consolidated.
docs(upstream): fix swapped description/status columns for #288, #726
Problem: issues #288 and #726 had their justifications in the
description column instead of the status column, leaving the status
as bare `not actionable` with no reason.
Solution: move justifications into the status column and replace
descriptions with the actual upstream issue titles.
Problem: upstream issue #349 requests a ranger-style Miller columns
layout. This is a fundamentally different navigation paradigm from
oil's buffer-as-filesystem model.
Solution: mark as not actionable and point to `mini.files`, which
stevearc himself recommended as the purpose-built alternative.
Problem: the permissions column rendered as a monolithic unstyled
string, making it hard to scan `rwx` bits at a glance.
Solution: add per-character highlight groups for permission characters
following the `eza`/`lsd` convention. All groups link to standard
Neovim highlights so every colorscheme works out of the box.
Problem: users wanted a visual indicator on the originating file when
opening a directory listing from a file buffer.
Solution: add `oil-recipe-highlight-opened-file` recipe that uses
`OilReadPost` to flash an extmark highlight on the cursor entry for
1.5 seconds after render.
Problem: upstream issue #85 (git status column) was still marked open.
This is tracked by our git integration issue #121.
Solution: mark as consolidated into #121, alongside the previously
consolidated #571.
Problem: three upstream requests (#655, #667, #736) all target the
same architectural change — rendering columns as extmark virtual text
instead of inline buffer text.
Solution: create canonical issue #142 and consolidate all three.
Problem: upstream issue #571 (callback before `highlight_filename`)
was still marked open. The underlying use case is per-directory git
status, which existing extensions already solve.
Solution: mark as not actionable.
Problem: upstream issue #466 (select into window on right) was still
marked open despite being trivially solvable with a custom action.
Solution: mark as not actionable. Users can write their own action
using `oil.select()` and window layout inspection.
Problem: the `:help oil-adapter-ssh` section was only 10 lines covering
URL format and server requirements. Users had no guidance on how the
adapter works, how to configure `extra_scp_args`, or how to troubleshoot
connection issues.
Solution: expand the section with architecture overview (persistent SSH
connection, `scp` for file transfer, no local mount), configuration
(`extra_scp_args`, `~/.ssh/config`), limitations (no third-party plugin
integration, no cross-adapter moves), and troubleshooting tips.
Problem: upstream issue #738 (allow changing mtime/atime via time
column) was still marked open despite requiring disproportionate
implementation effort (reverse strftime parser, new mutator action
type, per-adapter `utime` support) with zero community demand.
Solution: mark as not actionable. Purpose-built tools like `touch -t`
already handle the underlying need.
Problem: in insert mode, `<BS>`, `<C-h>`, `<C-w>`, and `<C-u>` could
delete backwards past the name column boundary into the icon/permissions/ID
prefix, corrupting the line and breaking the parser.
Solution: add buffer-local insert-mode expr keymaps that compute the name
column boundary (cached per line) and return no-op when the cursor is
already at or before it. `<C-u>` emits exactly enough `<BS>` keys to
delete back to the boundary, never past it.
Closes#133
* docs(upstream): track #254 in canola.nvim#129
Problem: Issue #254 (highlights lost during mid-edit) was listed as
`open`. Investigation shows a decoration provider approach can solve
this despite stevearc's extmark limitation assessment.
Solution: Created barrettruth/canola.nvim#129 with full technical
analysis and proposed `nvim_set_decoration_provider` approach. Mark
#254 as `tracked in #129`.
* docs(upstream): mark #449 not actionable
Problem: Issue #449 (LSP rename failing on TypeScript files) was listed
as `open` despite being a configuration issue.
Solution: Mark as `not actionable`. The LSP rename times out on large
TypeScript projects; increasing `lsp_file_methods.timeout_ms` resolves
it. stevearc confirmed this in the issue thread.
* docs(upstream): mark #416 fixed via cherry-picked #725
Problem: Issue #416 (case-sensitive keymap comparison preventing
remaps) was listed as `open` despite being fixed by the keymap
normalization in PR #725.
Solution: Mark as `fixed — cherry-picked (#725)`. The
`nvim_replace_termcodes` normalization in `config.lua` resolves
case variants like `<c-e>` and `<C-e>` to the same key.
* docs(upstream): mark #479 not actionable
Problem: Issue #479 (harpoon integration recipe) was listed as `open`
despite being a stale documentation request from 2024 with zero
engagement.
Solution: Mark as `not actionable — no demand, stale`.
* docs(upstream): track #254 in canola.nvim#129
Problem: Issue #254 (highlights lost during mid-edit) was listed as
`open`. Investigation shows a decoration provider approach can solve
this despite stevearc's extmark limitation assessment.
Solution: Created barrettruth/canola.nvim#129 with full technical
analysis and proposed `nvim_set_decoration_provider` approach. Mark
#254 as `tracked in #129`.
* docs(upstream): mark #449 not actionable
Problem: Issue #449 (LSP rename failing on TypeScript files) was listed
as `open` despite being a configuration issue.
Solution: Mark as `not actionable`. The LSP rename times out on large
TypeScript projects; increasing `lsp_file_methods.timeout_ms` resolves
it. stevearc confirmed this in the issue thread.
* docs(upstream): mark #416 fixed via cherry-picked #725
Problem: Issue #416 (case-sensitive keymap comparison preventing
remaps) was listed as `open` despite being fixed by the keymap
normalization in PR #725.
Solution: Mark as `fixed — cherry-picked (#725)`. The
`nvim_replace_termcodes` normalization in `config.lua` resolves
case variants like `<c-e>` and `<C-e>` to the same key.
* docs(upstream): track #254 in canola.nvim#129
Problem: Issue #254 (highlights lost during mid-edit) was listed as
`open`. Investigation shows a decoration provider approach can solve
this despite stevearc's extmark limitation assessment.
Solution: Created barrettruth/canola.nvim#129 with full technical
analysis and proposed `nvim_set_decoration_provider` approach. Mark
#254 as `tracked in #129`.
* docs(upstream): mark #449 not actionable
Problem: Issue #449 (LSP rename failing on TypeScript files) was listed
as `open` despite being a configuration issue.
Solution: Mark as `not actionable`. The LSP rename times out on large
TypeScript projects; increasing `lsp_file_methods.timeout_ms` resolves
it. stevearc confirmed this in the issue thread.
Problem: Issue #254 (highlights lost during mid-edit) was listed as
`open`. Investigation shows a decoration provider approach can solve
this despite stevearc's extmark limitation assessment.
Solution: Created barrettruth/canola.nvim#129 with full technical
analysis and proposed `nvim_set_decoration_provider` approach. Mark
#254 as `tracked in #129`.
* docs(upstream): mark #617 fixed via cherry-picked #618
Problem: Issue #617 (filetype-based icon detection) was still listed as
`open` in the upstream tracker despite being addressed by PR #618.
Solution: Update status to `fixed — cherry-picked (#618)`. Verified
with manual testing that `use_slow_filetype_detection` correctly detects
shebangs in extensionless files.
* docs(upstream): mark #675 as duplicate of #117
Problem: Issue #675 (move file into folder by renaming) was listed as
`open` despite being a duplicate of #117, the primary tracking issue
for move-by-rename (46 upvotes). Upstream already closed#675 as such.
Solution: Update status to `duplicate of #117`.
* docs(upstream): mark #707 as duplicate of #117
Problem: Issue #707 (move file/dir into new dir by renaming) was listed
as `open` despite being identical to #117. The associated draft PR #708
is already tracked separately in the PRs table.
Solution: Update status to `duplicate of #117`.
* docs(upstream): consolidate owner/group issues into #126
Problem: Three upstream issues (#436, #599, #684) all request the same
feature — owner/group columns in the directory listing.
Solution: Create canonical tracking issue barrettruth/canola.nvim#126
and mark all three as `consolidated into #126`.
* docs(upstream): mark #570 not actionable
Problem: Issue #570 (`c0`/`d0` deletes concealed entry ID prefix,
causing rename to be parsed as delete+create) was listed as `open`.
Solution: Mark as `not actionable — blocked on Neovim extmark API`.
Neovim provides no mechanism to protect concealed extmark text from
operator-pending motions. The intended rename workflow uses `cw`/`ciw`
within the constrained cursor region.
* docs(upstream): mark #617 fixed via cherry-picked #618
Problem: Issue #617 (filetype-based icon detection) was still listed as
`open` in the upstream tracker despite being addressed by PR #618.
Solution: Update status to `fixed — cherry-picked (#618)`. Verified
with manual testing that `use_slow_filetype_detection` correctly detects
shebangs in extensionless files.
* docs(upstream): mark #675 as duplicate of #117
Problem: Issue #675 (move file into folder by renaming) was listed as
`open` despite being a duplicate of #117, the primary tracking issue
for move-by-rename (46 upvotes). Upstream already closed#675 as such.
Solution: Update status to `duplicate of #117`.
* docs(upstream): mark #707 as duplicate of #117
Problem: Issue #707 (move file/dir into new dir by renaming) was listed
as `open` despite being identical to #117. The associated draft PR #708
is already tracked separately in the PRs table.
Solution: Update status to `duplicate of #117`.
* docs(upstream): consolidate owner/group issues into #126
Problem: Three upstream issues (#436, #599, #684) all request the same
feature — owner/group columns in the directory listing.
Solution: Create canonical tracking issue barrettruth/canola.nvim#126
and mark all three as `consolidated into #126`.
* docs(upstream): mark #617 fixed via cherry-picked #618
Problem: Issue #617 (filetype-based icon detection) was still listed as
`open` in the upstream tracker despite being addressed by PR #618.
Solution: Update status to `fixed — cherry-picked (#618)`. Verified
with manual testing that `use_slow_filetype_detection` correctly detects
shebangs in extensionless files.
* docs(upstream): mark #675 as duplicate of #117
Problem: Issue #675 (move file into folder by renaming) was listed as
`open` despite being a duplicate of #117, the primary tracking issue
for move-by-rename (46 upvotes). Upstream already closed#675 as such.
Solution: Update status to `duplicate of #117`.
* docs(upstream): mark #707 as duplicate of #117
Problem: Issue #707 (move file/dir into new dir by renaming) was listed
as `open` despite being identical to #117. The associated draft PR #708
is already tracked separately in the PRs table.
Solution: Update status to `duplicate of #117`.
* docs(upstream): mark #617 fixed via cherry-picked #618
Problem: Issue #617 (filetype-based icon detection) was still listed as
`open` in the upstream tracker despite being addressed by PR #618.
Solution: Update status to `fixed — cherry-picked (#618)`. Verified
with manual testing that `use_slow_filetype_detection` correctly detects
shebangs in extensionless files.
* docs(upstream): mark #675 as duplicate of #117
Problem: Issue #675 (move file into folder by renaming) was listed as
`open` despite being a duplicate of #117, the primary tracking issue
for move-by-rename (46 upvotes). Upstream already closed#675 as such.
Solution: Update status to `duplicate of #117`.
Problem: Issue #617 (filetype-based icon detection) was still listed as
`open` in the upstream tracker despite being addressed by PR #618.
Solution: Update status to `fixed — cherry-picked (#618)`. Verified
with manual testing that `use_slow_filetype_detection` correctly detects
shebangs in extensionless files.
Problem: Issue #675 (move file into folder by renaming) is an exact
duplicate of #117, which is the original request with ~20 comments,
stevearc acknowledgment, and a linked POC PR #708.
Solution: Update `doc/upstream.md` to mark #675 as a duplicate of #117.
* refactor: revert module namespace from canola back to oil
Problem: the canola rename creates unnecessary friction for users
migrating from stevearc/oil.nvim — every `require('oil')` call and
config reference must change.
Solution: revert all module paths, URL schemes, autocmd groups,
highlight groups, and filetype names back to `oil`. The repo stays
`canola.nvim` for identity; the code is a drop-in replacement.
* refactor: remove `vim.g.oil` declarative config
Problem: the `vim.g.oil` configuration path was added prematurely.
It adds a second config entrypoint before the plugin has stabilized
enough to justify it.
Solution: remove `vim.g.oil` support from `plugin/oil.lua`,
`config.setup()`, docs, and tests. Users configure via
`require("oil").setup({})`.
Problem: `get_current_dir()` returns nil for non-local adapters (SSH,
S3, trash), leaving users with no public API to get the current
buffer's location.
Solution: add `get_current_url()` which returns the full canola URL
for any adapter, or nil if not in a canola buffer.
Based on: stevearc/oil.nvim#646
docs(upstream): mark #382 not actionable (#482)
Problem: upstream issue #382 requests relative paths in the window
title, but this is already solved by the `get_win_title` callback
added in stevearc/oil.nvim#482.
Solution: mark the issue as not actionable in the tracker.
Problem: upstream issue #431 (SSH adapter documentation) is a
duplicate of #525 which covers the same request with more detail.
Solution: mark as duplicate of #525.
Problem: upstream issue #332 (buffer not fixed to floating window via
ctrl-o jumplist) is unresolved in our tracker.
Solution: mark as not actionable. Cannot reproduce — ctrl-o in the
float navigates back through oil directories, does not escape to file
buffers. Reported on nvim 0.10.0-dev (2023).
Problem: upstream issue #435 (LSP semantic token errors on preview)
is unresolved in our tracker.
Solution: mark as fixed. Upstream PR #467 (scratch buffer previews)
was merged Nov 2024 and is already in our codebase.
Problem: #623 was marked not actionable as a cross-plugin issue, but
oil's nonstandard buffer opening (`bufadd` + manual `buflisted` +
`vim.cmd.buffer()`) may be the root cause.
Solution: revert status to open for further investigation.
Problem: upstream issue #200 (highlights not working when opening a
file) is unresolved in our tracker.
Solution: mark as not actionable. Reported on nvim 0.9.4, no recent
reports, cannot reproduce on current versions.
