Just my two cents on this. When I first started transitioning to functional programming within wolfram language, I had some habits from the procedural and also legacy languages like Ada that I like to keep and Wolfram Language has the flexibility to allow for it. But as I started to code more and more in functional programming style, I suddenly realize that there simple work arounds that is already available.

If you write codes that are to complicated in terms of brackets. Try break it up by naming items

Use TreeForm to see structure

Use RightComposition if you don’t like the inside first of composite functions

Etc.

Being able to work with the brackets of Wolfram Language is one of the key skills. But after three years now programming in functional programming paradigm I have found the above to take care most of my brackets debugging needs

Raspi,

1. Wolfram Research cares deeply about our customers' feedback and aims to take it into consideration as much as possible.

2. Any estimate on when any suggestion may get picked up or not will be next to impossible to make, be it now or in a year, given the volume and diversity of suggestions we get as well as the number of either long-term and quickly developing high-priority projects the development teams are working on in the interest of our customers.

Considering point 1., customer-facing teams do reach out to our development teams for comment whenever the interest in particular issues and ideas arises, but given point 2. that information may often not be available at a given point in time.

Best, Peter

Thanks Peter for your reply! I conclude that the status of my suggestion/request/idea is then "suspended" for the time being, which is a neutral word for saying that a decision/discussion hasn't been made about the suggestion or has been put on hold (for unknown reasons, maybe lack of manhours/time/urgency/priority) and, once it gets seriously discussed among them with the aim to finally take a decision (to adopt vs. to reject), there could still be a chance of rejection, in the end.

Lemme wait another year (time flies!), but next year I'd surely love to hear a clear status change. Chatting with the developers (phone, lunch, fair, camp, assembly, conference, party, pub, etc), one should be able to get some word/half-baked information out, e.g. if they are fond of the suggestion in principle, and if they could ballpark what the odds are that the feature gets implemented at all.

@Peter Maybe you get a chance to produce the desired bit of information after all … , thanks in advance for your help re this matter. As you could imagine, I would be elated to hear something like "raspi, in favor of just you, I did manage to get a word … and they believe the odds are only 20% that your nice idea gets implemented within the next 5 years, meaning that it's definitely not off the table, it actually made it on the to-do-list schedule (congrats raspi!), flagged with the lowest priority imaginable. So it'll come, but you shouldn't hold your breath since nobody knows what the world, or the team/company for that matter, will look like in 5 years."

Thanks for thanking, the prospect (let me have some hopes up for this proposed new feature - your team might decide against it eventually, haha) and your attention @Peter, @Arnoud, @Karl, appreciated ymmd!

Crossing fingers, I would really enjoy and profit from such a feature in the GUI of Mathematica! And not only me, I am sure ::))

I will use your linked Product Feedback Form in future, too. Good to know, thank you.

Hi Raspi,

not really what you want, but here is at least a simple function for examining expressions:

Attributes[makeObvious] = HoldAll;
(* makeObvious[expr_]:=Framed//@HoldForm[expr] *)
makeObvious[expr_] := Map[Framed, HoldForm[expr], {2, Depth[expr] - 1}]

With this we get e.g.:

Hi Hans, thanks for participating in the discussion. I am fully aware of that functionality: we can leap around with the mouse pointer and then click around (or use your keyboard shortcut) to get an idea of 'the next bigger balanced compound expression'. Even in your example there's quite some clicking (and memorization) involved and once the selection is gone, the information/clarity about the grouping is lost.

My ultrashort algebraic example wasn't a good example anyway. Better examples involve a combination of pure functions, patterns, Boolean operators, conditionals, summation/integration symbols, rules, and alike; there we learn that we must place parentheses! Usually for conciseness and elegance we do not write down superfluous parentheses or we simply forget to write them, when they're needed. Seeing parentheses, even if they are indeed superfluous, can help intelligibility and provides unambiguousness to the reader.

So, your "Ctrl + ." comes first, yes, and for some users/uses it might be enough. It selects a balanced expression and the selection expands to compound expressions depending on the position of the mouse pointer (poor mouse pointer placement shown hehe):

Then my "Show Groupings" comes next, it makes all (or all relevant) groupings within that pre-selected compound expression readily visible to any reader, not just to the person with the keyboard/mouse ;-)

Mind you, on a print-out (paper, book, screenshot) one cannot click around anymore. In such a case, unambiguous code like a+((b/c)*(d^e)) proves to be a good alternative to the reader/debugging user. In summary, "your" and "my" features go well together/belong together/complement each other, yes, but in terms of practical usage they are different enough.

Yes Sir ! Loving it . That's a primitive yet still good example , thank you . A more involved "input" for the new menu item to process would be:

NestWhile[
  Join @@ Table[
     Table[ReplacePart[s, #1 -> n], {n, #2}] & @@ 
      First@SortBy[{#, 
           Complement[Range@9, s[[First@#]], s[[;; , Last@#]], 
            Catenate@
             Extract[Partition[s, {3, 3}], Quotient[#, 3, -2]]]} & /@ 
         Position[s, 0, {2}], 
        Length@Last@# &], {s, #}] &, {sudoku}, ! FreeQ[#, 0] &]

That is a nesting of five pure functions. The most basic (and trivial) example would be an algebraic code line:

a + b / c * d ^ e

Selecting this code snippet with my mouse, then right-click context menu item "Show Grouping" should transform/expand the selected code snippet in situ ("in-line") to:

a + ((b / c) * (d ^ e)) (*smart transformation*)
(a + ((b / c) * (d ^ e))) (*brute silly transformation*)

Thus making the code snippet more intelligible and debuggable to the reader, if the code is hard to review or doesn't deliver the desired output. Using FullForm[] for understanding in-line code or for debugging purposes is not always the way to go, imho.

A basic implementation to parenthesize a selection would be as follows:

b1 = Button["Parenthesize selection", Module[{x},
  x = CurrentValue["SelectionData"];
  NotebookWrite[ButtonNotebook[], RowBox[{"(", x, ")"}]]]]

And this is the inverse (assumes the selection includes the parentheses):

b2 = Button["Unparenthesize selection", Module[{x},
  x = CurrentValue["SelectionData"];
  NotebookWrite[ButtonNotebook[], Part[x, 1, 2]]]]

You can add these buttons to a docked cell to make available for all notebooks:

SetOptions[$FrontEndSession, 
 DockedCells -> {Cell[BoxData[ToBoxes@Row[{b1, b2}]]]}]

Change \ $FrontEndSession to \$FrontEnd to have it persist between restarts of the frontend.

Change things back with:

SetOptions[$FrontEndSession, DockedCells -> {}]

DISCLAIMER: This is just a simple prototype I wrote for you to experiment with. Implementing something like this that is production-grade is quite complicated because it needs to support large amount of edge cases (which this does not do). I won't be able to make improvements upon this, but you are welcome to (and anyone reading this is welcome to). This is not functionality I would use myself, because I prefer to write Wolfram Language code that is human readable in the first place (by limiting the amount of syntactic shortcuts).