Description: --> don' change into a arrow because first replace into a – (not a -) --- don't change into a border because first replace into a — (alt+0151) :<<: don't change into a ≪ because first replace into a « (conflict with https://bugs.documentfoundation.org/show_bug.cgi?id=133524) :>>: dont' change into a ≫ because first replace into a » (conflict with https://bugs.documentfoundation.org/show_bug.cgi?id=133524) Steps to Reproduce: Write into Writer some Autocorrect combination Actual Results: --> change into –> --- change into — (alt+0151) === change into a ≡ :<<: change into :«: :>>: change into :»: Expected Results: --> change into → --- change into a border margin to margin === change into a border with double line. :<<: change into « :>>: change into » Reproducible: Always User Profile Reset: No Additional Info: I propose: Change the combination or delete the autocorrect combination for -->, --- and ===. For :<<: and :>>: can be deleted because in this version the correction is automatic y es innecesaria. Likewise, this is at the discretion of the developers.
You can easily customize autocorrect with Tools => AutoCorrect => AutoCorrect Options Does this solve your problem? => NEEDINFO
I return the question: Is it a solution for you? Is it really the solution that gives LibreOffice to a PROBLEM? I mean, every time I install LibO I'm going to have to replace the malfunctions. I take this answer as an EXCUSE not as a SOLUTION. I'm not asking you to solve it TO ME: solve a problem that leaves LibreOffice as a poor quality product. I really take your answer as a hand wash and that you are not interested in making a good product, but in getting a case out of it quickly and easily. Actually, as technical support they leave a lot to be desired. As I said in another report with a similar answer: I have been using LibO since practically its release. But the answer that and the poor quality and very low competitiveness with other products led me to stop giving monetary support and today just use Writer. But I'm getting closer to stop using it for good and to start using MS Office again.
Let me first say clear: I'm working as a volunteer. I try to be friendly and I expect others to behave the same. So I will onswer once to an unfriendly comment, but not again. Your bug report wasn't clear to me. I cant finde the following AutoCorrect Options: === --- That was the reason why I asked, if it works, if you customize them. You haven't answered to that question. I can confirm that the other autocorrect settings doesn't work: --> changes into –> instead of → :<<: changes into :«:instead of ≪ :>>: changes into :»:instead of ≫
With respect to these changes: === --- They are not as part of the auto-correction as in the form in the dialog box but as part of the help itself where they indicate that typing three equal signs (===) is replaced with a double line margin paragraph border and three minus signs (or hyphens, ---) is replaced with a single line. Instead, === is replaced by ≡ and --- by a long line or hyphen, depending on the language (usually inserted with ALT+0151 [there may be another ASCII combination, but it is the one I learned to use]). And, sorry if I was rude but if you do 20 reports and in the 20 always try to fill a gap instead of repairing a damage, you get tired: meeting a wall every time you try to help is frightening and discouraging (which led me to remove my support to Wikipedia both financially and as a proofreader because I was accused of vandalism for correcting grammar or creating articles that a person, unilaterally, considered irrelevant). And the last thing, which already got me out of my head, was that in response they marked my report as a duplicate of a report from the year 2015? Plus five years to solve nothing! I volunteer at a lot of things too, and more so now in the pandemic. But my answers are never "you can do this other thing" as a solution. When you do customer service, you can't answer "we can't do what you ask"; the answer must always be "let me see what I can do" (even if it's false and you know that ultimately nothing can be done). A NO at first gives the impression that they haven't even taken the trouble to try (I'm not saying in this case, but in general). If I have offended you, I apologize. Please also understand that my language is not English but Spanish and I must use Google or DeepL to translate and believe me that this will most likely not be an optimal result in the translation.
Created attachment 164023 [details] Autocorrection opcion to replace ===, ---, *** etc In refer to correction of === or --- into a line, I refer the help online. https://help.libreoffice.org/7.0/en-US/text/shared/guide/line_intext.html Automatic lines in Writer Now I try and enyone works. Looking to set up the auto-correction options, I found that in order for ===, ***, etc. to work, an option must be enabled in the auto-correction options (it is disabled by default): So you can skip that bug because it's not really a bug. The rest of it is.
(In reply to Leandro Martín Drudi from comment #0) > :<<: change into :«: > :>>: change into :»: > > Expected Results: > :<<: change into « > :>>: change into » > I propose: > For :<<: and :>>: can be deleted because in this version the correction is > automatic y es innecesaria. > Likewise, this is at the discretion of the developers. Hola Leandro. This is a tricky case. As you correctly note, there can be an automatic conversion of << and >> (but, as explained in the help page, this is only for certain languages, and only if the Localized Option is enabled). For example, If the document is Spanish -- and you want to be able to write :<<: and have it to be converted, then it is necessary to do the following: 1. Open the Localized Options (Opiciones regionales) tab in Autocorrect (Tools > AutoCorrect > AutoCorrect Options - Localized Options). 2. Uncheck "Replace << and >> with angle quotes. "Reemplazar << y >> por comillas angulares 3. Switch to Options tab, make sure that "Replace table" is checked for [T] ([E] en Español) 4. Now you can use :<<: and :>>: and get ≪ ≫ (without a problem) I would not say there is a "bug" here. There are two different possibilities for working, where it is necessary (in this particular case) to know about the Localized Option. Both techniques work. If you know that the "automatic" conversion is turned on in Localized Options, then probably you will never use :>>: Or -- if for some reason -- you wanted to write :>>: then you would turn off the Localized option. Meanwhile -- if you open a document that is en-US. You will see that even though the Localized Option is checked, then >> and << will not be converted. It is necessary (and possible) to use: :<<: and :>>: I hope this clarifies the situation with >> and <<
So -- maybe there is only one problem remaining in this ticket? The case of: --> When I have "AutoCorrect While Typing" enabled, and have the "Use replacement table" AutoCorrect option enabled, and I enter: --> into a document, then I get → (that is, the actual = expected, when I use: Version: 6.3.6.2 (x64) Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: da-DK (en_DK); UI-Language: en-US Calc: threaded but when I do the same procedure with: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 86c8c775bbefe333d684e12c99855a3c1de68051 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_DK); UI: en-US Calc: threaded then the two dashes are converted to an en-dash so that it ends as: –> For fun, I deleted the first entry in the Replace tab (which is: -- (hyphen hyphen) - (en-dash) then --> was converted to → 6.3.6.2. also has -- (hyphen hyphen) - (en-dash) as its first entry -- and it works as expected (without having to delete that first entry as I did in 7.2.0.0.) So this suggests that there is a regression. If I understand correctly, Leandro had this problem already with 7.0.0.0.alpha0+ so it should be possible to bibisect.
<-- is autocorrected correctly to ← in 7.2.0.0.alpha0+ (even after I put back -- corrected to en-dash)
I speak from a user's point of view, totally unaware of how it works and/or how they work: Is it possible to automatically delete the replace entry when activating "Replace << and >> with angle quotes." and recreate the entry when deactivating? I mean, by code for the languages where it creates conflict. Just a question. And if it is possible to do so, as a suggestion.
(In reply to Leandro Martín Drudi from comment #9) > Is it possible to automatically delete the replace entry when activating > "Replace << and >> with angle quotes." and recreate the entry when > deactivating? I mean, by code for the languages where it creates conflict. > Just a question. And if it is possible to do so, as a suggestion. This could, in principle, be achieved. But the more important first question is: What "problem" (in using the software) are you are trying to solve here? (it is easier to evaluate "solutions" when the problem is clear.)
(In reply to sdc.blanco from comment #10) > (In reply to Leandro Martín Drudi from comment #9) > > Is it possible to automatically delete the replace entry when activating > > "Replace << and >> with angle quotes." and recreate the entry when > > deactivating? I mean, by code for the languages where it creates conflict. > > Just a question. And if it is possible to do so, as a suggestion. > This could, in principle, be achieved. But the more important first > question is: What "problem" (in using the software) are you are trying to > solve here? (it is easier to evaluate "solutions" when the problem is > clear.) The problem is for the average User, who barely understands how things work and that this would create a problem that would lead them to stop using LibreOffice, and I'm at the top of that list. Many of the people I recommended LibreOffice to stopped using it because of these problems because they did not understand and considered it a low-quality product where simple things were too complicated and solutions should not come from user actions but solved at source. If we think about it from a developer or advanced or expert user point of view, only a small group of people will stay with LibreOffice. Translated with www.DeepL.com/Translator (free version). Sorry, I speack spanish only.
(In reply to Leandro Martín Drudi from comment #11) Thanks for the explanation. You understand that this Bugzilla system is mostly to address specific problems with the software. If you want, you could make a enhancement request, where you make the suggestion that you gave in comment 9. That is, open a new bug report, and there is a label called Severity, that has the word "enhancement" in the drop-down box. Explain the confusion that arose with the >> -- it is possible that someone will be able to say a way to make an improvement to avoid this problem. But it is also possible that someone will say that this is explained in the documentation, for example: https://help.libreoffice.org/7.2/es/text/shared/01/06040400.html https://help.libreoffice.org/7.2/es/text/swriter/01/05150000.html and that an average user should also be willing to try to read a little. After all, it is also possible to turn off AutoCorrect completely. I am also an average user, not a developer. Sometimes it is just necessary to make some experiments and then try to find some help documentation. That is what I did in this case. I am not trying to persuade you of anything, just trying to show the possibilities where it might be possible to do something in relation to the concrete problem with <<.
-> is replaced with → (with "Use replacement table" enabled in AutoCorrect Options and "While Typing" enabled in Tools > AutoCorrect) tested with: Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: da-DK (en_DK); UI: en-US Calc: threaded and Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 62ee3d791d63cb693109b063b73dff5e81356d90 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_DK); UI: en-US Calc: threaded Additional information: 1. Did not matter what "language" was set for input. 2. Does not work if "Use replacement table" is disabled in AutoCorrect Options 3. -> does not appear in replacement table in Replace (afaict) 4. deleted --> from Replace table, but -> still works. Why does -> get converted to → even though it does not appear in the table in Replace tab, but "Use replacement table" and "While Typing" has to be enabled for it to work? cc: Mike Kaganski
Created attachment 169705 [details] -> to arrow replacement entry (In reply to sdc.blanco from comment #13) See https://help.libreoffice.org/7.1/en-US/text/shared/01/06040200.html#bm_id1574449 for description of the .*
(In reply to Mike Kaganski from comment #14) > https://help.libreoffice.org/7.1/en-US/text/shared/01/06040200. > html#bm_id1574449 for description of the .* Just to be sure that I understand this correctly (because the paragraph is hard to read; needs some grammatical improvements.). Because there is a .*->.* in the replace table (much farther down, after the : : entries), then -> gets replaced automatically. (so now I understand why -> was replaced. And thanks for the helpful screenshot.) And I can see the "advantage" with that pattern because arrows can be inserted in a string without spaces, so I can type: H2+02->H20 and the -> is automatically converted to → even though there were no spaces in what I entered. (it works. I tried it.) (And thanks for the help pointer! Interesting possibilities with that feature.) But then in relation to this bug report, maybe there is a regression -- see comment 7. In 6.3.6.2 --> replaced to → (as it should according to the replace table) but in 7.1.0.3 and 7.2.0.0.alpha0+ and maybe as early as 7.0.0.0.alpha0+, --> was converted to –> (en-dash greater-than) That seems wrong -- or is there another help page that we should be reading? (-:
(In reply to sdc.blanco from comment #15) > Just to be sure that I understand this correctly Yes you do :-) > But then in relation to this bug report, maybe there is a regression -- see > comment 7. > > In 6.3.6.2 --> replaced to → (as it should according to the replace table) > but in 7.1.0.3 and 7.2.0.0.alpha0+ and maybe as early as 7.0.0.0.alpha0+, > --> was converted to –> (en-dash greater-than) > > That seems wrong -- or is there another help page that we should be reading? > (-: Indeed it is a regression. It seems it treats non-alphanumeric character as "space" now. A bibisect is needed.
(In reply to sdc.blanco from comment #6) > (In reply to Leandro Martín Drudi from comment #0) > > :<<: change into :«: > > :>>: change into :»: > > > > Expected Results: > > :<<: change into « > > :>>: change into » > ... > > As you correctly note, there can be an automatic conversion of << and >> > > (but, as explained in the help page, this is only for certain languages, and > only if the Localized Option is enabled). This just needs one of two things. 1. For languages where automatic conversion to/from <</>> exist, remove the :<<: and :>>: from autoreplacement table (which is language-specific, as you know). or 2. Perform autoreplacement before other types of automatic corrections. This is similar to tdf#132300, where currently non-breaking space is added according to the language rules in front of : *before* the replacement table has a chance.
(In reply to sdc.blanco from comment #12) > (In reply to Leandro Martín Drudi from comment #11) > Thanks for the explanation. You understand that this Bugzilla system is > mostly to address specific problems with the software. If you want, you > could make a enhancement request, where you make the suggestion that you > gave in comment 9. That is, open a new bug report, and there is a label > called Severity, that has the word "enhancement" in the drop-down box. > Explain the confusion that arose with the >> -- it is possible that someone > will be able to say a way to make an improvement to avoid this problem. > > But it is also possible that someone will say that this is explained in the > documentation, for example: > https://help.libreoffice.org/7.2/es/text/shared/01/06040400.html > https://help.libreoffice.org/7.2/es/text/swriter/01/05150000.html > > and that an average user should also be willing to try to read a little. > After all, it is also possible to turn off AutoCorrect completely. > > I am also an average user, not a developer. Sometimes it is just necessary > to make some experiments and then try to find some help documentation. That > is what I did in this case. I am not trying to persuade you of anything, > just trying to show the possibilities where it might be possible to do > something in relation to the concrete problem with <<. You refer me to the help and believe me (I hope not to offend susceptibilities with what I am going to say) but the help has only the name: it is half translated, many things are outdated years ago, they give indications using third things without instructing how to access them (for example: it says "Insert an invisible space" but not how to insert it or a link to where it teaches how to do it). The common user does not have the knowledge to do everything that these answers propose because they barely understand. I regret that this software is self-condemning for not listening to the users but only to the egos of the programmers. They are repeating the history of Linux where only a select group of experts has access and the common user ends up using Windows because it does everything alone. Either they simplify things to the end user or they will lose many new potential users. I have been using LibreOffice for at least 12 years (I used OpenOffice before) and I could never convince anyone to use it because of its archaic interface and how difficult it is to do simple things like using an autocorrect and have it work. In the company where I work they never accepted to use LibreOffice because it never ends up working well: always something vital fails, but they solve it in the next update and in that one another vital thing breaks. And the worst thing is that the solutions take too long and the loss of productivity is noticeable. They should devote a whole full release to polish the code, fix all or most of the bugs and then start adding. Otherwise it will never be "ready". At the end of the day it seems like LibreOffice never got out of Beta. Translated with www.DeepL.com/Translator (free version)
This seems to have begun at the below commit. Adding Cc: to László Németh ; Could you possibly take a look at this one? Thanks linux-64-7.1$ 9eef37502e2a0de4eda3958eb11ca35a80c7211c is the first bad commit commit 9eef37502e2a0de4eda3958eb11ca35a80c7211c Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Jun 2 04:00:58 2020 +0200 source 57f07b1d7378d218648667c5b1315cc8ad905875 commit 57f07b1d7378d218648667c5b1315cc8ad905875 [log] author László Németh <nemeth@numbertext.org> Thu May 28 08:50:39 2020 +0200 committer László Németh <nemeth@numbertext.org> Sun May 31 23:13:23 2020 +0200 tree 5637c6bb18c61d960c1d1771a1f7d887649d8ba2 parent c87c7ddca46ae093a703ca673a204e4593402c38 [diff] tdf#133524 AutoCorrect: support double angle quotes
@All: thanks for reporting this issue. I'm going to fix it soon.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d1be3d80d0ca5ccd7639ede379a1befc48dc73f2 tdf#134940 sw: fix AutoCorrect of arrow "-->" It will be available in 7.2.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.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/8885bf8f8665286ae1df30d987790e5680f2bb36 tdf#134940 sw: fix AutoCorrect of arrow "-->" It will be available in 7.1.2. 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.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/472e2e08480d04ac9cc1c9ddcb5862bc2f1d8660 tdf#134940 sw: fix AutoCorrect of arrow "-->" It will be available in 7.0.6. 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.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0-5": https://git.libreoffice.org/core/commit/7ebf168e0ddc3fd95b1dcdbc760113b140527fe3 tdf#134940 sw: fix AutoCorrect of arrow "-->" It will be available in 7.0.5. 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.
*** Bug 140906 has been marked as a duplicate of this bug. ***