Coder Social home page Coder Social logo

Comments (11)

gegoune avatar gegoune commented on July 17, 2024 2

@tamago324 Amazing plugin, happily replaced dirvish with lir. I also have couple of thoughts:

  1. One thing I am missing is ability to place float window where I want to. Would you mind exposing col and row from
    row = top,
    col = left,
    ? If so, I can give PR a go.

Another possibility would be to allow users to pass in function that creates floating window, like in fzf:

vim.g.fzf_layout = { window = "lua require('utils').floatingLow()" }
  1. You are computing border's highlight group
    local make_border_opts = function(borderchars)
    return vim.tbl_map(function(char)
    return { char, "LirFloatBorder" }
    end, borderchars)
    end
    I would prefer to pass custom border along with highlight groups, which is currently impossible.

I would suggest removing that function, removing LirFloatBorder highlight group altogether and just set default allowing users to pass in their own. Once again, I might just have enough lua knowledge to come up with PR.

  1. Would love to have your new_file custom function distributed. I am yet to get it work locally, but it is what I am used to in nvim-tree and it is big improvement in my opinion.

Once again, great plugin, thanks for all your work on it!

from lir.nvim.

dhruvmanila avatar dhruvmanila commented on July 17, 2024 1

With the new PR, we can dynamically calculate the position of the floating window. This allows us to do something like this:

lir_floating_win.mov

Config for the above:

local api = vim.api

-- Construct the Lir floating window options according to the window we are
-- currently in. The position of the window will be centered in the current
-- window, thus not blocking other windows if opened.
---@return table<string, any>
local function construct_win_opts()
  local winpos = api.nvim_win_get_position(0)
  local winwidth = api.nvim_win_get_width(0)
  local winheight = api.nvim_win_get_height(0)

  local width = math.min(80, winwidth - 14)
  local height = winheight - 6
  local row = (winheight / 2) - (height / 2) - 1
  local col = (winwidth / 2) - (width / 2)

  return {
    width = width,
    height = height,
    row = row + winpos[1],
    col = col + winpos[2],
  }
end

lir.setup {
  float = {
    win_opts = construct_win_opts,
  }
}

from lir.nvim.

dhruvmanila avatar dhruvmanila commented on July 17, 2024 1

I believe this issue can be closed as most of the features have been implemented. If you want to keep it open, please feel free to reopen it 😄

Thanks everyone for their ideas and suggestions 👍

from lir.nvim.

tamago324 avatar tamago324 commented on July 17, 2024

Thank you for the suggestion!
I will share my thoughts below.

For floating window:

  • Provide additional options like width_percentage/height_percentage. This will allow configuration to make the window have more height then width, as most of the space is just empty.

I agree.
My idea is to implement it so that it can be specified as size_percentage = 0.5 or size_percentage = { width = 0.5, height = 0.7 }. What do you think?
The advantage of being able to specify width and height in this way is that you can explicitly specify width and height only when you want to specify them separately.
It also allows you to use the current option values.

  • Option to enable file details like ls -l/Telescope file_browser and ability to toggle them in the buffer similar to show_hidden_files/actions.toggle_show_hidden

I don't think it is necessary because I like the simplicity of the current display.
However, I am curious to see how it will be displayed and implemented.
Do you have a screen capture or something?

  • Update implementation for newfile to be similar to that of mkdir. Currently, newfile opens the buffer with the filename, but does not actually create the file unless we save the buffer.

I think it is fine as it is now.
I would like to keep the default implementation of new_file in lir.nvim concise and let users implement it freely.
In fact, I use my own implementation of it.

#22

I agree.
I would like to specify nowait directly in the mapping.
If there are any problems in the future, I may make it possible to specify it as in gitsign.nvim.

Delete the buffer when deleting files/directories, similar to how vim-eunuch does with :Delete: Delete a buffer and the file on disk simultaneously. or maybe provide two options, again similar to vim-eunuch: (1) To delete both buffer and file, (2) To only delete the file (already provided)

I agree.
I would like to have two actions like in vim-eunuch.
Currently, actions.delete() is the implementation of (2).
What do you think would be a good action name for (1)?

from lir.nvim.

dhruvmanila avatar dhruvmanila commented on July 17, 2024

Thanks for taking a look at all of them, appreciate it :)

My idea is to implement it so that it can be specified as size_percentage = 0.5 or size_percentage = { width = 0.5, height = 0.7 }. What do you think?

Yes, this is much better :)

I don't think it is necessary because I like the simplicity of the current display.
However, I am curious to see how it will be displayed and implemented.
Do you have a screen capture or something?

True, I prefer simplicity as well, although I was just curious if something like that would be of interest.

This is what is shown in nnn terminal file manager:

Screenshot 2021-05-23 at 14 11 22

And this is in Telescope file_browser:

Screenshot 2021-05-23 at 14 11 53

Mainly what I look for is just permissions and file size, maybe sometimes last modified time but not more than that.

I think it is fine as it is now.
I would like to keep the default implementation of new_file in lir.nvim concise and let users implement it freely.
In fact, I use my own implementation of it.

Understood. I am curious as to what your implementation is like. I have just adopted it from mkdir but used Path:touch() instead.

I agree.
I would like to specify nowait directly in the mapping.
If there are any problems in the future, I may make it possible to specify it as in gitsign.nvim.

I'll open a PR for that unless you have already implemented it :)

I agree.
I would like to have two actions like in vim-eunuch.
Currently, actions.delete() is the implementation of (2).
What do you think would be a good action name for (1)?

How about actions.remove() ? Others could be: destroy (too much lol), clean, wipeout (similar to bufwipeout). This should be properly documented and maybe put in the README as it might be confusing at first.


While writing this, I got another idea 💡
The floating window should be opened centered as per the current window. So, if there are splits, lir floating window will be opened in the current window. Actually, this does not seem like that of a great idea, but just putting out here in case someone likes this :)

It would be similar to the screenshot in this issue although that is a tmux pane.

from lir.nvim.

tamago324 avatar tamago324 commented on July 17, 2024

Yes, this is much better :)

Thank you for the pull request.

True, I prefer simplicity as well, although I was just curious if something like that would be of interest.

  • This is what is shown in nnn terminal file manager:
  • And this is in Telescope file_browser:
    Mainly what I look for is just permissions and file size, maybe sometimes last modified time but not more than that.

I see!
I'm not sure if that display can be implemented, but I'm interested.

Understood. I am curious as to what your implementation is like. I have just adopted it from mkdir but used Path:touch() instead.

Thanks for understanding.

My new_file implementation:

It has the following useful features.

  • If the input value ends with '/', the directory will be created and
  • If the input value contains '/', and the directory does not exist, it will be created recursively
  • If the input file name does not contain '.' or '/', check if it is a directory.
  • If the first string is '.' and show_hidden_files is false, set it to true and display it again.
local no_confirm_patterns = {
  '^LICENSE$',
  '^Makefile$'
}

local need_confirm = function(filename)
  for _, pattern in ipairs(no_confirm_patterns) do
    if not filename:match(pattern) then
      return true
    end
  end
  return false
end

local function newfile()
  local save_curdir = vim.fn.getcwd()
  lcd(lir.get_context().dir)
  local name = vim.fn.input('New file: ', '', 'file')
  lcd(save_curdir)

  if name == '' then
    return
  end

  if name == '.' or name == '..' then
    utils.error('Invalid file name: ' .. name)
    return
  end

  -- If I need to check, I will.
  if need_confirm(name) then
    -- '.' is not included or '/' is not included, then
    -- I may have entered it as a directory, I'll check.
    if not name:match('%.') and not name:match('/') then
      if vim.fn.confirm("Directory?", "&No\n&Yes", 1) == 2 then
        name = name .. '/'
      end
    end
  end

  local path = Path:new(lir.get_context().dir .. name)
  if string.match(name, '/$') then
    -- mkdir
    name = name:gsub('/$', '')
    path:mkdir({
      parents = true,
      mode = tonumber('700', 8),
      exists_ok = false
    })
  else
    -- touch
    path:touch({
      parents = true,
      mode = tonumber('644', 8),
    })
  end

  -- If the first character is '.' and show_hidden_files is false, set it to true
  if name:match([[^%.]]) and not config.values.show_hidden_files then
    config.values.show_hidden_files = true
  end

  actions.reload()

  -- Jump to a line in the parent directory of the file you created.
  local lnum = lir.get_context():indexof(name:match('^[^/]+'))
  if lnum then
    vim.cmd(tostring(lnum))
  end
e

I'll open a PR for that unless you have already implemented it :)

I've merged! Thank you!

How about actions.remove() ? Others could be: destroy (too much lol), clean, wipeout (similar to bufwipeout). This should be properly documented and maybe put in the README as it might be confusing at first.

Thanks for the suggestions. As for me, I like wipeout()!
You're right, I need to specify the function in the README.md and :help.

While writing this, I got another idea bulb
The floating window should be opened centered as per the current window. So, if there are splits, lir floating window will be opened in the current window. Actually, this does not seem like that of a great idea, but just putting out here in case someone likes this :)

It would be similar to the screenshot in this issue although that is a tmux pane.

That sounds kind of interesting.
Also, thanks for putting the idea here.

from lir.nvim.

windwp avatar windwp commented on July 17, 2024

do you consider render it like a tree. it will make easy to view project structure.
I know it have a reason to not do that but maybe we can have an option

from lir.nvim.

tamago324 avatar tamago324 commented on July 17, 2024

@windwp Thanks for the suggestion.
However, I think you should use nvim-tree.lua to display the tree.
In lir.nvim, I would like to focus only on the display of a single directory.

from lir.nvim.

tamago324 avatar tamago324 commented on July 17, 2024

@gegoune Thank you for the suggestion.

  1. One thing I am missing is ability to place float window where I want to. Would you mind exposing col and row from

Yes, I would like to be able to set the col and row to user configurable.
I was thinking w passing a function to the float, and then generating a floating window with the options returned by the function (a config-like table that nvim_open_win receives).

require'lir'.setup {
  -- ...
  float = function()
    -- nvim_open_win() の config の値
    return {
      relative = "editor",
      row = 10,
      col = 5,
      width = math.floor(vim.o.columns * 0,5),
      height = math.floor(vim.o.lines * 0.5),
      style = "minimal",
      border = 'single',
    }
  end
}

Is it bad to pass a function?
This means that if the user only wants to set row and col, they will have to specify a function.

  1. You are computing border's highlight group ...

Regarding the border setting, I don't have any trouble with the way it is currently set, but what would it allow me to do if I could set it as you suggest?

  1. Would love to have your new_file custom function distributed. I am yet to get it work locally, but it is what I am used to in nvim-tree and it is big improvement in my opinion.

Do you want to customize the newfile?
If that's what you mean, then action can be set to any function, so you can map it freely as follows If that's what you mean, you can set a function for action, which can be freely mapped as follows

local lir = require'lir'
local Path = require("plenary.path")


lir.setup({
  -- ...
  mappings = {
    ["K"] = function()
      local name = vim.fn.input("New file: ", "")
      if name == "" then
        return
      end
      local path = Path:new(lir.get_context().dir .. name)
      path:touch({
        parents = true,
        mode = tonumber("644", 8),
      })

      actions.reload()
    end,
  }
}

from lir.nvim.

tamago324 avatar tamago324 commented on July 17, 2024

@gegoune PR (#32) was created.
You should now be able to freely configure the floating window config.
Please give it a try and let us know what you think if it is possible.

from lir.nvim.

tamago324 avatar tamago324 commented on July 17, 2024

That's very cool 👏
Also, thank you for providing an example of your setup. I think this will make it easier for other users to configure the settings.

from lir.nvim.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.