yeah the System Browser has some shortcuts that you can find if you click that down arrow in top right corner of the window
About getting Window info, that is tricky, all is available through Morphic but Morphic is kinda messy. So if you are willing to do the hard work its definetly doable , you can create your own shortcuts etc. Finding the leftmost probably you will ask the World morph about all windows , ask each window whether its opened and if yes where is located (morph >>position) I think the focus is in SystemWindow >> isActive , look also at basicActivate for a better idea what activation means For groups there is isEmbeded , also Morph >> embededMorphs No idea about the Playground, it keeps timestamped session of whatever you do so there is definetly something Yeah Pharo is not Emacs that's for sure. Mainly because we attract people who are mouse driven, people who are keyboard driven tend to avoid IDEs. Its doable , its just not available out of the box. I can feel your pain though, this has been an issue for me with Pharo, the power is there, but its not easy to access. However to be fair Emacs has been around a lot longer and has far larger community of contributors so its no wonder it can do these things with ease. Emacs also has amazing documentation. But sadly is no IDE and its shortcuts is pure insanity, but then I am a mouse person myself. Ironically I was raised on CLIs and I always hated them with passion :D On Thu, Jan 24, 2019 at 8:32 PM Jose San Leandro <[email protected]> wrote: > I don't want to hijack this thread, but it would be useful for me to have > a cheatsheet to allow me to do the usual operations I do with the mouse, > programatically. I've had some difficulties with simple things in the past. > For example, to delete all Transcript or Playground windows, I use calls > such as > > (World submorphs select: [ :w | ((w model printString beginsWith: 'a >> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ]) >> do: [ :w | w delete ]. >> > > I'm missing ways to query World submorphs to know exactly my target > instance. For example: > - Which is the leftmost window? > - Which window has the focus? > - Which windows have "grouping" enabled? > - Which Playground instance I used more recently? > > And operations such as: > - Maximize morph. > - Activate "class side" in Nautilus. > - Select "accessing" protocol. > - Select package X. > - Select "Hierarchy". > - Choose the next child when "hierarchy" is active. > >> - Resize the method panel. >> > > Also, basic things like: > - Move to the next word. > - Highlight previous word. > - Highlight current line. > > That would be very helpful for me. I'm not saying it's difficult to do, > I'm just saying for me it'd be helpful. > That's basically why I love Emacs, because I can do with the keyboard > anything that can be done with the mouse, and more. > > Thanks! > > El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis (< > [email protected]>) escribió: > >> Playground is a REPL inside Pharo so I am not sure I understand what you >> are asking. Everything in Pharo is just Classes and methods so you can do >> whatever you want. If you are a bit more descriptive maybe I can help you >> more. There is no such thing as a bad idea, just an idea that has not >> mature enough :D >> >> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro < >> [email protected]> wrote: >> >>> I was aware of that. I was imaging a way to use the tools available in >>> Pharo, but within a REPL session. >>> Probably a bad idea anyway. I just think the mouse is useful when >>> exploring, but it's ridiculously inefficient once you know exactly what you >>> want to do. >>> In my 4k monitor I often feel like if I was saying "no, I want to resize >>> the window, not moving it, not changing the focus, thanks". I have to waste >>> time being accurate enough with the mouse, because it's the expected way to >>> communicate with live objects. Mouse, then keyboard. Not good. >>> >>> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (< >>> [email protected]>) escribió: >>> >>>> "I am sure there will always be skeptics. But my own experience was >>>> different. For me, the most weird thing about Squeak (and now Pharo) >>>> IDE >>>> is its insistence in showing only one method at a time. A method is too >>>> small a chunk of code. It is easy to miss the forest for the trees. In >>>> Dimitris video, you see lots more code in one glance in vim session. So >>>> there are pragmatic reasons why some coders fallback to using fileOuts >>>> for browsing classes." >>>> >>>> I could not agree more , I find the column GUI weird and a waste of >>>> space. This is why I have ended up relying a lot on GTSpotter (finder) >>>> which help me browse classes a lot faster than the class browser. Kinda >>>> ironic. >>>> >>>> I am using Pharo since 2011. I am still dont like Class Browser :D >>>> >>>> "In summary, if someone misses Emacs or Vim when working with Pharo, it >>>> could be due to: >>>> - being stuck in the file-based way to think of coding. >>>> " >>>> Its a common misconception that Pharo does not heavily rely on text >>>> files, it actually does. Not only the source file makes it possible to view >>>> the code even the oldest method of version control tha Pharo being a fork, >>>> inherited from Squeak, the known mcz files they may look small binary files >>>> like the Pharo image but they are merely zip files with source code text >>>> files with the st extension. >>>> >>>> The image is merely the bytecode, the VMs machine code sort of, the >>>> actually source works the same way as other languages. Like other languages >>>> you dont need the source code to execute , only the bytecode. What makes >>>> the image special is that its one file and its a memory dump which makes it >>>> easy to store both live code and live state. Which is very helpful, >>>> technically its mandatory for true live coding, but still Pharo has to rely >>>> on source code files to make our lives easy. From there on is just a >>>> question whether you break the source code files in several small ones, or >>>> keep one large. >>>> >>>> "Besides that, is there an easy way to run an image in text-only mode, >>>> with a REPL or a playground or something like that?" >>>> >>>> Yeap its possible and has been around for a very long time. Pharo also >>>> makes it dead easy to expose any method as command line argument, so its >>>> possible to code completely from the command line although definitely not >>>> recommended. >>>> >>>> Deep Into Pharo book explains how. >>>> >>>> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu <[email protected]> wrote: >>>> >>>>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote: >>>>> > >>>>> > >>>>> >> On 24 Jan 2019, at 17:04, K K Subbu <[email protected]> wrote: >>>>> >> >>>>> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote: >>>>> >>> Everybody is of course totally free to do whatever they want, >>>>> >>> but really, why the hell would you want to do that ? >>>>> >> Because text has many uses other than just feeding into a compiler >>>>> >> for translation to machine code? People who come from Unix/Linux >>>>> >> world are used to using a rich collection of tools that deal with >>>>> >> text in various ways. >>>>> > >>>>> > I am myself a server/linux guy, an emacs user, I know what is all >>>>> > possible and what the unix philosophy is. >>>>> >>>>> >>>>> No offense intended. Just wanted to point out that text can have >>>>> different purposes. Historically, Smalltalk presented itself as a >>>>> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform >>>>> IDE. >>>>> >>>>> > I also know how to integrate Pharo into that world, and this is super >>>>> > important. >>>>> Thanks. This is what I intended to bring out. >>>>> >>>>> >>> You lose so much by doing that, I do not even know where to >>>>> >>> start. >>>>> >> >>>>> >> Live coding (i.e. coding in the presence of instances) is >>>>> >> undoubtedly more powerful than edit-compile-run cycle. Text is used >>>>> >> to direct IDE to edit live objects. But text has many more uses >>>>> >> than just issuing commands. If beginners start using vim just to >>>>> >> edit code due to established habits, they will soon realize the >>>>> >> ease of live coding and remain in IDE. This is a self-correcting >>>>> >> error. >>>>> > >>>>> > Well, I don't think so. >>>>> > The users that you are going to attract in this way (the ones that >>>>> > don't want to leave their own IDE/editor), will look at textual Pharo >>>>> > and find it very strange and ill suited to textual editing (and they >>>>> > are absolutely right), they will not discover the power, will not >>>>> > learn (from this experience alone) what object >>>>> > design/programming/power is, and will ask for more (e.g. give me , >>>>> > style compiler errors, better/easier structure of the file, fixed the >>>>> > !! escape issue, etc, ...). >>>>> >>>>> I am sure there will always be skeptics. But my own experience was >>>>> different. For me, the most weird thing about Squeak (and now Pharo) >>>>> IDE >>>>> is its insistence in showing only one method at a time. A method is >>>>> too >>>>> small a chunk of code. It is easy to miss the forest for the trees. In >>>>> Dimitris video, you see lots more code in one glance in vim session. >>>>> So >>>>> there are pragmatic reasons why some coders fallback to using fileOuts >>>>> for browsing classes. >>>>> >>>>> Regards .. Subbu >>>>> >>>>>
