GUI vs. CLI

[Kirby54925]

Which one shall prevail???????

Currently, CLI is still king in many aspects. However, I sincerely want GUI to replace most situations where CLI is normally used. CLI in my view represents a very old-fashioned 1980's way of thinking when it comes to doing stuff on a computer. C'mon people, this is 2008! We should be past that geeky, kludgy phase already and focus more on more natural ways of doing stuff (i.e. Minority Report style, but that's more of wishful thinking )

[Gadren]

I don't object to people making GUI frontends for CLI actions -- in fact, I'm glad to have GUIs for things like wireless configuration in Linux, which I can't do in the CLI -- but I don't like the idea of getting rid of things just because they're old.

One advantage of the CLI in *nix is the ability to pipe the output from one program directly into another. This sort of thing is really useful if you use it right.

Also, Minority Report's GUI isn't all that usable, IMHO. One big reason why touchscreens have never really caught on is because of something called "gorilla arm," which is where your arms feel stiff and tired when holding them up in the air making tiny movements.

[Kirby54925]

At least they get some brownie points for trying...

[Berengal]

I like both. The GUI is nice because it's easy to navigate, and you know what's in front of you, but has the disadvantage of flexibility. If you want to make the GUI do something new, you have to program up a whole new GUI yourself. The CLI allows you to do all sorts of crazy things you can't do in a GUI that hasn't been told exactly what it is you want to do already, there's a reason GUIs aren't turing complete, and it's simply easier to use for some tasks such as navigating folders with lots of files. You've also got the entire OS at your fingertips, while the GUI might miss out on stuff that hasn't been put in the right configuration files.

Personally, I like a mix of them; compiz fusion + GNOME-terminal = wobbly bash

[++$_]

GUIs are for doing one thing at a time. They are also easier to learn (for most people; not so much for me).

CLIs are for doing lots of things at once. They are also inherently easier to script.

This makes CLIs faster and better than GUIs, IMO. Since they are also just as fast for doing a single thing, I see no reason at all to switch to GUIs.

In my view, the best option is to have a hybrid interface, where either text or graphical input drives a graphical display system (which could, of course, display text when necessary or desired). The only rules would be:

1. The text input allows you to perform any function with maximum flexibility with a single command (no paging through menus is allowed)
2. The graphical input allows you to perform common tasks with 1-2 clicks, or more unusual ones through menus and/or dialog boxes. Again, all functionality is available through the graphical system, but perhaps some flexibility is lost.

A reasonably good example is most modern Linux. Let's say the task you want to perform is removing files; you can do this with rm <filename>, or with a couple of clicks on the GUI. Text-based inputs allow you to issue the command with greater flexibility (through shell globs and pipelines), but with enough patience you can achieve the same effects through the GUI; you just have to manually find the files you want to remove rather than having the machine do it for you.

As of yet, Linux does not have perfect GUI support (one of the reasons it's not making serious forays into the desktop market, IMO), so it doesn't (yet) have the hybrid interface I'm envisioning.

EDIT:

...I'm glad to have GUIs for things like wireless configuration in Linux, which I can't do in the CLI...

This was one time I was very happy to have the GUI. However, after not too long, I decided that I would make more progress by editing the config file directly, since the GUI was giving me trouble. This is why I think text interfaces are very important; they help you get around the limitations inherent in any GUI, and allow you to better understand exactly what you are doing to the computer.

[Micron]

I'm not sure how you would compare the two since the features of each really target different users and behaviors. For example a CLI is good at showing a history of your actions and chaining actions together. Off hand I can't think of a GUI that really considers those important enough to try to provide equivalents. Similarly a GUI is much better at allowing users to discover functionality and sort items by visual location which are often not concerns for problems the command line focuses on (although more discoverablity would be nice).

Overall I think I have to side with the GUI approach since I find myself arranging things (including command line terminal windows) visually and prefer an interface where the computer can keep the display in sync with changes to the system rather than giving me a snapshot every time I issue a command line command. However I know I'm biased by the tasks I need to do right now and I still haven't seen a GUI implementation that serves as a better tool than a CLI in many many cases, even though I think such a design is possible.

[FACM]

I like having both interfaces available to me. Some things aren't as nice from the command line, and some things are worse from a GUI.

Example 1: Photo editing. GUIs make this far easier than typing in individual commands and changes to a photo.

Example 2: Changing a MAC address on a faulty ethernet card. Compare:
ifconfig eth0 hw ether addr 123456789012 up
versus
Preferences/Administration/Network/Wired Ethernet(eth0)/Properties/Advanced/Hardware Address:123456789012/Apply/OK.

Drawn out like that, the GUI isn't really faster or easier. It could be argued which one is faster if you don't already know what to do, at which point it's whether digging through GUI options and pages is faster to find what you want than 'man -k MAC address'

[zenten]

There's only one reason that I need a GUI for file browsing I can think of. To open a file in another program, that may or may not be running.

Sure I can do it with something like:

<program name> <filename> &

But remembering the name of the program is harder than just double clicking.

[masher]

Example 2: Changing a MAC address on a faulty ethernet card. Compare:
ifconfig eth0 hw ether addr 123456789012 up
versus
Preferences/Administration/Network/Wired Ethernet(eth0)/Properties/Advanced/Hardware Address:123456789012/Apply/OK.

Drawn out like that, the GUI isn't really faster or easier. It could be argued which one is faster if you don't already know what to do, at which point it's whether digging through GUI options and pages is faster to find what you want than 'man -k MAC address'

or, in my case, knowing that ifconfig and man -kMAC address actually exits.

GUIs are good where you can click, look at some options and easily try stuff out. eg: I find using synaptic a lot easier to use than apt-get.

If I want to check/change my network card, then I can click through a few menus and 80% be sure I'll find what I'm after. I'd have no idea with a CLI.

[Berengal]

I use synaptic and apt-get about the same. It really depends on what I'm working in right now. If I'm working in a terminal, it's easy for me to apt-cache search <whatever>, or even try some wild guess, which if it fails, apt-get might tell me I just need to install the package; for example, I wanted to look up a word in a dictionary, and since I already was in a terminal i just went "dict <word>". "Command not found, but if you go sudo apt-get install dict I'll find it."

Synaptic, however, is nice if you're not completely sure of what you want, or you know you want lots of stuff. For example, I wanted a bunch of codecs, so I started synaptic, searched for codec, and selected all the ones I wanted at once, without several "apt-cache search codec | less" "sudo apt-get install <package>" cycles.

The thing is that GUI and CLI are good at different things. Some things are easier to express in a GUI, for example configurations (exhaustive drop-down menues of all possible choices vs knowing valid options and their correct order), while other things are much easier expressed in a CLI.

A final example that CLI isn't obsolete:
Our assignments at uni were due today, and my partner and I had just done the final revisions of our project. During the last half hour, I'd been looking over the code to check that it was properly commented, while she wrote the overview. When we were both finished, we needed to get the overview file from her computer to mine, so I could archive it and the code and hand them in. We were on the same network, but we didn't have write permission on any shared part of the filesystem. Her first idea was to email it to me. "Naw" I said, and grabbed her pc, started a terminal and went "nc -l -p 5678 < overview", then turned to my terminal and went "nc 192.168.0.153 5678 > overview". Took me less than 15 seconds.

[segmentation fault]

gui just increases development time 100% because youre not only focusing on making something that works but also something that looks pretty.

[tehmikey]

There's only one reason that I need a GUI for file browsing I can think of. To open a file in another program, that may or may not be running.

Sure I can do it with something like:

<program name> <filename> &

But remembering the name of the program is harder than just double clicking.

What about gnome-open? A command such as this one will open the file with the default program. Unless you are talking about a program that is not the default.

Personally, I use both a lot. When performing a new task, it is a lot easier to navigate through a GUI where the options are ideally visible. CLIs are very helpful especially when you need to see program output Also, tab completion is >> than double clicking through a bunch of directories. I have a heads up terminal on my linux box, and I can quickly open a nautilius window to the desired directory.

[zenten]

There's only one reason that I need a GUI for file browsing I can think of. To open a file in another program, that may or may not be running.

Sure I can do it with something like:

<program name> <filename> &

But remembering the name of the program is harder than just double clicking.

What about gnome-open? A command such as this one will open the file with the default program. Unless you are talking about a program that is not the default.

Wow, that's exactly what I needed. Thanks.

[TheGZeus]

I think the GUI has brought us many very useful things, but the current systems are much too tied to that Desktop Metaphor.
Few things have dared to challenge the Macintosh.
I want a distro to default to a tiling WM.
I'll probably do that at some point, but I doubt I'll maintain it, just post a torrent based on sid.

[TheGZeus]

There's only one reason that I need a GUI for file browsing I can think of. To open a file in another program, that may or may not be running.

Sure I can do it with something like:

<program name> <filename> &

But remembering the name of the program is harder than just double clicking.

What about gnome-open? A command such as this one will open the file with the default program. Unless you are talking about a program that is not the default.

Personally, I use both a lot. When performing a new task, it is a lot easier to navigate through a GUI where the options are ideally visible. CLIs are very helpful especially when you need to see program output Also, tab completion is >> than double clicking through a bunch of directories. I have a heads up terminal on my linux box, and I can quickly open a nautilius window to the desired directory.

There a non-gnome alternative?
I avoid pulling in/using those libs, I think I have one or two gnome-based libraries, but that was for inkscape and texmacs(not sure if I'll be using that, but ot looks powerful. I should probably just learn LaTeX).

[TheGZeus]

Synaptic, however, is nice if you're not completely sure of what you want, or you know you want lots of stuff. For example, I wanted a bunch of codecs, so I started synaptic, searched for codec, and selected all the ones I wanted at once, without several "apt-cache search codec | less" "sudo apt-get install <package>" cycles.

Just noticed this.
I've a tendency to do a number of apt-cache search tasks and backscroll and type in the package names, but in realising that's weird and I shouldn't suggest it to others, it made me come up with a better idea: dual/split (via GNU Screen) terminal(s).
One for searching, one for entering things to be installed.

Even if you don't use that idea, I thank you for giving me the idea. I now have two rxvt-unicode terminals on my 'admin' group. Granted, I got into that habit because sidux doesn't have any graphical installer, so i had to learn a way to make apt-cache work for me.

[zenten]

Even if you don't use that idea, I thank you for giving me the idea. I now have two rxvt-unicode terminals on my 'admin' group. Granted, I got into that habit because sidux doesn't have any graphical installer, so i had to learn a way to make apt-cache work for me.

Btw, if it has wajig, try that out. Seriously.

[b.i.o]

GUIs are for doing one thing at a time. They are also easier to learn (for most people; not so much for me).

CLIs are for doing lots of things at once. They are also inherently easier to script.

This makes CLIs faster and better than GUIs, IMO. Since they are also just as fast for doing a single thing, I see no reason at all to switch to GUIs.

Er, no?

How are CLIs better for doing lots of things at once? It's a hell of lot easier to multitask with a good GUI than with a CLI.

Yes, CLIs are also easier to script. In my experience though, most of what I do with a computer is not something that could be scripted anyway, so that's essentially useless.


They have their mutual strengths. CLIs are better in my opinion for simple tasks that a GUI would be wasted on, or complex tasks that a GUI would be either obscenely complicated or too limited for. GUIs are good for pretty much everything else.

[TheGZeus]

Er, no?

How are CLIs better for doing lots of things at once? It's a hell of lot easier to multitask with a good GUI than with a CLI.

I think you misunderstood them.
I think they were referring to a situation where, for instance, you'd want to rename a series of files, all named something like "foo0001.bar, foo0002.bar...foo9999.bar".
On the CLI (or in Dired) you can do it in a big batch, whereas in a GUI is about as much fun as getting a Brazillian with a tweezers (guessing, there).
You need to write a whole new app or expand the current file manager to accommodate batch processing or some other ugly hack that just makes the GUI app more confusing. You either remove the ability to see a function, remove the function, or make the program impossible to navigate (1,200 menus, check boxes, sub-menus, popups...).

Also, it depends on how you define 'multitask.'
A certain amount of the reason there are often 12 windows open on a user's desktop is the inefficiency of a GUI to the task.
Technically, I'm using a GUI. However, I control 90% of it with keyboard shortcuts, and 1/2 of it is Terminal Emulators.

Not CLI per se, but text mode points:
I think the constraints of the console help make for better programs, often. For instance: Pidgin VS CenterIM. Pidgin can quickly turn into a mess of windows YOU'RE supposed to drag to an appropriate place, but CenterIM lays things out neatly and logically in one 'window'.
Another example, C* Music Player VS Amarok/iTunes-alikes.
cmus has all the playback functions of these other players, but takes up about 8 megs of RAM at most, and is more powerful. I can add a directory to the library, add songs to and arrange a playlist, load a playlist, search for a song/album, load a library, save any of the above, generally much more quickly than the GUI counterparts.
However, modification of tags/audio is relegated to other apps, though. No need to re-invent the wheel.

[n3xg3n]

One thing I find the CLI most useful for is providing help to less experienced users (and occasionally being on the receiving end ) With a GUI interface one must resort to either screen caps which are large files which need to be uploaded and hosted somewhere (and when they are removed, the information is lost) or vague references to the GUI in order to describe what the user should do. I hate saying things like "OK, do you see a drop down box in the upper left corner below the picture of a pig? No? Oh, thats right, in your version the devs moved it to the lower right corner". With the CLI it is as easy as "run 'program --foo bar' and tell me the output"

Another instance where I believe CLI rips GUI a new interface is in the remote control of a box. With a CLI remote control such as SSH, not only is it faster over a slow connection, but it is also possible to control multiple boxen through scripts. If you only have an rdesktop or vlc (or similar) interface, you better hope that both sides of the connection are quick and you only need to administer one or two boxen.

[aleflamedyud]

Why not just write a GUI that lets the user drop to a command prompt with a scripting language or something if they need it?

[TheGZeus]

Why not just write a GUI that lets the user drop to a command prompt with a scripting language or something if they need it?

Sounds kind of complicated and limiting.
It makes more sense to write a gui front end to a CLI app.
That or a simple back end and either CLI or GUI front ends (see MPD for examples of that).
That way you only use the GUI if you want to, and you get the same benefits.
If both the front and back end are designed properly, no one would be able to tell how what was designed.

[qbg]

You could have a GUI with an integrated special purpose command line. You could have a CLI and let applications/functions draw graphical widgets to their standard output. You could have both at the same time. (all of this, of course, has already been done)

[TheGZeus]

You could have a GUI with an integrated special purpose command line. You could have a CLI and let applications/functions draw graphical widgets to their standard output. You could have both at the same time. (all of this, of course, has already been done)

Suppose, I tend to prefer modularity whenever possible.

[recurve boy]

Surely this is a matter of best tool for the job?

Large Java app, having an IDE for code inspection is pretty handy. Graphics, you have no choice.

Doing stuff in a DB, a GUI doesn't buy you much. And if you need to write SQL, in postgres you can go \h, \h ALTER TABLE etc. The DB front ends I've seen can't do that.

Sometimes a combination is kinda good. I like Vim for editing, but having multiple terminal tabs for my project or using ctrl-z is not so nice sometimes. So I often use GVim or Mac Vim at home. Also bash scripting can be super useful.

Managing music, or photos, GUI wins I think. Word processing, GUI especially if you are a little nuts about the type setting.

Email, I miss pine actually ... maybe if I can get the power of spotlight in pine it would be OK.

Right tool for the right job folks.

[TheGZeus]

... Word processing, GUI especially if you are a little nuts about the type setting.
...

,,,LaTeX.
That is all.

Well, TeX, but that's like assembky programming,,,

[recurve boy]

... Word processing, GUI especially if you are a little nuts about the type setting.
...

,,,LaTeX.
That is all.

Well, TeX, but that's like assembky programming,,,

Get with the times. I've done things in plain TeX and LaTeX. It's really just a pain in the ass. LyX is far better.

[TheGZeus]

... Word processing, GUI especially if you are a little nuts about the type setting.
...

,,,LaTeX.
That is all.

Well, TeX, but that's like assembky programming,,,

Get with the times. I've done things in plain TeX and LaTeX. It's really just a pain in the ass. LyX is far better.

LyX IS LaTeX.
WYSIWYG is quite useful, I'll admit.
However, there will always be people who prefer to code their HTML manually. Even most WYSIWYG website builder users check the generated code for errors.

[hotaru]

Large Java app, having an IDE for code inspection is pretty handy. Graphics, you have no choice.

you need to use a gui when you're not dealing with anything except text?
that sounds a bit silly to me.

Managing music, or photos, GUI wins I think.

i actually use command-line programs for most of my photo management... but i'll agree with you about managing music, i've yet to find anything better for that than amarok.

[recurve boy]

LyX IS LaTeX.
WYSIWYG is quite useful, I'll admit.
However, there will always be people who prefer to code their HTML manually. Even most WYSIWYG website builder users check the generated code for errors.

I know. But WYSIWYG and never having to learn the markup is a GUI thing.

Large Java app, having an IDE for code inspection is pretty handy. Graphics, you have no choice.

you need to use a gui when you're not dealing with anything except text?
that sounds a bit silly to me.
[/quote]

Sounds like you've never developed an app in a large team that used different technologies to integrate different systems. It's really quite handy and much faster to have your IDE generate stub implementations, inspect the libraries you import to autocomplete method names and variables etc. When you debug or have questions you can send code pointers over with a message. Colour coded highlighting of changes when you merge allows you to skip all the benign changes and just compare the important ones.

When you need them IDEs are extremely helpful.

[hotaru]

It's really quite handy and much faster to have your IDE generate stub implementations, inspect the libraries you import to autocomplete method names and variables etc. When you debug or have questions you can send code pointers over with a message. Colour coded highlighting of changes when you merge allows you to skip all the benign changes and just compare the important ones.

you don't need a GUI for any of that. pretty much any modern terminal is capable of displaying colors, and the rest of that can be done regardless of the type of interface.
the fact that none of the popular IDEs have well designed interfaces doesn't mean that it's impossible.

[Berengal]

Are tabs GUI? If so, GUI wins at IDEs. I know there are sort-of-tabs in several text-and-keyboard-only editors, but they lack another thing GUIs have: Drag and drop. I have a hueg like xbox monitor, and that allows me to move my open files around the screen to just where I want them. I can have two beside eachother, two on top of eachother, two beside eachother and another on top. The combination of tabs and drag and drop works magnificently. Of course, drag and drop has other uses too. If I need to move text between different files, or my hand is already on the mouse, or for some reason selecting the desired text with the mouse is easier than doing it with the keyboard, then dragging the text around is much nicer than cut and paste with the keyboard. (The mouse is better at moving the text cursor too, if it's for long distances). Tree-views aren't GUI-specific, but I haven't seen one outside of a proper GUI in fifteen years. Besides, you need curses for that to work, at which point it's not really a CLI anymore anyway.

Also, I'm not very well versed in the various editors out there, but about the only editor that uses a CLI (as in Command Line Interface) by default is ed. I'm pretty sure none of you write large projects in ed (at least out of visual mode).

[TheGZeus]

Are tabs GUI? If so, GUI wins at IDEs. I know there are sort-of-tabs in several text-and-keyboard-only editors, but they lack another thing GUIs have: Drag and drop. I have a hueg like xbox monitor, and that allows me to move my open files around the screen to just where I want them. I can have two beside eachother, two on top of eachother, two beside eachother and another on top. The combination of tabs and drag and drop works magnificently. Of course, drag and drop has other uses too. If I need to move text between different files, or my hand is already on the mouse, or for some reason selecting the desired text with the mouse is easier than doing it with the keyboard, then dragging the text around is much nicer than cut and paste with the keyboard. (The mouse is better at moving the text cursor too, if it's for long distances). Tree-views aren't GUI-specific, but I haven't seen one outside of a proper GUI in fifteen years. Besides, you need curses for that to work, at which point it's not really a CLI anymore anyway.

Also, I'm not very well versed in the various editors out there, but about the only editor that uses a CLI (as in Command Line Interface) by default is ed. I'm pretty sure none of you write large projects in ed (at least out of visual mode).

Wow, we really have different ideas if what makes a good user experience.
I HATE drag and drop.
It's a simple visual cue a to what's going on, but far less flexible than....anything else.
I use the mouse for a few corner cases I've not figured out ways around (someone IM's me a URL and I have to copy it, the playlist in smplayer, and Flash, namely) but other than that I avoid it like the plague.
I bought a mogo mouse and next time I shut down (don't know how long that will be) I'm physically disconnecting my touchpad(can't get it disabled, tried everything).

[xyzzy]

...
Word processing, GUI especially if you are a little nuts about the type setting.
...

No, if you're anywhere near nuts about the typesetting you'll be using LaTeX or plain TeX or something similar. If what you actually meant was "nuts about drawing your documents crudely on a low resolution screen", then you might need a GUI.

I do (La)TeX through Emacs for all my typesetting needs, and trying to beat it Word is nigh on impossible (especially for the major mathematical stuff). I can even go nuts about the fonts in various interesting ways. And do plotting and all sorts of nifty trickses with that. All without a GUI*.

*well, I'm running emacs under X, and I use XDVI or KGhostView to view the files I produce. But the point still stands.

[Berengal]

Wow, we really have different ideas if what makes a good user experience.
I HATE drag and drop.
It's a simple visual cue a to what's going on, but far less flexible than....anything else.
I use the mouse for a few corner cases I've not figured out ways around (someone IM's me a URL and I have to copy it, the playlist in smplayer, and Flash, namely) but other than that I avoid it like the plague.
I bought a mogo mouse and next time I shut down (don't know how long that will be) I'm physically disconnecting my touchpad(can't get it disabled, tried everything).

Don't get me wrong, I don't like the mouse either. I'm at home with my fingers on f and j. I usually use the keyboard to copy-paste as well, but when moving an entire paragraph/method from one file to another using drag and drop is easier than selecting the whole thing by keyboard, moving to the right file using alt/ctrl(+shift)-tab, finding the correct location and paste. Using the mouse it takes about a second if you've got both files open next to eachother, just select drag release.

I also like file overviews in IDEs and multiple windows/panels in the same window. There's a reason I'm spending most of my time in a GUI, not CLI.

But there's also a reason I open a terminal ever time I need to perform surgery on my linux. Speaking of that, is there a way to do a sudo mouseclick?

[TheGZeus]

Wow, we really have different ideas if what makes a good user experience.
I HATE drag and drop.
It's a simple visual cue a to what's going on, but far less flexible than....anything else.
I use the mouse for a few corner cases I've not figured out ways around (someone IM's me a URL and I have to copy it, the playlist in smplayer, and Flash, namely) but other than that I avoid it like the plague.
I bought a mogo mouse and next time I shut down (don't know how long that will be) I'm physically disconnecting my touchpad(can't get it disabled, tried everything).

Don't get me wrong, I don't like the mouse either. I'm at home with my fingers on f and j. I usually use the keyboard to copy-paste as well, but when moving an entire paragraph/method from one file to another using drag and drop is easier than selecting the whole thing by keyboard, moving to the right file using alt/ctrl(+shift)-tab, finding the correct location and paste. Using the mouse it takes about a second if you've got both files open next to eachother, just select drag release.

I also like file overviews in IDEs and multiple windows/panels in the same window. There's a reason I'm spending most of my time in a GUI, not CLI.

But there's also a reason I open a terminal ever time I need to perform surgery on my linux. Speaking of that, is there a way to do a sudo mouseclick?

These all sounds like things Emacs was made to do.
Not everyone likes Emacs, though.

[sje46]

For the sake of argument, CLI will also refer to console applications.

I, for one, am a CLI man. I just get an intense amount of satisfaction in being able to work without X. Of course it isn't really practical to do web browsing/watch videos/look at porn without X (although it's still possible). I'm just wondering what you tend to. Do you tend to go on IRC on irssi, or on Xchat? Do you use ncmpcpp or rhythmbox? Etc.

EDIT: Oh whoops.

[EvanED]

Among other differences, CLI has scriptability going in it's favor; GUI has "play around with shit" going it its favor. Which is better depends heavily on what you're doing, your skill level in what you're doing, and your own preferences.

Personally, I'd love to see a better CLI; what I have in mind is something like rendered HTML. There's lots of things I don't want to read in monospace font; it'd be nice if the terminal could display it in a proportional font. Or if I could type cat foo.jpg and it would display the picture to me inline in the terminal. Or could display an emacs console with the same font-locking look as I get in X. PoshConsole is the one project I know that is actually moving in this direction. (That's for PowerShell on Windows, which is another issue; I love the concept there too, but that's just the shell.)

That said, IMO using *nix without X is just crazy; how do you manage all your terminals?

[Meteorswarm]

That said, IMO using *nix without X is just crazy; how do you manage all your terminals?

You can do some neat stuff with screen, or with running terminals inside Vim, but yeah, tiling window managers make for wonderful terminal dispensers, I mean, computers.

[EvanED]

Ah, screen... one bit of Linux culture I actually haven't embraced at all (for perhaps slightly unfair reasons). I gave it a try a few years ago, and if memory serves, between unfortunate clashes with Emacs keyboard shortcuts (and not wanting to take the time to figure out unique ones) and spending some time trying to get backspace to function correctly and failing, I gave up on it and haven't looked back.