Tasks: Include word under cursor in ZED_SELECTED_TEXT environment variable when no text is specifically selected

[florinpatrascu]

Check for existing issues

• [X] Completed

Describe the feature

Update the environment variable ZED_SELECTED_TEXT to collect the word under the cursor when no text is specifically selected. This adjustment will assist in tasks or snippets that require capturing the word under the cursor. Background: #13327, for more context

Thank you for considering this request for enhancement.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[osiewicz]

Hey, Thanks for filling an issue, but I don't think we should proceed with it; at least not as is. My gripe is: why should a word be the default? Sure, it would solve your use case, but if somebody needed the default to be a full line, they'd be screwed. We can go on and on like this; I don't think this variable should have a default value. I think what you want is to get the name of a module you're in/hovering over; tasks may provide a way to expose that information in the future. For now, since tasks can be arbitrary bash scripts, I'd suggest preprocessing ZED_SYMBOL value as you see fit. I'm not exactly sure what you meant in:

Ah I just tried $ZED_SYMBOL, but in my case it includes the module name - as I'm editing Elixir source code.

Does it contain just the module name? It should contain a function name if your cursor is inside of one.

[florinpatrascu]

Thanks for the reply, but I think you're exaggerating a bit about the risk of selecting a full line - the case of default. So what if that happens? The action a human operator performs in this context is expected to be deliberate. If someone selects a whole loremipsum string, his business right? I don't think the Zed editor, the tool in this case, has to play the role of the policeman, no?

Do I get turned on by the current solution, that of launching a process, and another process to send a simple openuri to the system? Absolutely not. Not obvious, but I haven't found a better method and the advice I received about using the task feature was an acceptable compromise, which is why we're discussing tasks at the moment.

About zed_symbol. Please understand better what I'm after. I'm interested in the word or selection I want, not the name of the function or module I'm in. That word or selection is actually what I am interested in and what I want to send to an external application, Dash in my case

You can reject this request, no problem, your project your rules and I completely respect your decision. All I did was suggest a change. If what I have suggested is not possible for the reasons you list is ok, I will wait until a better solution will be found, because I am convinced that what I wanted to solve is not a special case, and other users may have the same need. Thank you.

[osiewicz]

I was more so concerned with picking an arbitrary default (a word under the cursor, or the line), precisely because it's arbitrary; somebody else might expect that default to be different, and they wouldn't be wrong to. That's why I don't think SELECTED_TEXT should have any default. If you're indeed interested in deliberately using the current word under cursor then that's understandable & plausible, but we should use a separate task variable for it (ZED_CURRENT_WORD) instead of adjusting an unrelated task variable.

[florinpatrascu]

changed the title ..

@notpeter - The reason I initially considered suggesting assigning a default value to an existing variable was because of a very conservative perspective. I did contemplate suggesting a new environment variable, similar to what both of you are now pursuing. However, this approach would require the user to manage two environment variables and deal with unnecessary complexity in choosing between ZED_CURRENT_WORD and ZED_SELECTED_TEXT. Moreover, these variables would contain completely different content, especially when instructions like Map.put(my_map... are selected.

If I wanted to trigger a Dash query, having a default value and a single ZED variable would allow me, the user, to deliberately choose between selecting Map.put and sending it to Dash with a single keystroke, or selecting nothing and sending Map or put to Dash, depending on the cursor's position. In both scenarios, the custom code in the task, etc., would use only one variable. With two variables, the same logic would be more complex and different, if you see what I mean.

[notpeter]

Good morning @florinpatrascu. We definitely are likely to add additional task variables, but we want to make sure we get the behavior right as we will likely have to support those variables effectively forever.

With the selection expansion, the rules for what get included aren't immediately clear in all contexts. To take your example, I can imagine with a cursor inside the word put some people might want to search for Map.put while others would to do a global search for just put. Similarly how wide should the expansion occur, should it only expand to [A-za-z0-9] (some languages have utf-8 identifiers), should it stop at - (in CSS and Lisp identifiers may have hyphens) or at periods: in a JSON { "user.name": "peter" } expanding to user.name also seems reasonable.

TBH, we are amazed about the excited the community is about the power of tasks, but we want to make sure we don't add features that we have to deprecate or change behavior later because we hadn't thought it through.

That said, I absolutely understand your use case, you want to be able to have a keybind that passes a selection argument and when there's a cursor (no selection) it includes something in the arguments. I think this is totally reasonable, but I'm hesitant to override the default behavior of ZED_SELECTED_TEXT because I imagine someone might want to make the argument optional when nothing is selected.

And prefer not to add a bunch of hard coded variables:

• ZED_SELECTED_TEXT_OR_SELECT_CURRENT_WORD
• ZED_SELECTED_TEXT_OR_SELECT_CURRENT_IDENTIFIER
• ZED_SELECTED_TEXT_OR_SELECT_CURRENT_LINE

I'll think on it a little, but I am very excited that you were able to integrate searching docs with dash and that this is driving the future designs to meet real user needs.