Where are the build instructions in your Wiki?

Where are the build instructions in your Wiki?

Thanks. Perhaps it should be updated in
https://github.com/PascalCoin/PascalCoin#how-to-compile


How can i get the DH parameter to compute the Jacobian in null space？

How can i get the DH parameter to compute the Jacobian in null space？
in urdf？

@wangjunhe8127, You can find the DH parameters of the robot here.

Hi @wangjunhe8127 ,
I hope @peasant98 could answer your question, thanks!
If anything is still open, don't hesitate to throw it at us... :smile:
Cheers,
Andreas


Unable to add management IP to Azure Firewall instance

This is autogenerated. Please review and update as needed.
Describe the bug
I would like to enable forced tunneling on Azure Firewall via Azure CLI.
Command Name
az network firewall management-ip-config update Extension Name: azure-firewall. Version: 0.13.0.
Errors:
The command failed with an unexpected error. Here is the traceback:
'NoneType' object has no attribute 'public_ip_address'
Traceback (most recent call last):
  File "/opt/az/lib/python3.8/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/opt/az/lib/python3.8/site-packages/azure/cli/core/commands/__init__.py", line 658, in execute
    raise ex
  File "/opt/az/lib/python3.8/site-packages/azure/cli/core/commands/__init__.py", line 721, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/opt/az/lib/python3.8/site-packages/azure/cli/core/commands/__init__.py", line 692, in _run_job
    result = cmd_copy(params)
  File "/opt/az/lib/python3.8/site-packages/azure/cli/core/commands/__init__.py", line 328, in __call__
    return self.handler(*args, **kwargs)
  File "/opt/az/lib/python3.8/site-packages/azure/cli/core/commands/command_operation.py", line 200, in handler
    instance = custom_function(instance=instance, **custom_func_args)
  File "/home/k/.azure/cliextensions/azure-firewall/azext_firewall/custom.py", line 249, in update_af_management_ip_configuration
    instance.management_ip_configuration.public_ip_address = SubResource(id=public_ip_address)
AttributeError: 'NoneType' object has no attribute 'public_ip_address'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

az network firewall create --resource-group {} --name {} --firewall-policy {}
az network firewall management-ip-config update --resource-group {} --firewall-name {} --vnet-name {} --public-ip-address {}

Expected Behavior
I could create an Azure Firewall instance with forced tunneling enabled via Azure CLI.
Environment Summary
Linux-5.4.0-1077-azure-x86_64-with-glibc2.28 (Cloud Shell), Common Base Linux Delridge (quinault)
Python 3.8.13
Installer: DEB

azure-cli 2.36.0

Extensions:
azure-firewall 0.13.0
ai-examples 0.2.5
ssh 1.1.0

Dependencies:
msal 1.17.0
azure-mgmt-resource 20.0.0

Additional Context
None

network

Hi:
@kehao-chen 'management-ip-config' should be created before using update command, but now it has something wrong with creating function, for more information,pls refer: https://github.com/Azure/azure-cli-extensions/issues/1270.
Best wishes.


pocket settings not working with free version of spotify

i have 2 accounts, one with and one without premium.
the one with premium has a settings button on the top bar which allows me to change the colours and overall theme.
however, when i log in on my account without premium, the settings icon goes
is this normal? and is there a fix to this? as i would love to be able to use the colour scheme i made for my other account too.
thanks :D

this is the button im talking about, by the way

I do not have a free account so I can't test this, did you try restarting spotify after switching account?


Fixing import bugs

Paths in the src folder still reference the PDS directory, need to be changed to software-discovery-tool.
The log file is missing, giving the following errors:

________________ ERROR collecting test_json.py ________________
test_json.py:7: in <module>
    from config.config import server_host
../config/__init__.py:1: in <module>
    from .config import *
../config/config.py:75: in <module>
    logging.basicConfig(format='%(asctime)s %(message)s', filename=LOG_FILE_LOCATION, level=DEBUG_LEVEL)
/usr/lib/python3.8/logging/__init__.py:1976: in basicConfig
    h = FileHandler(filename, mode)
/usr/lib/python3.8/logging/__init__.py:1143: in __init__
    StreamHandler.__init__(self, self._open())
/usr/lib/python3.8/logging/__init__.py:1172: in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding)
E   FileNotFoundError: [Errno 2] No such file or directory: '/opt/software-discovery-tool/log/pds.log'
_______________ ERROR collecting test_render.py _______________
test_render.py:6: in <module>
    from config.config import server_host
../config/__init__.py:1: in <module>
    from .config import *
../config/config.py:75: in <module>
    logging.basicConfig(format='%(asctime)s %(message)s', filename=LOG_FILE_LOCATION, level=DEBUG_LEVEL)
/usr/lib/python3.8/logging/__init__.py:1976: in basicConfig
    h = FileHandler(filename, mode)
/usr/lib/python3.8/logging/__init__.py:1143: in __init__
    StreamHandler.__init__(self, self._open())
/usr/lib/python3.8/logging/__init__.py:1172: in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding)
E   FileNotFoundError: [Errno 2] No such file or directory: '/opt/software-discovery-tool/log/pds.log'

collections packages imported but not used in package_search.py leads to DeprecationWarning:

  /usr/local/lib/python3.8/dist-packages/requests/packages/urllib3/_collections.py:2: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
    from collections import Mapping, MutableMapping

@pleia2 I'll give it a look. Can you assign this issue to me.

Hey @pleia2 there was config error that has been resolved.

@indranilm256 had asked me to look into :))
config error was both in SUSE and ubuntu
Does anybody know who put this config.config here? Problem was here itself

currently trying to resolve the rest 2 warnings. Will send a PR right after:

We can close this issue, warnings were  local to my system. Using a python virtual environment solved it


Incompatibility with Laravel 8 schema_dump

Because this image is based on Alpine, when asked to install MySQL client it actually installs MariaDB's instead. This is often a reasonable substitution, but here it's fatal.
The problem is that Laravel 8's schema dump restore process (which makes CI pipelines run so much faster) builds a command line for the mysql CLI client and uses it to import the schema. MariaDB's CLI client is incompatible with MySQL 8.0 due to lack of support for its default auth mechanism, caching_sha2_password, so unless you also want to have to reconfigure your MySQL server (meaning you can't simply enable it using services: mysql:8.0 in your CI config) you have to disable schema dump and have your tests run slowly.
The command "mysql --user="${:LARAVEL_LOAD_USER}" --password="${:LARAVEL_LOAD_PASSWORD}" --host="${:LARAVEL_LOAD_HOST}" --port="${:LARAVEL_LOAD_PORT}" --database="${:LARAVEL_LOAD_DATABASE}" < "${:LARAVEL_LOAD_PATH}"" failed.
Exit Code: 1(General error)
Working directory: /builds/myapp
Output:
================
Error Output:
================
ERROR 1045 (28000): Plugin caching_sha2_password could not be loaded: /usr/lib/x86_64-linux-gnu/mariadb19/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory

It's only the MaraDB client that's the problem. This is tricky to fix for Alpine Linux because it does not have a real MySQL package, even though MySQL includes support for Alpine.
I've been looking through various Laravel/PHP focused images for CI, and nearly all seem to suffer this problem, so I'm hoping one will fix it!

Hey 👋
Thanks for raising this.
I'm tempting to support another distribution but I love that this repo is a simple and lightweight DockerFile with the bare minimum for Laravel apps so Alpine feels like the ideal distribution to me.
I'll keep this open until — fingers crossed — a proper MySQL client becomes available for Alpine.
Thanks again. :)

Thanks. I have found a workaround, but it involves downgrading the security of the mysql client connection, so it's not ideal. Add this command arg to the mysql service in your gitlab-ci.yml file:
  services:
    - name: mysql:8.0
      command: [ "--default-authentication-plugin=mysql_native_password" ]

Nice, thanks for the update! Let me know if this suddenly becomes achievable without the workaround. 😊


Beta-testing 'mini.pick'

Please leave your feedback about new mini.pick module here. Feel free to either add new comment or positively upvote existing one.
Some things I am interested to find out (obviously, besides bugs):

Are configuration and function/picker names intuitive enough?
Are default values of settings convenient for you?
Is documentation and examples clear enough?
Does default matching algorithm give relevant enough results?

Thanks!

Hi, thanks for the cool plugin!
I'm trying to make a picker similar to telescope.pickers.current_buffer_fuzzy_find({ default_text = vim.fn.expand('<cword>') }), but failed.
How can I pass the word under the cursor as a query when creating the picker?
I tried using MiniPick.set_picker_query(), but it has no effect. I called both before MiniPick.start() and after.
Here is an example of what I tried to do:
    local pick = require('mini.pick')

    pick.registry.grep_live_current_buf = function()
      local lines = vim.api.nvim_buf_get_lines(0, 1, -1, false)
      local items = {}

      local path = vim.fn.expand('%p')
      for lnum, line in ipairs(lines) do
        items[lnum] = { text = line, lnum = lnum + 1, path = path }
      end

      pick.start({
        source = {
          items = items,
          name = 'Grep current buffer',
        },
      })
      pick.set_picker_query(vim.split(vim.fn.expand('<cword>'), ''))
    end

As I understood from the plugin code, the initial query is always set empty in the private function H.picker_new. Is it possible to add an option in opts.source to specify the initial query?

I'm trying to make a picker similar to telescope.pickers.current_buffer_fuzzy_find({ default_text = vim.fn.expand('<cword>') }), but failed.

If it wasn't for only current buffer restriction, I'd suggest using grep directly. There is even example of that in the help (although, not in a very visible place).

How can I pass the word under the cursor as a query when creating the picker?

Your code is good, it only misses one important design: although start() is a non-blocking (allows other things to be executed), it is not fully asynchronous (it waits for user to choose and then returns certain value). It is documented both in "Implementation details" of overview and (not entirely directly) in start() itself.
So in your code by the time set_picker_query() is executed, picker is already stopped and thus it fails silently (as it is allowed to be called without active picker). If you call it directly before start(), it would behave the same (as there is no active picker yet). The solution here is to use vim.schedule() prior to start().
Here is my attempt:
MiniPick.registry.buffer_lines = function(local_opts)
  -- Parse options
  local_opts = vim.tbl_deep_extend('force', { buf_id = nil, prompt = '' }, local_opts or {})
  local buf_id, prompt = local_opts.buf_id, local_opts.prompt
  local_opts.buf_id, local_opts.prompt = nil, nil

  -- Construct items
  if buf_id == nil or buf_id == 0 then buf_id = vim.api.nvim_get_current_buf() end
  local lines = vim.api.nvim_buf_get_lines(buf_id, 0, -1, false)
  local items = {}
  for i, l in ipairs(lines) do
    items[i] = { text = string.format('%d:%s', i, l), bufnr = buf_id, lnum = i }
  end

  -- Start picker while scheduling setting the query
  vim.schedule(function() MiniPick.set_picker_query(vim.split(prompt, '')) end)
  MiniPick.start({ source = { items = items, name = 'Buffer lines' } })
end

So in your code by the time set_picker_query() is executed, picker is already stopped and thus it fails silently (as it is allowed to be called without active picker). If you call it directly before start(), it would behave the same (as there is no active picker yet). The solution here is to use vim.schedule() prior to start().
Here is my attempt:

Thanks for the quick reply!
Yes, I tried using vim.schedule before, but that didn't help either.
I copied and ran your code, but it doesn't seem to give the expected result either.
In the video, promt is expected to have a word under the cursor, but the prompt is empty. I also tried the example from the documentation, but in that case '' is also not passed and the result is empty:
https://github.com/echasnovski/mini.nvim/assets/46977173/49833e2a-3428-4bc3-8750-fdc9bc4f4136

I saw this issue after I filed mine, huge apologies. TLDR is Pick grep searches .git folder, which isn't really useful. Excellent plugin!
#516

I saw this issue after I filed mine, huge apologies. TLDR is Pick grep searches .git folder, which isn't really useful. Excellent plugin!
#516

No worries. I'll think about it.

Gosh this one is amazing! The speed increase compared to Telescope is staggering. You should be really proud of what you've created here.
I'm struggling to figure out how to browse files in another directory. With Telescope, I had to lcd first, otherwise each entry was ../foo/bar/... etc. Between the readme and the doc, I can't figure out the incantation here.
Is there a mechanism to tell builtin.files() to use a specific dir? If not, I'd definitely urge one as it's something that Telescope is sorely missing. MiniPick.builtin.files({dir = '../foo/bar'}) would be huge for me.

Gosh this one is amazing! The speed increase compared to Telescope is staggering. You should be really proud of what you've created here.

:heart:

I'm struggling to figure out how to browse files in another directory. With Telescope, I had to lcd first, otherwise each entry was ../foo/bar/... etc. Between the readme and the doc, I can't figure out the incantation here.
Is there a mechanism to tell builtin.files() to use a specific dir? If not, I'd definitely urge one as it's something that Telescope is sorely missing. MiniPick.builtin.files({dir = '../foo/bar'}) would be huge for me.

It is possible, as every source can have "current working directory". So with builtin.files() you can do MiniPick.builtin.files(nil, { source = { cwd = '../foo/bar' } }). If you plan to do that often interactively, you can modify files in registry and use :Pick files cwd='../foo/bar'.
It is made a part of the source for it to be more persistent and not depend on current working directory. Allowing it also as the local option for built-in picker is a code duplication I would like to avoid. Thus the modification of registry approach.

To be honest, I did not realize that picking something from different directory is a common thing. I'd make it more prominent in the documentation.
Maybe this is a workflow thing. I use setup_auto_root() and can't really remember when I needed to pick something from outside of the root. If I need something, then I  usually know the location and use 'mini.files' to quickly navigate to it.

It is possible, as every source can have "current working directory". So with builtin.files() you can do MiniPick.builtin.files(nil, { source = { cwd = '../foo/bar' } }). If you plan to do that often interactively, you can modify files in registry and use :Pick files cwd='../foo/bar'.

That first incantation is a little awkward, but works perfectly for me. Thanks!

To be honest, I did not realize that picking something from different directory is a common thing. I'd make it more prominent in the documentation.

I’d encourage that! I (hope) I’m not the only person who’s wanted to do that, because if so then I’ve missed the point somewhere along the way.

Maybe this is a workflow thing. I use setup_auto_root() and can't really remember when I needed to pick something from outside of the root. If I need something, then I usually know the location and use 'mini.files' to quickly navigate to it.

My use case there is primarily mini.starter. I have a couple projects that I often want to work on or examine a particular file in, and spawning nvim and browsing one of those dirs is a very common workflow for me.

I saw this issue after I filed mine, huge apologies. TLDR is Pick grep searches .git folder, which isn't really useful. Excellent plugin!
#516

Duplicating from #516: suggested approach is to set up custom rg config file. Thanks @Keyhart for the tip!

1. file first matching. For example, `foo/abc.ts` and `src/foo.ts`, after I input `foo`, I want `src/foo.ts` to be the first matched. Like `fzf --delimiter / --nth -1,..`

Yes, this is working as intended because matching algorithm is the same by default for any picker. If you add . or t (as in first letter of extension), it should put src/foo.ts first because its match has smaller width.

2. `:Pick grep` unable to paste to input?

What do you mean by "paste to input"? builtin.grep takes pattern as local option, which if not supplied asks user to input it interactively. You can do at least these:

Execute :Pick grep and then paste manually to the interactive input (via <C-r> and register name, for example).
Execute :Pick grep pattern='<paste here manually>'.
Execute :Pick grep pattern='<cword>' to search for word under cursor.

:Pick grep unable to paste to input?

Sorry, my typo.  I can't paste in :Pick grep_live.

:Pick grep unable to paste to input?

Sorry, my typo. I can't paste in :Pick grep_live.

What do you mean by "paste"? There is a paste action with default mapping of <C-r>. So you can :Pick grep_live followed by <C-r> and register name. If you want some automated functionality like preset query with certain word (like word under cursor), then yes, it needs extra manipulation along the lines of this comment.

What do you mean by "paste"?

Copy something from other then paste to grep_live by system clipboard.

What do you mean by "paste"?

Copy something from other then paste to grep_live by system clipboard.

System clipboard can be accessed via one of + or * registers. Take a look at :h quoteplus and :h quotestar.
So on my machine I can select text from this page (select, click with right mouse button, select "Copy"). Then go into Neovim, execute :Pick grep_live followed by <C-r> and +. This will add system clipboard entry to the query.

I'm triggering mini.pick by the following mechanism
vim.keymap.set("n", "<leader>f",  ":Pick files<CR>", { noremap = true, silent = true })
vim.keymap.set("n", "<leader>/",  ":Pick grep<CR>", { noremap = true, silent = true })
vim.keymap.set("n", "<leader>b",  ":Pick buffers<CR>", { noremap = true, silent = true })

I'm finding neither <C-n> / <Down> or <C-p> / <Up> bindings are working for me (as suggested in the docs).
- Type special keys to perform |MiniPick-actions|. Here are some basic ones:
    - `<C-n>` / `<Down>` moves down; `<C-p>` / `<Up>` moves up.

Would you mind go into a bit more detail? Like:

Do you press, for example, <Leader>f to start finding files. Does the floating window appear with the list of files?
If window is active, what does pressing <C-n> or <Down> result in? Just nothing happens or happens something else (not moving the current item down)?
Do other keys work? Like <C-f>, <Tab>, or <CR>?
Just for a good measure: what terminal emulator and OS do you use?

I'm on Mac OS & iterm, using <leader>f causes a floating window to appear, it's focussed and I can fuzzy search + open files in tabs or splits.
Most of the other bindings appear to be working, <C-a>, <C-u>, <C-x>, <C-f>, <C-b>
When pressing <C-n> / <Down> moves down; <C-p> / <Up> nothing is happening at all.

I think I have an idea what might be going on. What does :hi MiniPickMatchCurrent show? By default it is linked to CursorLine and if you have cleared it, then moving current item won't show any effect. However, there is still should be an effect. For example, right after you open the picker, press <Down> several times and then <S-Tab>. This would open the info view and Current index line should show number bigger than 1.

If I disable mini.base16 (i.e. by not setting a colourscheme and re-opening vim) I can see that it's actually working as expected.
As soon as I do colorscheme minicyan or similar I can see it breaks.
Running :hi MiniPickMatchCurrent consistently gives me:
MiniPickMatchCurrent xxx cterm= gui=links to CursorLine

whether I've got mini.base16 enabled or not

If I disable mini.base16 (i.e. by not setting a colourscheme and re-opening vim) I can see that it's actually working as expected.
As soon as I do colorscheme minicyan or similar I can see it breaks.
Running :hi MiniPickMatchCurrent consistently gives me:
MiniPickMatchCurrent xxx cterm= gui=links to CursorLine

whether I've got mini.base16 enabled or not

Yep, it is a 'mini.base16' issue. I forgot that floating window in it has the same background as cursor line. I'll fix it soon.

Is there any way H.actions could be made user-accessible? I'd like to make an action to mark and then move down, which should be as simple as:
require("mini.pick").setup({
  mappings = {
    mark = nil,
    mark_and_move = {
      char = "<C-X>",
      func = function(picker)
        H.actions.mark(picker)
        H.actions.move_down(picker)
      end
    }
  }
})

but isn't because of the way actions are defined, unless I'm missing something.

@echasnovski As a note, this works as well and can account for anything that would change the setup: vim.api.nvim_input(vim.api.nvim_replace_termcodes(string.format("%s%s", MiniPick.config.mappings.mark, MiniPick.config.mappings.move_down), true, true, true))

@echasnovski As a note, this works as well and can account for anything that would change the setup: vim.api.nvim_input(vim.api.nvim_replace_termcodes(string.format("%s%s", MiniPick.config.mappings.mark, MiniPick.config.mappings.move_down), true, true, true))

Well, to be even more precise, it should account for possible picker-local mappings. Like this:
local mark_and_move_down = function()
  local mappings = MiniPick.get_picker_opts().mappings
  local keys = mappings.mark .. mappings.move_down
  vim.api.nvim_input(vim.api.nvim_replace_termcodes(keys, true, true, true))
end
require('mini.pick').setup({
  mappings = {
    mark_and_down = { char = '<C-d>', func = mark_and_move_down },
  },
})

Edit: @Jackevansevo, I've pushed a 'mini.base16' update with tweaked highlight groups for 'mini.pick'. Should be all visible on latest main.

confirmed this is working perfectly now, cheers for the help 👍

is there a way to enable preview automatically?

is there a way to enable preview automatically?

Sorry, no. This doesn't play nicely with the possible asynchronous setting of items (i.e. there can be no items when picker is started meaning that preview is not properly defined). In theory, you can try to emulate it with vim.api.nvim_input('\t') after starting picker, but i wouldn't recommend.

Hi, thanks for another great plugin!
There's a weird interaction with mini.files:

README.md was opened with :edit and pick.lua was opened with mini.files. Current working directory is ~/.local/share/nvim/lazy/mini.pick but it looks like pick.lua is from another directory (not a sub-directory of cwd). Is this intended and if so is there a way to change so that file names opened with mini.files would be displayed as relative to cwd?
This is how the same files are displayed in telescope and I'd like mini.pick to display the files the same way (apart from numbers and indicators):

Can I use other commands instead of rg, fd and git? I want to use GNU find.
It looks like all the commands are hardcoded.

Can I use other commands instead of rg, fd and git? I want to use GNU find. It looks like all the commands are hardcoded.

There is builtin.cli() for other CLI commands. For example:

:Pick cli command={'find','-type','f'} using :Pick command.
If you want a more similar experience to builtin.files, you can create custom registry entry. With something like this:MiniPick.registry.files_find = function()
  local show_with_icons =
    function(buf_id, items, query) return MiniPick.default_show(buf_id, items, query, { show_icons = true }) end
  local postprocess = function(lines)
    return vim.tbl_map(function(l) return l:gsub('^%./', '') end, lines)
  end
  return MiniPick.builtin.cli(
    { command = { 'find', '-type', 'f' }, postprocess = postprocess },
    { source = { show = show_with_icons } }
  )
end

Hi, thanks for another great plugin!
There's a weird interaction of Pick buffers with mini.files:
README.md was opened with :edit and pick.lua was opened with mini.files. Current working directory is ~/.local/share/nvim/lazy/mini.pick but it looks like pick.lua is from another directory (not a sub-directory of cwd). Is this intended and if so is there a way to change so that file names opened with mini.files would be displayed as relative to cwd?
This is how the same files are displayed in telescope and I'd like mini.pick to display the files the same way (apart from numbers and indicators):

@lostl1ght, this is relatively strange and definitely shouldn't be the case. I can not reproduce, though. The builtin.buffers() use :buffers under the hood which does show buffer names relative to current working directory.
What does :buffers show?
And just to be sure:

Is 'README.md' also from '~/.local/share/nvim/lazy/mini.pick'?
What does :pwd show prior to reproducing this :Pick buffers?

@echasnovski Thank you for the assistance. Pick cli is awesome!

Is 'README.md' also from '~/.local/share/nvim/lazy/mini.pick'?

Yes.

What does :pwd show prior to reproducing this :Pick buffers?

/home/<user>/.local/share/nvim/lazy/mini.pick

What does :buffers show?

This:
  2 %a   "README.md"                    line 29
  3      "~/.local/share/nvim/lazy/mini.pick/lua/mini/pick.lua" line 20

So from my understanding there's nothing really wrong with anything here. It's just that mini.files uses absolute paths to open files and so :buffers displays the absolute paths, am I right? But is there a way to display shortened paths?

It would be nice to have an option to change the default icons that are not coming from nvim-web-devicons.
In my use case, I add 1 extra space after the icon to get a nice spacing between icon and text.
This is probably easier to do than allowing to change how the lines are rendered.
That also allows us to set our favorite icon for Directory and Unknown files.

It would be nice to have an option to change the default icons that are not coming from nvim-web-devicons.

I was waiting for someone to request it with a valid use case :)
Yeah, what you describe seems like one. I'll add is soon as opts.icons in default_show().

Huh, strange. I can describe the steps in more detail:
1. `cd` into `~/.local/share/nvim/lazy/mini.pick`

2. `nvim`

3. `:edit README.md`

4. `=MiniFiles.open()`

5. Put the cursor on the `lua` folder

6. Press `l` 3 times to open `pick.lua`

7. `:buffers` or `Pick buffers` display buffers as I described

@lostl1ght, yes, very strange. I could finally reproduce with minimal config containing only 'mini.files'. I'll look into it.

Do we have the option to sort the buffer list by last used?
Use Case:
If you work on multiple files (more than 2) and have to switch between them a lot, then it is way more convenient to have them sorted by last used. This way, you do not have to think so hard about how the buffer is called because you already know that it is one of the top results, so you can just move a few steps down instead of filtering/searching.
Currently, my buffers look like this:
1: Main file I work on
2 - 10: Many files that I opened for reference
11: My second important file I work on
12: My third related file I work on

Do we have the option to sort the buffer list by last used?
Use Case: If you work on multiple files (more than 2) and have to switch between them a lot, then it is way more convenient to have them sorted by last used. This way, you do not have to think so hard about how the buffer is called because you already know that it is one of the top results, so you can just move a few steps down instead of filtering/searching.
Currently, my buffers look like this: 1: Main file I work on 2 - 10: Many files that I opened for reference 11: My second important file I work on 12: My third related file I work on

No, not in the builtin.buffers(). Implementing that would need custom tracking instead of relying on built-in :buffers. The dedicated functionality of such tracking is currently planned in one of the next modules.
In the meantime, you can look into the following solutions:

Use oldfile() from 'mini.bracketed' (mapped to [o and ]o by default).
Write your own picker using vim.fn.expand('#n') functionality. Something like this:MiniPick.registry.buffers_recent = function()
  local items = {}
  for i = 1, 100 do
    local path = vim.fn.expand('#' .. i)
    if path ~= '' and vim.fn.filereadable(path) == 1 then table.insert(items, vim.fn.fnamemodify(path, ':~:.')) end
  end

  local show_with_icons =
    function(buf_id, items, query) MiniPick.default_show(buf_id, items, query, { show_icons = true }) end

  return MiniPick.start({ source = { items = items, name = 'Recent buffers', show = show_with_icons } })
end

It is not ideal (includes visited help files), but concise.
Then use it with :Pick buffers_recent.

@lostl1ght, the absolute path in :buffers after opening in 'mini.files' should be fixed on latest main. The issue indeed was that 'mini.files' used absolute path with :edit command. Although this is a more robust approach, it indeed has the issue that you found. I thought it shouldn't matter because nvim_buf_get_name() always returns full path and :buffers can handle that.
Apparently, it can handle that, but only after another cd (even if in the same directory). So everything is OK after these set of commands:
:cd ~/.local/share/nvim/lazy/mini.pick
:edit ~/.local/share/nvim/lazy/mini.pick/lua/mini/pick.lua
:cd .

The reason why I couldn't reproduce it is because I have setup_auto_root() from 'mini.misc' which does equivalent of cd on every BufEnter.

Works great. Thank you!

Also, I've finally figured out how to reproduce a bug(?) with the cursor and cmdheight = 0:

Can you see how the cursor is on top of the floating window?
This is very annoying if one uses folke's noice.nvim.
If cmdheight > 0 then the cursor just stays in the cmdline.

Also, I've finally figured out how to reproduce a bug(?) with the cursor and cmdheight = 0:

Sigh... Yeah, this is expected and seems to be the issue with Neovim itself, as I simply couldn't find a way to not show cursor reliably. Hence a "hack" to place it in command line.
I'll ask Neovim core about this.

Is there a reason why mini.pick uses what it seems to be a unicode character as a cursor instead of an actual cursor?

Is there a reason why mini.pick uses what it seems to be a unicode character as a cursor instead of an actual cursor?

Do you mean as caret in prompt? That is because it is not a cursor but a visual representation of a caret in a prompt. As prompt is displayed in floating window's title, there is no way to actually place a cursor in Insert mode there.

Do you mean as caret in prompt?

Yes.

there is no way to actually place a cursor in Insert mode there.

I see. Thank you.

Do we have the option to sort the buffer list by last used?

@JSteitz I think there might still be some weird edge cases lingering, but I ported telescope's sort_lastused option into MiniPick in my dotfiles.
You can use :Pick buffers sort_lastused=true to activate it.

Do we have the option to sort the buffer list by last used?

@JSteitz I think there might still be some weird edge cases lingering, but I ported telescope's sort_lastused option into MiniPick in my dotfiles.
You can use :Pick buffers sort_lastused=true to activate it.

I remember looking at lastused from getbufinfo() and it didn't quite do what is intuitively expected. It is really clear what "last used" actually means and it tracks timestamp up to seconds (so quick buffer change with ]b or ]o from 'mini.bracketed' doesn't produce good result). That's mostly the reasons why it is not included in builtin.buffers().

I quickly wrote a picker that replicates fzf-lua's lsp_document_symbols() behaviour (see below).

Are configuration and function/picker names intuitive enough?

Yes

Are default values of settings convenient for you?

Yes

Is documentation and examples clear enough?

Yes

Does default matching algorithm give relevant enough results?

Yes, although probably I'd customize it for this picker a bit. But seems easy enough to customize it judging by the docs.
MiniPick.registry.lsp_document_symbols = function()
  local bufnr = vim.api.nvim_get_current_buf()

  vim.lsp.buf_request_all(
    bufnr,
    'textDocument/documentSymbol',
    { textDocument = vim.lsp.util.make_text_document_params(bufnr) },
    function(lsp_responses)
      local items = {}

      local function process_result(result, depth)
        table.insert(items, {
          text = string.rep('  ', depth) .. '[' .. vim.lsp.protocol.SymbolKind[result.kind] .. '] ' .. result.name,
          bufnr = bufnr,
          lnum = result.range['start'].line + 1,
          end_lnum = result.range['end'].line + 1,
          col = result.range['start'].character + 1,
          end_col = result.range['end'].character + 1,
        })
        if result['children'] ~= nil then
          for _, child in ipairs(result.children) do
            process_result(child, depth + 1)
          end
        end
      end

      for _, lsp_response in ipairs(lsp_responses) do
        for _, result in ipairs(lsp_response.result) do
          process_result(result, 0)
        end
      end

      MiniPick.start({
        source = {
          items = items,
          name = 'LSP document symbols'
        }
      })
    end
  )
end

Thanks for the feedback, @oskarkook!

I quickly wrote a picker that replicates fzf-lua's lsp_document_symbols() behaviour (see below).

This looks sooo nice! I have a more general implementation based on vim.lsp.buf module, but yours looks much better.

Is there a reason why lnum, col etc are 1-based? It seems I need to always add 1 to values that are received from vim APIs.
MiniPick.registry.document_diagnostics = function()
  local items = {}
  local results = vim.diagnostic.get()

  for _, result in ipairs(results) do
    table.insert(items, {
      text = result.message,
      bufnr = result.bufnr,
      lnum = result.lnum + 1,
      end_lnum = result.end_lnum + 1,
      col = result.col + 1,
      end_col = result.end_col + 1,
    })
  end

  MiniPick.start({
    source = {
      items = items,
      name = 'Document diagnostics'
    }
  })
end

Is there a reason why lnum, col etc are 1-based? It seems I need to always add 1 to values that are received from vim APIs.
...
Mainly I'm thinking whether the plugin's API should match vim's? But it's a mild enough difference, fine as it is as well.

That is the thing: 1-based numeration is what Vim uses. It is Neovim's API what uses 0-based positions (and sometimes mixed, like in nvim_win_{get,set}_cursor()). See :h getqflist(), for example.
Besides, Lua also uses 1-based indexing. Both of those reasons are why 'mini.nvim' early on tried to use 1-based indexes.

Roger :). The plugin works great for my use cases! Adding extra pickers was easy and overall I'm super happy with it. I can even empirically perceive a lower latency compared to alternatives. Thanks a lot for the work you do on mini.nvim!

Do we have the option to sort the buffer list by last used?

@JSteitz I think there might still be some weird edge cases lingering, but I ported telescope's sort_lastused option into MiniPick in my dotfiles.
You can use :Pick buffers sort_lastused=true to activate it.

@oncomouse
Thanks, that would have been my next attempt.
After testing it, I can see that some buffers are not sorted correctly, especially buffers for files from different directories.
So I tried to do it myself and this is the result:
MiniPick.registry.buffers = function(local_opts, opts)
  local_opts = vim.tbl_deep_extend('force', { sort_lastused = false, include_current = true, include_unlisted = false }, local_opts or {})

  local cur_buf_id, include_current = vim.api.nvim_get_current_buf(), local_opts.include_current
  local flag_unlisted = local_opts.include_unlisted and "!" or ""
  local flag_recent = local_opts.sort_lastused and "t" or ""
  local command = string.format("buffers%s %s", flag_unlisted, flag_recent)
  local buffers_output = vim.api.nvim_exec2(command, { output = true }).output
  local items = {}

  for _, l in ipairs(vim.split(buffers_output, '\n')) do
    local buf_str, name = l:match('^%s*%d+'), l:match('"(.*)"')
    local buf_id = tonumber(buf_str)
    local item = { text = name, bufnr = buf_id }
    if buf_id ~= cur_buf_id or include_current then table.insert(items, item) end
  end

  local show = MiniPick.config.source.show or function(buf_id, items, query)
    MiniPick.default_show(buf_id, items, query, { show_icons = true })
  end

  return MiniPick.start(vim.tbl_deep_extend('force', { source = { name = 'Buffers', show = show } }, opts or {}, { source = { items = items } }))
end

:buffers has a flag to get all buffers already sorted by last used. So I'm just using that. Everything else is the same, as the builtin.buffers. @echasnovski is this solution good and simple enough to include?
@echasnovski
mini.pick is in beta, but the documentation reads like it is already included in mini.nvim.
If that is so, then I get the error that it does not find mini.pick.
Otherwise, it is misleading in the documentation and would be better if there was a note next to the module "(beta) not released" in the README.
Can someone give an example of how I can filter out directories? Don't know much about lua and neovim api :/
I am not convinced that this is enough to be a feature, more a preference in my use case.

@echasnovski
I have sometimes performance issues with builtin.grep_live where my CPU maxes out.
The project itself is big (many node_modules and other dependencies).
Does live_grep use the .gitignore?
This happens mostly initially after first startup of neovim. I never had this issue with Telescope using ripgrep.
How can I help with that?

:buffers has a flag to get all buffers already sorted by last used. So I'm just using that. Everything else is the same, as the builtin.buffers. @echasnovski is this solution good and simple enough to include?

Hmm... This is indeed an interesting suggestion which I wasn't actively aware of. I'll have a look into how it works on practice.

@echasnovski mini.pick is in beta, but the documentation reads like it is already included in mini.nvim.
If that is so, then I get the error that it does not find mini.pick. Otherwise, it is misleading in the documentation and would be better if there was a note next to the module "(beta) not released" in the README.

Yes, it is in public beta.
Yes, it is included in a 'mini.nvim'.
No it is not misleading.
When exactly does the error occur? If you use 'mini.nvim', make sure that you don't use stable branch or tag version.

Can someone give an example of how I can filter out directories? Don't know much about lua and neovim api :/
I am not convinced that this is enough to be a feature, more a preference in my use case.

From where do you want to filter out directories?

I've just pushed several updates.

The most visible one is that all CLI tools are now called with a minimal set of flags needed for picker to work properly. In practice, that means that both fd/rg in builtin.files() and rg in builtin.grep()/builtin.grep_live() don't recognize hidden files by default. To customize that, follow help.

@lostl1ght, 'mini.pick' now work for plain cmdheight=0, but not with 'folke/noice.nvim' (unfortunately). We've chatted with Folke a bit (as this is a bit of a complicated topic spanning 'mini.pick', Noice, and Neovim core), and the best approach here seems to let each plugin do its thing:

'mini.pick' places cursor in command line to avoid it being visible in picker window.
'noice.nvim' now practices custom dark magic ways of making making sure that cursor is up to date. Unfortunately, together with absent command line (as Noice itself is a command line), this means that cursor will always be shown in picker window.
But the best outcome here would be for Neovim core to implement proper ways of hiding and showing cursor, as it is not possible now. This needs some work, dedication, and C knowledge, so probably won't be done any time soon.

Another update is for you, @JSteitz: default_show() now supports custom icons. To use them, update every picker with which you want to use custom icons (like files) to use show_with_icons() similar to this comment. I know, it is not super scalable, but that is the price of having granular control over pickers.

:buffers has a flag to get all buffers already sorted by last used. So I'm just using that. Everything else is the same, as the builtin.buffers. @echasnovski is this solution good and simple enough to include?

@JSteitz, I've looked into this and :buffers t indeed doesn't always give an up to date results. I think this is mostly because "last used" is not really well defined anywhere. For example, ibhagwan/fzf-lua also ended up making custom solution.
As there is a planned alternative module with a similar functionality (but for files in general), I think sort_lastused for buffer won't be part of builtin.buffers().

Another update is for you, @JSteitz: default_show() now supports custom icons. To use them, update every picker with which you want to use custom icons (like files) to use show_with_icons() similar to https://github.com/echasnovski/mini.nvim/issues/513#issuecomment-1772239061. I know, it is not super scalable, but that is the price of having granular control over pickers.

Not a problem, have to create keybinds to call the methods anyway, so I'm good with that :+1:

As there is a planned alternative module with a similar functionality (but for files in general), I think sort_lastused for buffer won't be part of builtin.buffers().

I think that is a reasonable decision.
If people want to have such a feature now, they could just use my code snippet meanwhile.

I really like this plugin, feels very correct — I'm curious if something like require('mini.pick').load_extension() can be implemented to allow extra sources be implemented as plugins?

I'm curious if something like require('mini.pick').load_extension() can be implemented to allow extra sources be implemented as plugins?

The suggested way to do this is with MiniPick.registry. This is a more flexible approach at the cost of being slightly more explicit. It can be utilized in the following ways:

Have "extension" explicitly add picker with require('min.pick').registry.my_ext = function(local_opts) ... end. This works but has the downside of having 'mini.pick' being loaded strictly prior to that extension.
Have user make that assignment themselves (in the config) instead of load_extenstion(). This requires "extension" to export either full picker itself or a basic functionality to get items and let the user make the call to MiniPick.start().

What do you mean by "paste"?

Copy something from other then paste to grep_live by system clipboard.

System clipboard can be accessed via one of + or * registers. Take a look at :h quoteplus and :h quotestar.
So on my machine I can select text from this page (select, click with right mouse button, select "Copy"). Then go into Neovim, execute :Pick grep_live followed by <C-r> and +. This will add system clipboard entry to the query.

I am having issues using this solution using MiniPick on a remote machine over SSH. Any proposed solution there?

I am having issues using this solution using MiniPick on a remote machine over SSH. Any proposed solution there?

Does clipboard work in regular scenarios? Like typing "+p (or "*p) in inside modified text buffer leads to pasting text from the clipboard? As history shows, system clipboard and SSH is not a great pairing and can be a trouble to set up. I don't really have experience here, unfortunately.

Does clipboard work in regular scenarios? Like typing "+p (or "*p) in inside modified text buffer leads to pasting text from the clipboard? As history shows, system clipboard and SSH is not a great pairing and can be a trouble to set up. I don't really have experience here, unfortunately.

Yes, when nvim is running on the same machine the terminal is running on, pasting regularly works fine. Using mini-pick with <C-r> + register name also works great in this scenario.

Yes, when nvim is running on the same machine the terminal is running on, pasting regularly works fine. Using mini-pick with <C-r> + register name also works great in this scenario.

My question was a bit ambiguous. What I meant by "work in regular scenarios" is "does regular pasting inside SSH work, i.e. like typing ...".
What 'mini.pick' does with <C-r> is quite literally using the content of the register. If regular pasting with system clipboard doesn't work for some reason, then <C-r> in 'mini.pick' won't work. And vice versa: if one works, then should the other.

My question was a bit ambiguous. What I meant by "work in regular scenarios" is "does regular pasting inside SSH work, i.e. like typing ...".
What 'mini.pick' does with <C-r> is quite literally using the content of the register. If regular pasting with system clipboard doesn't work for some reason, then <C-r> in 'mini.pick' won't work. And vice versa: if one works, then should the other.

Ah, then yes this does not work over a remote session. I will look into getting OSC52 paste working in nvim so the system clipboard can be used!

Thanks for another great plugin! I already set it up to replace telescope and am using it's vim.ui.select() implementation.
I recently tried https://github.com/biozz/whop.nvim though and experienced a minor issue.
The plugin let's you choose from a set of (mostly shell) commands and executes it against the current buffer.
Using mini.pick the command however seems to be executed on the mini.pick buffer instead.
Wrapping the on_choice function with vim.schedule_wrap() fixes it.
I feel like this would be good to handle within mini.pick as it might potentially break other plugins as well.

Thanks for another great plugin! I already set it up to replace telescope and am using it's vim.ui.select() implementation.
I recently tried https://github.com/biozz/whop.nvim though and experienced a minor issue. The plugin let's you choose from a set of (mostly shell) commands and executes it against the current buffer.
Using mini.pick the command however seems to be executed on the mini.pick buffer instead. Wrapping the on_choice function with vim.schedule_wrap() fixes it.
I feel like this would be good to handle within mini.pick as it might potentially break other plugins as well.

That's a good use case, thanks!
Using vim.schedule_wrap() for on_choice() is OK, but might not work with implementation. I'll look into this.

Hi - the README says "Out of the box support for 'ignorecase' and 'smartcase'."
I have both options set, but picking (e.g. MiniPick.builtin.files()) is case-sensitive.  With the same config, both Telescope and fzf.vim are smartcase.  I tried a minimal config with only mini.pick enabled, but no luck.
It's using ripgrep, so I wonder if the fact that rg defaults to case-sensitive is the issue?  If so, is there a way to pass in flags to the rg command?
Or am I missing something more obvious?  Thanks!
❯ nvim --version
NVIM v0.10.0-dev-aab06ed
Build type: RelWithDebInfo
LuaJIT 2.1.1694316387

Hi - the README says "Out of the box support for 'ignorecase' and 'smartcase'."
I have both options set, but picking (e.g. MiniPick.builtin.files()) is case-sensitive. With the same config, both Telescope and fzf.vim are smartcase. I tried a minimal config with only mini.pick enabled, but no luck.
It's using ripgrep, so I wonder if the fact that rg defaults to case-sensitive is the issue? If so, is there a way to pass in flags to the rg command?
Or am I missing something more obvious? Thanks!
❯ nvim --version
NVIM v0.10.0-dev-aab06ed
Build type: RelWithDebInfo
LuaJIT 2.1.1694316387

It does respect those options for pickers which use default_match() (that is, not grep_live()). So I'd guess it is one of the two:

Options 'ignorecase' and 'smartcase' are not set. What does :=vim.o.ignorecase and :=vim.o.smartcase show? They both should be true for most pickers to query with smart case.
You used builtin.grep_live without rg being configured to use --smart-case.

(I guess that line in README could benefit from adding "... for 'ignorecase' and 'smartcase' options")

Thanks for the quick reply.  I mentioned that I do have both options 'ignorecase' and 'smartcase' set.  :=vim.o.ignorecase and :=vim.o.smartcase both show true.  And I'm not using grep_live, only MiniPick.builtin.files().
I also tried := MiniPick.builtin.files({ tool = 'rg' }) and 'fd' and 'git' (and 'fallback' but that strangely shows no results).  All of them are case-sensitive.

Thanks for the quick reply. I mentioned that I do have both options 'ignorecase' and 'smartcase' set. :=vim.o.ignorecase and :=vim.o.smartcase both show true. And I'm not using grep_live, only MiniPick.builtin.files().
I also tried := MiniPick.builtin.files({ tool = 'rg' }) and 'fd' and 'git' (and 'fallback' but that strangely shows no results). All of them are case-sensitive.

Sorry to hear that, but I can not reproduce. When I execute := MiniPick.builtin.files({ tool = 'rg' }), matching is most certainly smart-case. For example:

For query "li" it matches both "LICENSE" and "mini-align.md".
For query "LI" it matches only 'LICENSE".
For query 'lI" it matches none of them.

Besides those two cases I can not think about any other reasons why this should happen. I am pretty sure that it works as intended because also all tests for this behavior passed very recently.

I tried a minimal config with only mini.pick enabled, but no luck.

How did you do it?

Oh - I trimmed down my config to only run this plugin and ran nvim as normal.  But I tracked it down to an option I have set elsewhere: vim.opt.regexpengine = 1.  If I remove this (and have it automatically select the regexp engine), that fixes smartcase here.
I have that set to 1 for performance reasons (not related to this plugin).  I'm open to removing it for now to see if I'm still seeing performance issues elsewhere.  But do you know why the old regexp engine breaks smartcase here?  Is there a workaround we can add to our config if we use the old engine?
And either way, maybe worth a mention to this in the relevant help page?

Oh - I trimmed down my config to only run this plugin and ran nvim as normal. But I tracked it down to an option I have set elsewhere: vim.opt.regexpengine = 1. If I remove this (and have it automatically select the regexp engine), that fixes smartcase here.
I have that set to 1 for performance reasons (not related to this plugin). I'm open to removing it for now to see if I'm still seeing performance issues elsewhere. But do you know why the old regexp engine breaks smartcase here? Is there a workaround we can add to our config if we use the old engine?
And either way, maybe worth a mention to this in the relevant help page?

Interesting. That is maybe the third time I've been aware that this option exists, so didn't look at it. With it, I can reproduce. Thanks for the find!
I'll take a look why this is happening and will try to fix it.

One more thing: with 'smartcase', when using /, you can change the behavior to force case-sensitive by adding "\C" anywhere in the pattern (see :h /\C)?  e.g. if I want "foo" to not match "Foo", I can type "foo\C" and it will no longer match "Foo" or "Fbaroo", but still be a fuzzy match, so it'll match "foo" and "fbaroo".
Is there a way to do that in this picker?  That would be super useful!

There are several new updates here.

@hbiel, ui_select() should now call on_choice when target window (and buffer) is current. It indeed seems to be the better behavior for ui_select.

@bray, regexpengine=1 should now not block ignorecase/smartcase matching. The reason was that Vimscript's match() doesn't work well with [[:upper:]] regex atom when regexpengine is 1. And it was used to check if query is smart case.

One more thing: with 'smartcase', when using /, you can change the behavior to force case-sensitive by adding "\C" anywhere in the pattern (see :h /\C)? e.g. if I want "foo" to not match "Foo", I can type "foo\C" and it will no longer match "Foo" or "Fbaroo", but still be a fuzzy match, so it'll match "foo" and "fbaroo".
Is there a way to do that in this picker? That would be super useful!

No, I don't think this will be a part of default_match(). It already has quite complicated logic about how it parses query.

ui_select() should now call on_choice when target window (and buffer) is current. It indeed seems to be the better behavior for ui_select.

Works like a charm! I also didn't know about vim.api.nvim_win_call(), which seems to be a better fit in this case.
Thanks!

Using the open in split or new tab actions for :Pick help don't seem to work as expected, it's creating a new split of the current buffer first.

Using the open in split or new tab actions for :Pick help don't seem to work as expected, it's creating a new split of the current buffer first.

It works as documented: it first opens split and then chooses. Otherwise, to be consistent, plain choosing with <CR> should open help in the current window and not in split. I understand that this is not ideal, but I've tried making it work and didn't find any hackery-free solution. May look again in the future.

@JulesNP, today I realized that I can make builtin.help help custom mappings for <C-s>, <C-v>, and <C-t>. So those should now open the help window in horizontal, vertical, and tabpage splits.

@JulesNP, today I realized that I can make builtin.help help custom mappings for <C-s>, <C-v>, and <C-t>. So those should now open the help window in horizontal, vertical, and tabpage splits.

Awesome. Just updated and can report that it is working fine 👍

@JulesNP, today I realized that I can make builtin.help help custom mappings for <C-s>, <C-v>, and <C-t>. So those should now open the help window in horizontal, vertical, and tabpage splits.

Thanks! Everything's working great with the latest changes. I've fully switched over from Telescope now in my config.

I want to express my gratitude first for creating all these fantastic modules.
I've been utilizing mini.Pick since its inception, and it has proven to be excellent, especially in terms of its responsiveness and speed. It has nearly replaced my telescope workflow, particularly after the launch of mini.extra, for which I extend my congratulations.
While mini.Pick and mini.extra cover most of my needs, I still rely on telescope for one specific tool: the telescope-undo extension. This extension has been truly amazing, especially with its yanking capabilities for addition or deletion. My suggestion or rather a request is to consider creating a dedicated pick for undo/history functionality (or dedicated Module eg. Mini.Unfasten 🫣). This module could stand out by integrating git history seamlessly into the same timeline as undo 🔥, a feature that, as of now, is absent in the vim universe but present in VS Code.
Additionally, I'm curious if there's a way to customize the appearance of each pick. For instance, I'd like pick buffers or files to be much smaller and positioned in the bottom right, unlike grep_live, which I prefer to have in a larger window.
On a related note, I'm wondering if there's a method to implement grep_live specifically for help files (not the one for only help tags). I attempted to do so, but the outcome was less than satisfactory. Apologies for the less-than-ideal implementation.

My attempt for Pick help_grep

Note: some of the code below borrowed and modified from another tele. ext.

    config = function(_, opts)
      local MiniPick = require("mini.pick")
      MiniPick.setup({})
      MiniPick.registry.help_files = function(local_opts)
        -- Parse options
        local_opts = vim.tbl_deep_extend("force", { prompt = "" }, local_opts or {})
        local prompt = local_opts.prompt
        local_opts.prompt = nil

        -- Get the paths of the help files
        local paths = vim.api.nvim_get_option("runtimepath")
        paths = vim.split(paths, ",")
        local dirs = {}
        for _, path in ipairs(paths) do
          local doc_path = path .. "/doc"
          if vim.fn.isdirectory(doc_path) == 1 then
            table.insert(dirs, doc_path)
          end
        end

        -- Start the picker based on CLI output
        MiniPick.builtin.cli({
          command = {
            "rg",
            prompt,
            "--color",
            "never",
            "--no-messages",
            "--line-buffered",
            "-g",
            "!*.log",
            "-n",
            "-H",
            unpack(dirs),
          },
          prompt_title = "Help Grep",
        }, local_opts)
      end
    end,

thank you for your time and assistance!

I want to express my gratitude first for creating all these fantastic modules.
I've been utilizing mini.Pick since its inception, and it has proven to be excellent, especially in terms of its responsiveness and speed. It has nearly replaced my telescope workflow, particularly after the launch of mini.extra, for which I extend my congratulations.

Thanks for kind words! Much appreciated :pray:

While mini.Pick and mini.extra cover most of my needs, I still rely on telescope for one specific tool: the telescope-undo extension. This extension has been truly amazing, especially with its yanking capabilities for addition or deletion. My suggestion or rather a request is to consider creating a dedicated pick for undo/history functionality (or dedicated Module eg. Mini.Unfasten 🫣). This module could stand out by integrating git history seamlessly into the same timeline as undo 🔥, a feature that, as of now, is absent in the vim universe but present in VS Code.

Thanks for the suggestion! I'll think about it, but initial reaction is that this is unlikely to happen. There is a certain novel undo integration in 'mini.bracketed' (see its undo() target). I vividly remember having quite a few problems dealing with the undo history (as in, it can be done but there are many hidden pitfalls).

Additionally, I'm curious if there's a way to customize the appearance of each pick. For instance, I'd like pick buffers or files to be much smaller and positioned in the bottom right, unlike grep_live, which I prefer to have in a larger window.

Yes, it is possible. All pickers in MiniPick.builtin and MiniExtra.pickers take two arguments: local_opts (specific to picker) and opts (configuration for MiniPick.start()).
Here is a quick example of how to create a new picker help_right inside a MiniPick.registry:
MiniPick.registry.help_right = function()
  local win_config =
    { relative = 'editor', anchor = 'SE', row = vim.o.lines, col = vim.o.columns, height = 20, width = 40 }
  return MiniPick.builtin.help({}, { window = { config = win_config } })
end

Having this executed (after require('mini.pick').setup()), you can now do :Pick help_right. Customize specific details of window config to your liking (see :h nvim_open_win).

On a related note, I'm wondering if there's a method to implement grep_live specifically for help files (not the one for only help tags). I attempted to do so, but the outcome was less than satisfactory. Apologies for the less-than-ideal implementation.
My attempt for Pick help_grep

Note: some of the code below borrowed and modified from another tele. ext.

    config = function(_, opts)
      local MiniPick = require("mini.pick")
      MiniPick.setup({})
      MiniPick.registry.help_files = function(local_opts)
        -- Parse options
        local_opts = vim.tbl_deep_extend("force", { prompt = "" }, local_opts or {})
        local prompt = local_opts.prompt
        local_opts.prompt = nil

        -- Get the paths of the help files
        local paths = vim.api.nvim_get_option("runtimepath")
        paths = vim.split(paths, ",")
        local dirs = {}
        for _, path in ipairs(paths) do
          local doc_path = path .. "/doc"
          if vim.fn.isdirectory(doc_path) == 1 then
            table.insert(dirs, doc_path)
          end
        end

        -- Start the picker based on CLI output
        MiniPick.builtin.cli({
          command = {
            "rg",
            prompt,
            "--color",
            "never",
            "--no-messages",
            "--line-buffered",
            "-g",
            "!*.log",
            "-n",
            "-H",
            unpack(dirs),
          },
          prompt_title = "Help Grep",
        }, local_opts)
      end
    end,

thank you for your time and assistance!

I would advise not to try and implement specifically a grep_live version, as it it is quite involved if you want it to work smoothly (or at all even, really). If you must, I'd start from grep_live source (there are couple of unexported helpers used, but they should be replaceable).
What you have is a variant of builtin.grep, which is a more reasonable idea. The general approach of using rg inside a dedicated runtime directories seems doable. The details of which arguments to use I'll leave to the audience :) One observation, though: prompt_title is not a part of builtin.cli arguments; you'd probably want a { source = { name = 'Help Grep' } } as the second, opts argument.
That said, I'd suggest to go another route completely. Take a look at :h helpgrep or :h lhelpgrep. With it you can do something like this:

:helpgrep <pattern> (like :helpgrep window). This creates a quickfix list (with lhelpgrep it creates a location list).
Use :Pick list scope='quickfix' to navigate through quickfix list (or use location list if needed).

You can wrap those two steps in a single function if you'd like.

Hi ! Thanks a lot for mini.pick, it was a breeze to configure and works great ! Performance is really good too, which was my main reason for switching.
I've been wondering if there was something I could do to switch my rg configuration between pickers ?
For example, I'd like the default behavior of grep_live to use my default rg configuration, ignoring hidden and ignored files. But I'd also like to be able to call grep_live with another rg configuration, in case I need to find something in a hidden or ignored file.
To keep the configuration method consistent with the chosen solution, in the case of rg this would mean the ability, from mini.pick, to override RIPGREP_CONFIG_PATH for a given picker.
I saw that there is already support for cwd for the grep tool subprocess, mini.pick could also expose the env argument ?
And for simplicity, it would be nice to be able to concatenate arbitrary args to what mini.pick already uses, too.
This way, we could either do:
MiniPick.builtin.grep_live({tool = "rg"}, {source = {env = {"RIPGREP_CONFIG_PATH" = "/path/to/specific/configuration"}}})

or
MiniPick.builtin.grep_live({tool = "rg"}, {source = {args = {"--hidden"}}})

This wouldn't need any tool specific handling from mini.pick, but would allow users to customize the calls for convenience.

I've been wondering if there was something I could do to switch my rg configuration between pickers ?
For example, I'd like the default behavior of grep_live to use my default rg configuration, ignoring hidden and ignored files. But I'd also like to be able to call grep_live with another rg configuration, in case I need to find something in a hidden or ignored file.
To keep the configuration method consistent with the chosen solution, in the case of rg this would mean the ability, from mini.pick, to override RIPGREP_CONFIG_PATH for a given picker.

I think the best solution here would be to write a wrapper function which temporarily sets the environment variables. Something like this:
MiniPick.registry.grep_live_specific = function()
  local cache_rg_config = vim.uv.os_getenv('RIPGREP_CONFIG_PATH')
  vim.uv.os_setenv('RIPGREP_CONFIG_PATH', '/path/to/specific/configuration')
  MiniPick.builtin.grep_live({ tool = 'rg' })
  vim.uv.os_setenv('RIPGREP_CONFIG_PATH', cache_rg_config)
end

You can then call it with :Pick grep_live_specific.

I saw that there is already support for cwd for the grep tool subprocess, mini.pick could also expose the env argument ?
And for simplicity, it would be nice to be able to concatenate arbitrary args to what mini.pick already uses, too.

grep_live is a very unusual picker which doesn't operate as others. So having it affect the overall picker source design wouldn't be wise.
For other CLI related tasks there is a builtin.cli() picker which has spawn_opts local option to set anything vim.uv.spawn() allows as option.

I really like your work. My setup contains only mini.nvim and a few others for LSP. But I'm having trouble getting mini.pick to work.
On 2 out of 3 systems, I only get the floating window with no content. I can ESC to close that window, but nothing else happens. That's independent of the picker I choose, neither files nor buffers shows anything. On the third system, everything works as intended. I'm using exactly the same config (same init.lua file) on all three systems.
Any hints what might causing this? :checkhealth on all three shows nothing obviously wrong.

I really like your work. My setup contains only mini.nvim and a few others for LSP. But I'm having trouble getting mini.pick to work. On 2 out of 3 systems, I only get the floating window with no content. I can ESC to close that window, but nothing else happens. That's independent of the picker I choose, neither files nor buffers shows anything. On the third system, everything works as intended. I'm using exactly the same config (same init.lua file) on all three systems. Any hints what might causing this? :checkhealth on all three shows nothing obviously wrong.

Hi, thanks!
Without additional information I can not really help. For example:

What is the working system and what are two that don't work?
Does any built-in picker work? For example, builtin.help?
Does a direct picker start work? Try executing :lua require('mini.pick').start({ source = { items = { 'a', 'b' } } }) which should result into a picker with two items "a" and "b".

Without additional information I can not really help. For example:

What is the working system and what are two that don't work?

working: Arch, neovim 0.9.4
nonworking: debian 12, neovim 0.10.0 and debian 11, neovim 0.10.0

Does any built-in picker work? For example, builtin.help?

I'm using those via keybinding, but nothing shows beside the empty window :(

Does a direct picker start work? Try executing :lua require('mini.pick').start({ source = { items = { 'a', 'b' } } }) which should result into a picker with two items "a" and "b".

Nothing shown

working: Arch, neovim 0.9.4
nonworking: debian 12, neovim 0.10.0 and debian 11, neovim 0.10.0

My guess would be that both 0.10.0 versions are too old and don't have the floating window footer feature. Either using latest Nightly appimage or indeed rebuilding latest nightly from source should solve the issue in this case.

working: Arch, neovim 0.9.4
nonworking: debian 12, neovim 0.10.0 and debian 11, neovim 0.10.0

My guess would be that both 0.10.0 versions are too old and don't have the floating window footer feature. Either using latest Nightly appimage or indeed rebuilding latest nightly from source should solve the issue in this case.

As usual, you are absolutly right :) Rebuild both nvim versions solved my problem. Thanks.

Is there a way to resume just one individual picker? I would like to set a keymap to always open live_grep with the last searched word, basically something similar to fzf live_grep_resume.

Is there a way to resume just one individual picker? I would like to set a keymap to always open live_grep with the last searched word, basically something similar to fzf live_grep_resume.

Unfortunately, no. It would require storing too much data, so there is only one builtin.resume() to resume the latest used picker.
You can kind of implement this by overriding choose action to store the latest query and then implement other picker to use that query as initial. Something like this:
local latest_grep_live_query = {}
MiniPick.registry.grep_live = function(local_opts)
  local cache_query_and_choose = function(...)
    latest_grep_live_query = MiniPick.get_picker_query()
    return MiniPick.default_choose(...)
  end

  return MiniPick.builtin.grep_live(local_opts, { source = { choose = cache_query_and_choose } })
end

MiniPick.registry.grep_live_resume = function(local_opts)
  vim.schedule(function() MiniPick.set_picker_query(latest_grep_live_query) end)
  return MiniPick.registry.grep_live(local_opts)
end

With this you can use :Pick grep_live_resume to resume latest search. Note that it will resume with the query when the latest chosen item was chosen. So if you looked for something and hit <Esc>, it doesn't store the query. You can also override <Esc> to also store it, but I would like to leave to actual users.

With the release of 0.11.0, 'mini.pick' is now out of beta-testing. Huge thanks to everyone for constructive feedback and participation!

@echasnovski Thank you for your work and dedication! I immediately switched to it and I don't see any point to switch back.

Thank you for the very nice plugin. Is there a way to have ignorecase when doing grep_live?

Thank you for the very nice plugin. Is there a way to have ignorecase when doing grep_live?

builtin.grep_live uses CLI tool with only a minimal set of arguments to make it work. To configure it further, configure corresponding tool. If you use rg, then it is a matter of putting a --ignore-case line in some file and setting RIPGREP_CONFIG_PATH environment variable to point to it. See this part of rg guide.

Thanks a lot Evgeni! Did not know about ripgrep's config file. Works beautifully!

Hi, thanks for the great plugin!
How would I go about configuring a grep and grep_live picker that would use GNU grep?

Hi, thanks for the great plugin! How would I go about configuring a grep and grep_live picker that would use GNU grep?

builtin.grep_live only supports rg or git (which is git grep and very close to GNU grep) tools. I'd recommend using git tool with something like :Pick grep_live tool='git'.
builtin.grep also supports git tool, but if you really need GNU, you can use builtin.cli() picker to call grep CLI tool in a way similar to the output of git grep.

Thanks for the quick reply!
It's just that I don't want to have a dependency on rg. Using git is acceptable, but is it possible to pass additional flags like --untracked to git grep for grep_live picker?

Thanks for the quick reply!
It's just that I don't want to have a dependency on rg. Using git is acceptable, but is it possible to pass additional flags like --untracked to git grep for grep_live picker?

As grep_live is a fairly unique picker in how it works, there are some limitations as to it. The suggested approach is to configure each CLI tool separately, but I am not sure if git can be configured to use --untracked for only git grep command.
My suggestion would be to either use builtin.cli() with desired flags (but no "live" behavior) or use rg.

[!NOTE]
@echasnovski I'm not sure if this is appropriate to add here on this older gh issue but thought it was better than opening a new gh issue or something (since it is not an issue but a question / request). Please let me know for the future what protocol you would prefer I follow for items like these!

For mini pickers, is there a way to have preview split out to side of the main picker items? similar to how telescope does it so you can cycle through the items in the picker and have the preview shown on the right side for example. Also similar to how you have mini.files working in concept where you can navigate the list of items and the preview is shown to the right.
Thanks!

Please let me know for the future what protocol you would prefer I follow for items like these!

There is a separate Q&A category for discussion which is dedicated for this type of interaction.

For mini pickers, is there a way to have preview split out to side of the main picker items? similar to how telescope does it so you can cycle through the items in the picker and have the preview shown on the right side for example. Also similar to how you have mini.files working in concept where you can navigate the list of items and the preview is shown to the right.

I am afraid, no. The whole idea is to have it be single window only while separate preview needs extra window. The 'mini.pick' approach is to have preview enabled with <Tab> and then navigate up/down: this will stay in preview mode.

I am afraid, no. The whole idea is to have it be single window only while separate preview needs extra window. The 'mini.pick' approach is to have preview enabled with <Tab> and then navigate up/down: this will stay in preview mode.

No worries! Thanks for the response. I kind of figured as such given your approach (which I appreciate) with trying to keep code as simple and concise as possible while maximizing features/value. Cycling through while in preview gets me most the way there.


ML 3.10 : Outlier Detection using Local Outlier Factor (LOF) (D)

Description 📜
Documentation and code on Outlier Detection using LOF.
Fixes #4113

Type of change 📝

[ ] Au#dio (Should be in mp3 format Includes speech clarity, Concise ,Low distortion)
[ ] Vi#deo (Animations, screen-recordings, presentations and regular explanatory films are all possibilties etc)
[x] Documentation (Content Creation in the form of codes or tutorials)
[ ] Other (If you choose other, Please mention changes below)

Domain of Contribution 📊

[x] Machine Learning

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

PR approved :tada:


[communication] Migrate @azure-rest/communication-messages to ESM/vitest

Packages impacted by this PR

@azure-rest/communication-messages

Issues associated with this PR

https://github.com/Azure/azure-sdk-for-js/issues/31338

Describe the problem that is addressed by this PR
Migrates the @azure-rest/communication-messages package to ESM/vitest
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


Custom urls in FlutterInstall task don't work

Hello,
I tried using custom urls to get around #43, but unfortunately it seems that custom urls simply don't work as expected. The FlutterInstall task fails (logs attached in next comment).
The root cause is that the cacheDir function in the Azure pipeline tools lib (called here) expects a semver compliant version for the version spec.
However, when using custom urls, the task just naively gets the last part of the url path and uses that as the version (seen here)
Because of the wrong version format, the cacheDir function fails which causes the whole task to fail.
It could be fixed by writing a more robust way to extract the version from the url. Alternatively, we could add a customUrlVersion input to let us explicitly set the version for custom urls.

Logs attached. I removed the repetitive unzipping logs

##[debug]testing directory '/Users/runner/work/_temp'
##[debug]mkdir '/Users/runner/work/_temp/155d21e4-5d70-49cf-9bf0-0c2df8f4c647'
##[debug]which 'unzip'
##[debug]found: '/usr/bin/unzip'
##[debug]/usr/bin/unzip arg: /Users/runner/work/_temp/a24fd750-f719-4251-b71f-e530cc9a74b0
##[debug]exec tool: /usr/bin/unzip
##[debug]arguments:
##[debug]   /Users/runner/work/_temp/a24fd750-f719-4251-b71f-e530cc9a74b0
/usr/bin/unzip /Users/runner/work/_temp/a24fd750-f719-4251-b71f-e530cc9a74b0
Archive:  /Users/runner/work/_temp/a24fd750-f719-4251-b71f-e530cc9a74b0
   creating: flutter/
  inflating: flutter/CODE_OF_CONDUCT.md
  inflating: flutter/.ci.yaml
  inflating: flutter/LICENSE
   creating: flutter/bin/
   creating: flutter/bin/cache/
  inflating: flutter/bin/cache/openssl.stamp
...

  flutter/bin/cache/artifacts/engine/darwin-x64/FlutterMacOS.framework/FlutterMacOS -> Versions/Current/FlutterMacOS
  flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.framework/Resources -> Versions/Current/Resources
  flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.framework/Versions/Current -> A
  flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.framework/Headers -> Versions/Current/Headers
  flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.framework/Modules -> Versions/Current/Modules
  flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.framework/FlutterMacOS -> Versions/Current/FlutterMacOS
(node:2049) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'trim' of null
##[debug]Exit code 0 received from tool '/usr/bin/unzip'
##[debug]STDIO streams have closed for tool '/usr/bin/unzip'
    at Function.clean (/Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/node_modules/semver/semver.js:285:25)
##[debug]Extracted to '/Users/runner/work/_temp/155d21e4-5d70-49cf-9bf0-0c2df8f4c647' 'https://storage.googleapis.com/flutter_infra_release/releases/stable/macos/flutter_macos_3.0.2-stable.zip' archive
    at _createToolPath (/Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/node_modules/azure-pipelines-tool-lib/tool.js:249:62)
##[debug]Adding '/Users/runner/work/_temp/155d21e4-5d70-49cf-9bf0-0c2df8f4c647' to cache (Flutter,flutter_macos_3.0.2-stable.zip, macos)
    at Object.<anonymous> (/Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/node_modules/azure-pipelines-tool-lib/tool.js:281:24)
Caching tool: Flutter null macos
    at Generator.next (<anonymous>)
##[debug]source dir: /Users/runner/work/_temp/155d21e4-5d70-49cf-9bf0-0c2df8f4c647
    at /Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/node_modules/azure-pipelines-tool-lib/tool.js:7:71
##[debug]Agent.Version=2.204.0
    at new Promise (<anonymous>)
##[debug]Agent.ToolsDirectory=/Users/runner/hostedtoolcache
    at __awaiter (/Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/node_modules/azure-pipelines-tool-lib/tool.js:3:12)
##[debug]Trying again to get (Flutter,flutter_macos_3.0.2-stable.zip, macos) tool from local cache
    at Object.cacheDir (/Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/node_modules/azure-pipelines-tool-lib/tool.js:272:12)
##[debug]isExplicit: null
    at /Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/index.js:94:14
##[debug]explicit? false
    at Generator.next (<anonymous>)
##[debug]Agent.Version=2.204.0
    at fulfilled (/Users/runner/work/_tasks/FlutterInstall_83c91e05-bdf9-42ce-b27e-6dae8771294e/0.3.0/index.js:5:58)
##[debug]Agent.ToolsDirectory=/Users/runner/hostedtoolcache
    at process._tickCallback (internal/process/next_tick.js:68:7)
##[debug]evaluating 0 versions
(node:2049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
##[debug]match not found
(node:2049) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
##[debug]task result: Failed

Note the line Caching tool: Flutter null macos. The version is null because semver.clean is called on the version, and semver.clean returns null if the string is invalid semver. This null version eventually leads to the crash

Custom urls work as intentded. You have not written what and how you used it, so I can't debug your config.
Custom version exsits too, you can use it as shown in the image.

To use the "customUrl" you can use it like this:
Example : https://storage.googleapis.com/flutter_infra_release/releases/stable/windows/flutter_windows_3.0.2-stable.zip

Now your question regarding, semversion. If you check this line you will see how version is handled in the customURL case. If you check this semver code. You will see why it throws "NULL".
Now, How do I know custom urls work? First, I have these setup on my Windows agent.
Second, How can you test if these work?

Fork this repo
do  npm install
Dir to "tasks" => "install"
run tsc in "install" directory
open another cmd in "tests" folder within "install"
open "latest.ts" and replace/append the below lines
runner.setInput("mode", "custom"); runner.setInput("customUrl", "https://storage.googleapis.com/flutter_infra_release/releases/stable/windows/flutter_windows_3.0.2-stable.zip");
save and run tsc in this folder too
run "node latest" and you will see the output of CMD.

Apologies, I didn't post a sample yml.
I tested on my repo, this sample azure-pipeline.yml on a Flutter project is enough for the pipeline to fail on my end:
# azure-pipelines.yml

trigger:
- main

pool:
  vmImage: macos-latest

steps:
- task: FlutterInstall@0
  displayName: 'Install Flutter SDK'
  inputs:
    mode: 'Custom'
    customUrl: 'https://storage.googleapis.com/flutter_infra_release/releases/stable/macos/flutter_macos_3.0.2-stable.zip'

@ko16a46 It is working on windows as well as on my local tests. I think semver is a little strict or works different on mac vms. But in either case just to be future safe I have added a small fragment parser on the url to parse the version out of it. So, it should work for you now. Let me know if it is working by closing this issue.

Glad to hear that 👍🏻


Migrations: Make generated code play well with StyleCop

Steps to reproduce
Add a new migration
The issue
Let me start with saying "Thanks for an awesome project".
This isn't a huge problem, but for all of us that uses StyleCop, adding a new migration creates a lot of warnings (and errors for release builds where warnings-as-errors are enabled).

Namespaces in Migrations/MyAppDbContextModelSnapshot are not ordered alphabetically.
Namespaces in Migrations/20161205224611_MyMigration.cs are not ordered alphabetically.
Namespaces in Migrations/20161205224611_MyMigration.Designer.cs are not ordered alphabetically.
Access modifier for Migrations/MyAppDbContextModelSnapshot class is implicit.
Access modifier for Migrations/20161205224611_MyMigration.Designer.cs class is implicit.

I would be happy to provide a PR to fix this if you think it's worth doing.
Another solution to this would be to add the standard <auto-generated> header to the generated files.
Further technical details
EF Core version: (found in project.json or packages.config)
Operating system: Windows 10
Visual Studio version: VS 2015

The implicit modifiers in the .Designer partial classes is by design. It allows you to change the class's access in a single location--the migration file. We could probably mark those files as auto-generated since they'll rarely have to be modified after being generated.

@patriksvensson we'd love to take a PR on this one. Here is what we think should be done...

Add <auto-generated> to the .designer files and to the model snapshot
Do the alphabetical sorting of using statements

Putting on the backlog, but we'd take the PR into 1.2 if it is ready in time.

@rowanmiller I can submit a PR for this, but I'm not sure when 1.2 is due (the milestone gives me no information about this).

@patriksvensson if you can get it in sometime in the next month or so that would give us time to have it in one of the pre-releases for the next release.

@rowanmiller Sounds good to me. I have plenty of free time the next month or so, so sign me up for this one.

Here's where to start digging in: CSharpMigrationsGenerator 😉

Hi, I don't want to re-open this issue but I wonder if it's somehow related to this one, which I encountered while running migrations during a publish step: https://github.com/StyleCop/StyleCop/issues/201  Any insights or suggestions would be appreciated.

Doesn't seem related

Is there a specific reason this PR was reverted (or, rather, the functionality was removed)?
I'm seeing my analyzers light up like a Christmas tree after revisiting the project after a couple of years, and the <autogenerated /> tag is no longer added to new migrations.

Looks like it's still there:
https://github.com/dotnet/efcore/blob/99d0c74454b683a2d432968794b4627dee6b41e3/src/EFCore.Design/Migrations/Design/CSharpMigrationsGenerator.cs#L141

Odd, because it's not being added to new migrations.


Console is only rendered correctly if page is reloaded

When I first logging the console doesn't get updated. If I reload the page with F5 it works.
Also, if I login with a different account it will show the previous account and not the actual account.

@renataogarcia Thanks for the feedback! I think I know what's going on and will try to have a fix out this weekend.
The extension tries to perform a reload of the page (to apply the customizations) during your login. This reload occurs after a slight delay, however, sometimes this delay is not long enough and the reload fails due to network conditions, page load speed, etc.
I'll start with exposing the "reload delay" setting via the extension - I believe increasing this delay may resolve the issue.

@WTFender Thanks for the quick response and making such an useful extension!
 I've cloned it locally and increasing the delay indeed fixed the problem of not applying the console customizations. However, with delays is always a hit or miss... Maybe could use a solution based on Mutation observers which would be more robust?
I've tried this and it worked nicely with the extension:
export function waitForElement<TElement extends Element = HTMLElement>(
  selector: string,
  options: {
    timeout?: number;
    parentNode?: ParentNode;
  } = {},
): Promise<TElement> {
  const { timeout = 3000, parentNode = document } = options;

  return new Promise((resolve, reject) => {
    const element = parentNode.querySelector<TElement>(selector);

    if (element) {
      resolve(element);
      return;
    }

    const observer = new MutationObserver((mutations) => {
      mutations.forEach((mutation) => {
        Array.from(mutation.addedNodes).forEach((addedNode) => {
          if (addedNode.nodeType === Node.ELEMENT_NODE) {
            const targetElement = (addedNode as Element).querySelector<TElement>(selector);

            if (targetElement) {
              observer.disconnect();
              resolve(targetElement);
            }
          }
        });
      });
    });

    observer.observe(document.documentElement, { childList: true, subtree: true });

    setTimeout(() => {
      observer.disconnect();
      reject(new Error(`Timeout: Element not found with selector "${selector}"`));
    }, timeout);
  });
}

and then use it in customizeConsole like:
  const footer = await waitForElement('#awsc-nav-footer-content');
  const footerLbl = await waitForElement('div._awsc-footer__inner__content__center_swu42_106 > span',{parentNode:footer});

Happy to create a PR for this change if you like.
I also noticed that neither increasing the delay or waitForElement fixes the problem of not applying the color and the profile name for the SSO.  I think it might be something else because it worked once with just these settings, and once it works it becomes sticky (it never changes when you log with another account). Maybe I should open a separate issue for this?

The mutation is definitely more reliable and makes sense to go that route. It'd be awesome if you want to open a PR, I'll get it reviewed quick.
The SSO issue sounds different, but I don't seem to be able to replicate.

Are you on the latest version (1.2.2)? Chrome?
Do you have the Label/Color header & footer settings checked?
When you're logged in with IAM, is the entire header/footer colored or just the top right?
Does your SSO role start with AWSReservedSSO_? (check in the top right menu)

If you've got the extension side-loaded, you can enable this debug flag to potentially see if theres errors thrown on your SSO console.

Started a branch with the mutation observer.
https://github.com/WTFender/aws-sso-extender/tree/fixPageReload
One gotcha is the element IDs and class names are dynamic, but they don't seem to change often.
Ex: div._awsc-footer__inner__content__center_swu42_106

@WTFender Thanks for looking into this! I've created the PR with further changes. Can you please have a look when you get a chance?
Created a new issue color/label #20


Reimplement kind checking and synthesis as a single bidirectional algorithm

We have this worked out on paper, so it needs implementing and that will simplify various things in the code based and upstream changes (e.g., type classes).

This got done and is in the v0.8 release.

This got done and is in the v0.8 release.


[Backport 1.x] Support for Google Application Default Credentials (#8394)

backport #8394 to 1.x

Hi @deshsidd, I have fixed up the failing Gradle checks. Could you please have a re-review when you get a chance? We will really appreciate it.

Hi @pajuric, changelog is added and the tests has all passed. We will really appreciate it if you could escalate this as per discussion with Arjun.

@reta @andrross have been ween backporting features into 1.x?

@dblock  Per the maintenance policy:

The software maintainers will not back-port fixes or features to versions outside of the maintenance window. That said, PRs with said back-ports are welcome and will follow the project’s review process. No new releases will result from these changes, but interested parties can create their own distribution from the updated source after the PRs are merged.

We won't backport a feature like this into a patch release (1.3.x) and have no plans to release a 1.4 version. However, if @yallen-ic and folks are interested in building their own distribution, then per my understanding of the policy we should accept this backport. @yallen-ic Are you intending to build your own 1.x distribution with this feature?

@andrross Thanks very much for the reply and info. Building our own distribution is out of scope of what we want to do, so we will be closing this PR.


az storage blob: 'directory' is not in the 'az storage blob'

[Enter feedback here]
Hi there,
I find this article regarding  creating a directory in a storage blob container,
but it seems this doc: (https://docs.microsoft.com/en-us/cli/azure/ext/storage-preview/storage/blob/directory?view=azure-cli-latest) is not actual, cause when I trying to run it, I receiving the following error:
az storage blob: 'directory' is not in the 'az storage blob' command group. See 'az storage blob --help'.
I working with Azure Stack
My Az cli version is:
{
  "azure-cli": "2.7.0",
  "azure-cli-command-modules-nspkg": "2.0.3",
  "azure-cli-core": "2.7.0",
  "azure-cli-nspkg": "3.0.4",
  "azure-cli-telemetry": "1.0.4",
  "extensions": {}
}

How even can I create a directory in a container through a cli? I finded what it is now possible via storage explorer but I need to use it in automation.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 47613ea1-91af-6900-1867-19e08b116908
Version Independent ID: 17534203-877d-b510-666b-452d4e6382bc
Content: az storage blob directory
Content Source: latest/docs-ref-autogen/ext/storage-preview/storage/blob/directory.yml
Service: storage
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

add to S172

I'm sorry, cause i skipped this:
To use the directory commands, please make sure your storage account type is StorageV2.
Azure Stack support only v1 Storage accounts, so the article is correct.


add cudf to toctree

Follow up to https://github.com/huggingface/dataset-viewer/pull/2941
I realized the docs were not building in the CI: https://github.com/huggingface/dataset-viewer/actions/runs/9648374360/job/26609396615
Apologies for not checking this in my prior PR.

Thanks for the contribution @raybellwaves , it is now live in https://huggingface.co/docs/datasets-server/cudf


⚠ SceneTime has degraded performance

In 5bd46f8, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 6898 ms

Resolved: SceneTime performance has improved in 57411bf after 9 minutes.


Where is the problem?

https://ibb.co/fNWLNpv
https://ibb.co/YfyyYJk

Links aren’t valid. Share here directly @ansi82

@ansi82 You have removed PINCodes from thw config file. Don’t remove anything. If you feel you don’t want to search by PIN, just set the IsSearchToBeDoneByPINCode as false and leave it as it is. Also, I see there are some more missing stuffs in config file, make sure you don’t remove anything. Just fill what’s required. Check Readme MUST CHANGE Section for more details

thanks, solved

Enjoy and feel free to Star the Repo, if I could help you in any way! Share it in your circles @ansi82


EKF drop unused timestamp from collect_gps() and pass data by const reference

fixes https://github.com/PX4/ecl/issues/581
PX4/Firmware side https://github.com/PX4/Firmware/pull/11594

@fvantienen

The only warning I still get now is:
estimator_interface.h:172:46: warning: unused parameter ‘gps’ [-Wunused-parameter]
  virtual bool collect_gps(const gps_message &gps) { return true; }

But next to that it works fine.

Ok, I think I've got them all now. Please review.

Tested and works!


Installing<EMAIL_ADDRESS>failed.

hey @xfcdxg , what os are you using? can you please attache the above log ?
Thanks

MacOS Mojave 10.14.5

can you try to re-install tabnine ? it looks like some cashing issue with atom package manager

Windows 10, update failed, cannot re-install.

@RayFungHK  - with the same log? can you please check  the thread from  #18 ?


temporarily force ssl_verify_fun to use rebar3 manager to fix CI

Reason: https://github.com/deadtrickster/ssl_verify_fun.erl/pull/27

Pull Request Test Coverage Report for Build de040f449f9028e9e53dd1a47299706cc8ab0869-PR-105

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 9c411952961326a753dabf66216c59e6ba726176:
0.0%

Covered Lines:
370

Relevant Lines:
370

💛  - Coveralls


Update lib to be async

MPAGES_EVENT (and likely more) are actually async in Edge/Chrome, and methods should reflect this. Of note, MPAGES_EVENT:ORDERS returns values in three states when an invocation occurs:

null if an order fails, e.g. synonymId doesn't exist.
empty string when cancelled
XML string for orders that  were placed successfully.

Feedback should be provided to the user to help indicate the success of an order that was placed.
Task List

[ ] submitOrders -> submitOrdersAsync
[ ] openPatientTab -> openPatientTabAsync
[ ] openOrganizeTab -> openOrganizerTabAsync
[ ] makeCclRequest -> makeCcleRequestAsync
[ ] launchPowerNote -> launchPowerNoteAsync
[ ] launchClinicalNote -> launchClinicalNoteAsync

Starting work on submitOrdersAsync.
MPAGES_EVENT (and likely more) are actually async in Edge/Chrome, and methods should reflect this. Of note, MPAGES_EVENT:ORDERS returns values in three states when an invocation occurs:
null if an order fails, e.g. synonymId doesn't exist.
empty string when cancelled
XML string for orders that were placed successfully.

Issue: Suspect that when multiple orders are placed an array will result, in which case the object will be different. Need to find a way to handle this appropriately.

WARNING: POWERFORM, POWERNOTE, and CLINICALNOTE options for MPAGES_EVENT always return null no matter success or failure.


feat: Added Support for changing the week day position(top/bottom) in…

… weekView #283.
Description

Added a flag [showWeekDayAtBottom] option to change the position of the weekday in the week-view.
showWeekDayAtBottom: false (Default)

showWeekDayAtBottom: true

Checklist

[x] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[x] I have followed the Contributor Guide when preparing my PR.
[] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[ ] I have updated/added relevant examples in examples or docs.

Breaking Change?

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues

Closes #283

@jaiminrana05  Please resolve the conflicts in this PR.


Frontend-homework<6>

Topics Covered :
-Express
-Node
DriftVideo:https://video.drift.com/v/abYC60xOTScsdlt5JxikOW0jW8Fumlx0bfEsQuHwiPgao/
ScreenShots:

Metric
Value

alert_status
:white_check_mark: OK

bugs
0

code_smells
0

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


about $compile function

Vue.js version
2.0.2
I just miss  the _self.$compile(_self.$el) way to rebuild the page.
Is there any easy way to realize it ?
Because so many public js components are base on jquery.
most of them has self-render function.  and event Listener,
Although can use jquery way to bind function and bla, bla, bla things.
In vue i think Vue's way is better.
So , could u help with it.
I found many others have the same puzzle.

Just use this.dynamicComponent = Vue.extend({template: '......'}) to get a component, and then use it with <component :is="dynamicComponent">

This only works when you know where the compiled template is going to be inserted. Is there a more generic solution than this?