Hello, I've been using LibreOffice for about an hour now. I'm just trying to enter some data in Calc. I was able to Google some useful keyboard shortcuts and things are pretty cool. I figured out how to move rows around and stuff. However, when I enter "@" in a field, like "40V, 200mA, h=100@1V,10mA" then Calc goes nutty. It won't let me edit the word containing the "@", I see a gray rectangle containing the text "h=100@1V,10mA". I click on it and it selects the whole thing, I use the arrows and it skips over the rectangle. Sometimes after clicking around on other cells or something, then I can get Calc to let me edit the text in question, but then it seems kind of buggy - it forgets my edits, or when I edit the text after the rectangle, it comes out garbled. Maybe I've entered something atypical but it's weird that I would start using a piece of software and get stuck so quickly. No help from Google "libreoffice calc at sign". No help from F1 (searched for @ and "at"). No help from "Help > What's this?" and clicking on gray rectangle. I just want your software to stop trying to be so smart! I finally got help from user "Marqeaux" on IRC, but ... Can you think of some ways to remove this stumbling block for future new users? Thank you, Frederick Eaton
Hi @Frederick, there is an option. Menu/Tools/Autocorrect options/Options - URL recognition. disable it. Resolved as not a bug, please if you are not agree, reopen it.
Created attachment 125271 [details] Screenshot displaying issues 4-5 in comment 2 I think Frederick's issue wasn't that he personally couldn't get around the URL-ification, but that if someone wants to do that, they'll be at a loss how to do it, as he was initially. URL being uneditable is a known bug, and is reported in bug 75889. 1. "What's This?" not offering any help is a bug in my opinion. 2. Other ways of getting relevant help: while "at" is a very generic term, "link" or "hyperlink" should return something relevant in the help (hovering over the "URL" displays a tooltip that it's treated as a link). Some weird behaviors: 3. If the text is typed with a space after the comma after the link (so: "40V, 200mA, h=100@1V, 10mA"), weirdly, right-clicking the text in the Input line above the sheet permanently removes the URL (sometimes this can be reproduced if there's no space there, but it's not that consistent). 4. Sometimes the link is displayed as a link in the Input line (if it's typed in there, for example), but if you move between cells and come back, it will show as normal text (still in Input line). Particularly if you move with cursors, it'll stay as a link, if you select the cell with mouse, it'll be normal text. 5. When it's not displayed as a link in the Input line, and part of the text/link is selected, the selection shown in the cell won't be the same. 6. Using autocomplete to finish the entry based on a previous one does not create links. All observed in LO 5.1.3.2 / Windows 7. These are a lot of items for a single bug report, but I didn't want to open several reports, yet, plus I think 1-2 and 3-6 are closely related.
Thank you Aron. I appreciate that you correctly understood my bug report, and I also want to thank you for documenting the other buggy behavior related to URLs. I took Miguel's advice on disabling URL recognition (the person I asked on IRC only knew how to remove formatting on a cell-by-cell basis - right click, "Clear Direct Formatting"). But it sounds like this feature is broken enough that it should be disabled by default until it can be fixed. That's my opinion as an outsider. I was not surprised by Miguel's reply, but I was pleasantly surprised by Aron's - it's been a while since I submitted a bug like this to a project, and not had to explain twice or three or four times that I'm not just using Bugzilla to ask a "how do I do X" type question.
Thanks Frederick. I appreciate you're looking at the issue you're facing from a general user perspective. The reality is that a lot of people come here looking for immediate help with their issues, so providing a workaround is also very important (if there's one), and I'm glad Miguel could give you one suitable on the longer term (I didn't know about that setting, by the way). The more diverse the contributors are, the better the result will be in the end. The feature's been there since OOo times btw, I think disabling it now would cause confusion, but it certainly has bugs that need fixing.
*** This bug has been marked as a duplicate of bug 98154 ***
> *** This bug has been marked as a duplicate of bug 98154 *** Just wanted to understand what's happening - can someone explain the connection between this bug, and bug 98154?
Having not heard back from Eike Rathke (please be more responsive?), I'm trying to reopen this bug.
Frederick: Eike is one of the Calc lead developers. I assume bug 98154 is the root cause of this. Reclosing. *** This bug has been marked as a duplicate of bug 98154 ***
If Eike is a lead developer then he is probably a good person to explain the connection between the two bugs. Reading them again, it seems pretty bizarre to mark this one as a duplicate. Did you read the bugs, Buovjaga, or are you just trying to annoy me? Really, if you want a good piece of software, you shouldn't try to make it so difficult for users to report problems.
(In reply to Frederick Eaton from comment #9) > If Eike is a lead developer then he is probably a good person to explain the > connection between the two bugs. > > Reading them again, it seems pretty bizarre to mark this one as a duplicate. > > Did you read the bugs, Buovjaga, or are you just trying to annoy me? Really, > if you want a good piece of software, you shouldn't try to make it so > difficult for users to report problems. The connection is that your annoyance is caused by autocorrect. Bug 98154 proposes to split autocorrect settings of Writer and Calc for certain items. This URLification would be one of them. I don't understand why you talk to me like I was not a user like yourself. As if I'm working for some corporation. What was so difficult in reporting your problem? Nothing. There is no need to mess with the status while you ask your questions. You can always come on IRC, if you need to discuss things in more depth: https://wiki.documentfoundation.org/Website/IRC The points Áron made in comment 2 belong to separate reports anyways. *** This bug has been marked as a duplicate of bug 98154 ***
Buovjaga, what was difficult about reporting this is that people like yourself insist on replying without reading what I wrote. Aaron Budea was the only one. He replicated my experience and identified six issues that need to be fixed. His points are my points, if they are "separate", as you say, from bug 98154 and bug 75889 then that means this bug is not a duplicate. Last time I waited patiently for two weeks for a response from Eike before reopening the bug. Still nothing from Eike. So that's why I don't wait anymore. Reopening.
(In reply to Frederick Eaton from comment #6) > > *** This bug has been marked as a duplicate of bug 98154 *** > > Just wanted to understand what's happening - can someone explain the > connection between this bug, and bug 98154? Sure, functionally the dev and UX position is that Calc would benefit from defining auto correct options independently of Writer. Eike dupped this to the bug 98154 established for doing that "Some Autocorrect options should be treated separately in Calc" [1] With autocorrect configuration split, in Writer URL recognition will remain enabled, while in Calc URL recognition would probably be disabled by default. Eliminating your issue. Deficiencies in the F1 Help and documentation of the URL recognition of the @ syntax is a side bar--that needs annotation in [2] @Aron, probably should open a new issue for 1&2 against Documentation bug 80430 to revise text in the "Turning off Automatic URL recognition" [2], and post a new bug for your items 3-6. Otherwise agree with Miguel Ángel and Eike, and resolving DUP of 98154. =-ref-= [1] https://bugs.documentfoundation.org/show_bug.cgi?id=98154#c2 [2] http://opengrok.libreoffice.org/xref/help/source/text/shared/guide/autocorr_url.xhp *** This bug has been marked as a duplicate of bug 98154 ***
OK, Mr. Foote, thank you for the explanation. So you're closing my bug on the assumption that someone else is "probably" going to spend time opening a new version of it, because a different person kept marking it as a duplicate of a vaguely-related third bug whose resolution is "probably" going to eliminate some of the issues in Calc only? Well, you sound like you know what you're doing so I'll just let you take responsibility at this point. :)
I opened bug 103447 with issues 3-6 from comment 2. Not sure what to put exactly in a documentation-related report, so I haven't opened anything on that. Note that bug 98154 doesn't mention anywhere that URL recognition would be disabled by default. That might be worth clarifying. Also note that this bug report was partly about the documentation issue (in particular how it's difficult to find out what is going on), why it can't be kept for that purpose is beyond my understanding.
Thank you again Aron. > Also note that this bug report was partly about the documentation > issue (in particular how it's difficult to find out what is going > on) Going by the title, I'd say that this bug report was *mostly* about the documentation issue.
LOCALHELP: description of Autocorrect recognition of URL provides no details of string formats triggering the replacement filed as bug 103463
(In reply to Aron Budea from comment #14) > Also note that this bug report was partly about the documentation issue (in > particular how it's difficult to find out what is going on), why it can't be > kept for that purpose is beyond my understanding. Sure, it could have been on first pass through. But because it was already closed/reopenened/closed as a duplicate of bug 98154 --with way too much noise about what is clearly a duplicate--best to put it to rest here, and have a clean documentation issue for the autocorrect syntax of URLs proceed. Purely a QA editorial decision. Stuart
All right, thanks for opening the bug report on the help issue, Stuart.