The shortcut based interface has been tried and has failed. It works well for medium size complexity but to rely the whole functionality of a very complex application to shortcuts is not anything shorter than insane. So shortcuts are without any doubt useful and should be used by all apps but they can go so far.

Add to that the emacs shortctus are mess , a huge mess. Many of them make zero logical sense with some really weird keyboard combinations. Emacs has not solve the problem of UI it has made severely worse and the same story goes for Vim. Both projects rely on the obsession of coders with relying on command line interfaces. Command line are of course much simpler to customise and produce but design wise they come with some inherit weakness.

The thought that I need to search for a buffer, setup buffer groups , create tabs , use a weird complex shortcut etc when I just can use my mouse and in one second click the window I want is a no brainer for me. Its not just simple , its better.

Bare in mind, I come from Emacs, actually it was Emacs people (at #emacs in irc) that introduced me to squeak and then to pharo. Without emacs I would not be here . I still use #emacs to edit files because is such a great editor. I love emacs . But a good UI ? Nope, definitely not in my book. Actually Emacs for me is proof why text based UIs will never be able to compete with GUIs because emacs is one of the best and still very difficult to use.

Do I want some of the emacs buffer management tools in Pharo ? Sure
Will they improve the workflow ? Absolutely
Will they solve the problem ? Nope

I think Spotter can play a very good role in the management of windows to implement functionality similar to Emacs.�� But no I wont trade the Pharo mess for the Emacs mess not even in a 1 million years. I was raised with text based interfaces and command lines since 1988 and I always had and will forever hate them.��

For me at least the future is AI GUIs , GUIs that watch user actions , understand his habbits and automate the workflow with minimum amount of manual customization.�� There was a tool once promoted here that watched the usage of windows and the ones least used were closed which I think is a step towards the right direction but its definitely a very long road ahead.



On Tue, May 19, 2015 at 5:42 PM Avdi Grimm <avdi@avdi.org> wrote:
On Tue, May 19, 2015 at 3:53 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:


About general GUI and UI designs its not any less nightmarish to open multiple windows in Pharo than it is to open multiple buffers in emacs. The diffirence between the two is that with emacs you have the nightmare of lack of any GUI while in pharo you have the lack of sophisticated editing.


With respect, this is manifestly untrue. Buffer management is a solved problem in Emacs. In fact, it's been solved and re-solved many times over, to the point where it can suit anyone's tastes. Whether you want:

* To simply toggle between the last few buffers
* To list, sort, and filter buffers quickly until you find the one you want
* To do fuzzy-completed searches on buffers
* To manage buffers in tabs and tab groups
* To have sidebars listing open buffers
* To kill or operate on many buffers at once based on what project they are in or some other criteria
* To have a fully window-managed interface that can save, reload, and switch between different window configurations for different contexts at a keypress
* To forget about buffers completely, and just navigate to the thing you want to see (and let Emacs worry about what buffers happen to be in memory)

(And lest anyone say that buffer management is a different problem from window management, remember that Emacs is an application environment, and that a "buffer" may be a full application window, such as an IRC channel or even a Smalltalk-style browser.)

Whether you want any of these features or many others, there are mature and well-tests solutions for all of them. Whereas as many longtime users have confirmed in this thread, Smalltalk environments don't even have the window management to match the Emacs built-in features, let alone the mature extension ecosystem.

I made my original seven-minute Pharo video with the intent of getting traditionally IDE-averse Ruby programmers to realize some of the things they are missing.����It's way too easy to say "oh, no one else has solved this any better". And as a result, a number of people said "wow, I usually hate IDEs but I need to check this out". But this cuts both ways.
��
Pharo is doing some good work on this area but realistically , the community is too small to solve such a huge problem even with pharo ease of use.


This I agree with completely.

My favorite OS for programming is Linux. In linux, window management is a problem that has been solved many times over. There are dozens of window managers (hundreds, if you count inactive projects).�� There are high-tech compositing window managers that can do MacOS-style Expose zoom-out for quickly locating windows. There are WMs that rigidly control where windows show up, based on a policy you decide. There are all kinds of different aids for quickly listing and navigating between windows.

It took thousands of programmers decades of work in many different languages to create this variety. I'd hate to see the smaller Pharo community pour tons of effort into re-inventing these solutions.

Which is why I'm suggesting that it may be more helpful to re-frame the problem. General purpose window management is a problem that has been solved many times over. Do you really want to do it yet again? I suspect that with some careful examination of Pharo coding workflows, you could find a way to obviate the need for zillions of windows, and solve a simpler problem instead.