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 (<kilon.al...@gmail.com>) 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 <jose.sanlean...@osoco.es> > 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 (< >> kilon.al...@gmail.com>) 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 <kksubbu...@gmail.com> wrote: >>> >>>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote: >>>> > >>>> > >>>> >> On 24 Jan 2019, at 17:04, K K Subbu <kksubbu...@gmail.com> 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 >>>> >>>>
