Make the limitation of region context lines optional

[martenlienen]

This change lets the user decide to how many lines the embedded region context should be limited. I have set the default nil, because I personally expect the context to send the complete region when I explicitly select one, but I can of course change it to 5 as it was hard-coded before.

Checklist

• I agree to communicate (PR description and comments) with the author myself (not AI-generated).
• I've reviewed all code in PR myself and will vouch for its quality.
• I've read and followed the Contributing guidelines.
• I've filed a feature request/discussion for a new feature.
• I've added tests where applicable.
• I've updated documentation where necessary.
• I've run M-x checkdoc and M-x byte-compile-file.

[xenodium]

Thank you for the PR.

This change lets the user decide to how many lines the embedded region context should be limited. I have set the default nil, because I personally expect the context to send the complete region when I explicitly select one,

It's capped as a preview so you get a peek at what you're sending, but the agent still knows that you are inerested in the full range context, which is specified in the file path (along with line range).

but I can of course change it to 5 as it was hard-coded before.

Yes please. The cap was introduced because it was too noisy if selection was large.

[martenlienen]

Yes, I noticed that too after using it a bit now and I can see that there are cases where I just want to give the agent a pointer. My feeling at the moment is that when I select a region, I also want to send the full region, but that is noisy in the UI. What do you think about sending the full region, but hiding some of it in the agent-shell UI with an overlay that hides lines 6+?

[xenodium]

What do you think about sending the full region, but hiding some of it in the agent-shell UI with an overlay that hides lines 6+?

Curious, for your use-case does it matter if it's sent inline or not? The agent already knows the lines that it needs to look at encoded in the file path (eg. path/to/agent-shell.el:5771-5775). If anything, I'm wondering if relying on the existing behaviour is more efficient as it enables the agent to decide what's the best way to look at those lines (maybe they are too long and thus adjusts its streategy).

[martenlienen]

So my situation is that I have a piece of text in an org file and I have a custom context function to send the current subtree. I want to refine the text with feedback from the agent. If I rely on the file link, I have to rely on the agent to deduce to read the file (which it sometimes does not and then gives me the same feedback again) and then wait for the tool use. Just sending the subtree directly as text to the agent is quicker in this situation and more reliable.

[xenodium]

Ok, I've submitted 5fd9794 which likely caters for both worlds. Default behaviour remains as is, but you now have an expand button (actually replaces the preview with full text) to get the entire text if needed (and edit if needed).

[martenlienen]

That looks amazing! I will close this PR for now and report back if I have another idea for how to improve it.

[xenodium]

That looks amazing!

Glad you like it. If you or your employer are in a position to do so, please consider sponsoring. I regularly get requests like this one and I work with submitter to find a suitable solution. I'm working daily on agent-shell to keep up, but it's not quite sustainable as indie dev (this is time I could have spent on more sustainable activities).