dharmx / nvim

Blazingly fast SHUTTHEFUCKUP.
GNU General Public License v3.0
85 stars 0 forks source link

replace vimscript functions with lua ones and plenary ones + DRY up exclude #6

Closed matu3ba closed 1 year ago

matu3ba commented 1 year ago

Also, exclude in init.lua of core and plug could be DRYed up.

dharmx commented 1 year ago

Hey, there!

vim.fn.readdir (plenary)

This might not be possible because plenary is not available on the first run. Also, I am assuming that you are suggesting to use plenary.scandir instead? And, if that is the case then the code will look unsanitary as opposed to fn.readdir.

local scan = require("plenary.scandir").scan_dir
scan(vim.fn.stdpath("config") .. "/lua/dharmx/core", {
  add_dirs = false,
  depth = 1,
  silent = true,
  on_insert = function(entry)
    -- returns absolute path
    dofile(entry) -- this causes problems sometimes
    -- maybe use require + fnamemodify
    -- or maybe use require + split
  end
})

Additionally, if I use the vim.loop.fs_scandir and vim.loop.fs_scandir_next functions that is wrapped by scan_dir then that would require even more validation and checks (I actually did this before).

vim.fn.stdpath (superfluous)

How? One might try to run my config over an existing config by supplying the RCPATH via -u which will morph the config path.

vim.fn.fnamemodify (plenary)

Are you suggesting me to use vim.split instead? Or, is there a equivalent utility in plenary? I checked plenary.strings and couldn't find any. plenary.path also has nothing.

-- say
local stem = vim.fn.stdpath("config") .. "/lua/dharmx/core/autocmd.lua"
stem = vim.split(stem, "/", { plain = true })
stem = stem[#stem]
stem = vim.split(stem, ".", { plain = true })
stem = stem[#stem]
print(stem) -- "autocmd"

Also, exclude in init.lua of core and plug could be DRYed up.

Yes. I will do this shortly :)


Let me know if you have any more suggestion/solutions. Personally I dislike using vimscript functions but, here I do not think I have any other choice.

matu3ba commented 1 year ago

This might not be possible because plenary is not available on the first run.

Ah, yeah. Totally forgot about that. The user can overwrite $XDG_PATH with the environment variable $NVIM_APPNAME.

matu3ba commented 1 year ago

btw, master has now a change to read all files from a path merged in bc15b075d14c85098d674a2466d2386e08b0005f with examples.

fnamemodify with :r does (see :h expand): "root (one extension removed)". This can be replaced with vim.fs.basename. Unfortunately the docs assume you check man basename for the meaning of that POSIX function.

dharmx commented 1 year ago

The user can overwrite $XDG_PATH with the environment variable $NVIM_APPNAME.

This seems like a nightly feature. I would switch to that after it becomes stable.

This can be replaced with vim.fs.basename. Unfortunately the docs assume you check man basename for the meaning of that POSIX function.

IIRC it is not a complete replication of GNU basename. It does not allow any additional arguments hence vim.fs.basename("/a/b/c/d/v.lua") will yield "v.lua" as opposed the stem of the path i.e. "v". Whereas, basename -s .lua /a/b/c/d/v.lua yields v.

I completely forgot about the existence of vim.fs by the way. This made me aware of vim.fs.dir which is an iterator over a directory's files. This might eliminate scan_dir or, readdir

master has now a change to read all files from a path merged in bc15b075d14c85098d674a2466d2386e08b0005f with examples.

Can't seem to find this.

matu3ba commented 1 year ago

IIRC it is not a complete replication of GNU basename.

Oh, POSIX as usual, is horribly under specified https://pubs.opengroup.org/onlinepubs/9699919799/utilities/basename.html and you are correct https://man7.org/linux/man-pages/man3/basename.3.html

Can you make an issue on this, such that 1. either it gets properly documented and/or 2. function gets renamed and/or 3. semantics get changed to "what most people expect" how basename works ?

Can't seem to find this.

https://github.com/neovim/neovim/commit/bc15b075d14c85098d674a2466d2386e08b0005f

dharmx commented 1 year ago

Can you make an issue on this, such that 1. either it gets properly documented and/or 2. function gets renamed and/or 3. semantics get changed to "what most people expect" how basename works?

Sure. But before that you should probably see the source of vim.fs.basename :rofl:.

dharmx commented 1 year ago

Okay. Nevermind they actually wrote the function now. It is like the following in stable:

--- Return the basename of the given file or directory
---
---@param file (string) File or directory
---@return (string) Basename of {file}
function M.basename(file)
  return vim.fn.fnamemodify(file, ':t')
end
dharmx commented 1 year ago

Closing this!