August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

2016-08-03 11:10 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 03 Aug 2016, at 10:52, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> I will just re-post my first answer: >> >> if reintroduce them means reintroduce them hardcoded as before, then Iâm >> complete against it and I WILL NOT integrate such solution. >> Iâm sorry for being so strong here, but previous implementation was lame >> and we need to get rid of them. >> >> Now, I understand people are used to use those bindings and also some >> others (no idea which ones because I never used themâ¦ for me ocompletion is >> good enoughâ¦ but those are tastes). So I would be very happy to integrate a >> generic way to define keybindings and outputs (which is already there, with >> keymapping, but I mean an editor or something), and I would be very happy >> to integrate a default configuration (which of course, will include >> #ifTrue:/##ifFalse:) >> > > we already have > PharoShortcuts>>#displayIfFalseShortcut > ^ $f alt > > this is defined and therefore in the same kind "hardcoded" as any other > shortcut > doItShortcut > ^ $d meta > inspectItShortcut > ^ $i meta > In PharoShortcuts > > the action (RubSmalltalkEditor>>displayIfFalse: aKeyboardEvent) is just > not (yet) bound to this shortcut. > I don't see how this is an argument against this shortcut definition. All > other shortcuts are defined like that. > > And this is not really for adding a new feature. This shortcut already > (always :) ) existed in the old PluggableTextMorph based editor, it was > just lost (and not on purpose I think) like other things when > we moved to rubric (as you can see, the code for this action is already > there in rubric). > > > yes, it existedâ¦ and it was bad, as are bad all hardcoded shortcuts that > yes, still exists a lot in the system. > but we want to clean the system, not perpetuate it. > > for me, this is not a shortcut problem but a completion oneâ¦ what we need > to do is to enhance it. But even not doing it, I would not introduce new > hardcoded shortcuts. > And what is a hardcoded shortcut? The ones defined in PharoShortcuts? Do we have any why to define shortcuts "not hardcoded". Sure we should make this editable/configurable. But *first* we need to unify the current shortcut handling. This shortcut handling is done by the KMDispatcher and (even in Rubric) by the editors actionMaps and in various places in the code. If I can not *move* a shortcut definition/handling from the text editors action map to the KMDispatcher because that shortcut definition would be "hardcoded", I can not do anything. > > Esteban > > > > > > > > > > >> >> Esteban >> >> On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> >> 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: >> >>> I'm also against. >>> >>> - They take a place in the shortcuts that prevents others to use it >>> - If lazy people really needs this, the code completion should be >>> enhanced. This is a code completion concern... >>> >> >> +1 >> >> >> > >

Aug. 3, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

by Marcus Denker

> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com> wrote: > > > Log Message: > ----------- > 60163 > 18831 Integrate new Epicea version > https://pharo.fogbugz.com/f/cases/18831 > ChangeLog for this: - Case 18813: Implement redo and undo of protocol addition and removal. - Case 18612: disable drag&drop until TreeModel supports it correctly. - Case 18384: Redo and undo: show on any selection (not only when all selected entries are code changes). - Enhancement: Improve lost changes detection; show only the events actually lost. - Enhancement: Pass on filters. - Clean up: Do not show the "absent entry" item anymore since it was not useful at all. - Clean up: Remove unused "commit tags" in log browser. - Clean up: Remove unused tests. They were good idea, we can re-introduce them but working and covering more cases. - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. It is more meaningful. - Workaround: Hide "Open in Sorter" menu action since it is useless until Treemodel drag&drop is fixed. > 18768 Inlined method const could be implemented by metalinks > https://pharo.fogbugz.com/f/cases/18768 > > 18835 Update RBParser-Nodes class comments > https://pharo.fogbugz.com/f/cases/18835 > > http://files.pharo.org/image/60/60163.zip > >

Aug. 3, 2016

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

by Nicolai Hess

2016-08-03 10:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > 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? > > > > Any way to take a decision? > > > > I don't really want to wait until we implement a new layer. > > Thanks for the ping. > > I think that you cannot use now properly a uniform shortcut if we do not > introduce these âlayersâ. I also think that we are talking about a couple > of methods, so the effort is only in making the decision. I think that > given that nobody disagreed, we can go ahead with it. > > For the specific question related to text navigation in Rubric, you could > use #meta. > But how? If I add this to RubTextEditor class>>#buildShortcutsOn: aBuilder (aBuilder shortcut: #nextWord) category: RubTextEditor name default: Character arrowRight meta do: [ :target :morph :event | target editor cursorRight: event] description: 'move to next word'. (aBuilder shortcut: #previousWord) category: RubTextEditor name default: Character arrowLeft meta do: [ :target :morph :event | target editor cursorLeft: event] description: 'move to the previous word'. we can not dive in/out in spotter. This is why I asked: Why did the shortcut for dive-in element/category changed from cmd+right cmd+shift+right to ctrl+right ctrl+shift+right > > What do you think? > > Doru > > > > > 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." > > > > > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Esteban Lorenzano

> On 03 Aug 2016, at 10:52, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > I will just re-post my first answer: > > if reintroduce them means reintroduce them hardcoded as before, then Iâm complete against it and I WILL NOT integrate such solution. > Iâm sorry for being so strong here, but previous implementation was lame and we need to get rid of them. > > Now, I understand people are used to use those bindings and also some others (no idea which ones because I never used themâ¦ for me ocompletion is good enoughâ¦ but those are tastes). So I would be very happy to integrate a generic way to define keybindings and outputs (which is already there, with keymapping, but I mean an editor or something), and I would be very happy to integrate a default configuration (which of course, will include #ifTrue:/##ifFalse:) > > we already have > PharoShortcuts>>#displayIfFalseShortcut > ^ $f alt > > this is defined and therefore in the same kind "hardcoded" as any other shortcut > doItShortcut > ^ $d meta > inspectItShortcut > ^ $i meta > In PharoShortcuts > > the action (RubSmalltalkEditor>>displayIfFalse: aKeyboardEvent) is just not (yet) bound to this shortcut. > I don't see how this is an argument against this shortcut definition. All other shortcuts are defined like that. > > And this is not really for adding a new feature. This shortcut already (always :) ) existed in the old PluggableTextMorph based editor, it was just lost (and not on purpose I think) like other things when > we moved to rubric (as you can see, the code for this action is already there in rubric). yes, it existedâ¦ and it was bad, as are bad all hardcoded shortcuts that yes, still exists a lot in the system. but we want to clean the system, not perpetuate it. for me, this is not a shortcut problem but a completion oneâ¦ what we need to do is to enhance it. But even not doing it, I would not introduce new hardcoded shortcuts. Esteban > > > > > > > > > > Esteban > >> On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >> I'm also against. >> >> - They take a place in the shortcuts that prevents others to use it >> - If lazy people really needs this, the code completion should be enhanced. This is a code completion concern... >> >> +1 > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

2016-08-03 10:56 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > I will just re-post my first answer: > > > > if reintroduce them means reintroduce them hardcoded as before, then Iâm > > complete against it and I WILL NOT integrate such solution. > > Iâm sorry for being so strong here, but previous implementation was lame > and > > we need to get rid of them. > > > > Now, I understand people are used to use those bindings and also some > others > > (no idea which ones because I never used themâ¦ for me ocompletion is good > > enoughâ¦ but those are tastes). So I would be very happy to integrate a > > generic way to define keybindings and outputs (which is already there, > with > > keymapping, but I mean an editor or something), and I would be very > happy to > > integrate a default configuration (which of course, will include > > #ifTrue:/##ifFalse:) > > I would guess code expansions could be many and varied between > different individuals, and quickly consume available keyboard > shortcuts. Perhaps a generic mechanism would be single shortcut for > "code expansion" which processes the letters preceding the cursor. > For example, using shortcut <ctrl-e> for code expansion and typing... > > itf<ctrl-e> > > ==> ifTrue: [ ] ifFalse: [ ] > > The could be an interface to define these code expansions - initially > at least on a purely personal basis. > > > And this is not really for adding a new feature. This shortcut already > (always :) ) existed > > With a single shortcut for code expansion, perhaps a few other > existing combinations could be freed up. > > good idea, some kind of template expansion with user defined templates. > cheers -ben > > > > > Esteban > > > > On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > > > 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > >> > >> I'm also against. > >> > >> - They take a place in the shortcuts that prevents others to use it > >> - If lazy people really needs this, the code completion should be > >> enhanced. This is a code completion concern... > > > > > > +1 > > > > > >

Aug. 3, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 3, 2016

[pharo-project/pharo-core] f57843: 60163

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f578434a0d828004d918c36066a3cff9163f056b https://github.com/pharo-project/pharo-core/commit/f578434a0d828004d918c360… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-03 (Wed, 03 Aug 2016) Changed paths: M AST-Core.package/RBArgumentNode.class/README.md M AST-Core.package/RBBlockNode.class/README.md M AST-Core.package/RBComment.class/README.md M AST-Core.package/RBGlobalNode.class/README.md M AST-Core.package/RBInstanceVariableNode.class/README.md M AST-Core.package/RBLiteralValueNode.class/README.md M AST-Core.package/RBMessageNode.class/README.md M AST-Core.package/RBMethodNode.class/README.md M AST-Core.package/RBParseErrorNode.class/README.md M AST-Core.package/RBPatternPragmaNode.class/README.md M AST-Core.package/RBPragmaNode.class/README.md M AST-Core.package/RBProgramNode.class/README.md M AST-Core.package/RBSequenceNode.class/README.md M AST-Core.package/RBTemporaryNode.class/README.md M AST-Core.package/RBVariableNode.class/README.md R ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version796_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version797_.st M Epicea.package/EpLog.class/definition.st R Epicea.package/EpLog.class/instance/accessing/commitAt_ifPresent_.st R Epicea.package/EpLog.class/instance/accessing/commitAt_put_.st A Epicea.package/EpLog.class/instance/copying/copyFromHead.st M Epicea.package/EpLog.class/instance/initialization/initializeWith_.st R Epicea.package/EpMonitor.class/class/accessing/detectLostLogAndDo_.st R Epicea.package/EpMonitor.class/class/accessing/findLogFiles.st R Epicea.package/EpMonitor.class/class/accessing/findLogFilesIn_.st R Epicea.package/EpMonitor.class/class/accessing/loadAllLogs.st R Epicea.package/EpMonitor.class/class/accessing/loadCurrentImageLogs.st A Epicea.package/EpMonitor.class/class/accessing/logFilesIn_.st A Epicea.package/EpPluggableFilter.class/class/special filters/after_.st A Epicea.package/EpPluggableFilter.class/class/special filters/before_.st A Epicea.package/EpPluggableFilter.class/class/special filters/todayFilter.st M Epicea.package/EpPluggableFilter.class/class/well-known filters/behaviorFilter.st M Epicea.package/EpPluggableFilter.class/class/well-known filters/codeChangeFilter.st R Epicea.package/EpPluggableFilter.class/class/well-known filters/evaluationFilter.st R Epicea.package/EpPluggableFilter.class/class/well-known filters/lastSixHoursFilter.st M Epicea.package/EpPluggableFilter.class/class/well-known filters/logBrowserOperationFilter.st M Epicea.package/EpPluggableFilter.class/class/well-known filters/methodFilter.st M Epicea.package/EpPluggableFilter.class/class/well-known filters/noTriggerFilter.st M Epicea.package/EpPluggableFilter.class/class/well-known filters/refactoringScopeFilter.st R Epicea.package/EpPluggableFilter.class/class/well-known filters/todayFilter.st A EpiceaBrowsers.package/EpAbsentItem.class/instance/converting/asMorph.st R EpiceaBrowsers.package/EpAbsentItem.class/instance/operations/timeString.st R EpiceaBrowsers.package/EpAbsentItem.class/instance/populating browser/displayWidget.st A EpiceaBrowsers.package/EpEntryItem.class/instance/converting/asMorph.st M EpiceaBrowsers.package/EpEntryItem.class/instance/populating browser/defaultMenuActions.st R EpiceaBrowsers.package/EpEntryItem.class/instance/populating browser/displayWidget.st A EpiceaBrowsers.package/EpFetchMoreItem.class/instance/converting/asMorph.st R EpiceaBrowsers.package/EpFetchMoreItem.class/instance/operations/timeString.st R EpiceaBrowsers.package/EpFetchMoreItem.class/instance/populating browser/displayWidget.st M EpiceaBrowsers.package/EpFilteredEntriesItem.class/definition.st M EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/entries.st R EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/entries_.st A EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/filteredEntriesCount.st A EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/filteredEntriesCount_.st A EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/olderFilteredEntry.st A EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/olderFilteredEntry_.st M EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/accessing/priorEntryReference.st A EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/converting/asMorph.st A EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/initialization/initialize.st R EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/populating browser/displayWidget.st M EpiceaBrowsers.package/EpFilteredEntriesItem.class/instance/testing/isCombinableWith_ifTrue_ifFalse_.st A EpiceaBrowsers.package/EpLogBrowser.class/class/instance creation/openWithItems_.st A EpiceaBrowsers.package/EpLogBrowser.class/instance/accessing filters/removeAllFilters.st M EpiceaBrowsers.package/EpLogBrowser.class/instance/initialization/initializeFiltersModel.st M EpiceaBrowsers.package/EpLogBrowser.class/instance/initialization/initializeItemsModel.st M EpiceaBrowsers.package/EpLogBrowser.class/instance/initialization/initializeTabs.st A EpiceaBrowsers.package/EpLogBrowserItem.class/instance/converting/asMorph.st R EpiceaBrowsers.package/EpLogBrowserItem.class/instance/populating browser/displayWidget.st M EpiceaBrowsers.package/EpLogBrowserView.class/instance/initialization/initializeBrowser.st M EpiceaBrowsers.package/EpLostChangesDetector.class/class/startup - shutdown/startUp_.st R EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/private - menu actions/redoMenuAction.st M EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/private - menu actions/redoSelectionCompleteRefactoringMenuAction.st M EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/private - menu actions/redoSelectionPropagateRefactoringMenuAction.st R EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/private - menu actions/undoMenuAction.st M EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/visitor/visitCodeChange_.st R EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/visitor/visitExpressionEvaluation_.st R EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/visitor/visitMonticelloVersionsLoad_.st R EpiceaBrowsers.package/EpMenuActionsVisitor.class/instance/visitor/visitRedo_.st R EpiceaBrowsers.package/EpPriorView.class/instance/initialization/initializeBrowser.st M EpiceaBrowsers.package/EpPriorView.class/instance/private/draggingPassengerMorphsFor_.st R EpiceaBrowsers.package/EpPriorView.class/instance/private/itemFor_.st M EpiceaBrowsers.package/EpPriorView.class/instance/private/newFilteredItemFor_.st M EpiceaBrowsers.package/EpPriorView.class/instance/private/next_from_.st M EpiceaBrowsers.package/EpPriorView.class/instance/refreshing/refresh.st A EpiceaBrowsers.package/EpRedoVisitor.class/instance/visitor/visitProtocolAddition_.st M EpiceaBrowsers.package/EpRedoVisitor.class/instance/visitor/visitProtocolRemoval_.st M EpiceaBrowsers.package/EpSelection.class/instance/accessing/entriesToRedo.st A EpiceaBrowsers.package/EpSelection.class/instance/operations/filterAfter.st A EpiceaBrowsers.package/EpSelection.class/instance/operations/filterBefore.st A EpiceaBrowsers.package/EpSelection.class/instance/operations/removeAllFilters.st M EpiceaBrowsers.package/EpSelection.class/instance/operations/spawnSorterWithSelection.st M EpiceaBrowsers.package/EpSelection.class/instance/populating menu/filtersSubMenu.st M EpiceaBrowsers.package/EpSelection.class/instance/populating menu/populateMenu_.st M EpiceaBrowsers.package/EpSessionBrowser.class/instance/refresing/refresh.st R EpiceaBrowsers.package/EpSorterView.class/instance/initialization/initializeBrowser.st M EpiceaBrowsers.package/EpSorterView.class/instance/private/wantedItemsFrom_.st A EpiceaBrowsers.package/EpUndoVisitor.class/instance/visitor/visitProtocolAddition_.st A EpiceaBrowsers.package/EpUndoVisitor.class/instance/visitor/visitProtocolRemoval_.st R EpiceaBrowsersTests.package/EpAbsentEntryViewTest.class/README.md R EpiceaBrowsersTests.package/EpAbsentEntryViewTest.class/definition.st R EpiceaBrowsersTests.package/EpAbsentEntryViewTest.class/instance/resources/newLog.st R EpiceaBrowsersTests.package/EpAbsentEntryViewTest.class/instance/resources/pageSize.st R EpiceaBrowsersTests.package/EpAbsentEntryViewTest.class/instance/tests/testRootItems.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/README.md R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/class/initialization/withMiniMonticello_.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/definition.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/instance/accessing/miniMonticelloResource_.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/instance/visitor/visitClassAddition_.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/instance/visitor/visitClassModification_.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/instance/visitor/visitClassRemoval_.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/instance/visitor/visitCodeChange_.st R EpiceaBrowsersTests.package/EpBeforeTestVisitor.class/instance/visitor/visitMethodModification_.st R EpiceaBrowsersTests.package/EpClassFactoryForTestCase.class/README.md R EpiceaBrowsersTests.package/EpClassFactoryForTestCase.class/definition.st R EpiceaBrowsersTests.package/EpClassFactoryForTestCase.class/instance/accessing/packageName.st R EpiceaBrowsersTests.package/EpFilterTest.class/instance/tests/testEvaluation.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/README.md R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/definition.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/classFactory.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/currentSnapshot.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/patchRelativeTo_.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/utilityPackage.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/utilityRepo.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/utilityWorkingCopy.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/workingPatch.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/accessing/workingSnapshot.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/actions/revert.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/actions/snapshot.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/running/setUp.st R EpiceaBrowsersTests.package/EpMiniMonticelloResource.class/instance/running/tearDown.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/README.md R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/class/accessing/resources.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/definition.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/asserting/assertNoChanges.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/asserting/assertNoChangesRelativeTo_.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/running/runCase.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/running/tearDown.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/test-generation/generateAllTests.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testBehaviorCategoryChange.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testBehaviorCommentChange.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testBehaviorNameChange.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testCategoryAddition.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testCategoryRemoval.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testCategoryRename.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testClassAddition.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testClassModification.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testClassRemoval.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testItem_.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testMethodAddition.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testMethodModification.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testMethodRemoval.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testProtocolAddition.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testProtocolRemoval.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testTraitAddition.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testTraitModification.st R EpiceaBrowsersTests.package/EpRedoAndUndoVisitorTest.class/instance/tests/testTraitRemoval.st R Ombu.package/OmSessionStore.class/instance/testing/isPointsTo_.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/README.md A Reflectivity-Tools-Tests.package/MethodConstTests.class/definition.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/constFromBlock_.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/constFromReceiverExpression.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/sumOfTwoConsts_and_.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/testAPIFromBlock.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/testAPIFromMessageSendReceiver.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/testConstPlaceInTransformedMethod.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/testTwoConstsInSameMethod.st A Reflectivity-Tools-Tests.package/MethodConstTests.class/instance/tests/testUsingConstJustInSameMethod.st A Reflectivity.package/extension/Object/instance/asMethodConst.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60162.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60163.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60162.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60163.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60163 18831 Integrate new Epicea version https://pharo.fogbugz.com/f/cases/18831 18768 Inlined method const could be implemented by metalinks https://pharo.fogbugz.com/f/cases/18768 18835 Update RBParser-Nodes class comments https://pharo.fogbugz.com/f/cases/18835 http://files.pharo.org/image/60/60163.zip

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Ben Coman

On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I will just re-post my first answer: > > if reintroduce them means reintroduce them hardcoded as before, then Iâm > complete against it and I WILL NOT integrate such solution. > Iâm sorry for being so strong here, but previous implementation was lame and > we need to get rid of them. > > Now, I understand people are used to use those bindings and also some others > (no idea which ones because I never used themâ¦ for me ocompletion is good > enoughâ¦ but those are tastes). So I would be very happy to integrate a > generic way to define keybindings and outputs (which is already there, with > keymapping, but I mean an editor or something), and I would be very happy to > integrate a default configuration (which of course, will include > #ifTrue:/##ifFalse:) I would guess code expansions could be many and varied between different individuals, and quickly consume available keyboard shortcuts. Perhaps a generic mechanism would be single shortcut for "code expansion" which processes the letters preceding the cursor. For example, using shortcut <ctrl-e> for code expansion and typing... itf<ctrl-e> ==> ifTrue: [ ] ifFalse: [ ] The could be an interface to define these code expansions - initially at least on a purely personal basis. > And this is not really for adding a new feature. This shortcut already (always :) ) existed With a single shortcut for code expansion, perhaps a few other existing combinations could be freed up. cheers -ben > > Esteban > > On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: >> >> I'm also against. >> >> - They take a place in the shortcuts that prevents others to use it >> - If lazy people really needs this, the code completion should be >> enhanced. This is a code completion concern... > > > +1 > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I will just re-post my first answer: > > if reintroduce them means reintroduce them hardcoded as before, then Iâm > complete against it and I WILL NOT integrate such solution. > Iâm sorry for being so strong here, but previous implementation was lame > and we need to get rid of them. > > Now, I understand people are used to use those bindings and also some > others (no idea which ones because I never used themâ¦ for me ocompletion is > good enoughâ¦ but those are tastes). So I would be very happy to integrate a > generic way to define keybindings and outputs (which is already there, with > keymapping, but I mean an editor or something), and I would be very happy > to integrate a default configuration (which of course, will include > #ifTrue:/##ifFalse:) > we already have PharoShortcuts>>#displayIfFalseShortcut ^ $f alt this is defined and therefore in the same kind "hardcoded" as any other shortcut doItShortcut ^ $d meta inspectItShortcut ^ $i meta In PharoShortcuts the action (RubSmalltalkEditor>>displayIfFalse: aKeyboardEvent) is just not (yet) bound to this shortcut. I don't see how this is an argument against this shortcut definition. All other shortcuts are defined like that. And this is not really for adding a new feature. This shortcut already (always :) ) existed in the old PluggableTextMorph based editor, it was just lost (and not on purpose I think) like other things when we moved to rubric (as you can see, the code for this action is already there in rubric). > > Esteban > > On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > >> I'm also against. >> >> - They take a place in the shortcuts that prevents others to use it >> - If lazy people really needs this, the code completion should be >> enhanced. This is a code completion concern... >> > > +1 > > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Esteban Lorenzano

I will just re-post my first answer: if reintroduce them means reintroduce them hardcoded as before, then Iâm complete against it and I WILL NOT integrate such solution. Iâm sorry for being so strong here, but previous implementation was lame and we need to get rid of them. Now, I understand people are used to use those bindings and also some others (no idea which ones because I never used themâ¦ for me ocompletion is good enoughâ¦ but those are tastes). So I would be very happy to integrate a generic way to define keybindings and outputs (which is already there, with keymapping, but I mean an editor or something), and I would be very happy to integrate a default configuration (which of course, will include #ifTrue:/##ifFalse:) Esteban > On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > I'm also against. > > - They take a place in the shortcuts that prevents others to use it > - If lazy people really needs this, the code completion should be enhanced. This is a code completion concern... > > +1

Aug. 3, 2016