feat: aflpp parser fuzzer

Description
Problem*
Resolves
Summary*
Basic parser fuzzer with example output and tests auto-generated from crash files:
    fuzz!(|data: &[u8]| {
        if let Ok(s) = std::str::from_utf8(data) {
            let _ = noirc_frontend::parser::parse_program(&s);
        }
    });

And then for each crash file found:
#[test]
fn name_here() {
    let program_str = std::fs::read_to_string("{crash_path}").unwrap();
    let _ = parse_program(&program_str);
}

Additional Context
Documentation*
Check one:

[x] No documentation needed.
[ ] Documentation included in this PR.
[ ] [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

[ ] I have tested the changes locally.
[ ] I have formatted the changes with Prettier and/or cargo fmt on default settings.

What's the status of this PR?

@TomAFrench this is paused for progress on https://github.com/noir-lang/noir/pull/4744

it's working as intended and plan to extend after pure CLI
can refresh to re-run or else to merge and keep it more stable if it's getting too stale

Replaced by https://github.com/noir-lang/noir/pull/5591


Implement MySQL service broker for Kubernetes

From @shudipta on July 3, 2018 12:13

https://medium.com/bitnami-perspectives/service-catalog-in-kubernetes-78c0736e3910
https://github.com/prydonius/mariadb-broker
https://github.com/pmorie/osb-starter-pack
https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md
---------------------- 0 ---------------------------

implementation:

https://github.com/kubernetes-incubator/service-catalog/blob/dedfea55ffac10d4fe763fc5377c42edc04d7958/contrib/pkg/broker/user_provided/controller/controller.go
https://github.com/prydonius/mariadb-broker
https://github.com/pmorie/osb-starter-pack
https://github.com/osbkit/minibroker
-------------------------- 0 --------------------------

tests:

https://github.com/kubernetes-incubator/service-catalog/tree/master/test

Copied from original issue: kubedb/service-broker#1

Done.


full_stack_example for 6.0.0 ?

full_stack_example is a great thing for developing and testing. Thanks a lot.
But with 6.0.0 there are several changes: default userid/pw for elasticsearch, setup of templates, indexes, ...
Do you plan an upgrade for 6.0.0 ?

Yes we plan to update all examples. We are slowly working through them. We will also add Logstash and several other systems to the full stack example in due course.

Thanks for the Watcher History Dashboard. For 6, this is something that I came across, in case it helps: In the "Most Frequent Watches Executing Actions" visualization, the search now has to be "result.condition.met: true", not "result.condition.met: 1"

Any updates on this as it's been nearly 5 months?


Use pre-process step instead?

Rather than forking text/template, why not pre-process the template to strip offending newlines?
Something like: http://play.golang.org/p/1hixWanQAV
(or use text/template/parse if you really want to be sure)

Because pre-processing basically requires writing a complete parser to ensure correctness. eg. in your example, a literal }}\ anywhere in the template will be stripped, even if it is not part of a template expression.
As for using text/template/parse, this was the first thing I looked at, but (as the name implies) it produces a parse tree. If the lexer were exposed it would be relatively trivial to transform the lexed tokens, but the parse tree is much more difficult to process. It was far simpler to just fork it and patch.


Fix #845 -- Rename test functions

Fixes https://github.com/jazzband/django-axes/issues/845

Thanks for the fix @hramezani :)


ALDS Gen2 Rename Secions in Path Properties Dialog

Sercan said to just leave names for now. Closing.


Feature/Relationship decomposition

To not wait for the backbone to complete the pseudonymization any longer, I'm asking for a review now  since this only affects the messages. The tests for the messages are skipped.

Why do you scattered the name BackboneRelationshipStatus all over the codebase? I think the wording is not good.

After decomposing on the backbone you have to handle messages yourself, the backbone will not send external events.

I didn't like the backbone status DeletionProposed as runtime status name, so I changed it there into DecomposedByPeer

I don't get this explanation. We shouldn't just change how things are named.

Please move the refactoring (rename from RelationshipStatus to BackboneRelationship) out of this PR. It is to much noise.

@stnmtz as this now heavily changes the behaviour of messages I'd be happy about a review.


revamp public map [DO NOT MERGE]

first commit, familiarizing myself with the code and so, just made the changes in the header for now

created a dashboard_header, do we want to change them only in the public pages or in the dashboard , too? Inevitably the styles will change

then, already in the public_header

left the links with a bit of opacity to keep the hover states, didn't found them in the mockups, is it white with underline, do I leave them like this?

do we lose "Learn" in favour of "Industries" + "Pricing" ?

I suppose the link "Login" was left with no update, applied the same style please confirm you want it different

had to modify .UserAvatar-img in order to the signup button to be aligned. Avatar is 42px with that transparent border (what is it for?), button is 44px :/

despite we already have a size variable for 40px I created a new one for the items separation, modifying $sMargin-element wasn't feasible, so many side changes.

finally, I created .Header-navigationItem as we have .Header-settingsItem, actually, don't you think we should consolidate them both in a single class? the same with .Header-navigationLink

will go on with this, but as I first dove here I prefer to check these before going any further ^^^
/cc @CartoDB/frontend

Frontend tests were OK :+1: (details)

ping @viddo @javierarce (as you are the most concerned with styleguide and @xavijam specifically asked me to ping other people in this case)

I answer the questions I feel I can answer, but in general :ok:

created a dashboard_header, do we want to change them only in the public pages or in the dashboard , too? Inevitably the styles will change
left the links with a bit of opacity to keep the hover states, didn't found them in the mockups, is it white with underline, do I leave them like this?
do we lose "Learn" in favour of "Industries" + "Pricing" ?
I suppose the link "Login" was left with no update, applied the same style please confirm you want it different

I feel these questions are better suited for @CartoDB/design, it depends more on you ppl.

had to modify .UserAvatar-img in order to the signup button to be aligned. Avatar is 42px with that transparent border (what is it for?), button is 44px :/

Seems like the file history got b0rked with the common/old_common submodule move so can't verify, but I have some vague memory that it was due to some modifier rules had border set too, so this was added to maintain the same size.
Anyhow, I feel we have a general problem with this kind of issue. Is there some argument for not applying a consistent box-sizing, like suggested by in his article on css-tricks, to avoid issues with borders/padidng affecting final element size? cc @xavijam ?

finally, I created .Header-navigationItem as we have .Header-settingsItem, actually, don't you think we should consolidate them both in a single class? the same with .Header-navigationLink

I'm all for consolidating, we have not been very good at this but we should do it more I think.

:ok_hand: for me

About the box-sizing, if we want to set that for everything, perfect, but first we have the problem of the old CSS and we need to get rid of it first IMHO. This is one of the problems with "new" and "old" code.

ooh, I see, not changing that border, then

left the links with a bit of opacity to keep the hover states, didn't found them in the mockups, is it white with underline, do I leave them like this?

the links in #FFF and :hover with .7 opacity

do we lose "Learn" in favour of "Industries" + "Pricing" ?

We should have the same links than comercial site

I suppose the link "Login" was left with no update, applied the same style please confirm you want it different

link color #FFF
border color #FFF with .3 opacity and 2px width

had to modify .UserAvatar-img in order to the signup button to be aligned. Avatar is 42px with that transparent border (what is it for?), button is 44px :/
I unified all those sizes in a new mockup,

Avatar 36px
Button 36px

Take a look to my proposal:

Frontend tests were OK :+1: (details)

made most of the work with the header, going on with the rest of the page
I left ready in shared/dashboard_header the new dashboard header, but as I think it's not ready yet from the proposals (for example Org. cases, see attached) I'll focus on public pages only by now

There's the notifications icon in the proposal but despite I managed to add the view I'll borrow some @vikingo time to ask him how to do this properly (we'll have to populate user model and LocalStorage)

Thanks Matallo!
I think this new nav is much more convenient, without no reference to the org, in the actual nav it's like a reminder with no functionality. I prefer to make the navigation to datasets and maps more accesible.

cool, then I'd include a reference to the org in the public page dropdown, as it's in the dashboard dropdown
what do you think @CartoDB/design?
dashboard

public page

Are the links on the right the good ones?
On Jul 16, 2015 10:53 AM, "Carlos Matallín"<EMAIL_ADDRESS>wrote:

cool, then I'd include a reference to the org in the public page dropdown,
as it's in the dashboard dropdown
what do you think @CartoDB/design
https://github.com/orgs/CartoDB/teams/design?
dashboard
[image: screen shot 2015-07-16 at 10 50 46]
https://cloud.githubusercontent.com/assets/36676/8718989/b84e762c-2ba8-11e5-99cd-950967ea45c1.png
public page
[image: screen shot 2015-07-16 at 10 51 00]
https://cloud.githubusercontent.com/assets/36676/8718990/b857c0ec-2ba8-11e5-8a91-88a4c3737197.png
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb/pull/4333#issuecomment-121883473.

maps and datasets? confirmed with @carlostallon

@matallo yep, I think is enough ; )

I meant on the left,sorry
On Jul 16, 2015 10:58 AM, "Carlos Matallín"<EMAIL_ADDRESS>wrote:

maps and datasets? confirmed with @carlostallon
https://github.com/carlostallon
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb/pull/4333#issuecomment-121886475.

bump @carlostallon

I created a branch just for the header that could be reviewed and merged now
--
some of the things I've encountered (and as I know @viddo had some concerns) while I'm doing this

better keep short class names
.NotSupportedDialog-itemLink => .NotSupportedDialog-link

remove specificity when possible
.PublicMap-map .Spinner => .Spinner--center

Aim for generic components
when creating the breadcrumb at first I went with .PublicMap-breadcrumb then made it .Breadcrumb then realized a similar component that wasn't really a breadcrumb, so again moved to .Navmenu

so summing up, I could have ended with something like .PublicMap-breadcrumbItemLink but settled on .Navmenu-link which would be reusable (thinking of dashboard) and is less verbose
I think I already asked this, but why is better rgba(#aaa, 1) than #aaa?
we are writing empty stylesheets for non-rendering CSS, worth investigating/improving?
write public/assets/3.15.09/stylesheets/variables/colors.css (0.005s)

I think I already asked this, but why is better rgba(#aaa, 1) than #aaa?

AFAIK we might as well use #aaa in those cases, I think it only makes sense to use that when the opacity value is something else than 1


Switch to using env_logger

Following Aya, switch bpfd to use env_logger in place of simplelog. By
default, logs are printed at error level instead info. This can be
overwritten using the RUST_LOG environment variable.
sudo RUST_LOG=info ./target/debug/bpfd
Resolves: #88
Signed-off-by: Billy McFall<EMAIL_ADDRESS>

As mentioned above, this changes the default log level from info to error. We can back to info by changing the init() to something like:
env_logger::Builder::new().filter_level(log::LevelFilter::Info).init();

But since the default seems to be to run bpfd in the background, may be best to limit the number of logs dumped. There are other issues around logging to systemd journal (#89) that may make it more useful to go back to a default of info in the future.

Thanks @Billy99!


Add app name env variable

Current dependencies on/for this PR:

main

PR #6   👈

This comment was auto-generated by Graphite.


fix(#1591): Add padding to accordion heading

1. What this code change do:
This PR is a proposed fix for https://github.com/GovAlta/ui-components/issues/1591. It adds padding to the according heading and aligns the icon to the top. It allows the heading to accommodate multi-line heading & secondary text.

Testing in latest Microsoft Edge
Small with one line heading:

Small with multi-line heading:

Small with one line heading and secondary text:

Small with multi-line heading and secondary text:

Small with multi-line heading and multi-line secondary text:

Medium with single line heading:

Medium with multi-line heading:

Testing in latest Google Chrome
Small with single line heading

Small with multi-line heading

Medium single line heading

Medium with multi-line heading

Testing in latest Apple Safari
Small with single line heading

Small with multi-line heading

Medium single line heading

Medium with multi-line heading

Testing in latest Mozilla Firefox
Small with single line heading

Small with multi-line heading

Medium with single line heading

Medium with multi-line heading

2. Make sure that you've checked the boxes below before you submit MR:

[x] I have read and followed the contribution guidelines

[x] I have run a build locally.

[x] I have ran unit tests locally.

[x] I have tested the functionality.

Reviewer Checklist

[x] Appropriate unit test coverage.
[x] Coding Standards followed.

When review is satisfactory reviewer will merge the changes.

I squashed my commits and updated the message to fix(#1591): Add padding to accordion heading.

:tada: This PR is included in version 1.17.0-alpha.34 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.17.0-alpha.21 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.20.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.20.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-alpha.4 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can't extract hindi news

i provide hindi url in goose library it's return always empty text why it's doesn't support indian language please fix this issues

Can you provide an example URL?
It most likely one of a few things, such as:

non-standard article body class or tag
missing stopwords

Without an example, it will be hard to determine what the underlying issue is

example url :
https://www.indiatv.in/india/national/ayodhya-ram-mandir-pran-pratishtha-ceremony-bhagwan-ram-ram-idol-has-been-kept-in-the-garbha-griha-of-temple-2024-01-18-1016965
barrust sir , please provide support for indian news (for native languages like hindi(hi),tamil(ta),telugu(te),urdu(ur),.....etc)

https://github.com/codelucas/newspaper/blob/master/newspaper/resources/text/stopwords-hi.txt
barrust sir , it's already exist's in newspaper3k library

https://khabaruttarakhand.com/kuldeep-martolia-appointed-to-the-post-of-ieec-officer/
barrust sir , this site is not working after you updated stopwords (hindi) why ??? please update it sir

Did you try pulling the pull request and the page still didn't work?

Using the PR like so works:
from goose3 import Goose

with Goose() as g:
    g.config.use_meta_language = False
    g.config.target_language = "hi"
    art = g.extract(url="https://khabaruttarakhand.com/kuldeep-martolia-appointed-to-the-post-of-ieec-officer/")
    print(art.cleaned_text)
    print(art.meta_lang)

When not overriding the language it doesn't pull anything since the website states that it is in English in the HTML.:

<meta property="og:locale" content="en_US">
tml lang="en-US" prefix="og: https://ogp.me/ns#">

if sites don't help by correctly stating the language codes, then it is up to the user to tell goose what language to use. I don't see this as a fault of the library and will continue merging the PR.

Thanks sir for update and quick resolution for that issue


Minimize bundle size

Tried to follow the konva readme advice to reduce the bundle size for people who only need to use a few shapes by importing the specific pieces used in each component.

Nice! Thank you very much


[Fix] roboError can be null

Closes #155

@afharo You are the man!
You're doing a really great job here. I would be happy if you continued to manage this plugin. Make changes, edit issues and merge pull reqeuests. I'm out. I sign me out of all notifications for this plugin. You are also registered as a collaborator with miio and also with both NPM packages.
Good luck und thanks.

Thank you @nicoh88 !
I'm sad you are leaving the front line. But I understand! It can be really time consuming.
Before you fully unsubscribe, can you make sure I have the rights to run npm publish?
Also, I cannot see the settings tab in this project. I may need it if I want to set any automated actions (hopefully we'll have some unit tests and build process in the future) :)

I've added you (or a wrong person 🤣). I don't know what I have to do.

Oh! Cool! Sorry I didn't even check. I assume just because I didn't receive an email from NPM, it was not done.
I just logged in the NPM site and I can see those packages in "My Packages" list.
Thank you kindly!


setFAIcon on UITextField

I’d like to use FontAwesome in my textfield but there’s no mention of UITextField in the README. Is it supported?

update pod to 1.6.1 and it's working


[SPARK-1061] assumePartitioned

https://issues.apache.org/jira/browse/SPARK-1061
If you partition an RDD, save to hdfs, then reload it in a separate SparkContext, you've lost the info that the RDD was partitioned.  This prevents you from getting the savings of a narrow dependency you could get.  This is especially painful if you've got some big dataset on hdfs, and you periodically get small updates that need to be joined against it.
assumePartitionedBy lets you simply assign a partitioner to an RDD, so you can get your narrow dependencies back.  Its up to the application to know what the partitioner should be, but it will at least verify the assignment is OK.

Test build #26991 has started for   PR 4449 at commit e041155.

This patch merges cleanly.

Test build #26991 has finished for   PR 4449 at commit e041155.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/26991/
Test FAILed.

Test build #26992 has started for   PR 4449 at commit 943984f.

This patch merges cleanly.

Test build #26992 has finished for   PR 4449 at commit 943984f.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/26992/
Test FAILed.

Test build #27014 has started for   PR 4449 at commit 0e98abe.

This patch merges cleanly.

Test build #27014 has finished for   PR 4449 at commit 0e98abe.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27014/
Test FAILed.

Test build #27016 has started for   PR 4449 at commit b828f01.

This patch merges cleanly.

Test build #27016 has finished for   PR 4449 at commit b828f01.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27016/
Test FAILed.

Test build #27021 has started for   PR 4449 at commit ed154ce.

This patch merges cleanly.

Test build #27021 has finished for   PR 4449 at commit ed154ce.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27021/
Test FAILed.

Jenkins, retest this please.

(This failure was due to me changing a Jenkins settings; I've reverted the change)

Test build #27022 has started for   PR 4449 at commit ed154ce.

This patch merges cleanly.

Test build #27022 has finished for   PR 4449 at commit ed154ce.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27022/
Test FAILed.

Test build #27023 has started for   PR 4449 at commit ea016db.

This patch merges cleanly.

Test build #27026 has started for   PR 4449 at commit f6c13a1.

This patch merges cleanly.

Test build #27023 has finished for   PR 4449 at commit ea016db.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27023/
Test PASSed.

Test build #27026 has finished for   PR 4449 at commit f6c13a1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27026/
Test PASSed.

This seems like a slightly awkward API to expose since to use it you need to basically write a customized InputFormat. If someone is writing customized InputFormat's, then why can't the just write a custom RDD as well. Is the idea that someone would write an input format that only returns a single split for each file?

@pwendell its a good question, I was wondering the same thing a little bit as I was writing those unit tests and was going to comment on the jira about this a little.  It is definitely annoying to have to write a custom input format -- but I only need to do that to turn off splits.  Every once in a while this comes up on the user list too -- should we just add another version of sc.hadoopFile, sc.textFile, and sc.sequenceFile to turn off splits?  Unfortunately I don't think it makes any sense to directly pass an assumedPartitioner as an argument to those functions, since you really need to put in a map step in the middle to extract the key.
Really this gets to a more general question: when do we add these "convenience" methods to RDD??  Given that this requires application logic to track the partitioner to use, I doubt this will ever be used by other code within spark itself.  But I would still make the case for its inclusion, since (a) it leads to a big optimization that is not obvious to most users.  By promoting it to a function within spark itself, users are more likely to be aware of it.  (b) its a little tricky to get right -- I think the verify step is really important to make sure this doesn't lead to completely wrong results in the user app.  And (c) I think its a common use case.  Not so common it would make it into spark tutorial's, or even into daily use of an experienced spark-user -- but I imagine it has a place in every "batch" use of spark, where there is some big dataset that lives on hdfs between spark contexts.
OTOH, we could just put this in some general location with spark-examples, and leave it out of spark itself.  I guess we only need to make the change to HadoopRDD to sort the partitions.

ping
If I haven't made a convincing argument this is a useful addition to the core api, than I'll change the PR to only add the sorting to HadoopRDD's partitions, as that is the only change to what is already there, and I can move this to an external package

@squito Imran, any progress on this issue? We have same problem with narrowing dependencies(exactly the case you are describing with big dataset that lives on disk with small additions to it using join in different spark context eash time)
Do you have some examples? Maybe some blog post ;)?

@rapen sorry no updates ... I think this is more or less ready, but seems there isn't much interest in getting this in core, unfortunately.  It would be nice to put this elsewhere into a standalone package for Spark.  I don't have time to do that at the moment -- feel free to take a stab at if you like.
You can also just use what's here in your project.  The only problem is you need to make a copy of HadoopRdd so you can make the modifications here (in particular, to get consistent ordering of the partitions)

@squito thanks! your work is very helpful. I'm testing now solution based on your code. I've subclassed NewHadoopRDD with same changes you've made in HaddopRDD and then created new method that creates this custom rdd(kind of copy-paste from newHadoopApi from SparkContext) + defined NonSplittable InputFormat(subclassed from avro formats). Thus I don't need to change HadoopRDD and recompile spark with it...it's just sort of extension(might be this what can be part of standalone library...I'm not pro in scala programming, so not sure to show this code to someone :)
Anyway, all shuffles disappeared ! :+1:

Hi,
Is there a chance someone could share some code that could shed some light on how to use this feature?
Thank you.
Daniel

@danielhaviv , see tests in PR

i would like to have something like this in core
On Fri, Sep 4, 2015 at 6:22 AM, rapen<EMAIL_ADDRESS>wrote:

@danielhaviv https://github.com/danielhaviv , see tests in PR
—
Reply to this email directly or view it on GitHub
https://github.com/apache/spark/pull/4449#issuecomment-137697278.

What's the final verdict on this? Can we do the standalone package approach for now, then close this out?


Add CORS

[x] Add cors
[x] Increase rate limit (2 req/s)

omited because of local tests... can be closed.


[TRACKER] More API renames for Godot 4.0

This is a follow-up to the mega tracker #16863 which we've used for the past 3 years to keep a list of things we'd like to rename in the API for Godot 4.0.
Many of these renames have been done, some are still pending with open PRs, others might actually not be wanted, as we didn't do thorough discussion of all proposals on that issue.
Now that we're getting closer to the 4.0 release, it's time to give this a second look, and start anew from the current API.
Are there more classes, methods, properties, or signals, which have an awkward name and could be improved before we freeze the API to preserve compatibility?
Here's my workflow proposal for this tracker:

Add your suggestions as comments below. Include links to relevant proposals or issues/comments if they exist (but you don't necessarily need to open a proposal for it, unless it's a very substantial change to the API).
Upvote the proposals you support, downvotes the ones you disagree with. Don't take downvotes personally, we need to assess the general feeling of the community for a given proposal to see if it makes sense to rename, beyond core maintainers' own intuition.
If you're motivated, you can also salvage unresolved suggestions from #16863 so they are considered again here (beware, there are 500 comments...).
Suggestions (not approved yet, so don't open PRs for them) will be listed by repo maintainers in the second comment of this issue.
Avoid lengthy discussions of suggestions in this tracker, as it makes it hard to keep track of things. Prefer discussion on the Contributor Chat, and if needed, open dedicated proposals for non-consensual suggestions that require more debate.
After review, approved suggestions will be moved to the task list below in this first comment, so they can be implemented by contributors and merged.

Important: This tracker is only for API renames. I.e. changing a name to another name, not changing behavior, adding/removing logic, etc. Anything that changes the behavior of the engine should be discussed in a proposal on https://github.com/godotengine/godot-proposals.
For this tracker, let's also exclude suggestions for changes in the Project Settings and Editor Settings. Those should probably have their own trackers, as the settings do need a cleanup for 4.0.

Approved renames
None yet.

search_in_file_extensions in Project Settings should be renamed to find_in_files_extensions, to be consistent with Script Editor naming.

It's a big one, but may I submit CanvasItem's update() -> request_redraw() or update_canvas() or something like that? Since CanvasItem is base for 2D nodes, we have node types way down the line which all share an update function which doesn't really communicate what it is that's being updated.

Should we rename the ignore stretch aspect mode to stretch (or perhaps distort)? This would make its effect more obvious.

@Calinou I think ignore is still the most accurate description of those options. (simply because stretch applies to all other aspect setting too, and distort is not always true. You can also get undistorted stretch when using ignore mode.)

I have posted this in the big issue and imho this should be fixed as its arguably beyond taste, you could consider it a bug:

The counterparts Camera::unproject_position() and Camera::project_position() do the exact opposite of what you would expect / what is commonly agreed upon. Camera::unproject_position() does a normal camera projection, i.e. it takes a 3D position and projects it onto the screen. Camera::project_position() does what people would call an unprojection, i.e. 2D->3D. (Technically everything is a projection, but we're not speaking correct mathematical terms here but graphics slang.)
If you're not convinced see https://www.google.com/search?q=camera+unproject or https://dondi.lmu.build/share/cg/unproject-explained.pdf to convince yourself that practically every other library uses the terms project and unproject in the opposite directions to what they are currently implemented in Godot.

A few more thoughts in the original comment.

VSeparator and HSeparator seem to be semantically flipped: I understand that VSeparator stretches visually up and down, but it separates things on the horizontal axis and serves as a child of a horizontal stack. I feel like the visual, in-editor dimensions of the VSeparator are less important for meaningful/consistent naming than the actual purpose it serves---that of being a horizontal separator. Same goes for HSeparator.

VSeparator and HSeparator seem to be semantically flipped: I understand that VSeparator stretches visually up and down, but it separates things on the horizontal axis and serves as a child of a horizontal stack. I feel like the visual, in-editor dimensions of the VSeparator are less important for meaningful/consistent naming than the actual purpose it serves---that of being a horizontal separator. Same goes for HSeparator.

Not gonna lie, the current naming makes more sense to me. It's a separator that's vertical. Very self-evident.

Ah, maybe it's just me, then.
Has thought been given to consolidating both into a single Separator class, possibly with a toggle for direction? I know the UI system's getting a pretty big upgrade coming up so it might be worth considering, but if there's good reason otherwise I don't want to open a whole proposal.

The counterparts Camera::unproject_position() and Camera::project_position() do the exact opposite of what you would expect / what is commonly agreed upon.

What about naming it in accordance with conversion methods elsewhere in the engine, as Camera::viewport_to_world/world_to_viewport or something similar? The current names made sense to me when I first learned them, as they gave me the sense of projecting through the screen into the world and vice-versa. The same's probably true for other people who aren't coming from a 3D graphics background. The inverses seem to be unanimously the correct versions, but maybe in the vein of Godot's clarity/obviousness-centered design it might be worth going for something less technical?

CAMERA_MATRIX rename to VIEW_TO_WORLD
INV_CAMERA_MATRIX rename to WORLD_TO_VIEW

I just realized that @clayjohn's sugggestions imply that the project/unproject weirdness is consistent with with the current namings/definitions of (INV_)CAMERA_MATRIX, which are apparently equally inverted compared to the convention. It doesn't take long to find people being confused about this, too. It also makes my rambling about the documentation being incorrect incorrect, as it clearly is all consistent throughout Godot, albeit the opposite of the convention everywhere else. I guess @clayjohn's proposal fixes this issue without confusing the community that has gotten used to this.
I would like to add that those references to these matrices in the documentation should also be changed at some point. I.e. where it currently says "the camera projection" in Camera::project_ray_normal()/Camera::project_ray_origin(), it should either be reworded to "the inverse camera projection" or there needs to be a wording found that avoids implying a canonical direction at all.

Array (some changes also apply to PackedArrays) #16863 (comment):

Rename remove to remove_at (remove by index) to avoid ambiguity: Rename remove() to remove_at() when removing by index #50139
Rename erase to remove_value (remove by value) to avoid ambiguity

A comment: With current names you should keep in mind the difference (and/or periodically read the docs to remember the difference).

See also https://github.com/godotengine/godot-proposals/issues/2885#issuecomment-864282198, https://github.com/godotengine/godot/pull/49701#issuecomment-863752431, it seems some people aren't keen on remove_value()

Also: Transform2/3D.interpolate_with -> Transform2/3D.lerp (and elsewhere if I've missed a lerp) in accordance with the other interpolation method names.

I have posted this in the big issue and imho this should be fixed as its arguably beyond taste, you could consider it a bug:

The counterparts Camera::unproject_position() and Camera::project_position() do the exact opposite of what you would expect / what is commonly agreed upon. Camera::unproject_position() does a normal camera projection, i.e. it takes a 3D position and projects it onto the screen. Camera::project_position() does what people would call an unprojection, i.e. 2D->3D. (Technically everything is a projection, but we're not speaking correct mathematical terms here but graphics slang.)
If you're not convinced see https://www.google.com/search?q=camera+unproject or https://dondi.lmu.build/share/cg/unproject-explained.pdf to convince yourself that practically every other library uses the terms project and unproject in the opposite directions to what they are currently implemented in Godot.

A few more thoughts in the original comment.

I was just about to file a bug report as I stumbled upon this. The naming is absolutely wrong, an unprojection is transfering from vector space Rn to Rn+1 .. hence 2D to 3D or 3D > 4D (homogeneous coordinates)

CAMERA_MATRIX rename to VIEW_TO_WORLD
INV_CAMERA_MATRIX rename to WORLD_TO_VIEW

I just realized that @clayjohn's sugggestions imply that the project/unproject weirdness is consistent with with the current namings/definitions of (INV_)CAMERA_MATRIX, which are apparently equally inverted compared to the convention. It doesn't take long to find people being confused about this, too. It also makes my rambling about the documentation being incorrect incorrect, as it clearly is all consistent throughout Godot, albeit the opposite of the convention everywhere else. I guess @clayjohn's proposal fixes this issue without confusing the community that has gotten used to this.
I would like to add that those references to these matrices in the documentation should also be changed at some point. I.e. where it currently says "the camera projection" in Camera::project_ray_normal()/Camera::project_ray_origin(), it should either be reworded to "the inverse camera projection" or there needs to be a wording found that avoids implying a canonical direction at all. But that is not release critical, I guess.

Thanks for pointing this out. Honestly, I got really frustrated with many of the camera related concepts going against the common convention in computer graphics. I kept running circles for exposing the projection matrix but the argument was it is too complicated and thus Godot is stuck with the heavy parameterization of the intrinsic camera parameters. I would have hoped that 4.0 is a chance to change this. Maybe I'm wrong.

Theme font colors have different verb tenses. The font colors for the Button Node are font_color font_color_disabled font_color_focus font_color_hover font_color_pressed
So either
font_color_focus -> font_color_focused and font_color_hover -> font_color_hovered
or
font_color_disabled -> font_color_disable and font_color_pressed -> font_color_press
The first makes more sense because it expresses an action that is currently happening that changes the font color.

In the previous tracker https://github.com/godotengine/godot/issues/16863#issuecomment-595585595 brought up combining Camera2D's limits into one property and, for being a proposal that goes beyond renaming, here's a matching proposal
https://github.com/godotengine/godot-proposals/issues/3604

Rename "physical_key" In the Input and Input Map class to "QWERTY_key".
 Both AZERTY and QWERTY keyboards can be "physical". The opposite of physical is virtual. But input method has nothing to do with the difference between physical and virtual keyboards. It only has to do with the keyboard layout, and with QWERTY in particular.
When the user reads "QWERTY" it is very likely they understand this is related to a specific keyboard layout. "physical" does not do that. This has nothing to do with the keyboard being physical.

Rename "physical_key" In the Input and Input Map class to "QWERTY_key".

The issue is that there is no single "QWERTY" layout out there. You're probably referring to the US  QWERTY layout implicitl. However, there are plenty of derivatives that still use QWERTY, but with different secondary key placements that will impact physical key location. Such examples would be Spanish QWERTY and French Canadian QWERTY.

@Calinou:
I don't understand why this would be an issue. This is just about the name of the method. This thread is not about behaviour.

@Mickeon can you help me understand where you see the benefit of calling it "physical"? All hardware keyboards are physical, regardless what layout they use. What keyboard layout you use has nothing to do with it being physical or not.

It's not that I do not see the benefit of calling it "physical", it's that I do not find replacing every instance of "physical key" with "QWERTY key" or "qwerty key" beneficial. I wanted to simply express distaste. It just doesn't sound right.

Don't take downvotes personally, we need to assess the general feeling of the community for a given proposal to see if it makes sense to rename, beyond core maintainers' own intuition.

@golddotasksquestions It's not that I do not see the benefit of calling it "physical", it's that I do not find replacing every instance of "physical key" with "QWERTY key" or "qwerty key" beneficial. I wanted to simply express distaste. It just doesn't sound right.

Don't take downvotes personally, we need to assess the general feeling of the community for a given proposal to see if it makes sense to rename, beyond core maintainers' own intuition.

Like all of these renames we are discussing here, the benefit is not for current users who already know the methods and names and what they do, but for new uses who come new to Godot and GDScript and need to learn everything. For current users renaming things will always be additional effort, but should make life and work for future use and newcomers much more intuitive and easier to learn.
The word "physical" has nothing to do with what this function does. There is no connection to anything physical, or it's opposite "virtual". There is connection to QWERTY however, since this function uses the QUERTY layout rather than the native one. Using this method is like going into your OS keyboard settings and changing your AZERTY layout to QWERTY (what physical keyboard you have is totally irrelevant in any of this).

Looking back at it, I feel like some Camera2D properties are in need to be renamed.
Particularly, rotating could be rotate_view, since it's what it is. The Camera2D node itself is able to rotate even when it is disabled, it just doesn't display.

Furthermore, Camera2D drag_margin_h_enabled and drag_margin_v_enabled could be called drag_margin_horizontal and drag_margin_vertical. However, the reason behind not doing this is understandable. There would be no hint at them being booleans.

We should remove Scale On Expand (Compat) stretch option in TextureRect. It behaves like Keep when expand is off and Scale when it's on. As name suggests, it was kept that way for compatibility, so now we can break.

Signals:
Tree:
item_activated()->item_double_clicked()
item_double_clicked()->item_icon_double_clicked()

Regarding the in-consistency of Mesh.surface_set_material and MeshInstance.set_surface_material:
It looks like on master this is now Mesh.surface_set_material and MeshInstance.set_surface_override_material. Personally I find this pair still a bit awkward, due to the shuffling of "set".
I assume the main reason to keep the name for Mesh was this comment. Wouldn't that reasoning imply that it should be MeshInstance.surface_set_matrial_override as well? CC @madmiraal @clayjohn

MeshInstance.set_surface_override_material(Material) applies to the MeshInstance and overrides all surfaces not a particular surface.
Mesh.surface_set_material(surf_idx, Material) applies to a specific surface and not to the Mesh. Note the additional surf_idx parameter. If it helps to understand the logic, try reading it as Mesh_surface.set_material().

Suggested renames for CanvasItem:

draw_polygon() -> draw_polygon_colors() (it draws a polygon with multiple colors).
draw_colored_polygon() → draw_polygon() (it draws a polygon with a single color).

MeshInstance.set_surface_override_material(Material) applies to the MeshInstance and overrides all surfaces not a particular surface.

From what I can see on master, MeshInstance is per-surface as well, right?
https://github.com/godotengine/godot/blob/0e261523926e776bc0b1b85178a60fa476490a9c/scene/3d/mesh_instance_3d.cpp#L340
After having a second glance, the placement of "set" in surface_set_material and set_surface_override_material still feels somehow inconsistent to me.

OS.get_data_dir -> OS.get_user_home
OS.get_user_data_dir -> OS.get_project_data_path
Not sure if these should end with dir, directory, or path.

local_to_scene in Resource could be renamed to local_to_instance, to be more precise.

It seems like Documentation favours bytes over raw, as in PoolByteArray. Strange, but small inconsistency.
Variant.TYPE_RAW_ARRAY -> Variant.TYPE_BYTE_ARRAY

It seems like Documentation favours bytes over raw, as in PoolByteArray. Strange, but small inconsistency.

The inconsistency comes from PoolByteArray (now PackedByteArray) being called RawArray in Godot 2.x. We can surely change this in 4.0 now :slightly_smiling_face:

I'm not very caught on the progress of Godot 4, and it's possible that a different implementation may have rendered this method useless, as I can't find it even exists in the latest build, but:
@GDScript.typeof() ->@GDScript.type_of()

I'm not very caught on the progress of Godot 4, and it's possible that a different implementation may have rendered this method useless, as I can't find it even exists in the latest build, but:
@GDScript.typeof() ->@GDScript.type_of()

I think the reason it is named this way is similarity to the keyword sizeof in C++. Maybe this should be removed in favor of Object.get_class()?

Maybe this should be removed in favor of Object.get_class()?

typeof works for any Variant and for classes it returns VARIANT_OBJECT (probably). They are different methods.

ItemList has styleboxes named "cursor" and "cursor_unfocused". They are used in multi-select mode for the currently highlighted item. Maybe we could come up with a better name? Something like "highlight", idk. Also it should be "focused" not "unfocused", because it's inconsistent with other styles.

I want to do a pass on all theme properties before the beta, because consistency in their naming is very very poor.

There's are two old issues about renaming particle properties: https://github.com/godotengine/godot/issues/24468 and https://github.com/godotengine/godot-docs/issues/2359
Should we go forward with any of those renames? (Note that Fract Delta will likely be removed in 4.0.)

What about virtual methods of EditorPlugin? Virtual methods in Node starts with a _ (like _ready) but in EditorPlugin virtual methods doesn't has that prefix (like edit). Is that suggestion related to this issue?

They were already renamed to begin with _.

Node.print_stray_nodes() -> Node.print_orphan_nodes()
Seems like "orphan" is used everywhere else across the engine, and this inconsistency might be confusing.

@expose instead of @export as a keyword to expose variables to the inspector.
I think there's a couple of downsides in terms of ambiguity to the export keyword.
since there's also the export in terms of exporting the project, looking up documentation can be cumbersome. I've often found myself on the wrong docs page or having to sift through search results. it can also be confusing when asking questions about it. for instance, which kind of export is being referred to occasionally needs to be clarified in Discord help channels.
and lastly, I think expose just makes more sense in describing what the feature does.
I mentioned this already over here but realized that this thread is probably a much better place for it.
pycbouh already commented on it:

It's not all that the keyword does, though. It also makes that field serializable when you save resources using that script. That's not just scenes, that's also resources. And you can expose a property to the inspector without making it serializable too, but not with the keyword. So whether the export term is bad, expose is technically even less correct.

although I don't quite follow their reasoning. I think there's no need for a keyword to reflect the technicalities of how the engine implements something under the hood - rather, it should reflect what happens from the perspective of the user. also they do not address the issue in regards to ambiguity.

If anything, something like @serialize would be better.

although I don't quite follow their reasoning. I think there's no need for a keyword to reflect the technicalities of how the engine implements something under the hood - rather, it should reflect what happens from the perspective of the user. also they do not address the issue in regards to ambiguity.

My point was precisely to address the user perspective, and not the implementation detail. export serves multiple purposes, when you mark a property as export it being exposed in the editor is not the only thing that happens. The field also becomes serializable (i.e. saved on disk with the resource that holds it, be it a scene or a custom resource). So your suggestion does the opposite of reflecting the user experience because it hides part of what the keyword does. I was trying to make you aware of that.
I'm not sure if there is a good term that we can use here to reflect both effects of this keyword, so I kind of accept "exported property" as a Godot-specific term that works fine after you get familiar with the engine.

hm, I see the serialization and storing in the scene file as an implementation detail of making variables editable in (exposing to) the inspector. of course the value you enter into the inspector has to be stored somewhere; and for that it needs to be serialized, so all that is already implied. but in the end the purpose of it comes down to overwriting/editing variables/resources from the inspector. or is there some separate use-case that doesn't involve the inspector? if so, it's not being mentioned in the docs.
even when familiar with Godot, looking up docs for exporting properties can be a real hassle, evidently by checking search terms:
exported property - doesn't show up at all
export - shows up as the 22nd item
GDScript export - 22nd item again
exporting - 17th item
you pretty much need to remember the exact title of the article - GDScript exports - do find it quickly.
although to be fair that is also to some extent and issue of the readthedocs search. Google does a better job.

hm, I see the serialization and storing in the scene file as an implementation detail of making variables editable in (exposing to) the inspector.

It's not, it's a part of the feature exposed to the user. If you've ever created a custom resource, you'd know that you need to mark the property with export to make it save on disk, whether you need it visible in the inspector or not.

of course the value you enter into the inspector has to be stored somewhere

Not really. You can have properties exposed to the inspector without storing them. This is controlled by usage flags, and no, this is not an implementation detail, it's also exposed to the API and is fully controllable by the user. You can check PropertyUsageFlags in the docs for the global scope to see what options are available<EMAIL_ADDRESS>Exported properties have  PROPERTY_USAGE_DEFAULT for their usage flag, which is both STORAGE and EDITOR, but those are not one and the same.

if so, it's not being mentioned in the docs.

Indeed, the docs are not over-encompassing, but they do mention that being editable in the inspector is just one of the qualities of exported properties:

One of the fundamental benefits of exporting member variables is to have them visible and editable in the editor.

although to be fair that is also to some extent and issue of the readthedocs search

Indeed, and we were unable to find a better solution for RTD so far, but suggestions are welcome.

Contributors such as yourself @pycbouh and @KoBeWi have an amazing technical background knowledge. However I feel like you guys often forget that by far not every Godot user has this knowledge, or even a CS degree.
The "export" keyword wording has confused me since the first day using Godot and it really does not help how hard it is to research due to "export" having such a strong meaning elsewhere in game development or editors in general, like @h0lley explained.
"expose" on the other hand might not be your best association for someone like you who has a very high level of understanding about the behind-the-scenes technicalities, but it's much easier to find in documentation because there can be no confusion about it having a connection to exporting the game or exporting assets.
"expose" to me also really infers the most obvious, basic and common use of the keyword (to expose a property to the Inspector) so much better.

I think @expose is a better name since it's more searchable and can't be confused with exporting projects.
For the argument that exported variables are stored since they have the default property usage flags and therefore it does more than exposing... if we can say "exported variables are stored by default", why can't we say "exposed variables are stored by default"?
In terms of English words, exporting something does not necessarily imply storing it, in fact a good/product exported overseas typically means the opposite of storing it, it's shipped away.

@golddotasksquestions This has nothing to do with behind-the-scenes technicalities or some CS knowledge. This keyword has a function. The user doesn't know its function, so my job is to explain it. We will not be using a misnomer just because someone is new to Godot and doesn't yet know what export does to a property.
Furthermore, I feel like you doubling down on ignorance is not productive or helping.

For the argument that exported variables are stored since they have the default property usage flags and therefore it does more than exposing... if we can say "exported variables are stored by default", why can't we say "exposed variables are stored by default"?

We can, and I'm not saying that the keyword is not problematic. But we don't have to choose between just those two options, we can find a better word that would encompass the functionality. Or we may want to split the functionality between different annotations. This can be even more useful.

About the @export annotation:

Avoid lengthy discussions of suggestions in this tracker, as it makes it hard to keep track of things. Prefer discussion on the Contributor Chat, and if needed, open dedicated proposals for non-consensual suggestions that require more debate.

This should really be moved to its own proposal.

@pycbouh
I'm sorry I believe this is a misunderstanding, I did not want to imply you or anyone else to be ignorant about other people needs. We all live in a bubble of our own perception, experiences and biases, it's not a choice. I strongly believe the best way to overcome this is to share different perspectives and listen to each other. Github in general but also especially the discussions here on the Godot repos seem to be frequented disproportionately by very tech-savy people and I often feel like I need to make a stand for the perspective of those who won't even show up to these discussions.
So I do strongly believe finding a good names which infer intuitive useage for a wider range of Godot users (rather than an expert group) has to do with background and should be part of the discussion and considerations.
I definitely appreciate you and other much more experienced users explaining the functions of things such as specific keywords. I would rather expect this on the documentation repo though. Problem we are discussing here in this thread is the naming of the export keyword, and the fact that it's name makes it hard to impossible to find your explanation (which again, is very much appreciated, just as all the other work you do).

@golddotasksquestions Thanks, and sorry if I was unfairly harsh to you. I agree that we should be looking for better terms, and I agree that we need to improve the documentation. I believe we can continue this search for the solution in the proposal that @h0lley has created: https://github.com/godotengine/godot-proposals/issues/3906

but then I realised that "force" would somewhat imply the redraw happens on the spot

What's worse, it implies that you go against some natural order of updates, when in reality it is normal and expected to request updates after data changes to redraw your visual element. So yeah, we should avoid "force" here.

Should we rename the or_lesser property hint to or_less? This property hint is the opposite of or_greater, so it hints at allowing lower values.

Camera2D.get_camera_position() could use a rename.
I would propose get_track_point(), get_tracking_point(), get_following_point()...
Whatever it could be, it would allow documenting the Camera2D's functionality to be less of a careful "tip-toe" around the Node2D properties with the similar names, as well as making it considerably less confusing for beginning users experimenting with what the Class has to offer.

@Calinou If or_lesser is renamed to or_less then we could rename or_greater to or_more. I think either this or the current way is fine since both are hard to misunderstand and both are consistent with having er or not.

@Calinou If or_lesser is renamed to or_less then we could rename or_greater to or_more. I think either this or the current way is fine since both are hard to misunderstand and both are consistent with having er or not.

I think the rationale is that the > and < operators are called "greater than" and "less than", so it could make sense to be consistent with that here. It does seem a bit awkward but it's English which is to blame here :P
That being said, or_more,or_less seems fine to me too.

Not a linguist, but or_more and or_less sound like they refer to a physical count of something, not real numbers. Not necessarily against it, but I find or_greater to just sound more appropriate.

Can these Rename Suggestions for Godot 4.0 Alpha 2 be assessed before Godot 4.0 Beta 1? I know this is dense so please bare with me.
Consistent naming rules:

If it has ALWAYS or Once then use a matching NEVER (instead of DISABLED). If DISABLED still does a default effect then do not rename to NEVER but SHOW_NEVER is okay.
If it has a latch that runs once then sets itself to NEVER then use ONCE with matching NEVER (instead of NEXT).
If it is a Bool or Flag that latches itself to false then use ONCE (instead of NEXT).
If it is NOT a latch and runs once on a rare trigger like a watched property changed, use ON_{TRIGGER} (instead of IF, ONCE, AT, or WHEN).
If it is NOT a latch and If an alternate to ALWAYS or runs every loop but depends on a rare state that this does not modify, use IF_{STATE} (instead of ONLY, ON, ONCE, or WHEN). (Favor IF over WHEN because of enums like INSTANCE_FLAG_DRAW_IF_VISIBLE_ONCE only work with IF.) If the enum is alternatives to how Nodes are effected, then don't use this. If the enum is alternatives to which Nodes are effected or when are they effected, then use ALWAYS, IF, and/or NEVER.
If it is a choice between which game loop it is processed in use PROCESS_{SYSTEM} (instead of STEP or REALTIME).

Important Renames:
[ ] SceneTree.GroupCallFlags.GROUP_CALL_REALTIME -> GROUP_CALL_IMMEDIATE. See AnimationNodeStateMachineTransition.SwitchMode.
[ ] See 2. RenderingServer.ViewportClearMode.VIEWPORT_CLEAR_ONLY_NEXT_FRAME -> VIEWPORT_CLEAR_ONCE. ONCE implies latching to NEVER on the next handle pass and FRAME isn't needed unless there are multiple handler to differentiate. See Subviewport.ClearMode.CLEAR_MODE_ONCE.
#if INSTANCE_FLAG_DRAW_NEXT_FRAME_IF_VISIBLE latches to false:
[ ] See 3. RenderingServer.InstanceFlags.INSTANCE_FLAG_DRAW_NEXT_FRAME_IF_VISIBLE -> INSTANCE_FLAG_DRAW_IF_VISIBLE_ONCE.
#elif INSTANCE_FLAG_DRAW_NEXT_FRAME_IF_VISIBLE always draws when visible:
Remove misleading information. RenderingServer.InstanceFlags.INSTANCE_FLAG_DRAW_NEXT_FRAME_IF_VISIBLE -> INSTANCE_FLAG_DRAW_IF_VISIBLE. Next frame implies a latch which this is not.
[ ] See 4. ReflectionProbe.UpdateMode.UPDATE_ONCE -> UPDATE_ON_TRANSFORM because this isn't a latch to NEVER.
[ ] See 4. RenderingServer.ReflectionProbeUpdateMode.REFLECTION_PROBE_UPDATE_ONCE -> UPDATE_ON_TRANSFORM because this isn't a latch to NEVER.
[ ] TileMap.VisibilityMode.VISIBILITY_MODE_FORCE_HIDE -> VISIBILITY_MODE_SHOW_NEVER.
[ ] TileMap.VisibilityMode.VISIBILITY_MODE_FORCE_SHOW -> VISIBILITY_MODE_SHOW_ALWAYS.
#if SubEmitterMode works like it sounds:
[ ] See 1. ParticlesMaterial.SubEmitterMode.SUB_EMITTER_DISABLED -> SUB_EMITTER_NEVER.
[ ] ParticlesMaterial.SubEmitterMode.SUB_EMITTER_CONSTANT -> SUB_EMITTER_ALWAYS.
[ ] See 4. ParticlesMaterial.SubEmitterMode.SUB_EMITTER_AT_END -> SUB_EMITTER_ON_END.
[ ] See 4. ParticlesMaterial.SubEmitterMode.SUB_EMITTER_AT_COLLISION -> if triggered once SUB_EMITTER_ON_COLLISION or if a state SUB_EMITTER_IF_COLLIDING.
[ ] See 1. GeometryInstance3D.ShadowCastingSetting.SHADOW_CASTING_SETTING_OFF -> SHADOW_CASTING_SETTING_NEVER.
[ ] See 5. GeometryInstance3D.ShadowCastingSetting.SHADOW_CASTING_SETTING_ON -> SHADOW_CASTING_SETTING_IF_UNCULLED.
[ ] GeometryInstance3D.ShadowCastingSetting.SHADOW_CASTING_SETTING_DOUBLE_SIDED -> SHADOW_CASTING_SETTING_ALWAYS.
[ ] See 1. RenderingServer.ShadowCastingSetting.SHADOW_CASTING_SETTING_OFF -> SHADOW_CASTING_SETTING_NEVER.
[ ] See 5. RenderingServer.ShadowCastingSetting.SHADOW_CASTING_SETTING_ON -> SHADOW_CASTING_SETTING_IF_UNCULLED.
[ ] RenderingServer.ShadowCastingSetting.SHADOW_CASTING_SETTING_DOUBLE_SIDED -> SHADOW_CASTING_SETTING_ALWAYS.
[ ] See 4. AnimationNodeStateMachineTransition.SwitchMode.SWITCH_MODE_AT_END -> SWITCH_MODE_ON_END.
[ ] See 1. AnimationPlayer.AnimationProcessCallback.ANIMATION_PROCESS_MANUAL -> ANIMATION_PROCESS_NEVER.
[ ] See 1. AnimationTree.AnimationProcessCallback.ANIMATION_PROCESS_MANUAL -> ANIMATION_PROCESS_NEVER.
[ ] ScrollContainer.ScrollMode.SCROLL_MODE_AUTO -> SCROLL_MODE_SHOW_AUTO. This correlates with SHOW_NEVER instead of DISABLED.
[ ] DisplayServer.VSyncMode.VSYNC_ADAPTIVE -> VSYNC_AUTO.
[ ] See 5. LinkButton.UnderlineMode.UNDERLINE_MODE_ON_HOVER -> UNDERLINE_MODE_IF_HOVERED.
[ ] Sky.ProcessMode.PROCESS_MODE_QUALITY -> SkyProcessMode.SKY_PROCESS_STATIC.
[ ] Sky.ProcessMode.PROCESS_MODE_REALTIME -> SkyProcessMode.SKY_PROCESS_{SYSTEM}. System is Idle, Physics, etc.
[ ] RenderingServer.SkyMode.SKY_MODE_QUALITY -> SkyProcessMode.SKY_PROCESS_STATIC.
[ ] RenderingServer.SkyMode.SKY_MODE_REALTIME -> SkyProcessMode.SKY_PROCESS_{SYSTEM}. System is Idle, Physics, etc.
Suggested Renames:
[ ] See 6. AudioStreamPlayer3D.DopplerTracking.DOPPLER_TRACKING_DISABLED -> DOPPLER_TRACKING_PROCESS_NEVER.
[ ] See 6. AudioStreamPlayer3D.DopplerTracking.DOPPLER_TRACKING_IDLE_STEP -> DOPPLER_TRACKING_PROCESS_IDLE. Step isn't used or explained anywhere else.
[ ] See 6. AudioStreamPlayer3D.DopplerTracking.DOPPLER_TRACKING_PHYSICS_STEP -> DOPPLER_TRACKING_PROCESS_PHYSICS. Step isn't used or explained anywhere else.
[ ] See 6. Camera3D.DopplerTracking.DOPPLER_TRACKING_DISABLED -> DOPPLER_TRACKING_PROCESS_NEVER.
[ ] See 6. Camera3D.DopplerTracking.DOPPLER_TRACKING_IDLE_STEP -> DOPPLER_TRACKING_PROCESS_IDLE. Step isn't used or explained anywhere else.
[ ] See 6. Camera3D.DopplerTracking.DOPPLER_TRACKING_PHYSICS_STEP -> DOPPLER_TRACKING_PROCESS_PHYSICS. Step isn't used or explained anywhere else.
[ ] See 6. VelocityTracker3D.track_physics_step -> tracking_process_physics. Step isn't used or explained anywhere else.
Suggested Outlier Renames:
[ ] RigidDynamicBody2D.CCDMode.CCD_MODE_DISABLED -> CollisionMode.COLLISION_MODE_NORMAL.
[ ] RigidDynamicBody2D.CCDMode.CCD_MODE_CAST_RAY -> CollisionMode.COLLISION_MODE_CAST_RAY.
[ ] RigidDynamicBody2D.CCDMode.CCD_MODE_CAST_SHAPE -> CollisionMode.COLLISION_MODE_CAST_SHAPE.
[ ] PhysicsServer2D.CCDMode.CCD_MODE_DISABLED -> CollisionMode.COLLISION_MODE_NORMAL.
[ ] PhysicsServer2D.CCDMode.CCD_MODE_CAST_RAY -> CollisionMode.COLLISION_MODE_CAST_RAY.
[ ] PhysicsServer2D.CCDMode.CCD_MODE_CAST_SHAPE -> CollisionMode.COLLISION_MODE_CAST_SHAPE.
[ ] Sky.ProcessMode.PROCESS_MODE_AUTOMATIC -> SkyProcessMode.SKY_PROCESS_AUTO.
[ ] RenderingServer.SkyMode.SKY_MODE_AUTOMATIC -> SkyProcessMode.SKY_PROCESS_AUTO.
[ ] DisplayServer.VSyncMode.VSYNC_DISABLED -> VSYNC_NEVER.
[ ] DisplayServer.VSyncMode.VSYNC_ENABLED -> VSYNC_ALWAYS.
Suggested Minor Renames:
[ ] See 1. SubViewport.UpdateMode.UPDATE_DISABLED -> UPDATE_NEVER.
[ ] See 5. SubViewport.UpdateMode.UPDATE_WHEN_VISIBLE -> UPDATE_IF_VISIBLE.
[ ] See 5. SubViewport.UpdateMode.UPDATE_WHEN_PARENT_VISIBLE -> UPDATE_IF_PARENT_VISIBLE.
[ ] See 1. RenderingServer.ViewportUpdateMode.VIEWPORT_UPDATE_DISABLED -> VIEWPORT_UPDATE_NEVER.
[ ] See 5. RenderingServer.ViewportUpdateMode.VIEWPORT_WHEN_VISIBLE -> VIEWPORT_IF_VISIBLE.
[ ] See 5. RenderingServer.ViewportUpdateMode.VIEWPORT_WHEN_PARENT_VISIBLE -> VIEWPORT_IF_PARENT_VISIBLE.
[ ] See 1. BaseMaterial3D.DepthDrawMode.DEPTH_DRAW_DISABLED -> DEPTH_DRAW_NEVER.
[ ] See 5. BaseMaterial3D.DepthDrawMode.DEPTH_DRAW_OPAQUE_ONLY -> DEPTH_DRAW_IF_OPAQUE.
[ ] See 1. Node.ProcessMode.PROCESS_MODE_DISABLED -> PROCESS_MODE_NEVER.
[ ] See 5. Node.ProcessMode.PROCESS_MODE_PAUSABLE -> PROCESS_MODE_IF_UNPAUSED.
[ ] See 5. Node.ProcessMode.PROCESS_MODE_WHEN_PAUSED -> PROCESS_MODE_IF_PAUSED.
[ ] See 5. TouchScreenButton.VisibilityMode.VISIBILITY_TOUCHSCREEN_ONLY -> VISIBILITY_IF_TOUCHSCREEN.
[ ] See 5. TabBar.CloseButtonDisplayPolicy.CLOSE_BUTTON_SHOW_ACTIVE_ONLY -> CLOSE_BUTTON_SHOW_IF_ACTIVE.
[ ] See 5. VisibleOnScreenEnabler2D.EnableMode.ENABLE_MODE_WHEN_PAUSED -> ENABLE_MODE_IF_PAUSED.
[ ] See 5. VisibleOnScreenEnabler3D.EnableMode.ENABLE_MODE_WHEN_PAUSED -> ENABLE_MODE_IF_PAUSED
[ ] See 5. GPUParticlesCollisionHeightField3D.UpdateMode.UPDATE_MODE_WHEN_MOVED -> UPDATE_MODE_IF_MOVED.
Hopefully this will be of some use.

@RefinedSoftwareLLC I brought up the ProcessMode enum naming in #46191, but reduz decided these names were better.

[ ] See 4. ReflectionProbe.UpdateMode.UPDATE_ONCE -> UPDATE_ON_TRANSFORM because this isn't a latch to NEVER.

See also https://github.com/godotengine/godot-proposals/issues/2934.

just had someone looking for help being confused about there not being randf_range() in @GDScript.
it's not like the function is missing, but it is called rand_range() - without the "f".
so for consistency, I suggest to raname @GDScript.rand_range() into @GDScript.randf_range(),
which would also make space for a potential randi_range() to be added to @GDScript in the future.

@h0lley Your feature request has already been implemented in 2020 in #40718. It will be present in Godot 4.0.

@aaronfranke ah cool, although I'm confused that it's not already in the current Godot 4 alpha then?

Here is a way to standardize signals:
Use:
*_starts_soon (nodes may not exist), *_started (nodes exist), *_ended, *changed, *{verb}ed,
Change:
*_finished -> *_ended (both pairs with started but ended is shorter. If target of ended isn't clear, then finished probably isn't either, so if needed use qualifier_ended.)
request -> *_requested
*_request -> *_requested
*_updated -> *_changed
connection_error -> connection_failed (like other APIs)
go_to_help -> help_requested
connection_from_empty -> connection_from_empty_requested
connection_to_empty -> connection_to_empty_requested
custom_action -> custom_action_requested
frame_pre_draw -> draw_starts_soon or draw_started
about_to_popup -> popup_starts_soon
pre_sort_children -> sort_children_starts_soon
process_frame -> process_started
physics_frame -> physics_started
begin_node_move -> node_move_started
end_node_move -> node_move_ended
frame_post_draw -> draw_ended
on_request_permissions_result -> permissions_changed (or { permission_request | request_permissions }{ _changed | _ended | _resolved | _received }
reference_space_reset -> reference_space_changed
popup_hide -> popup_hidden
peer_packet -> peer_packet_received (like other APIs)
Outliers:
*_up, *_down # raw signals forwarded to *_pressed
{word}, {word}start (no _), {word}end (no _) # squeeze, select
tree_exiting # keep because tree_exit_starts_soon is confusing (haha)
*_closed (instead of *_ended) # windows, popups, connections, and editor files?

@RefinedSoftwareLLC I like this proposal, but want to add:

HTTPRequest.request_completed seems to be the only remaining *_completed signal - all others have already been changed into *_finished. Should it be changed into *_ended, too?
I think the _soon sounds a bit too vague for computing terms. so how about _next instead. I think in pretty much all cases it's something that happens within this or the next tick.

request_completed should definitely be added to my list :+1:.
I recommend that all *_finished be changed to *_ended, but I am not on the development team.
I agree that *_next is a great option :+1:. *_soon being vague has the benefit of the API being consistent (there are less outlier signal names). Next personally makes me think of next(callback).

My hope is that the handful of pre signals gets standardized to the same phrasing, no matter what it is. Most signals are _on_{Node}_{noun}_{verb}ed.
_on_MenuButton_about_to_popup() could be considered misleading because the Button isn't popping up as it is already visible; It's internal Button.Popup displays, which is closer to the meaning of _on_MenuButton_popup_starts_next().

Thanks for your insights and I hope my lists help find the outliers, that don't make sense, before beta.
Separate from a dedicated proposal, here is my reasoning for consistency (weighed against each other): Reduced confusion (what timing? differentiated verb), consistent implied details (started what? cognitive load), cleaner reusable code (can: n in group: n.enabled = true), ease of knowing more features (A == B, use A or B?), reduced double negatives, and reduced typing.
For outliers which reduce the same type of confusion, they should be consistent with themselves, if possible, for the above reasons.

Signals
button_down -> press_started
button_up -> press_ended
WebXRInterface: # Godot API is already not a letter for letter match of JS API
session_ended -> session_closed (Equivalent to a window being closed)
selectstart -> select_started
select -> selected # Docs: not called if aborted
selectend -> select_ended # Docs: always called?
squeezestart -> squeeze_started
squeeze -> squeezed # Docs: not called if aborted
squeezeend -> squeeze_ended # Docs: always called?

@RefinedSoftwareLLC the idea of improving the signal naming convention is not bad, but I think that you should open a proposal, as @pycbouh said this is generating quite a lot of discussion. This thread is for small proposals, not big changes to the API.

IMO, Tree should rename. Tree should a DataStruct or a true TREE, but int godot, it was a Control.
Sorry I haven't a good new name, maybe TreeControl.
And ItemList maybe renamed ListControl.

@CsloudX that'd make sense if all controls had a consistent naming scheme IMO.

^V^, I wish Godot will provide List, Tree, Stack etc DataStruct one day.

I see how Tree is a rather ambiguous name that may be confused with an AnimationTree or the SceneTree.
I don't like TreeControl though. No other Control node is suffixed with Control.
I think ItemList is just fine though, and would suggest to name Tree ItemTree in the same way. It already uses the "item" terminology in its create_item method just like the ItemList does have an add_item method.

AudioStream::instance_playback() to instantiate_playback()
Relevant PR: https://github.com/godotengine/godot/pull/49693

A polyline can be opened/closed also a multiline can be opened/closed also A polygon can be opened/closed.

draw_multimesh()
draw_line()
draw_multiline()
draw_multiline_colors()
draw_polyline()
draw_polyline_colors()
draw_polygon()
draw_colored_polygon()
draw_primitive()

No practical difference in multi- vs. poly- prefixes. They're based on the word's Latin (multi-) or Greek (poly-) roots. The meaning difference is on the word rather than the prefixes in most cases. [*]

Another oddity. Primitives in geometry can have more than 4 vertices. But according to the draw_primitive() method this is not possible.

There is no difference between a multi-line and a single-line if there are only two points.
Proposal:
Reduced methods and more understandable names. Primitives such as draw_circle() and draw_rect() can remain.

draw_polymesh()
draw_lines() # if there are two points it's a single line (simple and elegant)
draw_regular_polygon(... closed: bool, fill: bool) # minimum 3 corner
draw_polygon(... closed: bool, fill: bool)

copy-paste from -> https://github.com/godotengine/godot-proposals/discussions/4168

I have some renaming suggestions for the Control.LayoutPreset enum:

PRESET_LEFT_WIDE -> PRESET_LEFT_TALL
PRESET_RIGHT_WIDE -> PRESET_RIGHT_TALL
PRESET_VCENTER_WIDE -> PRESET_V_CENTER_TALL
PRESET_HCENTER_WIDE -> PRESET_H_CENTER_WIDE
PRESET_WIDE -> PRESET_FULL_RECT

Changing WIDE to TALL for vertical presets helps to differentiate them from horizontal presets, and changing PRESET_WIDE to PRESET_FULL_RECT makes it easier to find since the editor tool uses the name "Full Rect".

I suggest to rename two CanvasItem::get_..._transform() functions, which is one part of the proposal https://github.com/godotengine/godot-proposals/issues/4250.

CanvasItem::get_global_transform() -> CanvasItem::get_canvas_transform()
CanvasItem::get_global_transform_with_canvas() -> CanvasItem::get_viewport_transform()

The reason for this change is to create a convention for naming 2D get_..._transform() functions as explained in the linked Proposal:

The function "Caller::get_xxx_transform()" either returns a transform, that belongs to the "Caller" or it returns the Transform2D from the parent "xxx"-Coordinate System to the "Caller"s coordinate system.

Also, as explained in https://github.com/godotengine/godot-proposals/issues/3866, the word "global" is interpreted differently by different people. With this change, this problem could be circumvented, by explicitly stating the target Coordinate System endpoint of the returned Transform2D in the function name.

The naming of "one-shot" properties should be unified. There are currently two spellings, one with a space between words and one without:

Node
Property/Enum Name

AtlasTexture
oneshot

Object
CONNECT_ONESHOT

Particle nodes (CPU/GPUParticles2D/3D)
one_shot

Timer
one_shot

I believe it should be one_shot for all, as "one-shot" is how it is written. However, for me, I do have to admit something about CONNECT_ONE_SHOT doesn't feel right.

I found a few more renames:

Node
Property Name
Suggested Rename

CanvasLayer
follow_viewport_enable
follow_viewport_enabled

NavigationAgent2D/3D
neighbor_dist
neighbor_distance

rmb_selected in ItemList is emitted even when allow_reselect is false. The signal should likely be renamed to rmb_clicked (see #55381) to be more clear on that.

@KoBeWi the proposal is fine, but are we sure it isn't some old obscure bug that should instead be fixed?

This behavior is coded explicitly:
https://github.com/godotengine/godot/blob/d7d528c15f0e858b52bb0f510ff47e65c2341de1/scene/gui/item_list.cpp#L661-L663
So this is most likely intended and I don't remember any opened issues about it.

void DisplayServer::mouse_warp_to_position(const Point2i &p_to);
void Input::warp_mouse_position(const Vector2 &p_to);
void Viewport::warp_mouse(const Vector2 &p_pos);
void Control::warp_mouse(const Point2 &p_to_pos);

All these functions do the same thing: relocate the mouse cursor.
They should all have the same name, for example warp_mouse.

In the class CanvasItem:
get_global_mouse_position() -> get_canvas_mouse_position()
The makes the function-name more explicit by including the name of the coordinate system "canvas" of the mouse position that the function returns. "Global" can mean different things, depending on who one asks.

In the class CanvasItem: get_global_mouse_position() -> get_canvas_mouse_position()
The makes the function-name more explicit by including the name of the coordinate system "canvas" of the mouse position that the function returns. "Global" can mean different things, depending on who one asks.

is there any difference between these two?
get_global_mouse_position()
get_viewport().get_mouse_position()
maybe just get_viewport_mouse_position() is enough. Just an idea.

They are different. get_viewport().get_mouse_position() returns the mouse position in the viewport without the canvas.

Suggested renames for consistency across shader uniform setters/getters:

Per-material: ShaderMaterial.set_shader_param() → ShaderMaterial.set_shader_uniform(): WIP
Per-instance: GeometryInstance3D.set_shader_instance_uniform → GeometryInstance3D.set_instance_shader_uniform(): WIP
Global: RenderingServer.global_variable_*() → RenderingServer.global_shader_uniform_*(): https://github.com/godotengine/godot/pull/59840

The key is to always have shader_uniform in order somehow, so that the methods can be found easily when searching the class reference.

Suggested rename Control::minimum_size to Control::custom_minimum_size.
This property maps to Control::set_custom_minimum_size and Control::get_custom_minimum_size, so I expect it to be called custom_minimum_size.
Also naming minimum_size cause troubles for some languages like Kotlin, because there's another method named Control::get_minimum_size, which is not linked to property Control::minimum_size, and needs to be generated. This makes conflicting naming in generated code because Control::minimum_size generated getter has signature that is the same as Control::get_minimum_size.

Same for AnimationNodeTransition::input_count.
It refers to AnimationNodeTransition::get_enabled_inputs and AnimationNodeTransition::set_enabled_inputs.
Also it conflicts with AnimationNode::get_input_count (AnimationNode is parent class).
I suggest to rename it to AnimationNodeTransition::enabled_inputs.

I propose renaming project settings such as rendering/shadows/shadows/soft_shadow_quality to rendering/shadows/point_shadows/soft_shadow_quality. This way, the project settings explicitly refer to point light shadows (OmniLight3D and SpotLight3D), avoiding confusion with the directional shadow project settings.
The same should be done for the corresponding RenderingServer methods.

DisplayServer.WindowFlags is the only plural-y named enum on DisplayServer - which just seems a little janky to me.
Presumably should be DisplayServer.WindowFlag for e.g. DisplayServer.WindowFlag.WINDOW_FLAG_BORDERLESS
I'd also note that ScreenOrientation and CursorShape only repeat the first word in their values.
Why not:
WindowFlag.WINDOW_BORDERLESS and WindowMode.WINDOW_FULLSCREEN
over:
WindowFlag.WINDOW_FLAG_BORDERLESS and WindowMode.WINDOW_MODE_FULLSCREEN
?

@willstott101 I know I gave a +1 but wait, isn't that the case only for class enums? These enums can be accessed, at least from the core C++ API, without any type indication. I guess it's just good practice to prefix them sufficiently to avoid collisions. Really in that case the issue becomes: what's the preference now that we have enum classes? I'm not particularly experienced in that regard and don't known if it could be worth it.

Talking about DisplayServer I don't particularly like one aspect of its API. Most methods regarding windows have an argument for the window as the last to allow to default it to MAIN_WINDOW_ID, likely for compatibility/readability reasons, but to do that they have to make the window parameter the last. This causes situations where stuff like window_get_flag(flag, window_id) happens while for example window_set_transient(window_id, parent_id) can happen too. While I understand the reasoning behind it that still causes some mild confusion IMO and perhaps we could do something like some sort of child/main only set of wrappers and make the API more consistent with them? Also, I'm not particularly fond of the weird shift that can happen while reading from "get me this window position" to "get me the (impliying main) window position" with the same method, but I guess that's more subjective.

@Riteo enum class in general is superior to enum, since enum class is more like enum in C#. I converted the input enums to enum class last year: https://github.com/godotengine/godot/blob/master/core/input/input_enums.h

@aaronfranke oh, that explains why it was an enum class, shouldn't we write is somewhere, if it  hasn't been documented already?

I think about renaming PointLight2D to OmniLight2D ? There is no PointLight3D, only OmniLight3D which lacks a 2D counterpart.

I feel like the "Omni" rolls less off the tongue of non-English speaking users. I was going to suggest renaming it to PointLight3D, but it's not standard and at the same time, plenty of things in Godot are vaguely named "Point". Yeah, it's a light starting from a Point, but it is emitted on all directions, and that is the important part.

@Chaosus See the discussion here https://github.com/godotengine/godot/issues/16863#issuecomment-869206213

@aaronfranke okay, I didn't see that, thanks

While working on https://github.com/godotengine/godot/pull/60696, I was wondering whether we should rename project settings that only affect 3D to contain an explicit "3D" prefix. This is already done for 2D shadow quality settings, but 3D settings are only implicitly marked as 3D-only (either in the documentation, or because the feature doesn't "make sense" to have in 2D).

We have a few methods like abs that have integer and float variant (absi/absf). But strangely, rounding methods are missing this. We could maybe add roundi, floori and ceili that still take a float, but return an int (it's awkward that they round to integer number and return it as float...).

https://github.com/godotengine/godot/issues/16863#issuecomment-742419534
FileSystem dock to File System
Also requires some API changes like FEATURE_FILESYSTEM_DOCK → FEATURE_FILE_SYSTEM_DOCK.

https://github.com/godotengine/godot/issues/16863#issuecomment-855084075
AudioStreamSample -> AudioStreamWAV

I already got surprised a few times that roundi, floori, ceili and signi don't exist.

I noticed the percent_visible property in RichTextLabel. It goes from 0 to 1.
It should be fraction_visible

I noticed the percent_visible property in RichTextLabel. It goes from 0 to 1.
It should be fraction_visible

I am particularly interested in this, since I like to comment my code with units as much as possible. Usually what I get stuck on is the last argument of lerp.

English Stack Exchange post with some discussion:

I'm looking for a word to replace "percentage" for numbers between 0 and 1.

.
First answer: fraction or decimal_fraction, top comment suggests ratio:

Numbers between 0 and 1 are fractions, and fractions expressed as a decimal are decimal fractions.

.
Second answer: Why percent might work:

In mathematics, a percentage is a number or ratio expressed as a fraction of 100. [wikipedia]

0.12 and 12% are as equivalent, as 0.1234 and 12.34% are. If the numbers you are expressing are proportional then percent is as valid as anything else.

I am curious if there is any agreed upon symbol to denote a decimal fraction from 0 to 1, if so, we should use that as a suffix in the editor. As for name, I prefer ratio over fraction. visiblity_ratio could work. I think we can all agree decimal_fraction is too wordy though.

I am curious if there is any agreed upon symbol to denote a decimal fraction from 0 to 1, if so, we should use that as a suffix in the editor.

A ratio by definition is unitless - it's the fraction of two quantities of the same unit (here e.g. "48 characters / 240 characters" gives a ratio of 0.2).

Second answer: Why percent might work:

Personally I think percent is fine. In math calculations, and thus by extension IMO in APIs, a percentage should always be expressed like a ratio, otherwise you tend to get a factor 100 error in your calculations, which is something that I see too many people struggle with. 20% just means 20 × 1 / 100 which is 0.2.
But yes if that creates confusion for some we can go with ratio.

LineEdit's caret_blink_speed might need a rename. Usually higher speed = faster, but this one is revered.
Maybe caret_blink_delay?

LineEdit's caret_blink_speed might need a rename. Usually higher speed = faster, but this one is revered.
Maybe caret_blink_delay?

What about caret_blink_time or caret_blink_duration?

Rect2.has_no_area() -> !Rect2.has_area() (or Rect.is_empty()). The no in the middle makes the current name rather odd.

@KoBeWi Aren't you doing the exact opposite in this PR, adding a new negatively-named method? https://github.com/godotengine/godot/pull/62294

That one was suggested by reduz, personally I don't like this idea xd (and doesn't seem like there is much interest in merging it, given our discussion on chat)

NOTIFICATION_INSTANCED

Rename interpolate in Curve.interpolate, Curve2D.interpolate, Curve3D.interpolate, and Gradient.interpolate to sample
eg. Curve.sample(0.5)
the methods don't actually "interpolate" anything, rather they sample the curve at a point

Array.front() -> Array.first()
Front feels a bit misleading...
The front doesn't necessarily point left.

Array.front() -> Array.first()
Front feels a bit misleading... The front doesn't necessarily point left.

I believe front and back are fine, see https://cplusplus.com/reference/array/array/front/

I've been searching around for the functions to get icons or theme colors from the current one and couldn't find until I asked Yuri, so leaving a comment here for the future:
get_icon -> get_theme_icon
get_color -> get_theme_color

The reply I got was:

In 4 those methods are called get_theme_… instead of get_…

I think we should rename methods like str2var and linear2db to use _to_ instead of 2 in the middle for consistency.

This naming is not always used (for example, String.bin_to_int)
The number feels unnatural when the first part is omitted (such as String.to_lower)
The number isn't proper English && less inclusive to those unfamiliar with chatting culture.

var reg = RegEx.new()
reg.compile("\s+")

->
var reg = RegEx.new("\s+")

@bend-n Last time I checked, core class constructors may not have arguments exposed to them (even optional).

Compile could be a static method.

Compile could be a static method.

It might be confusing if it's named compile(). Maybe create_and_compile() or create_from_string()?

@Calinou

core class

What is a core class? Rect2 and Vector2 take arguments.

What is a core class? Rect2 and Vector2 take arguments.

These are constructors for Variant types, while RegEx is not a Variant type on its own (other than being Object-derived).

The ParticlesMaterial turbulence_active property should be renamed to turbulence_enabled for consistency.

Maybe create_and_compile() or create_from_string()?

So like
var reg = RegEx.create_from_string("\s+")

? Still less straightforward than RegEx.new("\s+"), but its a acceptable compromise.

I think we should rename Position2D and Position3D to Marker2D and Marker3D to explain its usage better. It's odd that it's named the same as a property. It feels natural to do @onready var my_position := $Position2D and then my_position.position all of a sudden feels wrong.

Also, could we rename RigidDynamicBody to DynamicBody / RigidBody? Over on Discord, I've never ever seen anyone liking the rename.

Two adjectives (aside from dimension) describing one object – what other node does that?
Wait, was it DynamicRigidBody or RigidDynamicBody?
Cucumbersome to type
RigidBody is an industry standard, DynamicBody describes function better. I don't have a preference.
The current name is neither an industry standard, neither good at describing function (it's not necessarily rigid!)

AnimatedSprite2D/3D.flip_x and flip_y sound like commands, shouldn't they be flipped_x and flipped_y?

@Mickeon flipped_x and flipped_y sound like signals, so no. flip_x and flip_y are not ambiguous because methods ("commands") have parentheses after them, while properties do not.

I made this proposal in the process of refactoring PathFollower2D/3D. I fell the change of Stage 1 is essential, Stage 2 is more a matter of personal tastes. What you guys think?
The gist is:
stage 1:
for both PathFollower3D and PathFollower2D

offset -> distance,
unit_offset -> unit_distance

for PathFollower3D

add f_offset (f for forward) beside h_offset and v_offset for completeness

stage 2:
for PathFollower3D

v_offset -> up_offset
h_offset -> right_offset
f_offset -> forward_offset

for PathFollower2D

v_offset -> forward_offset ,
h_offset -> right_offset,

I prefer distance over offset, especially because three/four properties vaguely named offset in the same Class can be really confusing. There may be a better alternative, however, as I personally associate "distance" with actual distance in space, and its related Vector2/Vector3 methods.
"v" and "h" are used so frequently across the engine (and other programs as well), that it's easy to see a couple of them as shortened "vertical" and "horizontal". On the other hand, the meaning of the "f" in f_offset can potentially prove difficult to gather while reading code. As it probably makes sense to implement that new property, it's likely worth naming all three more explicitly.
But now that I think about it, can't v_offset, h_offset and f_offset just be a Vector2/Vector3?

How about...?
PathFollower2D and PathFollower3D:
offset -> progress
unit_offset -> progress_ratio or progress_percent

for PathFollower3D

v_offset -> up_offset
h_offset -> right_offset
f_offset -> forward_offset
for PathFollower2D

v_offset -> forward_offset ,
h_offset -> right_offset

It'd be a lot more straightforward to convert those to a single offset  Vector2/Vector3 property instead.

Why are there h_* and v_* options together, ever? Why not just Vector2/3.
It's not just PathFollower that has v_ and h_ options.
Should we change them all? They're also difficult to interact with in code...
It just doesn't make sense to have many options that could be one thing.
But we cant change one, and not all, that would be confusing for people.
Although, some nodes (Control) have offset variables that are vectors... So its already confusing.

Why are there h_* and v_* options together, ever? Why not just Vector2/3.
It's not just PathFollower that has v_ and h_ options.
Should we change them all? They're also difficult to interact with in code...

Most of the places where h_* and v_* are separate are in themes, which only support a limited number of types: int, Color, StyleBox, Font, and Texture2D. Those can't be changed to Vector2/Vector3 without significant changes to Theme and Control. There is some discussion around changing theme properties to variants in https://github.com/godotengine/godot-proposals/issues/4486.
Any of the places that use separate h_* and v_* variables outside of themes should definitely be changed to use Vector2/Vector3 though. I have a similar proposal open here: https://github.com/godotengine/godot-proposals/issues/4076.

How about...? PathFollower2D and PathFollower3D: offset -> progress unit_offset -> progress_ratio or progress_percent

I am ok with that. And I changed the proposal accordingly.

But now that I think about it, can't v_offset, h_offset and f_offset just be a Vector2/Vector3?
Any of the places that use separate h_* and v_* variables outside of themes should definitely be changed to use Vector2/Vector3 though

I totally agree. Hope 4076 could follow through

We had a small discussion on discord on function name plus_file.
It appends one string to another as a subpath with '/' as seperator.
It could be a file, but can also be another directory, or even used to build a url.
The name plus_file not seen in other programming languages, so its hard to find/search for existing developers.
Examples:
C#:     Path.Combine("a", "b")
Python: os.path.join("a", "b")
JS:     path.join("a", "b")
Ruby:   File.join("a", "b")
Java:   Paths.get("a", "b")
Rust:   Path::new("a").join("b")

There was also the suggestion of removing plus_file and make it a part of a dedicated class.
Something like Dictionary.new().join("a", "b")
Is this something that should be renamed/removed before 4.0?

There was also the suggestion of removing plus_file and make it a part of a dedicated class.
Something like Directory.new().join("a", "b")

Godot 4 supports static methods in built-in classes, so it could actually just be Directory.combine(), theoretically.

@Scraphead There is already a Directory class which is used for performing directory operations on the file system, so I'm not sure it would be a suitable place for string operations. I'd suggest renaming plus_file to path_join or similar.

Yeah, rename for now.
path_join is also my preferred alternative, and is very readable coming from other programming languages.
Some other names from discord. If any caches your fancy.
"a".path_join("b")
"a".combine_path("b")
"a".concat_path("b")
"a".append_path("b")
"a".add_subpath("b")

I'll make a proposal for a dedicated path manipulation class later.

why not join_path?

why not join_path?

String already have a join, so we would have two sort of unrelated functions that begins the same (join and join_path)
That also overlap a bit for script autocomplete.

I find plus_file() more intuitive to think with compared to join_path() (or anything of the sort, such as Node.js's path.join()).

I find String.plus_file() more intuitive to think with compared to join_path() (or anything of the sort, such as Node.js's path.join()).

If you are used to it, its sort of fine, but the method name did not stand out to me when combining directory paths.
It's used for more things then just plussing a file (name) to string.

This issue isn't for discussion. The plus_file() rename is controversial (given how many comments it spawned), so it needs a dedicated proposal.

Also relevant: https://github.com/godotengine/godot/issues/28748

As discussed in a maintainers meeting today, we'll be bikeshedding over the renames that have been PR'd this Thursday. Anything that didn't make the cut, c'est la vie! We need to draw the line somewhere, and the timeframe for the beta means we need to do it now. For all intents and purposes, this tracker has served its purpose and is now closed.
Thanks for all the suggestions! Wait for reviews on the relevant PRs, or join the meeting on Thursday if you have strong opinions in favor or against that you'd like to voice!

Shader builtin matrices rename suggestions
Spatial Shaders

WORLD_MATRIX rename to MODEL_TO_WORLD
WORLD_NORMAL_MATRIX rename to MODEL_TO_WORLD_NORMAL
MODELVIEW_MATRIX rename to MODEL_TO_VIEW
MODELVIEW_NORMAL_MATRIX rename to MODEL_TO_VIEW_NORMAL
CAMERA_MATRIX rename to VIEW_TO_WORLD
INV_CAMERA_MATRIX rename to WORLD_TO_VIEW
PROJECTION_MATRIX rename to VIEW_TO_CLIP
INV_PROJECTION_MATRIX rename to CLIP_TO_VIEW

CanvasItem Shaders

WORLD_MATRIX rename to MODEL_TO_WORLD
CANVAS_MATRIX rename to WORLD_TO_CANVAS
SCREEN_MATRIX rename to CANVAS_TO_SCREEN

is this moved to separate issue, and tracked / tagged against any future release ?
As I am banging my head with issue described in https://github.com/godotengine/godot/issues/19800 the built-ins naming convention and lack of documentation examples of how to utilise them does not help.
I am just worried that this rename will be lost in this issue comment and forgoten, shall I create separate issue for it ?

@2fd5 The agreed upon renames have been made in 4.0: #59268. No further renames are planned.


Linebreaks

I'm sending this PR only to start a discussion and to hopefully communicate that some of us in the community want to help you guys reach this feature :dog:. I don't pretend to think that this implementation is all there is to it, of course.
The commit 735b307 has the relevant code.
This is testable by running:

make dist
python -m SimpleHTTPServer // in project root
open http://localhost:8000/static/

For me the standout problem to line breaks seemed to be that elements weren't getting their heights correctly set. I suppose this is due to something with how the web font is used (larger text without setting larger font size.) "X-ing" the line height for each size class however solves this problem.
The problem that this PR does not solve however is where line breaks happen. MathJax for example would be smart enough to split things up, whereas in this branch the line break is "breaking up a group." I suspect that this can be fixed with CSS, though I need to refresh my memory.

Thoughts? I'm sure you guys had considered something like this already.

PS. I did not test this in anything else than Chrome, as I just wanted a proof of concept.

I think this is generally the right idea. I was thinking that we should make the entire expression wrappable but each unit inside unbreakable. So that means a left/right atom wouldn't wrap and neither would something created with braces like {a + 2}. TeX actually has more complicated breaking rules – like it will generally only break after a +, not before. It would be really nice if we could encode those rules properly in the output. Maybe one option is to even output ordinary HTML wbr tags. We should at least start by looking in the TeXbook to see what those rules are.

I might or might not be able to approach the TeXbook and get some progress done. At our company we'll go with this little change for now as a poor workaround for small devices. I've never written a line of TeX in my life, going through the book might be a daunting task! If I can assist you in any way meanwhile to get the ball rolling let me know. :-)

@mull I'm going to close this.  Let me know if you do any investigating in the TeXbook?