Bug 46517 - Subscript/superscript shortcuts apply style to whole word instead of only characters written after use of shortcut
Summary: Subscript/superscript shortcuts apply style to whole word instead of only cha...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-23 05:23 UTC by daniel.schaaaf
Modified: 2014-11-06 21:15 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
document with Basic macos for correctly formatting to sub/superscipts (21.75 KB, application/vnd.oasis.opendocument.text)
2012-12-07 13:44 UTC, sasha.libreoffice
Details
The same script, but in extension (6.79 KB, application/vnd.openofficeorg.extension)
2013-02-25 10:31 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description daniel.schaaaf 2012-02-23 05:23:26 UTC
When the user edits a cell with content and wants to write something in subscript/superscript by using shortcuts (Ctrl+b or p), the whole word at the cursor position will be put in subscript/superscript if the cursor position was not at the end or beginning of that word.

Since the description of this bug is probably more confusing than anything else, I will give an example here:

Double-click a cell and write text "ab" and do not "exit" that cell. Move the cursor between "a" and "b" and press "Ctrl+b", followed by "c". The whole text "acb" will now be in subscript instead of just the newly typed character "c".

If the cursor is either before or after "ab", subscript will only be applied to newly entered characters.

You can take this even further:
Double-click on an empty cell, type text "ab" again, move the cursor in front of "a", type "c", press "Ctrl+b" and type d. Again, the whole text "cdab" will be in subscript instead of just the character "d".
Comment 1 sasha.libreoffice 2012-05-23 07:37:13 UTC
Thanks for bugreport
But why it is wrong? Writer behaves the same.
Developers needed additional information to determine, which variant of behaviour is more productive for user.
Comment 2 daniel.schaaaf 2012-05-23 13:04:47 UTC
Yes, Writer behaves the same and I changed "Product" to Libreoffice.

Now that you mention it I think it could actually be intentional behaviour. It's a quick way to have a whole word in subscript/superscript. On the other side, once you already have a word written somewhere, it would just be as easy to double-click the word and thereby mark it, before putting it into subscript/superscript. But that case never happened to me while I often stumble over an unintentional "subscript/superscript whole word + next word".

As said before, having a whole word in subscript/superscript can easily be done by marking that particular word with a double-clicking and pressing Ctrl+b/p. That seems more natural to me and not more work for people who like this function. On the other side it would make life easier for people like me (I have a lot of chemical formulas in my writing).

Hope this clarifies the issue.

PS: Let the user decide with an option ... make everything optional in an "Advanced" tab in the options dialog where geeks like me can go wild!
Comment 3 sasha.libreoffice 2012-05-23 22:08:08 UTC
General rule of LibreOffice is:
First write thing, then select it and formate. 
Therefore, if this behaviour will change, it will serious regression for many users.
IMHO it makes sense to use Basic scripts to automate formulas writing and formatting. In specific situations also helps Edit->Find&Replace (Writer only)
Comment 4 sasha.libreoffice 2012-05-23 22:10:55 UTC
If amount of different used formulas is small, then helps Edit->Auto text
Comment 5 daniel.schaaaf 2012-05-24 00:22:24 UTC
Oh my, I didn't know that there are rules! Hope the police won't arrest me for not following _your_ way of handling things ... </sarcasm>

I tried Autoformat, but there is no way to turn e.g. N2O into N<subscript>2</subscript>O. And I am not advanced enough to program some scripts to do the job.

Apart from that, in my opinion the cursor is where text is being inserted, _after_ the cursor. That's why I assumed that subscript/superscript should apply to everything _after_ the cursor position and not the whole word.
The current solution reminds me of a typical Microsoft product that behaves intelligently and anticipates what the user wants to do, before the user even knows. (more sarcasm in this sentence ;-)
And again, why not have an option for this behaviour and let the user choose what is best. This way LibreOffice would be for everyone and wouldn't force rules upon anyone!
Comment 6 sasha.libreoffice 2012-05-24 02:08:03 UTC
> I tried Autoformat, but there is no way to turn e.g. N2O
Strange. In my case it works. I assigned this formula to n2 name and when I type n2 and press F3, then n2 replaces to N2O where 2 in subscript.

> And again, why not have an option for this behaviour and let the user choose
> what is best.
Very good idea. Please, create separate Functionality Request bugreport for it.

IMHO changing font to subscript and again to normal font in each formula is not perfect. We should invent something what does it automatically, at least in most cases.

PS: And how about Edit->Find&Replace using Regular Expressions?
Comment 7 daniel.schaaaf 2012-05-31 01:40:56 UTC
> Strange. In my case it works. I assigned this formula to n2 name and when I
> type n2 and press F3, then n2 replaces to N2O where 2 in subscript.

Thanks for this tip! Unfortunately it only works in Writer documents. As so very often things work differently (or not at all) in other documents. In Calc the subscript replacement does not work. In Impress the marked text is not automatically put into the replacement field and pasting or entering anything there manually will be unformatted text.
I am filing a new bug report for that ... LibreOffice is _seriously_ fucked up! (sorry for strong language)

> PS: And how about Edit->Find&Replace using Regular Expressions?
This is what I am doing now but it is not optimal and such a replacement has to be verified for each and every occurrence to rule out mistakes.

I still consider this a bug because a command should not influence unmarked text before the cursor! If this is being done on purpose than it is still a bug. Doing things automatically to help the user is wrong, wrong, wrong! Microsoft is doing these "intelligent" things in their office package and it does more harm than it helps. It is wrong that users have to anticipate what software is going to do in different situations!
Comment 8 sasha.libreoffice 2012-05-31 02:54:24 UTC
Thanks for additional information. I hope it will help.

What about Impress: there is very unhandy to work with formulas. Sometime as workaround we can use this: write text with formulas in Writer, select and copy it, then in impress press Ctrl-Shift-V, select variant"LibreOffcie 3.5 text document". Then double click it and increase size (another bug). It works well with formulas as pictures, not works with Math formulas, because another bug, may be not filled yet.
Comment 9 daniel.schaaaf 2012-05-31 04:00:40 UTC
Sorry if I was not clear enough about my inquiry. This is really only about Subscript and superscript, not anything more complicated. With "chemical formulas" I meant having atom numbers in subscript and charge in superscript. There should not be a need for real formulas from the formula editor.

And, please, don't get me started on workarounds ;-)
I am used to doing things in really weird ways in LibreOffice (e.g. using text boxes in Impress instead of rectangle shapes because rounded corners are broken with these) but i would like to keep these "fixes" to a minimum.
I have the feeling that more and more things in LibreOffice do not get fixed at the root of a problem but on a higher level, causing more problems in the future and forcing the user to think around corners. (sorry for being off-topic here)
Comment 10 sasha.libreoffice 2012-05-31 04:33:18 UTC
> don't get me started on workarounds
Currently on this site are more then 5000 bugs about LibreOffice. Each week fixed 2 or even 3 bugs. We should wait until all bugs will fixed or use workarounds now.
Comment 11 daniel.schaaaf 2012-06-07 01:39:17 UTC
> Currently on this site are more then 5000 bugs about LibreOffice. Each week
> fixed 2 or even 3 bugs. We should wait until all bugs will fixed or use
> workarounds now.

Yeah, it's easy to forget about that! Sorry!
I just have the feeling sometimes that integration of new features is more important than fixing bugs. And I am not talking about this one but about real show stoppers. Well, everything will turn out fine in the end :-)
Comment 12 bfoman (inactive) 2012-08-01 12:17:32 UTC
Confirmed with:
LO 3.5.5.3 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

I do not think that this is a bug. Word 2010 behaves the same way for example.
Therefore I will triage this bug as RESOLVED NOTABUG.
Please report additional problems or feature enhancements in separate bug reports.
Also take a look at http://numbertext.org/linux/. Maybe you consider using those fonts in TeX mode (Linux Libertine G:texm=1) and build your formulas like SO_4 in Writer, Calc and Impress.
Comment 13 daniel.schaaaf 2012-08-01 12:24:03 UTC
It's not a bug, it's a feature! Welcome to Microsoft!1!!1!11
Well, I will post it in ux-advise ... without any hope that this will ever be resolved.

LibreOffice is worse and worse :-(
Comment 14 sasha.libreoffice 2012-11-22 15:19:59 UTC
I have created separate bugreport about chemical formula formatting and placed there Basic macro which performs this formatting automatically:
Bug 57415 - Writer FORMATTING: add function for automatically formatting chemical formula
Comment 15 daniel.schaaaf 2012-12-07 12:04:22 UTC
My bosses forced me to work with MS Office for interoperability reasons, and it turns out that Word 2010 does _not_ apply any formatting to the whole word, when any kind of formatting was chosen! Only characters, that were inserted after the format has been applied, will be affected.
I  therefore reopened this bug and state again, that this is not a feature request.
Comment 16 sasha.libreoffice 2012-12-07 12:48:00 UTC
What is interesting:
1. All font properties are applied to whole words in Writer
2. Calligra Words does not automatically apply to whole word (works as needed for Daniel)
3. Calc and Impress behave as Writer
Comment 17 daniel.schaaaf 2012-12-07 13:13:45 UTC
I finally brought this topic up in LibreOffice-ux-advice. Ignore my last comment, which was born out of a tired, forgetful and childish mind ;-)
Comment 18 sasha.libreoffice 2012-12-07 13:44:59 UTC
Created attachment 71126 [details]
document with Basic macos for correctly formatting to sub/superscipts

I solved this problem. I created two basic Macro for subscript and superscript. They worked as needed. Replace toolbar buttons and keyboard shortcuts for subscript and superscript by these macros.
Writer-only. If needed of Calc or Impress, tell me.
Comment 19 Michael Stahl (allotropia) 2013-02-21 19:46:28 UTC
trying this out in Writer there are apparently 2 cases:
1) with cursor at end of the line, changing the formatting does not change existing text
2) otherwise, the changed format applies to the word at the cursor position

i don't really see any advantage in making this consistently work like
1) or consistently work like 2) or just leave it as it is.
(but i'm of course no UI expert)

oh wait, there is one reason to prefer the status quo: if we change
it there is guaranteed to be at least one user who files a regression bug :)
Comment 20 Rainer Bielefeld Retired 2013-02-21 21:55:29 UTC
The subscript / superscript buttons work exactly as other formatting (at least with my WIN LibO 3.6.5, and exactly as Michael stated), for example (shorctuts for German UI):

If you want to write H2O with an italic "2" in it type
H<contol+i>2<contro+i>O

If you want to write H2O with a subscript "2" type
H<shift+contol+b>2<shift+contol+b>O

Why should we see that as a problem for Subscript/superscript, but not for other character formatting?

I can't see a bug, and I can't see any advantage in changing the current behavior. And if somebody thinks he could work better in a different way, sasha's approach is the appropriate one. Or a complete new concept for all character formatting.

NOTABUG again?
Comment 21 daniel.schaaaf 2013-02-22 15:26:51 UTC
> Michael Stahl
> oh wait, there is one reason to prefer the status quo: if we change
> it there is guaranteed to be at least one user who files a regression bug :)

Yeah, that's the spirit! Don't ever change the status quo!
How about a constructive discussion? Yes, changing the current behavior might startle LibreOffice users, but it might please others. And it will surely please Microsoft Office users ...


> Rainer Bielefeld  2013-02-21 21:55:29 UTC 
> The subscript / superscript buttons work exactly as other formatting ...
> Why should we see that as a problem for Subscript/superscript, but not
> for other character formatting?

You are right, it does apply to all formatting! And in my opinion, it would be for the better to change it to "new formatting only applies to newly typed characters, or currently marked characters". Since this would change LibreOffice' behavior quite substantially, it is worth a discussion.
Viewed logically, I don't see why anything should affect non-marked characters.
From a user's point of view, there are three cases:
1) Apply formatting to a whole word
2) Apply formatting to characters within a word
3) Apply formatting to newly typed characters within a word

Let's see how those two scenarios can be handled currently:
1A) Click into a word and apply formatting
1B) Double-click the word and apply formatting
2A) Mark character and apply formatting
3A) Type, mark typed characters and apply formatting

If the behavior would be changed to my suggestion, 1B and 2A would still apply and 3A would change for the better to "Choose formatting and type character". It sounds like an unnecessary change, but in my case it would solve a lot of undo actions due to involuntary formatting. But then again, I might be a special case. I despise everything a program does all by itself, probably because my brain is not able to anticipate what the software is going to do (read "what the programmers think is best for the user").


> NOTABUG again?

You might not consider it as a bug  per se, but this was the only way I saw to bring up the issue. I subscribed to [Libreoffice-ux-advise], but discussing matters there is extremely difficult, because there are several different discussions going on at the same time. In addition, as a "n00b and ordinary user" I found it impossible to get a discussion going with all the "pros". If one of the "pros" is against something, while most of the others might not disagree but simply don't care that much, it's the end of the "discussion".
Comment 22 Rainer Bielefeld Retired 2013-02-22 16:32:39 UTC
I did an additional quick test: Softmaker FreeOffice does it the same way like we.

@daniel.mania (In reply to comment #11):

I believe there is consensus that any change here would touch lots of users, many functions, scope unknown. And some users would like a change,  and some would submit a regression Bug, as Michael stated.

At least this can not be decided quickly, before we can do a change we need a consistent overall plan. I recommend to discuss your ideas on mailing list <libreoffice-ux-advise@lists.freedesktop.org>, may be exchange of ideas there can find a way to fulfill needs of some more users? Or we get an Extension or a code snippet like sashas macro.

So I return to NOTABUG, because currently the current behavior is the intended one, and for an Enhancement Request there is too less common sense and concept. May be you do some cowork with sasha for a preliminary soulution

@Sasha
I tested your macro, yes, works fine.

Unfortunately our Macros Page
<https://wiki.documentfoundation.org/Macros>
is as dead as a dead herring.
It would be great if you could create an Extension (using BAB, details see on <http://archive09.linux.com/feature/120875>) and upload it, I believe that might be useful for some people, as we see here.
Comment 23 Stefan Knorr (astron) 2013-02-22 16:46:19 UTC
Daniel (In reply to comment #21):
> Yeah, that's the spirit! Don't ever change the status quo!
> How about a constructive discussion?

Please note this part of your comment is not actually helping to establish a constructive discussion. Bugzilla is not a platform to vent frustrations/attack others. Cut it out.

That said, I largely agree with your reasoning for the change (yes the new behaviour is slightly inconsistent, but then sub-/superscript are also used differently than most other formatting options).

Two remarks:
* having yet another option in LibreOffice sounds like a terrible idea to me – we already have a crazy amount of options and it does not make the software better (more chances to crash because of unusual combinations, more cluttered and intimidating UI)
* software, to a degree always has to try working out what you have in mind – otherwise it wouldn't help you get things done.

Rainer (In reply to comment #22):
This has already been on UX-advise:
http://nabble.documentfoundation.org/Libreoffice-ux-advise-Change-LibreOffice-s-behavior-of-how-formatting-is-applied-td3999470.html

(Not changing the status of the bug now, to avoid permanent resetting.)
Comment 24 sasha.libreoffice 2013-02-25 10:31:21 UTC
Created attachment 75491 [details]
The same script, but in extension

Alas, still needed manual assigning to keyboard shortcuts
Comment 25 Rainer Bielefeld Retired 2013-02-25 10:43:17 UTC
@sasha:
Great, thanks a lot. Can you upload the extension to <http://extensions.libreoffice.org/>, where they would be found my muhc more people than here?

What do you think, should we invite someone to test it for a Right to Left language, or did you already check that?
Comment 26 sasha.libreoffice 2013-02-25 11:12:19 UTC
IMHO this macro is too specific for place it among common widely used extensions. It will be not useful there.
May be somebody collects small macros into one big collection. I would ask author of collection for adding this macro into collection.

What about testing: not nested.
Comment 27 Joel Madero 2014-11-06 21:15:38 UTC
I am closing this as NOTABUG as it appears like that is the general consensus from the UX team - it should NOT be reopened, reopening will not get the change done so it is wholly useless.