Let's ask the UX team's opinion on this feature.

Enclose in brackets (round / curly / square) sounds like a nice enhancement but I wonder if the average Writer user needs this function. The recommended toolbar button means to add a UNO command (which would be accessible via API/macro) meaning some maintenance, and it takes space which is detrimental for usability. But what I could imagine is an autocorrect function that, when activated, adds a bracket before and after the selected text when (,{,[ is pressed.

The topic was on the agenda of the design meeting but didn't receive further
input. 

I believe it would be a valuable enhancement and should be added as autocorrect function. Pressing one bracket (), [], and {} adds it at both the beginning and the end of the selected text (and insert a single character if nothing is selected). It might be confusing that overwriting is not possible and the option should therefore be off by default.

Or maybe make typing some combination of bracket key and modifier, like Ctrl-(, insert the surrounding brackets around the current selection?

We are short on shortcuts. And in case of the German keyboard you need Shift for the round brackets and AltGr for the curly and square bracket. Nevertheless, a UNO command would provide customization and is an alternative. Drawback is, at least, that we later cannot easily remove the UNO command.

I just today discovered that macros can be assigned shortcuts :-)
 
Menu > Tools > Customize > Keyboard
Category -> Application Macros

FWIW here is a Basic macro that will place () around selected text.
Disclaimer: I'm no basic macro expert so YMMV.

Sub Parenthesize
  Dim oCurrentSelection as Object
  oCurrentSelection = thisComponent.getCurrentSelection()
  if oCurrentSelection.supportsService("com.sun.star.text.TextRanges") then
    nCount = oCurrentSelection.Count
    if nCount = 1 then
      oTextRange = oCurrentSelection.getByIndex(0)
      oTextRange.String = "(" + oTextRange.String + ")"
    else
      for i = 1 to nCount - 1
        oTextRange = oCurrentSelection.getByIndex(i)
        oTextRange.String = "(" + oTextRange.String + ")"
      next
    end if
  end if
End Sub

Macro's can also be assigned to menu and toolbars. Surprise surprise. Seriously I didn't know that until today. Way cool!

But perhaps this is an enhancement that is worthy of it's own UNO. IMHO it would make an interesting beginners hack. I can supply code pointers if needed.

(In reply to Jim Raykowski from comment #7)
> But perhaps this is an enhancement that is worthy of it's own UNO. IMHO it
> would make an interesting beginners hack. I can supply code pointers if
> needed.

Good idea, please do so.

(In reply to Jim Raykowski from comment #7)

> I can supply code pointers if needed.
Hi Jim. Could you please share the code pointers?
Thanks.

An article that illustrates how to add an UNO command for Calc[1]

Examples of two UNO commands added to Writer[2]

officecfg/registry/schema/org/openoffice/Office/UI/Commands.xcs contains information on properties used in the .xcu file. There is also information about commands here[3].

Decide on a name for the command. It probably should be generic to allow other than enclosing selected text with parenthesis. Perhaps something like .uno:EncloseText or .uno:SurroundText.

Loop through the cursor ring[3] to get each cursor selection PaM[4] and text. Create an enclosed string by placing the selection text between open and close parenthesis, adding optional enclosures is an advanced hack that can be done for bonus points after implementing the parens request :-), then use the IDocumentContentOperations::ReplaceRange function[5] to replace the text at the PaM with the created enclosure string.  

[1] https://dev.blog.documentfoundation.org/2022/02/23/adding-a-new-uno-command/
[2] https://gerrit.libreoffice.org/c/core/+/91605
[3] for (SwPaM& rPaM : SwWrtShell::GetCursor()->GetRingContainer())
[4] sw/inc/pam.hxx
[5] sw/source/core/view/viewsh.cxx SwViewShell::getIDocumentContentOperations() 
    hint: SwWrtShell is derived from SwViewShell

The first [3] reference in my previous post

[3] https://design.blog.documentfoundation.org/2018/02/28/easyhacking-all-about-terminology/

Thanks for the code pointers. Assigning to myself...

Bayram: are you aware this is in the GSoC ideas page https://wiki.documentfoundation.org/Development/GSoC/Ideas#Quickly_insert_brackets ? GSoC applicants are asking why you assigned this to yourself.

(In reply to Buovjaga from comment #13)
> Bayram: are you aware this is in the GSoC ideas page
> https://wiki.documentfoundation.org/Development/GSoC/
> Ideas#Quickly_insert_brackets ? GSoC applicants are asking why you assigned
> this to yourself.

You are right. unassigning. apologize for that.

It is a bad idea for LibreOffice to have this feature. That is, it's not just not-useful, it is detrimental for the application for it to exist. I will explain why that is the case, and then request that this bug be closed as NOTABUG.

First, let us note that that no Office suite (AFAICT) has such a button, or command. Also, no text editor (that I know of) has such a command. I am also not aware of IDEs which have such a command. Why do you think that is, even in applications that are focused entirely on text rather than on styling, formatting, tables, frames, pages etc.?

One reason is that this is text-entry functionality. And in text editors, we use the keyboard to enter text. If you look at the Writer toolbars, you'll not find a single button whose function is to enter text (with the exception of 'Special Character', which is for what you can't type in). We do not want to encourage users to click buttons instead of typing text.

Now, it's true that it involvements entering text at two points, but it's still just entering two characters. The effort of selecting the text, then pressing this button or shortcut, is roughly the same as reaching its beginning, adding the '(', navigating to the end and adding the ')'. Even if you have the text pre-selected somehow, the workflow is: cut the selection, enter '(', paste, enter ')'. Faster than picking up the mouse, finding a toolbar button, pressing the button and letting go of the mouse.

Also note, that once we have a parentheses-enclosing command, we would be hard-pressed to reject a curly-brackets-enclosing command. And other kinds of brackets. And a command for applying double quotation marks. And single quotation marks. And the list will go on. Let us not start down this path.

A second reason - and perhaps an even more important one - is that encourages grammatical overuse and misuse of parentheses. 

The Modern Language Association says [1]:

> As strong punctuation marks, parentheses tend to slow down the
> experience of reading prose. They also momentarily take the 
> reader outside the main point and grammatical coherence of the
> sentence. For these reasons, a text that relies heavily on 
> parentheses can feel like a path filled with distractions that
> shift the reader off course.

we do not want to encourage the use of parentheses! 

Also, parentheses enclosing a larger piece of text - a multi-line sentence or so - are a problem regardless of frequently. It's like someone talking to you who suddenly start a different conversation, without any warning they've gone off on a tangent. And by the time they're done - you've half-forgotten you were talking about something else! Instead, in a conversation, the person should make the effort to connect the sentence narratively; or just give up on the long side-sentence or move it elsewhere. in a Writer document, a footnote, or comment, or a floating text box may also be appropriate alternatives.


So, to recap - for the benefit of all involved - let's reject this enhancement request.


[1] : https://style.mla.org/how-to-use-parentheses/

(fixing up my comment above)

(In reply to Eyal Rozenberg from comment #15)
> It is a bad idea for LibreOffice to have this feature. That is, it's not
> just not-useful, it is detrimental for the application for it to exist. I
> will explain why that is the case, and then request that this bug be closed
> as NOTABUG.

If people agree with your point, it should be "won't fix" rather than "not a bug".

> First, let us note that that no Office suite (AFAICT) has such a button, or
> command. Also, no text editor (that I know of) has such a command. I am also
> not aware of IDEs which have such a command. Why do you think that is, even
> in applications that are focused entirely on text rather than on styling,
> formatting, tables, frames, pages etc.?

RStudio has the default setting of enclosing selected text with the pressed enclosing character key, at least for parentheses, square brackets, curly braces and quotes. I am sure others have that too.

> One reason is that this is text-entry functionality. And in text editors, we
> use the keyboard to enter text. If you look at the Writer toolbars, you'll
> not find a single button whose function is to enter text (with the exception
> of 'Special Character', which is for what you can't type in). We do not want
> to encourage users to click buttons instead of typing text.

We do have various commands that replace characters or enter extra characters into a text document: case-changing commands, autocorrect, autotext, spellcheck...

> Now, it's true that it involvements entering text at two points, but it's
> still just entering two characters. The effort of selecting the text, then
> pressing this button or shortcut, is roughly the same as reaching its
> beginning, adding the '(', navigating to the end and adding the ')'. Even if
> you have the text pre-selected somehow, the workflow is: cut the selection,
> enter '(', paste, enter ')'. Faster than picking up the mouse, finding a
> toolbar button, pressing the button and letting go of the mouse.

My opinion would be to not have a button by default for this feature, but instead have a setting that can be turned off or on to "automatically enclose selected text with (brackets|braces|parentheses|quotes)".
This is the refocus recommended by Heiko after it was on the UX agenda, in comment 3, and I think the summary should be changed accordingly.
 
> Also note, that once we have a parentheses-enclosing command, we would be
> hard-pressed to reject a curly-brackets-enclosing command. And other kinds
> of brackets. And a command for applying double quotation marks. And single
> quotation marks. And the list will go on. Let us not start down this path.

This is a slippery slope argument, I don't think it's fair.

> A second reason - and perhaps an even more important one - is that
> encourages grammatical overuse and misuse of parentheses. [...]
> we do not want to encourage the use of parentheses! 

> Also, parentheses enclosing a larger piece of text - a multi-line sentence
> or so - are a problem regardless of frequently. It's like someone talking to
> you who suddenly start a different conversation, without any warning they've
> gone off on a tangent. [...]

I believe this is subjective and reductive of the variety of writing styles that exist. I have read books in which authors make use of ellipsis of that kind very frequently. It might not be your preferred style, but I don't think it's our role to influence that.

So to recap my opinion:

this project should refocus on the _optional_ option to have enclosing characters like parentheses, brackets, braces and quotes be added automatically at beginning and end of a selection when one of those character keys is pressed + there is a text selection.

First patch provides an option at tools > autocorrect and if checked, pressing (,{,[," on a selection adds the corresponding closing character. So far it works nicely as known from IDEs but is actually not an autocorrection.

How about moving the function to tools > autocorrect > word completion (same dialog) or tools > options > writer > formatting aids > auto completion (new frame in options dialog)? My preference is the second, and I would enable it by default.

(In reply to Heiko Tietze from comment #18)
> First patch provides an option at tools > autocorrect and if checked,
> pressing (,{,[," on a selection adds the corresponding closing character. So
> far it works nicely as known from IDEs but is actually not an autocorrection.
> 
> How about moving the function to tools > autocorrect > word completion (same
> dialog) or tools > options > writer > formatting aids > auto completion (new
> frame in options dialog)? My preference is the second, and I would enable it
> by default.

First patch also contains a UNO command as initially suggested in the previous comments. Personally, I don‘t think this command adds any value when considering the remaining patch, there is no need to have this customizable alternative way of achieving the same thing in this case. I‘m voting for removing it altogether.

Yiğit Akçay committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a7dd2e5a4712083cc5934e1d677e7dff86ceb7e6

tdf#151710 Enable enclosing of selected text with characters

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.