In my opinion this is quite niche. But if this can be added to many languages (e.g. python, rust, C, ...), it would make more sense.

Some languages have type annotation (TS and Python) and others have just type as a mandatory field (C, Rust). So maybe instead of calling it annotation, it can be called something else?

By the way, also note that you can make custom queries for yourself. Even if this doesn't get accepted you can still use it and do whatever you can imagine!

Yes, I repeat that the bar for adding new types of textobjects is quite high. You need to make a much better case for a new one, including

1. multiple(!) concrete(!) examples showing where and how this would be useful;
2. showing how this cannot be achieved with any existing textobject.

Remember that consistency across languages is a primary project goal here; we will not make special exceptions for "the best language eva", and especially not web frontend. Such additions belong to dedicated language plugins (as @kiyoon wrote, you can easily extend the bundled queries in your config or a plugin; this is by design).

Yes, I repeat that the bar for adding new types of textobjects is quite high. You need to make a much better case for a new one, including

1. multiple(!) concrete(!) examples showing where and how this would be useful;

2. showing how this cannot be achieved with any existing textobject.

Remember that consistency across languages is a primary project goal here; we will not make special exceptions for "the best language eva", and especially not web frontend. Such additions belong to dedicated language plugins (as @kiyoon wrote, you can easily extend the bundled queries in your config or a plugin; this is by design).

Languages that this would impact

Ok, so first, example for all languages (to show that this is useful in more than just typescript, and to consider the scope of a possible PR implementing all of them. I'd be happy to do it)
This was generated with chat gpt

Integer age: Integer = 30;

int age = 30;

string name = "John";

int count = 42;

int value = 100;

let isDone: boolean = false;

name :: String.t() = "Alice"

var isAvailable bool = true

age :: Int
age = 25

variable "count" {
  type = number
}

float lightIntensity = 1.0f;

int speed = 60;

let message: string = "Hello";

let isVisible: boolean = true;

x::Int = 42

val age: Int = 28

local age: number = 30

let pi: float = 3.14

pi: f64 = 3.1415;

my int $age = 25;

$price: float = 19.99;

age: int = 25

age: numeric = 30

age: Integer = 30

let temperature: f64 = 36.6;

val name: String = "John"

$primary-color: Color = #333;

var isActive: Bool = true

variable "replicas" {
  type = number
}

const isOnline: boolean = true;

const value: string = "hello";

mut count: int = 10

logic [7:0] data = 8'b10101010;

let g:age: number = 25

var<private> color: vec4<f32> = vec4<f32>(1.0, 0.0, 0.0, 1.0);

port: !!int 8080

const value: i32 = 42;

Why is this useful?

Changing the type of an assignment is an incredibly common task, at least for me. This isn't possible with any of the current text objects.

I had considered some alternatives, e.g. something like this:

• Creating a keybind that will go at the end of the previous or next LHS assignment
• Then it will move 1 word to place the cursor where the "type annotation" is (since they're mandatory in some languages)

But this will be awkward e.g. if the type annotation has spaces, wraps over several lines, etc.

I know I could make queries myself, but if I can get a PR for this then it'll improve the experience of, I imagine a lot of people (I'd assume its likely lots more than if @regex.inner or @regex.outer was added)

It'd be great to be able to just instantly remove a type assignment e.g. with daa or change its value with cia (assuming it was mapped to da for .outer and ia for .inner

Name

I don't have a strong opinion on the name, I had considered @type prefix but that can be confusing. Or @declaration is another alternative

Without prejudicating any decision on whether this should be added: the name must follow the corresponding highlight capture.

Without prejudicating any decision on whether this should be added: the name must follow the corresponding highlight capture.

Ok, so here's some information then

In C its type: (_)
In typescript its type: (type_annotation (_))

So how about the name @type ?

Alternative suggestion: @type that will capture just any type, not necesserily a type_annotation or equivalents in other languages

Since this will be even more useful and will extend to various contextx e.g. assertions or predicates

In C its type: ()
In typescript its type: (type_annotation ())

The capture, not the node name. (The latter are very language-dependent, the former not -- that is the point.)

In C its type: ()
In typescript its type: (type_annotation ())

The capture, not the node name. (The latter are very language-dependent, the former not -- that is the point.)

In that case I think @annotation is the most fitting. In languages where they are not required, they are still referred to and recognised. "annotation" does not seem to imply the word "optional"

Research:

Rust: https://users.rust-lang.org/t/is-there-a-semantic-difference-between-type-annotation-and-ascription/70259

C: https://stackoverflow.com/questions/19345630/c-style-type-annotations-vs-others