smarter or more granular auto closing of certain characters

[jcompagner]

in the preferences we have:

Which is quite broad, you can't say for " I want to auto close but not for {.
It's all or nothing.
Also it is called "enabling auto close brackets" but its not always a bracket right?

But I would like that it would be a bit more smarter, because in the Typescript editor I really just want to turn it all off.
But in the Java editor I am not so bothered by that, it seems they know a bit better when or when not to do it.

As an example:

if (true) statement;

If i now want to make this:

if (true) { statement; }

In Java it is easy, I can do { and it won't insert a } right away and I can move to the end and place a } myself.
But in the typescript editor it right away inserts {} so I have to delete it again myself.

Same for example for strings.
In Java if you just type " and there is nothing else around it it will make "" and that's fine.
But if I type it just just in front of another char so I have:

a

and I place the cursor just before the a and type " I get:

"a

not a double ""a that I get in ts editor.

Those are the things that make the auto close a bit smarter so it's not annoying that you just want to turn it off.

[sebthom]

@mickaelistria @angelozerr do you think it makes sense we change it so brackets are only automatically closed if inserted at the end of a line of line? I don't think we have enough context info to intelligently (partially) enclose any trailing text anyways.

[mickaelistria]

Also it is called "enabling auto close brackets" but its not always a bracket right?

Should be just "Enable auto closing". A PR to fix the label would be welcome.

But in the Java editor I am not so bothered by that, it seems they know a bit better when or when not to do it.

It knows much better when to do it or not. As it has access to an AST, it can evaluate the impact of auto-insert vs not auto-insert in AST, with something like if (doesAutoInsertDetachNextTokenFromItsParentAndThusProbablyBreaksAST) simpleInsert(); else autoInsert();. I don't think we have this here.

do you think it makes sense we change it so brackets are only automatically closed if inserted at the end of a line of line? I don't think we have enough context info to intelligently (partially) enclose any trailing text anyways.

Even that is both a bit weak and error-prone IMO, I don't think it's noticeably better than the current state. But so far I also don't have any idea of what would be a better strategy.

[sebthom]

Also it is called "enabling auto close brackets" but its not always a bracket right?

Should be just "Enable auto closing". A PR to fix the label would be welcome.

I changed the checkbox text accordingly.

[sebthom]

do you think it makes sense we change it so brackets are only automatically closed if inserted at the end of a line of line? I don't think we have enough context info to intelligently (partially) enclose any trailing text anyways.

Even that is both a bit weak and error-prone IMO, I don't think it's noticeably better than the current state. But so far I also don't have any idea of what would be a better strategy.

I just tried it in vscode. There auto closing seems to only happen if the char was entered at the end of a line or if followed by a whitespace. I think we could/should do the same.

[mickaelistria]

I think we could/should do the same.

OK.

[sebthom]

@jcompagner could you please try the latest TM4E 0.6.0 release and check if this resolves your issue?

[jcompagner]

how do i install 0.6? i don't see 0.6 yet on this: http://download.eclipse.org/tm4e/snapshots/
the latest i find there is 0.5.0.20220624

[jcompagner]

ah if i install that then it gives me some 0.6 stuff (ui and registry management) so is it in there?

[sebthom]

Yeah, I also don't find it optimal that the different plugins deviating version numbers. Currently we anyway end up bumping versions of all plugins, so it could also be the same for all of them for easier troubleshooting.

[jcompagner]

i have the same thing with WWD.. also there it reports version https://github.com/eclipse/wildwebdeveloper/releases 013.5 but what i see in the ui what is installed is 0.11.xx

that is always confusing to me, the thing is plugins can have different versions. But the main plugin or the feature (so the thing you really see for example in the install/update panel) that should always be the version that is also promoted on github and what the release version is..
But thats just how i see it..

[mickaelistria]

But the main plugin or the feature (so the thing you really see for example in the install/update panel)

Sometimes, often, there are multiple such main things and a release only affect one of them; and next time the other. It's exactly what has happened to numerous projects.

[jcompagner]

i get that it is sometimes difficult but the main things like TM4E (i was told install 0.6)
i get this:

or WWD now has 0.13.5 according to github (and i think that release is also mentioned somewhere else
but

thats all just confusing in my eyes, the thing the users sees as the "end" thing, the thing they install should somehow be able to relate.
If now somebody wants to report a case an wwd, then he would for sure report it on version 0.11...

[sebthom]

But the main plugin or the feature (so the thing you really see for example in the install/update panel)

Sometimes, often, there are multiple such main things and a release only affect one of them; and next time the other. It's exactly what has happened to numerous projects.

that might in theory the case but currently when I change one file I am forced to bump the versions of unrelated plugins otherwise the build fails with the notorious "compare-version-with-baseline. For example I tried to update the Jenkins file and had to bump the versions of all plugins despite not touching any.

Anyways this topic is off-topic in this issue.

[mickaelistria]

that might in theory the case but currently when I change one file I am forced to bump the versions of unrelated plugins otherwise the build fails with the notorious "compare-version-with-baseline.

I would argue that this is either wrong, or this is a bug. This practice has been working without such issue for Eclipse Platform for the last 3 years/12 releases and dozen of Git repos and hundreds of bundles; so I'm skeptical this is causing such trouble for TM4E. The only thing that might require touching after you modified a bundle are the features that does include it. Other bundles don't need this. However it can also happen that using a newer version of some tool in the build chain (JDT, or Tycho, or ECJ, or signing service, or...) does change the artifact and require this version bump.

[sebthom]

@jcompagner is this issue still present?

[jcompagner]

i think its currently way better, quickly testing it seems to be that it doesn't insert when i don't want to.

I think its better, because i didn't notice it that much anymore.. so i kind of forgot about it.

[sebthom]

Thanks for reporting back! I am going to close then.