My friend read your email and remarked: "How is this guy not embarrassed posting on the internet about not liking vim because he doesn't like editing config files?" On 21/05/07, Michael T. Richter wrote:

On Mon, 2007-21-05 at 11:47 +0100, Jules Bean wrote:

Michael T. Richter wrote:> 1. A real GUI environment that takes into account some of the HID> advances made in the past 30 years. (Emacs and Vim don't count,> in other words.)

That particular part is trolling. Both emacs and vim take into account many of the HID advances made in the past 30 years. You're going to have to be more explicit about what you find unacceptable about them to get useful answers, in my opinion.

Vim is eliminated before it reaches the gate because it's a modal editor. Even with GVim in place, it still has that modal stench to it that leaps up and bites at awkward moments. And HID advances (the modal issue aside)? Go to an underpowered little editor like Gedit (what I use currently for raw Haskell, but which sadly isn't applicable to .lhs files of either stripe) and adjust your editing preferences. It's not a particularly good programmer's editor, but look at the lovely tabbed dialog box with all those lovely HID bits like checkboxes, radio buttons, spin buttons, dropdown lists, lists, etc. Now do the same in GVim and get ... a text file with some editing tricks to make things slightly easier. (It's not immediately obvious how to get rid of it either.) Where is the accounting for HID advances there? (Raw Vim is even worse.)

Hell, even comparing the out-of-the-box syntax highlighting support in Gedit vs. (G)Vim is instructive. Code like "makeRandomValueST :: StdGen -> (MyType, StdGen)" (which, incidentally, was far easier to copy from in Gedit than GVim to paste into this message) only differentiates "::" and "->" from the text and delimiters in GVim while in Gedit (keeping in mind that Gedit isn't a very good editor!) differentiates those *plus* "makeRandomValueST" vs. "StdGen" and "MyType". And the parentheses.

(G)Vim is losing to freakin' GEDIT here! The Notepad of the GNOME world.

Emacs is its own set of nightmares. I'm not even going to start going down the path of that particular holy war (and bucky-bit Hell). I'll acknowledge freely that it's an incredibly powerful programming environment. It just really doesn't play well with others at almost any level and quite definitely doesn't have anything resembling modern HID thought behind it. (To be fair to it, it does predate most modern HID work by a couple of decades.)

-- *Michael T. Richter* (*GoogleTalk:* ttmrichter@gmail.com) *All really first class designers are both artists, engineers, and men of a powerful and intolerant temper, quick to resist the least modification of the plans, energetic in fighting the least infringement upon what they regard as their own sphere of action. (Nevil Shute)*

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, 2007-21-05 at 13:04 +0100, Rodrigo Queiro wrote:

My friend read your email and remarked: "How is this guy not embarrassed posting on the internet about not liking vim because he doesn't like editing config files?"

Because, unlike your friend, I actually have seen the advances in HID over the past 30 years. Editing text files is not the be-all/end-all of user interfaces. Indeed there is astonishingly high volumes of evidence showing that it's a pretty miserable user interface -- a misery amplified by the fact that every two-bit program has its own entirely unique syntax (usually broken in many exciting ways!) full of cryptic commands and settings. Don't believe it? Go to your home directory and compare all the .<files> you find. You really think it's a good thing to maintain each of those manually? Oh, and of course it wasn't just the config files I showed problems with, now, was it? I seem to remember something about modality and bad syntax highlighting. Maybe I was tripping. It happens. For your friend's reference, here's a good outline of what principles underlie HID: http://www.asktog.com/basics/firstPrinciples.html. For even more modern outlooks, I'm sure a quick search at Amazon.com (or his bookseller of choice) can give him other ideas. So am I embarrassed for asking for something resembling a 21st-century user interface instead of a 1970s vintage one? Not in the slightest. -- Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it. (Steve McConnell)

Hi Can everyone just relax a moment. There are different editors which suit different people. Most VIM/Emacs users wouldn't ever consider changing. Michael is asking "is there something more GUI like?" - to which the answer is yes - Visual Haskell - http://www.haskell.org/visualhaskell/ . It doesn't tick all the boxes, but it sounds to be the kind of thing you are driving for. I personally use TextPad (www.textpad.com) because it has a very nice user interface and does exactly what I expect every single time. Your text editor is merely an interface between your brain and the computer, its not surprising everyone has different preferences. Thanks Neil

Your rant accomplishes nothing. Just note that programmers can generally be considered more open towards harder-to-learn but eventually more efficient to use interfaces. Yes, to a large part they lack visibility, consistency, integration, or other such properties; then again, once you learn to use them you're so much more efficient than before. And you loose the incentive to improve things. So instead of insulting people and complaining that nothing fits your needs you have at least two options: 1. Implement it. Of course, this is a _major_ effort and many many things are completely unsolved research issues. 2. Take what's there, learn to use it. Yes, it will lack so many things but one way or another you'll eventually get things done. On 5/21/07, Michael T. Richter wrote:

On Mon, 2007-21-05 at 13:04 +0100, Rodrigo Queiro wrote:

My friend read your email and remarked: "How is this guy not embarrassed posting on the internet about not liking vim because he doesn't like editing config files?"

Because, unlike your friend, I actually have seen the advances in HID over the past 30 years. Editing text files is not the be-all/end-all of user interfaces. Indeed there is astonishingly high volumes of evidence showing that it's a pretty miserable user interface -- a misery amplified by the fact that every two-bit program has its own entirely unique syntax (usually broken in many exciting ways!) full of cryptic commands and settings. Don't believe it? Go to your home directory and compare all the .<files> you find. You really think it's a good thing to maintain each of those manually?

Oh, and of course it wasn't just the config files I showed problems with, now, was it? I seem to remember something about modality and bad syntax highlighting. Maybe I was tripping. It happens.

For your friend's reference, here's a good outline of what principles underlie HID: http://www.asktog.com/basics/firstPrinciples.html. For even more modern outlooks, I'm sure a quick search at Amazon.com (or his bookseller of choice) can give him other ideas.

So am I embarrassed for asking for something resembling a 21st-century user interface instead of a 1970s vintage one? Not in the slightest.

-- Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it. (Steve McConnell) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- "Remember! Everytime you say 'Web 2.0' God kills a startup!" - userfriendly.org, Jul 31, 2006

Vim is eliminated before it reaches the gate because it's a modal editor. Even with GVim in place, it still has that modal stench to it that leaps up and bites at awkward moments.

that's a bit more specific, at least. but as far as i recall, modes were considered bad for specific reasons, such as 'users can't see where they are, modewise', 'functionality becomes unavailable in a mode', 'users have no way to get out of a mode', etc. and most of these specific issues have actually been addressed in vim. so, what remains is convenience: do i always want to start navigating from some home mode (meaning long, absolute, command navigation strings), or do i want the interface to remember where i navigated last (meaning short, relative, command navigation strings)? what used to be called modes (bad, or rather: badly implemented) is now called context-sensitivity (good, or rather: good, if done well). you do not want your fortran- or xml-editing commands around when editing haskell, so unless you're prefixing every command with 'haskell-', or refuse to use haskell-specific commands, you're editing haskell in a haskell-mode, right? you could use insert mode as your home mode, and wrap each command sequence to leave insert mode and to return to it, so 'dd' would become '<esc>ddi'. or you could use normal mode as your home mode, and make sure to end every excursion into insert mode with '<esc>'. or you could use vim as it was intended: using insert mode, or normal mode, for what they are good at, and switch between them whenever you like. have you tried 'easy vim', btw? i don't like it myself, but it is useful for getting students started quickly (':help easy', ':help evim-keys'): -y Easy mode. Implied for |evim| and |eview|. Starts with 'insertmode' set and behaves like a click-and-type editor. This sources the script $VIMRUNTIME/evim.vim. Mappings are set up to work like most click-and-type editors, see |evim-keys|. The GUI is started when available. {not in Vi}

files of either stripe) and adjust your editing preferences. It's not a particularly good programmer's editor, but look at the lovely tabbed dialog box with all those lovely HID bits like checkboxes, radio buttons, spin buttons, dropdown lists, lists, etc. Now do the same in GVim and get ... a text file with some editing tricks to make things slightly easier. (It's not immediately obvious how to get rid of it either.)

you're referring to ':options', i assume? and you're aware that the sheer number of options would make a single dialog box hard to design in any useful way? gvim actually permits setting a whole lot of options via its menus, and i tend to set options either in my vimrc file or in a filetype plugin, or directly, using ':set'+tab for command-completion/navigation. yes, the ':options' window doesn't look pretty, merely functional. on the positive side, it is just another text window, so you navigate in it they same way as in any other text window (no separate dialogue-box-mode!-). and since vim is about programmers editing (program) text, handling everything as text is consistent. claus

On 5/21/07, Michael T. Richter wrote:

Code like "makeRandomValueST :: StdGen -> (MyType, StdGen)" (which, incidentally, was far easier to copy from in Gedit than GVim to paste into this message) ...

Really? To copy that line of code in vim you could do: v%y assuming the cursor is in the right place (at the start of the code) and if it isn't it's easy in vim to get it there! Of course, in Windows you must have "guioptions=a" in your config so that all yanks go directly to the Windows clipboard (which should really be in there by default but it isn't). Vim is extremely powerful, but I understand that the steep learning curve is a problem for many. As a developer, I would recommend taking the time to learn advanced features of any editor (whether emacs, vim, or whatever). I presume most developers on this list use regular expressions to navigate their code despite the relatively steep learning curve, correct? BTW: Hello everyone - first post! I planned to wait to introduce myself as a Haskell newbie when I came up with my few questions but as a Vim lover I couldn't resist posting about this! Paul.

apfelmus wrote:

I can't know whether that's the case, but the fact that virtually all commands are invoked with the keyboard clashes with HID research reported at

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is:

"* Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding."

The research there is reported as hearsay, it is not referenced research, so I can't check their methods. Despite the implicit claim that my brain must be lying to me and causing amnesia I'm unaware of, I would dispute the claims there. I suspect there might well be a large body of users (even 'most') for which it's true. However 'most' people are not fast typists. I'm sure that I can quite reliably hit the command editor keybindings I use many, many times faster than if I had to select them from a menu. Jules

...

I'm sure that I can quite reliably hit the command editor keybindings I use many, many times faster than if I had to select them from a menu.

Note that the claimed time-consuming part is not to actually press the keybinding, but to chose and remember which one to press.

Yes... except that for a lot of people, programmers especially, a lot of key bindings have become part of your motor memory, and so you can probably hit the common ones quite quickly without having to stop to think about which combination of keys to press. Cut/copy/paste are good examples of this, I think. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

On Tue, 2007-22-05 at 10:19 +0200, apfelmus wrote:

I can't know whether that's the case, but the fact that virtually all commands are invoked with the keyboard clashes with HID research reported at

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is:

"* Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding."

You beat me to the punch. And to exactly the same URL, in fact. I see strong parallels between the insistence that keyboarding is faster than mousing and the insistence that manual memory management is faster than automated memory management. -- Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) In his errors a man is true to type. Observe the errors and you will know the man. (孔夫子)

...

"* Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding."

Even if it is empirically true that mousing is wall-clock faster than keyboarding, one has to ask the question why users feel internally that keyboarding wins. Perhaps it is because using the mouse requires a cognitive switch from editing the document, to a physical hand-eye co-ordination task, and back again? The mental effort of switching might be harder work than keeping your focus on the document at all times, and therefore switching _feels_ as if it must be slower. Of course this assumes that the person is sufficiently skilled at typing on a keyboard that they do not need to look at it, and hence their eye can stay with the cursor in a window on the screen. Perhaps you can find and move your mouse using only peripheral vision, but even so, the first cognitive task you need to accomplish is to find the mouse pointer on screen, which is invariably in a different place from the text cursor, and so drags your attention from one focus to another. Regards, Malcolm

This recent development of the thread leads me to these conclusions and conjectures. * If you want to demonstrate the mouse to be faster than the keyboard, you can contrive an experiment to do so. Example: Randomize occurences of X's in a text, ask to replace them by Y's, but make sure there is no find-replace command or wizard to help. * If you want to demonstrate the keyboard to be faster than the mouse, you can contrive an experiment to do so. Example: Ask to crack open your favourite Haskell textbook and enter it into the computer. Some of us raise that speed is not the only concern. Indeed, cognitive switch may be more taxing on the worker. However, going on a limb, I'm going to wager that: * If you want to demonstrate the mouse to be less taxing than the keyboard, you can probably contrive an experiment to do so. * If you want to demonstrate the keyboard to be less taxing than the mouse, you can probably contrive an experiment to do so. The keyboard-mouse duality (duelity?) doesn't end here. Some of us explains that keyboarding has become part of our motor skill, and mousing has not quite. So I ask, are there also people who are the opposite? One year I went to COMDEX Canada (in Toronto) and saw a live demo of Photoshop or something. The demonstrator was amazing. He clicked through the menu system faster than I could watch! He performed long sequences of back-to-back menu mousing at a sustained speed paralleling that of my keyboarding. You may say "aha, Photoshop, analog!" but no, in his demo analog operations were the minority, the majority was on the discrete menus - I do mean it when I say long sequences of back-to-back menu mousing. A possible objection would be that he practiced on his demo. But I do invite you to observe someone who uses Photoshop or the like professionally; you may see a level of mouse-fu you never thought possible. But all this musing on HCI and HCI research may all be just talking wind because: Michael T. Richter wrote:

All this talk about "efficiency" while editing text would make me believe that most of my time spend writing software is typing. Yet, oddly enough, I find that the typing is the *least* of my tasks. Most of my work is done in my head, on whiteboards or on scraps of paper long before my fingers stroke a keyboard.

Conventional wisdom would say: Then the priority is on improving the head, the whiteboard, and the paper. Give secondary priority to HCI and IDE dreams.

it should also be noted that there are rsi issues with switching constantly between mouse and keyboard. moving to an environment that focuses on textual input (mutt+emacs+elinks on top of screen on top of xmonad) has allowed me to keep my hands in the ergonomic position dictated by my keyboard. for people with extreme-ergo keyboards (kinesis etc), keeping your fingers in position is important

Ketil Malde wrote:

On Tue, 2007-05-22 at 10:19 +0200, apfelmus wrote:

...

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is:

"* Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding."

Interesting! I did a quick test doing search and replace using the keyboard and the menus in Emacs. It takes me about six seconds with the keyboard, and closer to ten using the menus. (The first time, it took thirty as I spent time to locate the correct menu options :-)

But I agree with the report that using the mouse *feels* a lot slower. Quoting the report: "It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function." I'm not so sure I agree, using the mouse feels way more abrupt and intrusive.

The question is whether the stopwatch feels the same way :)

I can do M-x repl TAB str TAB foo RET bar RET with my eyes closed¹, but to use the mouse, I need to locate the mouse with my hand, locate the mouse cursor, locate the menu, etc etc.

Note that "locate the menu" is indeed something may take more time than it should. Traditionally, Mac OS features a single menu bar at the top of the screen as opposed to Windows or GNOME. This is a consious design choice whose rationale is explained at http://www.asktog.com/columns/022DesignedToGiveFitts.html In short, Fitt's Law says that the amount of time to navigate to a target on screen depends logarithmically on the ratio (size of target / distance to target). Now, a menu bar at the top of the screen has effectively infinite target size, you can just throw your mouse pointer to the top of the screen and be assured that it hits the top edge = the target. This is much faster than targetting a small menu attached to a window. And it has the additional side effect that the task "locate the mouse pointer" can be partially omitted because only the horizontal position matters if you're going to throw the pointer to the top of the screen anyway. Regards, apfelmus

...

1. A real GUI 2. Good quality syntax highlighting for Haskell..., plus: 3. raw Haskell both forms of Literate Haskell; 4. properly highlight Haddock comments; 5. highlight functions and types from libraries differently from local 3. Line folding to hide and show blocks of code. 4. Code completion 5. Easy, quick access to online documentation 6. access to external utilities for compilation, debugging, profiling, type inference, project management, etc. 7. A good plug-in system

Having dismissed Visual Haskell for being Windows-only, have you considered EclipseFP? It doesn't tick all of your boxes, but maybe it goes far enough in the right direction. AFAICT it fulfills 1, 2.3, 2.5 (but I'm not sure about this), 3, 6, and 7 (ish - plugins would be written in Java). There is also some experimentation under way to implement plugins in Haskell: http://leiffrenzel.de/eclipse/cohatoe/ The Haskell code is

Bayley, Alistair wrote: plugged into Eclipse via hs-plugins. However, the ultimate entry point to the IDE is still Eclipse's, so there will be some Java/XML boilerplate necessary for getting a plugin hooked. Thanks && ciao, Leif

Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

While I strongly disagree with you on the fact that "refactoring" is just big macros (well it is, simply they're macros which operate more on structured code than on structured text, ie they're aware of the semantic of the language on which they're operating, and I don't know you but I don't code macro like that in less than a few days/weeks (/months ?)... Let's say _really_ big macros and settle at that), I thank you for introducing me to acme. It seems really interesting, and with the acme-sac project I can use it on my OS. So thanks. (Oh and if you saw things your coworker called refactoring and you would have done as well with a one-line macro in emacs (or even a standard command), it's just that you're right to consider "refactoring" as a buzzword, but it's not only that) -- Jedaï

Am 23.05.2007 um 00:20 schrieb Ashley Yakeley:

I don't suppose you're familiar with the Dylan programming language, or more to the point, have looked at the IDE that Apple included in their original implementation of the language (around 1993 or so)? Characteristic of Apple of that time, the UI was both highly innovative and a joy to use. It was based around "browsers", where each browser had a "subject" (such as a project, module, definition etc.) and an "aspect" (such as "contents of", "errors in", "references to", "direct methods of" etc.). Browsers could be linked so that the selection in one browser became the subject in another. This made it very easy to navigate your project.

All code was stored in a database rather than as text files, and individual code definitions were separate objects in the browsers rather than pieces of text in a big file.

Info w/ screenshots: http://osteele.com/museum/apple-dylan http://wiki.opendylan.org/wiki/view.dsp?title=Apple%20Dylan Needless to say, this goes in rather the opposite UI direction to the "Ctrl-M Ctrl-Meta-Z <esc> :edit qx" approach to editors that some people prefer.

Dylan's not a bad language, and there are open source implementations available for Gnu/Linux. But if you want to check out Apple's IDE, you'll really need a 68K Mac, as the PPC version is very buggy and I don't think the 68K version will run in PPC.

Michael's blog: http://snakeratpig.blogspot.com/2007/02/road-to-haskell.html Dylan and Haskell are very similar in the multiple-dispatch (a haskeller would call that pattern matching on several arguments) respect. Cheers, Gabor PS: Btw, the Apple Dylan IDE works well on PPC if you apply a patch that was issued by Digitool shortly after the initial port of the IDE to PPC.