Good First Issues in Lua

WarningInstalling via LuaRocks (rocks.nvim, luarocks install) is currently broken. Until this is fixed, install via git instead: -- lazy.nvim { "S1M0N38/love2d.nvim" } -- or vim.pack vim.pack.add({ "https://github.com/S1M0N38/love2d.nvim" }) then run git submodule update --init --recursive in the plugin directory. What's wrong: the published rockspec has no build.copy_directories, so installed rocks are missing plugin/ (:Love command), libraries/ (LÖVE type definitions), compiler/, after/, and lsp/. Symptoms: :Love doesn't exist, no love.* completions, :checkhealth love2d warns about missing type definitions. Affected: all LuaRocks artifacts (scm/dev and tagged releases).

Feature request right now when you press "i" where the results are shown, neovim tells you "readonly buffer/can't be modified". Would be great to have instead focus the input container of the sidebar since that's what the user wants most likely. Motivation improve UX Other I dont have the time to experiment with #3081 but maybe it could make for a better experience.

Bug description Some xrow decoders assume a key always fits in a byte, resulting in truncation of long unknown keys and attribution of their values to other keys: tarantool/src/box/xrow.c Lines 2370 to 2371 in fffad3e uint8_t key = mp_decode_uint(&d); switch (key) { So, encoding box.iproto.key.INSTANCE_NAME + 256 key with some value will override the real box.iproto.key.INSTANCE_NAME's value. Reproducer: Run the following script in tarantool in interactive mode and observe log output: nb = require('net.box') msgpack = require('msgpack') uuid = require('uuid') function subscribe(conn, uuidstr, key, value) local header = msgpack.encode({ [box.iproto.key.REQUEST_TYPE] = box.iproto.type.SUBSCRIBE, [box.iproto.key.SYNC] = conn:_next_sync(), }) local body = msgpack.encode({ [box.iproto.key.INSTANCE_UUID

Bug description Most xrow decoders intend to skip unknown keys and their values, like this: tarantool/src/box/xrow.c Lines 977 to 979 in fffad3e if (key < iproto_key_MAX && iproto_key_type[key] != mp_typeof(*value)) goto error; But this check ignores the fact that known keys have gaps below iproto_key_MAX. At the moment of writing, 0x16 key is unassigned, for example (and many others as well). Such keys get MP_NIL as their iproto_key_type, so when such a key is found in a request it's rejected if it has any other value than MP_NIL. Correct handling is implemented in iproto_watch decoder: tarantool/src/box/xrow.c Lines 1798 to 1802 in fffad3e uint64_t key = mp_decode_uint(&data);

Summary Server discovery only looks for service.json in the XDG state directory, but OpenCode v2 names the registration file after OPENCODE_CHANNEL. The Nix package sets OPENCODE_CHANNEL = "prod", so it writes service-prod.json and the plugin never finds a server. Why the filename is channel-dependent packages/cli/src/services/service-config.ts: export function filename(channel = OPENCODE_CHANNEL) { if (channel === "latest" || channel === "dev" || channel === "beta" || channel === "next") return "service.json" return `service-${channel.replace(/[^a-zA-Z0-9._-]/g, "-")}.json` } So only latest, dev, beta and next produce the plain name. nix/opencode.nix on v2 builds with env.OPENCODE_CHANNEL = "prod", which is not one of them, so Nix users get service-prod.json. lua/opencode/server/discovery/init.lua hardcodes the plain name: local path = vim.fs.joinpath(state_dir, "service.json") Reproduction From a Nix-packaged OpenCode v2 (nix build .#opencode), with an isolated state dir: $ expor

right now except if I am in debug mode, it's hard to know for instance in :AvanteSwitchProvider if I am selecting is an ACP provider. Maybe one shouldn't care but I do. It should also appear in label windows.sidebar_header.include_model (which should default to true btw).

Currently, some features of our plugin may not be presented in a well-visualized manner, and some aspects are not even mentioned at all It would be very helpful to have clear explanations and GIF demonstrations, both for attracting new contributors to iterate on this plugin and for reducing the friction for humans and agents reading it. If you like this plugin and want to try doing something for it, this might be a good place to start.

Describe the issue In #1825, a bug is reported that a toilet room with a large number of toilets and sinks will cause the room not to be fully utilized. Patients cannot move fast enough through the door. Which CorsixTH version was the issue first discovered in? Unknown, but there is a 0.70.1 savegame in the issue. How can this be reproduced in CorsixTH? Load save game https://github.com/user-attachments/files/32342737/0.70.1_big_toilet.sav.zip Watch the behavior of the patients with the toilet room. Observe that not all toilets are used. What is the idenitifed cause of the problem (if a bug)? It seems that using the door by the patients is not fast enough. What is the recommended approach(es) to resolve this? The issue only contains discussion about Corsix-TH behavior. It seems nobody tried what happens when you do this in the original game. It is not clear what to do in #1825 to resolve the problem (if it can be resolved at all). Corsix-TH aims to give similar results as the o

Description FiveM for GTAV Enhanced crashes reproducibly when using consumable food/drink items through ox_inventory. So far the crash has been reproduced with: water burger The client crashes during or shortly after the item use animation finishes. Environment FiveM for GTAV Enhanced ox_core ox_inventory ox_lib Windows 11 Local development server Steps to reproduce Start the server with ox_core and ox_inventory. Connect using FiveM for GTAV Enhanced. Give the player a water or burger. Use the item. FiveM Enhanced crashes. Behaviour The crash is reproducible across multiple attempts. Example crash report codes: 2e2bd9b4-4ff5-4ac4-80b9-4df7454ba938 b6741ef9-699c-423c-9ade-44fa14dd2528 9a46e782-cc23-4bef-a65d-14a1fb63bcd8 The Enhanced client log ends with: The application has crashed! In several reproduced sessions the log also contained: Unable to load file web/build/none for resource ox_inventory. This file is not supported in NUI. I am not sure whether that message is relat

I noticed this after copying a faction from a DrGBase NextBot with the "Faction Tool" then applying it to a VJ NPC via the "Relationship Modifier" tool. This also occurs after applying a VJ NPC's class to a NextBot. The order of spawning each entity is relevant as well: A. If a VJ NPC is spawned first with a DrGBase faction applied, then the NextBot won't attack the NPC, yet the NPC will be hostile. B. If a NextBot is spawned first with a VJBase class applied, then the NextBot won't attack the NPC, yet the NPC will be hostile. C. If a NextBot is spawned first without changing its faction AND the VJ NPC has a faction applied, then both will be hostile to each other. I used VJ NPCs from "HL Resurgence" and "Black Mesa SNPCS" along with NextBots from DrGBase itself and "Pillar Chase 2" to replicate this behavior.

It would be useful to have an option to connect to an already running sandboxed, headless pi instance instead of having pi.nvim start pi as a subprocess. Motivation If Neovim is sandboxed as well, it would be convenient to run Neovim and pi in separate sandbox profiles (nono in my case). For example: Neovim runs in one nono sandbox profile. Headless pi --mode rpc runs in another, more restrictive nono sandbox profile. pi.nvim connects to the already running pi instance instead of spawning it itself. This would allow the Neovim and pi sandboxes to have independent permissions while still providing the same pi.nvim UI and workflow.

While reviewing midealocal/devices/ed/, I found a few pieces of code that look unreachable in production, and want a second opinion before touching them — some may be intentional test seams or placeholders for future subtype support rather than cruft. 1. _use_new_set() / MessageOldSet midealocal/devices/ed/__init__.py:171-173: def _use_new_set(self) -> bool: # if (self.sub_type > 342 or self.sub_type == 340) else False return True This is hardcoded to always return True, and no subclass overrides it. That means the else branch in set_attribute() (midealocal/devices/ed/__init__.py:418-419) that builds a MessageOldSet can never run on a real device, and by extension MessageOldSet itself (midealocal/devices/ed/message.py:504-521, whose body is always an empty bytearray([])) never gets used in production. The only place this branch executes is tests/devices/ed/device_ed_test.py:884-895, which mocks the private _use_new_set method (patch.object(self.device, "_use_new_set", return_

FD contains _detect_modes / detect_modes logic copied from the FC implementation, but it is never wired into the FD device attributes. As a result, the parsed mode information is currently unused. It is unclear whether this is incomplete functionality that should be exposed through the FD attributes or dead code that should be removed. We need to verify the intended FD behavior and decide whether the mode detection logic should be wired into DeviceAttributes or removed.

CAExceptionMessageBody defines around 25 error-flag attributes, but they all currently read the same bitmask: body[3] & 0x04. These attributes are also not wired into DeviceAttributes, so they are currently inert and have no observable effect. Correcting the bitmasks would require determining the actual bit positions for each error flag. Without firmware documentation or hardware/protocol data, assigning different bits would be speculative. We need to verify the CA exception message layout using reliable protocol or hardware data before changing the bitmasks or exposing these attributes through DeviceAttributes.

X34 parses a start field, but the value is never wired into DeviceAttributes, making it unreachable through the public device attributes. The field does have dedicated unit tests, so it is unclear whether this is an incomplete implementation or intentionally retained parsing logic. We need to verify the intended behavior for the start field and decide whether it should be exposed through DeviceAttributes or removed along with its dedicated tests.

FDA0MessageBody.tank and .mode both derive their values from body[10], unlike the C8 variant, which uses separate bytes for these fields. The existing test also explicitly derives both fields from the same byte value, suggesting this may be intentional firmware encoding rather than an implementation bug. We need to verify the FD firmware message layout and confirm whether sharing body[10] for both tank and mode is intentional. If confirmed, document the behavior and keep the existing implementation and test unchanged.

1. Problem overview A customer request consists of two parts. The light one is made with balance = true, prefer_replica = true (i.e. router.callbre()), the heavy one — with balance = true, prefer_replica = false (i.e. router.callbro()). In a master + replica setup almost all the heavy requests land on the master. Each call type on its own is balanced correctly, the problem appears only when they are mixed. It is not a matter of the calls being ordered in some unlucky way either: the customer has many independent load generators, the calls interleave randomly, and the master still takes the heavy load. The reason is that callbre() does not rotate the shared round-robin cursor, it resets it. 2. Reproduce test/router-luatest/router_balance_test.lua local t = require('luatest') local vtest = require('test.luatest_helpers.vtest') local g = t.group('balance') -- -- Setup of the client: one replicaset, master + one replica. -- local cfg_template = { sharding = { {

I've ran into a couple of situations where I wished to be able to send a prompt directly from lua code: Trying to integrate review.nvim (local diff annotation, similar to PR review UIs), similar to how it already supports sidekick plugin: https://github.com/georgeguimaraes/review.nvim/blob/main/lua/review/export.lua#L101C1-L117C4 Spawn a separate subagent session in a new tmux window. Right now it would require me to manually copy paste into a buffer. I'd imagine it would look something like this: require("agentic").send("Useful Prompt") For people who are using multiple sessions at once this function would send the prompt to the currently active session. Additionally there could be send_to_session(prompt, session_id), and leave it to users to figure out which session_id they need.

https://iot.midea.com/docs/control-midea-cloud-devices/cloud-2-cloud-v3-api.html

想解决的问题 阅读时标注想法，像同步阅读时长一样把想法同步到微信读书 建议方案 无 截图或参考，可选 No response 插件版本 1.2.0 KOReader 版本 2026.07.2 提交前确认 我已经搜索过已有 issue，确认没有相同或非常类似的请求。 这个请求不包含 API key、cookie、完整 cURL、账号信息或私人书籍内容。

Did you check docs and existing issues? I have read all the haunt.nvim docs I have updated the plugin to the latest version before submitting this issue I have searched the existing issues of haunt.nvim I have searched the existing issues of plugins related to this issue Neovim version (nvim -v) nightly Operating system/version MacOS Describe the bug @TheNoeTrevino i finally found why the tests fail locally for me. I am guessing you are not on macOS. macOS has var symlinked to /private/var. function M.create_test_buffer(lines, filename) local bufnr = vim.api.nvim_create_buf(false, false) local test_file = filename or (vim.fn.tempname() .. ".lua") vim.api.nvim_buf_set_name(bufnr, test_file) vim.api.nvim_buf_set_lines(bufnr, 0, -1, false, lines or { "Line 1", "Line 2", "Line 3" }) vim.api.nvim_set_current_buf(bufnr) return bufnr, test_file end So the vim.fntempname()returns/var/folders/...but Neovim resolves the buffer name to/private/var/folders/...`. The test keep the original pa

minetest_game/mods/tnt/init.lua Line 177 in 0e07e1c obj:set_hp(obj:get_hp() - damage)

Hey! Just adding this here mainly as a note to self to have a think and propose a design/solution for a feature idea 👀 GitHub is releasing a new feature, Stacked PRs. I'm wondering how useful it would be to include support for this in Octo? :D PullRequest objects in GraphQL include a new field for stack, representing a list of related PRs that build on top of each other (reference). So I think this is technically very possible! But I'm not too sure what the most helpful way of showing this in Octo could be. Few ideas I'm thinking of: Stack information is simply listed within a pull request buffer, as a summary (Stack: 1/x approved, ready to merge) or as a list of PRs within the stack. New action for pull request buffers to view the stack within a picker, allowing the user to jump between PRs. picker could show stack status too. Some kind of shortcut to move up/down within a stack. Thoughts? Realise this is just very much a dump of my own thinking right now sorry! 😅

I was thinking we might wanna start a new conversation every time the extension loads (1 nvim session = 1 pi session) The advantages would be making a quick edit AND then say something "actually, remove that" and it will have the context potentially faster responses: we can start the session at extension load time, so we remove that overhead when calling pi. Model response time would be the only time we care about I'm not sure if it'd be too bad for long-running sessions

Claude code has support for asking users questions. It does this as part of the tool_call with tool_name set to AskUserQuestion. I don't see anything about this tool in the ACP spec, so I think the right way to support this is some kind of callback/hook mechanism, which agentic already partially offers via on_session_update. There's also the possibility that #217 might be a better approach to hooks in general and could be another way to expose the hook. So, first, what hook mechanism would be correct for this? Second, I think this would require some official API for prompting the user for input in one of the existing agentic widgets. So then integrating AskUserQuestion would involve implementing a hook on tool calls, checks if the tool isAskUserQuestion and then renders the questions from the tool call in the widget. It would then also need to attach another callback for after the user responds to return the answers to the agent. This is just based on my brief read on how to integrate

It would be awesome if in addition to installation through the AUR, there was a nix flake in the repository for installation using nix.

Using the lua version of this plugin is not really supported when using homemanager. The default method of loading a plugin through homemanager uses hl.plugin.load() which I think only works with cpp plugins. It's possible to just add raw Lua to the config, but then you need to access the lua files inside the nix store, which is a bit difficult. A workaround for that is adding the plugin files as "extraLuaFiles", but that is a bit verbose. I found 2 solutions, but I don't like them as they are both pretty unstable. Here you can see the different solutions: Everything has to be in wayland.windowManager.hyprland. ExtraLuaFiles Here you have to manually add each lua file. As soon as a new file gets introduced this will break. extraLuaFiles = { "globals" = { content = builtins.readFile "${inputs.split-monitor-workspaces.outPath}/lua/globals.lua"; autoLoad = false; }; "helpers" = { content = builtins.readFile "${inputs.split-monitor-workspaces.outPath}/lua/helpers.lua";

When you use a nightly build , the version CommonData/VERSION reports 0.0.0 it could be nice to have the AAAA.MM.JJ instead.

Front passenger doors are too far forward. It should be somewhere behind the nose gear doors. Not sure if the other doors are in the right spots or not. PLEASE VERIFY THE DOOR POSITIONS (AND ALSO THE WINDOW POSITIONS AND THE AMOUNT OF WINDOWS WHILE YOU'RE AT IT)

lazy.nvim support rockspec https://lazy.folke.io/packages#rockspec rocks.nvim support download prebuilt binary rocks https://github.com/lumen-oss/rocks-binaries How about adding a rockspec like https://luarocks.org/modules/teto/avante.nvim? Related: olimorris/codecompanion.nvim#3173