Is anyone interested in these flaws in the editor (and debugger)?

[stefano.menci]

Hi George,

It’s great to see new Anvil users being active on the forum, sharing feedback, and suggesting improvements. I hope you’ll keep that enthusiasm for a long time.

That said, a small piece of advice: posts like this can start interesting discussions, but they rarely lead to real changes. The Anvil team does read every post, especially when several users join the conversation. Still, a post needs to be specific for the team to act on it.

Here are a few suggestions:

1. Writing things like this:

@thetaghun

Pasting code never worked as far as aligning Pyhton code indents are concerned: E. g. if I write a “def …:” code, I may add another “def …:” code just below it and that next line shouldn’t be indented at all because that will be a def on the same indent level.
It occurred with if statements too.
Somehow, it never indented correctly my pasted code. (Well, incidentally, 5 % of cases.)
Again, I HAVE TO DECIDE what I write not a dumb machine.

…doesn’t help much. Every software has bugs, and saying “sometimes it didn’t work” is too vague to reproduce.

A clearer way would be something like:

Clone this test app, select function y, press Ctrl+C, put the cursor at the end of function y, press Ctrl+V → the indent is wrong.

That kind of example makes the issue reproducible and immediately actionable for the Anvil team.

2. This sounds like a bug report, but everything works as expected, so it can’t be a bug:

@thetaghun

Going back and forward to previous places (code edition points) in code is not supported. E.g. by pressing Alt+Left/Right.

A better way is to create a feature request like:

Please add shortcuts to navigate to previous locations.

3. Combining many unrelated points in one post reduces its impact. At best, you’ll get a reply about one of them and the other points are forgotten; at worst, people might skip it entirely because it’s unclear what it’s about. It’s usually better to write one post per bug report and one per feature request.

4. You don’t need to mention how long you’ve been programming — clear, focused posts get attention regardless of experience.

5. Before calling something a bug, it often helps to ask if it’s expected behavior, explain what you expected, and see if others can confirm or suggest a workaround. If the team agrees it’s a bug, they’ll move it to the right section.

I’ve reported hundreds of bugs here; many were fixed quickly. None needed me to mention experience or call them “bugs” — clarity and reproducibility were enough.

---

The fact that this is the first answer to your long post, and it doesn’t address any of the points you brought up, shows that bringing up too many topics at once makes it harder for others to engage effectively.

In short:

• One issue or feature request per post
• Make it reproducible
• Keep it concise and specific

That approach makes your feedback much more valuable and easier for the team to act on.