- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch

by Tudor Girba

Hi, Does anyone want to pick this up on the Pharo image side? I took a brief look at this and while playing I noticed that the errors when we send more than 15 arguments seem a bit strange. Take a look at this snippet: http://ws.stfx.eu/958BXP5GR136 (you can paste it in Spotter to get the playground) In summary: - If we compile a method with a signature containing more than 15 arguments we get: "SyntaxErrorNotification: Too many argumentsââ. This is good. - If we compile a method with a message send containing between 16-31 arguments we get: "'InMidstOfFileinNotificationââ. Ok-ish. - If we compile a method with a message send containing more than 31 arguments we get: "'Error: genSend:numArgs: numArgs index 32 is out of range 0 to 31â" This is wrong. Did I misunderstand something? Cheers, Doru > On Jun 16, 2016, at 8:10 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi everyone. > > It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks. > > I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change. > > The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments. > > The normal calling convention in the Smalltalk bytecode is as follows: > > push receiver > push arg 1 > push arg 2 > .... > push arg N > send selector > > N is limited to 15 arguments due compiled method header & bytecode encoding. > > In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors. > > The convention will look like that: > > push receiver > push arg 1 > push arg 2 > .... > push arg N > popIntoArray N-15 values > send selector > > The compilation of a method with more than 15 arguments is then changed: > - As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg. > - the compiled method header is still marked with 15 arguments > > In addition one needs to change CompiledMethod to: > - allow larger frames (instead of 56 we could allow 128 or 256) > - have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon. > > And to change the fall-back of a couple primitives, such as: > - Object>>perform: withArgs: > - Object>>perform: withArgs:inSupedClass: > - BlockClosure>>valueWithArgs: > > This design would allow methods to up to 141 arguments. > > What do you guys think ? -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."

June 19, 2016

System and user processes

by Max Leske

Hi, In Pharo and Squeak we have no separation between processes that belong to the IDE, tools etc. and processes that are spawned as part of an application. Iâd like to know your opinion on the following (rough) idea: 1. We introduce two subclasses of Process: SystemProcess and UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We introduce #newSystemProcess and #newUserProcess 4. We deprecate #newProcess and delegate to #newUserProcess (thereby modifying all users of #forkXXX to yield instances of UserProcess) Of the following Iâm less sure: 5. We introduce #forkSystemProcess et. al Iâve tried this out in Pharo 6 and there seem to be no problems with the VM. The benefit would be improved separation between system and user space. It would allow us to implement stuff for processes in general (e.g. for the debugger) which we do not want to affect system processes like the UI process or the background process. One concrete example: the process browser could hide all system processes and make them visible on demand (that would greatly improve the view because you can now better find your own processes). Iâm looking forward to your comments. Cheers, Max

June 19, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by stepharo

open a bug entry. Stef Le 19/6/16 Ã 01:44, Sean P. DeNigris a Ã©crit : > Max Leske wrote >> Why donât you use OSSubprocess? > My scripts require this functionality to be pre-loaded in a vanilla image. > Also, on a minor note, some projects use OSProcess and I thought OSSP and > OSP are incompatible. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682p4901727.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

June 19, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by Max Leske

> On 19 Jun 2016, at 01:44, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >> Why donât you use OSSubprocess? > > My scripts require this functionality to be pre-loaded in a vanilla image. Ok, just wanted to check. > Also, on a minor note, some projects use OSProcess and I thought OSSP and > OSP are incompatible. Not as far as I know. OSSubProcess uses the OSProcess VM plugin but is otherwise independent. Cheers, Max > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682p4901727.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 19, 2016

[pharo-project/pharo-core] 574a53: 60097

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 574a53b03b0d089f6d0b43aea562b56690bb78c4 https://github.com/pharo-project/pharo-core/commit/574a53b03b0d089f6d0b43ae… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-19 (Sun, 19 Jun 2016) Changed paths: M Announcements-Tests-Core.package/AnnouncementSetTest.class/instance/testing/testIncludeOnlyOnce.st M Announcements-Tests-Core.package/AnnouncementSetTest.class/instance/testing/testInstanceCreation.st M Kernel.package/Object.class/instance/deprecation/deprecated_transformWith_.st M Refactoring-Critics.package/RBBadMessageRule.class/instance/private/badSelectors.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/defaults/iconBlock_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60096.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60097.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60096.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60097.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeInspector.class/instance/accessing/elements.st M Spec-PolyWidgets.package/EditableList.class/instance/initialization/initializePresenter.st M Spec-PolyWidgets.package/EditableList.class/instance/private/moveElementAt_to_.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/actions/editSelectedPackageRequirements.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/actions/editSelectedProjectLoads.st M Versionner-Spec-Browser.package/VersionnerToolBar.class/instance/actions/newConfiguration.st Log Message: ----------- 60097 18520 EyeTreeInspector is broken https://pharo.fogbugz.com/f/cases/18520 18527 #halt should not be in the badSelectors rule https://pharo.fogbugz.com/f/cases/18527 18525 fix for IconStyler https://pharo.fogbugz.com/f/cases/18525 http://files.pharo.org/image/60/60097.zip

June 19, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60097 Home: https://github.com/pharo-project/pharo-core

June 19, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Ben Coman

On Fri, Jun 17, 2016 at 11:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > >> On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> >>> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> Hi Alistair, >>> >>> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>>> >>>>> On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: >>>>> Hi All, >>>>> >>>>> so after fixing "git remote get-url origin" to fail over to "git remote >>>>> show origin | filter and munge" the culture shock of "git commit -a" >>>>> (git >>>>> commit does nothing ?!?!?) >>>> >>>> "git commit" will commit anything that has been "git add"ed to the >>>> index. -a is a convenience to automatically stage files that have been >>>> modified. >>> >>> >>> What I don't understand is how, or indeed why, one stages modified files. I >>> get that adding files requires informing git. But why doesn't "git commit" >>> commit modified files by default? Why do I have to use git commit -a to >>> include modified files? >> >> Because you can choose what files will be part of the commit >> (cherry-picking changes). > > Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature. Hi Eliot, Seems enough others must have felt the same that this was added to help... https://git-scm.com/docs/git-stage Perhaps it would be preferred to use "stage" over "add" in documenting the usual workflows for this project? cheers -ben

June 19, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Ben Coman

On Sun, Jun 19, 2016 at 2:55 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Command is an actual key on Mac next to Option(which is Alt) and Control. So, Command is a concrete key and mapping it logically to another key on another platform is mixing semantics. +1000. We should avoid our abstract shortcut key modifiers overlaping concrete keys. > > I propose to have two distinct layers in the image: > 1. the raw layer is about having a distinct selector for each concrete key that is found on the keyboard. Right now, it seems to me that the VM does a bit of interpretation and mapping, and if it does, I think it should just provide a distinct code for each distinct key. > 2. the portable layer is about having a couple of selectors (e.g., #meta, #secondaryMeta) that provide consistent mappings to the raw keys. Sounds good. > > So, in this way, #command/#control/#alt would belong to layer 1. and #meta/#secondaryMeta > > (we could find a better name) would belong to layer 2. Historical alternatives: hyper, super But super looks to already be associated with a concrete key, so that would leave hyper. http://askubuntu.com/questions/19558/what-are-the-meta-super-and-hyper-keys btw, Emacs uses these names https://www.gnu.org/software/emacs/manual/html_node/emacs/Modifier-Keys.html Or, just brainstorming a unique alternative... If meta is thought of as met-a, we could use: metb, meti, meto, metu, mety, metz, mota, miti, moti. I think I like meti or miti for the diminutive / secondary feel of them. p.s. I like this article I bumped into with tips on physical exercises... http://ergoemacs.org/emacs/emacs_pinky.html > > Does this make sense? Very much. In addition, to help the layering (and also to encourage not-using ctrl, alt directly), maybe require a modifier like 'exception' or 'exceptionDirect' or just 'direct' for access to those concrete keys. e.g. f exception ctrl, f exceptionDirect dtrl, f direct ctrl cheers -ben > > Cheers, > Doru > > >> On Jun 18, 2016, at 8:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> 2016-06-17 18:25 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> > >> > 2016-06-17 14:35 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > Hi Nicolai, >> > >> > I am a bit removed from the code details at the moment, and I think I need to step back a bit :). >> > >> > If I understand correctly, you are saying that: >> > 1. defining bindings with #alt does not work on Windows. This means that we should fix this one. Using Cmd should not be a solution here. >> > >> > As far as I know, this is on purpose. A key pressed with windows (left) alt modified is mapped to "command" >> > >> > from vm source: >> > >> > * 3) The modifier keys are mapped as follows: >> > * >> > * Mac | Win32 >> > * -------------------- >> > * Shift -> Shift >> > * Ctrl -> Ctrl >> > * Command -> Left ALT >> > * Option -> Right ALT >> > >> > (but actually, the right ALT key does not generate any keystrokes (only key down/up) and it is treated as ctrl+alt (windows right Alt key is "Alt Grâ) >> >> Hmm. I think we have to rethink this one because we need two layers of keys: >> 1. first we should have the raw ones, and >> >> what are the "raw" ones? The events the OS generates or the events the VM send out to the image? >> >> 2. another layer that offers a more logical keys (like meta). >> >> Can you explain this a bit more. >> >> >> What do you think? >> >> >> > 2. defining the >> > bindings for Spotter can indeed be made to override the ones in the text editor if needed. But, I think we can start thinking about using #alt. >> > >> > using alt+right on windows/linux and >> > command + right on mac >> > for dive-in or for text navigation? >> > >> > Is there a default keycombination for word-moving in text components for mac ? >> >> On Mac, typically Alt+Right/Left moves between words. >> >> So, we would need a logical modifier that would mean: >> - Mac: Alt >> - Win: Ctrl >> - Linux: Ctrl >> >> I though this is what Guillermo already did, but with "command" >> >> - Mac: Command >> - Win/Linux: Ctrl >> >> Why did we choose Command and not Alt in the first place, why is Alt now better? >> >> >> >> What do you think? >> >> Cheers, >> Doru >> >> >> > >> > Does this make sense? >> > >> > Cheers, >> > Doru >> > >> > >> > > On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> > > >> > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > > Hi, >> > > >> > > I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. >> > > >> > > On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter >> > > because spotter redefines this keystrokes for dive in /out. >> > > Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher >> > > explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. >> > > (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph). >> > > >> > > >> > > The idea was to offer a uniform support of keybindings in Pharo, in general. >> > > >> > > exactly, and using ctrl+left/right uniformly in editor and external tools would be great. >> > > >> > > Then Guille etal added #meta to have a predictable mapping. >> > > >> > > Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this >> > > if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) >> > > >> > > All #cmd places were changed to #meta, and since then we should not use explicitly #cmd anymore, except when we know we are on Mac. For a portable modifier, we should only use #meta. >> > > >> > > At this point, both Rubric and Spotter use #meta. #meta maps on: >> > > - Mac: Command >> > > - Win: Control >> > > - Linus: Control >> > > >> > > This means that #alt is now a portable modifier that will not conflict with #meta, so we can now think of using that one in combination with #meta. >> > > >> > > You can not use #alt modifier on windows. A shortcut definition like >> > > $g alt >> > > is never recognized. You have to define it >> > > $g command >> > > to make it work with as "alt+g"-keycombination (on windows). >> > > >> > > For text navigation, the situation is a bit complicated. On Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left moves the cursor at the end/beginning of line. So, using #meta for text navigation between words is not entirely accurate. We should use #ctrl instead. >> > > >> > > This would anyway mean that it would be an option to use #alt for Spotter now. But, if we are at it, would anyone be interested in working on revisiting the overall keybindings in Pharo? >> > > >> > > > On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> > > > >> > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> > > > >> > > > We can, but I remember there were some discussions and it was decided to use meta everywhere. >> > > > >> > > > If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier. >> > > > >> > > > What are the arguments for using meta for dive-in/out shortcuts ? >> > > > >> > > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> > > > >> > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> > > > >> > > > During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd. >> > > > Can we change this for spotter ? cmd instead of meta >> > > > ctrl left/right is often used for text components to move to next/previous word. >> > > > >> > > > On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> > > > >> > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> > > > >> > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard(a)uia.no>: >> > > > > IIRC the shortcut is not changed, it still is meta+right(+shift). Only the tooltip was changed to display the system specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. >> > > > >> > > > No, it changed >> > > > In #40624, for example, it was cmd (alt-key on windows ) right/shift right >> > > > >> > > > > To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> > > > > Subject: [Pharo-dev] GT-Spotter dive in shortcut >> > > > > >> > > > > >> > > > > >> > > > > Why did the shortcut for dive-in element/category changed from >> > > > > >> > > > > cmd+right >> > > > > cmd+shift+right >> > > > > >> > > > > to >> > > > > >> > > > > ctrl+right >> > > > > ctrl+shift+right >> > > > > >> > > > > I know there were some discussions about this and that the behavior changed some >> > > > > time ago, but I don't know the rational behind this.

June 19, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by Sean P. DeNigris

Max Leske wrote > Why donât you use OSSubprocess? My scripts require this functionality to be pre-loaded in a vanilla image. Also, on a minor note, some projects use OSProcess and I thought OSSP and OSP are incompatible. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682p4901727.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 18, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

2016-06-18 20:55 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Command is an actual key on Mac next to Option(which is Alt) and Control. > So, Command is a concrete key and mapping it logically to another key on > another platform is mixing semantics. > > I propose to have two distinct layers in the image: > 1. the raw layer is about having a distinct selector for each concrete key > that is found on the keyboard. Right now, it seems to me that the VM does a > bit of interpretation and mapping, and if it does, I think it should just > provide a distinct code for each distinct key. > 2. the portable layer is about having a couple of selectors (e.g., #meta, > #secondaryMeta) that provide consistent mappings to the raw keys. > > So, in this way, #command/#control/#alt would belong to layer 1. and > #meta/#secondaryMeta (we could find a better name) would belong to layer 2. > > Does this make sense? > > So, what does that mean for the text navigation mapping in Rubric. Which shortcut should I use? > Cheers, > Doru > > > > On Jun 18, 2016, at 8:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-06-17 18:25 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Nicolai, > > > > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > Hi Nicolai, > > > > > > I am a bit removed from the code details at the moment, and I think I > need to step back a bit :). > > > > > > If I understand correctly, you are saying that: > > > 1. defining bindings with #alt does not work on Windows. This means > that we should fix this one. Using Cmd should not be a solution here. > > > > > > As far as I know, this is on purpose. A key pressed with windows > (left) alt modified is mapped to "command" > > > > > > from vm source: > > > > > > * 3) The modifier keys are mapped as follows: > > > * > > > * Mac | Win32 > > > * -------------------- > > > * Shift -> Shift > > > * Ctrl -> Ctrl > > > * Command -> Left ALT > > > * Option -> Right ALT > > > > > > (but actually, the right ALT key does not generate any keystrokes > (only key down/up) and it is treated as ctrl+alt (windows right Alt key is > "Alt Grâ) > > > > Hmm. I think we have to rethink this one because we need two layers of > keys: > > 1. first we should have the raw ones, and > > > > what are the "raw" ones? The events the OS generates or the events the > VM send out to the image? > > > > 2. another layer that offers a more logical keys (like meta). > > > > Can you explain this a bit more. > > > > > > What do you think? > > > > > > > 2. defining the > > > bindings for Spotter can indeed be made to override the ones in the > text editor if needed. But, I think we can start thinking about using #alt. > > > > > > using alt+right on windows/linux and > > > command + right on mac > > > for dive-in or for text navigation? > > > > > > Is there a default keycombination for word-moving in text components > for mac ? > > > > On Mac, typically Alt+Right/Left moves between words. > > > > So, we would need a logical modifier that would mean: > > - Mac: Alt > > - Win: Ctrl > > - Linux: Ctrl > > > > I though this is what Guillermo already did, but with "command" > > > > - Mac: Command > > - Win/Linux: Ctrl > > > > Why did we choose Command and not Alt in the first place, why is Alt now > better? > > > > > > > > What do you think? > > > > Cheers, > > Doru > > > > > > > > > > Does this make sense? > > > > > > Cheers, > > > Doru > > > > > > > > > > On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > > > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > Hi, > > > > > > > > I think we are mixing the topics a bit. The #meta discussion is not > specific to Spotter actions. > > > > > > > > On windows, it is. Because on windows #meta is mapped to #ctrl, and > you can use ctrl+left/right for moving by "words". This works in a > browser, an editor, pharos text components but *not* in spotter > > > > because spotter redefines this keystrokes for dive in /out. > > > > Currently, both ctrl+left/right and alt+left/right (and shift for > selection) are working in rubric for moving by "word". But only because the > (old) shortcut (cmd/shiftcmd) action dispatcher > > > > explicitly allows both. If we want to remove this and use the > KMDispatcher framework only, we *need* to define only one mapping, > otherwise you won't be able to use dive in/out in spotter. > > > > (Or you could modify spotter to register(overwrite) the mapping on > the textfield instead of the spotter morph). > > > > > > > > > > > > The idea was to offer a uniform support of keybindings in Pharo, in > general. > > > > > > > > exactly, and using ctrl+left/right uniformly in editor and external > tools would be great. > > > > > > > > Then Guille etal added #meta to have a predictable mapping. > > > > > > > > Yes, and to make this work, we have to remove the old keymapping > implementation (cmd/shiftcmd action map) and use the KMDispatcher > registration. But I can only continue with this > > > > if we have a decision what to use, (windows/linux: either ctrl+arrow > or alt+arrow, mac: whatever is used on a mac for text navigation) > > > > > > > > All #cmd places were changed to #meta, and since then we should not > use explicitly #cmd anymore, except when we know we are on Mac. For a > portable modifier, we should only use #meta. > > > > > > > > At this point, both Rubric and Spotter use #meta. #meta maps on: > > > > - Mac: Command > > > > - Win: Control > > > > - Linus: Control > > > > > > > > This means that #alt is now a portable modifier that will not > conflict with #meta, so we can now think of using that one in combination > with #meta. > > > > > > > > You can not use #alt modifier on windows. A shortcut definition like > > > > $g alt > > > > is never recognized. You have to define it > > > > $g command > > > > to make it work with as "alt+g"-keycombination (on windows). > > > > > > > > > > > > > > > > For text navigation, the situation is a bit complicated. On > Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, > Cmd+Right/Left moves the cursor at the end/beginning of line. So, using > #meta for text navigation between words is not entirely accurate. We should > use #ctrl instead. > > > > > > > > This would anyway mean that it would be an option to use #alt for > Spotter now. But, if we are at it, would anyone be interested in working on > revisiting the overall keybindings in Pharo? > > > > > > > > Cheers, > > > > Doru > > > > > > > > > > > > > > > > > On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com > >: > > > > > We can, but I remember there were some discussions and it was > decided to use meta everywhere. > > > > > > > > > > Cheers, > > > > > Andrei > > > > > > > > > > > > > > > If we don't change this, I'll use cmd+left cmd+right in rubric, > but this is bad, because all other navigate/select+navigate shortcuts would > use meta as shortcut modifier. > > > > > > > > > > What are the arguments for using meta for dive-in/out shortcuts ? > > > > > > > > > > > > > > > > > > > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess < > nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com > >: > > > > > During Pharo 5 most shortcuts from tools were changed to use > "meta" instead of cmd. > > > > > > > > > > Cheers, > > > > > Andrei > > > > > > > > > > Can we change this for spotter ? cmd instead of meta > > > > > > > > > > ctrl left/right is often used for text components to move to > next/previous word. > > > > > > > > > > > > > > > > > > > > On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess < > nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" < > henrik.nergaard(a)uia.no>: > > > > > > > > > > > > IIRC the shortcut is not changed, it still is > meta+right(+shift). Only the tooltip was changed to display the system > specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. > > > > > > > > > > > > > > > No, it changed > > > > > > > > > > In #40624, for example, it was cmd (alt-key on windows ) > right/shift right > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Henrik > > > > > > > > > > > > > > > > > > > > > > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > Behalf Of Nicolai Hess > > > > > > Sent: Tuesday, June 7, 2016 12:56 PM > > > > > > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > > > > Subject: [Pharo-dev] GT-Spotter dive in shortcut > > > > > > > > > > > > > > > > > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > > > > > > > > > cmd+right > > > > > > > > > > > > cmd+shift+right > > > > > > > > > > > > to > > > > > > > > > > > > ctrl+right > > > > > > ctrl+shift+right > > > > > > > > > > > > I know there were some discussions about this and that the > behavior changed some > > > > > > > > > > > > time ago, but I don't know the rational behind this. > > > > > > > > > > > > thanks > > > > > > > > > > > > nicolai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > www.tudorgirba.com > > > > www.feenk.com > > > > > > > > "If you interrupt the barber while he is cutting your hair, > > > > you will end up with a messy haircut." > > > > > > > > > > > > > > > > > > -- > > > www.tudorgirba.com > > > www.feenk.com > > > > > > "Quality cannot be an afterthought." > > > > > > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Being happy is a matter of choice." > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > > >

June 18, 2016