Issue 93749

Not a P1 issue, of course.

Tried here with OOO300m5 build on macmini. Shift-Option-Arrow left/right works
perfectly for word wise selection. Do you have the correct assignments in System
keyboard settings?

Closed.

> Do you have the correct assignments in System keyboard settings?

Indeed, I do. 

shift + alt/option + right/left
does extend or reduce a selection, one word at time, in applications *other* than OOo. Tested in at 
least Apple Mail.app, Smultron and TextWrangler. 

In my OOo, the routine does nothing. 

Now using m7, RC2. Mac OS X 10.5.5, Intel. 

Is it possible that some *preference* in my OOo is over-riding, or in conflict with, normal behaviour?

/me updates his Service Scrubber <http://www.manytricks.com/servicescrubber/> for a closer look at 
the caboodle.

Sorry for the P1 ;) at the time (so close to the 16th, which might have been a release date) it was an over-
reaction to what seemed to be a major issue affecting word processing. 

Service Scrubber reveals nothing in conflict. 

(Side note: reading this comment alongside Issue 94394 I wonder whether any key combination associated 
with a Services-enabled application could affect an application such as OOo that may be not so enabled.)

Issue 94335 reported by rollom appears to be a duplicate of this issue 93749 and as 94335 was assigned to sba so I'm 
assigning 93749, too, to sba. 

@mru:

 * At System Preferences… | International | Language 
   what does your list comprise?

 * At System Preferences… | International | Input Menu
   which language is set when for you things work as expected?

@rollom:

 * At System Preferences… | International | Language 
   what does your list comprise?

 * At System Preferences… | International | Input Menu
   which language is set when, for you, application behaviour is improper?

@myself: 

British English
English
Francais
Greek
Hebrew
Arabic

Input menu options comprise British and U.Ss. British is selected

— and for me the symptoms persist in m7 (release candidate 2) of OOo 3. 

Possibly irrelevant, but if keyboard layouts are a concern then the tail end of this comment may be of interest: 

I find that some of my preference files are mishandled whenever I restart Mac OS X. 

Most noticeable and frustrating with 
~/Library/Preferences/com.apple.AddressBook.plist
— preferences for sort order, LDAP, template etc. are lost every time.

Noticeable but less frequent with 
~/Library/Preferences/com.apple.dock.plist
— preferences for Spaces are lost occasionally.

Very recently, following a hardware repair (25th September change of main board in my first generation MacBook 
Pro 17") noticeable with:

~/Library/Preferences/com.apple.security.plist
— references to all keychains are lost every time

~/com.apple.systempreferences.plist
— preferences for Character Palette, Keyboard Viewer and British are lost at least once. 

^^ that last line, keyboard input-related ^^

= See also =

Issue 34355, assigned to bh

> cursor position after deselecting text by pressing arrow keys

@grahamperrin: What setting do you mean exactly, I do not find these settings
(using a German installation here, so this is a bit tricky to find...). Do you
mean the Mac control panel and there language settings, or OOo settings? Could
you give me the exact way to get to the settings?

BTW: The key assignment in the OOo keyboard settings says Apple-left/right is
used to jump wordwise. This is obviously wrong, as alt-left/right is used and
Apple-left/right is used to jump to the beginning/end of the line. (But you
cannot assign the alt key at all there... Might be that the famous missing alt
key assignment issue which is also there on PCs plays a trick on us here - why
not finally fix that one?). 

My report 49335 is a duplicate of this one here (sorry). I'm just going to mark
it as such. To repeat what I said there in addition to the report here:
Shift-Ctrl-Left/Right mistakenly has the function of Shift-Alt-Left/Right on my
Mac. I'm using a Macbook Pro 2.16 GHz here.

Sorry, I meant issue 94335 of course. I cannot mark it as a duplicate on my own
there. Is this because I am not an admin? Can anyone else do this for me please?
Tnx.

The issue here is that on Mac OS:

SHIFT-OPTION-LEFT and SHIFT-OPTION-RIGHT should extend or reduce a selection.
This is not true in OOO300m7 Build 9354. The key combos do nothing.

On the other hand, COMMAND-SHIFT-LEFT and COMMAND-SHIFT-RIGHT *DO* extend/reduce
a selection word by word. These key combos should extend/reduce a select to the
end or beginning of a line.

Without SHIFT:

OPTION-LEFT, OPTION-RIGHT work correctly, moving the cursor position word-wise.
COMMAND-LEFT, COMMAND-RIGHT also work correctly, moving the cursor from one end
of a line to another.

This should be rectified for consistency within OOO and to conform with the
global MacOS key-command layout.

Adam

.

> Without SHIFT:
> 
> OPTION-LEFT, OPTION-RIGHT work correctly, moving the cursor
> position word-wise.
> COMMAND-LEFT, COMMAND-RIGHT also work correctly, moving the
> cursor from one end of a line to another.

Extending these behaviours (defocusing slightly from the original subject of this bug): 

In Apple TextEdit.app 1.5 (244), working with a single sentence paragraph that wraps to three lines within the window, double-click (select) a 
mid-sentence word within the second line then:

* command-shift-left then right

— effectively extends the selection … first, to the far left of that one line; then from the far left to the far right of that one (mid) line 
— without extending to upper or lower lines within that one-sentence paragraph.

Comparing with TextWrangler 2.3 (262), Microsoft Word 2008 and Safari 3.1.2 (5525.20.1), all three differ from the behaviour of TextEdit. I 
sometimes prefer Apple's TextEdit as a comparator but in this new example, the behaviours of TextWrangler, Word and (probably most 
significantly) WebKit-based Safari do *feel* more intuitive, more consistent with the original subject of this bug. Here now in Safari: 

* command-shift-left then right

— effectively extends the selection … first, _from the mid-point_ to the far left of that one line

— then, _from the mid-point_ (NOT from the far left) to the far right of that one (mid) line.

= Summary =

1) I concur with apieroni. 

2) If there arises doubt about behaviour of 

* command-shift left then right

or 

* command-shift right then left

I should tend towards the examples set by Safari, TextWrangler and Word.

= Priority =

Issues such as this are not as obvious as crashes, but I realise now (after some years of using OpenOffice.org) that these things do nebulously 
make OOo 'not feel quite right' to seasoned users of key combinations. Before now, I have never pinned down that feeling. It's good now to 
pin down the inconsistencies. 

> Do you mean the Mac control panel and there language settings

I do mean Apple Mac OS X System Preferences.

I have no recollection of changing keyboard settings within OOo. (It's possible that I did so, many years ago 
whilst using earlier major versions, but I doubt it.)

> The key assignment in the OOo keyboard settings … you cannot
> assign the alt key at all there... Might be that the famous
> missing alt key assignment issue which is also there on PCs
> plays a trick on us here 

Please, do you have an issue # for the 
'missing alt key assignment' issue?

> Shift-Ctrl-Left/Right mistakenly … Shift-Alt-Left/Right

Hmm, I find now (in TextWrangler and Apple Safari compositions) that (a) shift-control-left and shift-alt-left 
have identical behaviours, (b) shift-control-right and shift-alt-right have _identical_ behaviours. 

If we are to debate 
shift-control 
behaviours, my instinct is that we should take observations to a separate (probably new) ticket. 

> sorry

Thank you :) but the duplication did not bother me. IMHO the different expressions in the summary lines will 
sometimes increase the likelihood of people finding their way to a particular issue. Particularly in multi-lingual 
environments.

Thanks/regards to all
Graham

Grahamperrin,

>Please, do you have an issue # for the 
>'missing alt key assignment' issue?

It is issue 4756.

I expressed my view there long time ago, that only supporting the alt key (above
all on Windows machines) would give keyboard layout compatibility with Word, and
that I am convinced that only the widest keyboard compatibility possible will
avoid this "not feeling quite right" of our users which you mentioned, too. As
we know, most of our users switch to OOo from Word. So supporting compatible
keyboard layout is crucial for them to feel "at home" when using OOo and finally
for the success off OOo.

I'll be back here soon to answer your Mac question. Sitting at a PC right now...

I'll vote for this issue (assuming it's possible to vote for one's own report)…

See also Issue 96184 where (on Mac OS X) 
alt-shift-left 
alt-shift-right 
alt-shift-up
alt-shift-down 
_MUST NOT_ manipulate tables. 

Issue 96184 is the most likely explanation for this Issue 93749. 

SBA->ES: Please proceed, thx.

My issue 96184 (mentioned in comments) was a duplicate of broader issue 92224 — sorry. 

Reading some of the tickets, I *suspect* that this issue 93749 is also a duplicate of 92224.

As 92224 is assigned to pl, so I am adding pl to the list of CCs for this issue 93749.

As discussed with PL: yes, duplicate.

*** This issue has been marked as a duplicate of 92224 ***

Closed