Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | Translation: since perfection is unattainable, we shouldn't even try, | and just foist upon our poor users whatever awkward and hard-to-learn | interface pops into our heads first? uh, I think the point here is that some think it might be an idea to force *their* idea of the ideal interface upon others, refusing to understand that people might have their own preferences. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Kjetil S. Matheussen [EMAIL PROTECTED]] | | Did you expect something specific before starting to read that book? | Thats a failure. SICP is a book you should read just for pure | pleasure. I was told by a lot of people I consider to be intelligent that this book would change how I think about writing software. it didn't. I didn't really know what to expect, but after reading it I did feel that its importance was greatly exaggerated. | these people seemed to be | completely disconnected from reality. | | Please don't write things like that without backing it up with some | reason. well, for one, Scheme lacked proper libraries for doing everyday things, so when I tried to use it I found myself writing a lot of library code that I shouldn't have had to deal with. but it is quite long ago, so things might have changed since then. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | Some people might say the same thing about emacs. A lot of unix tools | even. Stubbornly insisting on being odd appears to be a particularly | prevalent character flaw among the geeknoscenti. I think you are missing the point. you may find Emacs (and UNIX) to be odd, and you consistently parade this around as a reason not to even make an honest attempt at understanding how to use it (them). if the oddness still eclipses usefulness once you've made a proper attempt at understanding a tool, then the oddness is a problem. Emacs (and UNIX) don't exhibit these characteristics for a great number of people. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Kjetil S. Matheussen [EMAIL PROTECTED]] | | Things have probably changed a little, but the stuff in SISC isn't | specific for scheme, although a schemish language is used in the book. well, those are really two separate discussions: Scheme and whether SICP is an important book or not. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Robert Uhl [EMAIL PROTECTED]] | | Once again I am forced to wonder if you have _ever_ actually used | emacs. find-file has tab completion: hit tab without anything typed, and | it displays _everything_ in the directory; type a few characters to | narrow it down; hit tab to complete the filename and be done with | it. ...and of course, in addition you have access to history so you can easily find previous parameters and edit them. this makes it very efficient when you need to fiddle about in deep directory trees in a way no GUI can yet offer. ...and then there's bookmarking, which is very good for keeping a set of files (and locations) handy for quick access. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | Really? None of this happens if you just do the straightforward file- | open command, which should obviously at least provide a navigable | directory tree, but definitely does not. well, if you insist on using Emacs in the most clumsy way possible, then of course, not it won't be easy. it is very obvious to any Emacs user that you haven't bothered learning Emacs at all. go away, troll. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Robert Uhl [EMAIL PROTECTED]] | | Agreed. Stallman got sidetracked by Scheme, which IMHO was a | dead-end. too many people buying SICP and believing what they heard about it being an important book. I too spent some time exploring Scheme, or should I say, wasted some time, years ago, and nothing came of it other than a profound irritation. these people seemed to be completely disconnected from reality. Scheme, and thus Guile, might have been a viable path if these people had only been practical instead of stubbornly insisting on being odd. | A Common Lisp emacs would be pretty sweet. There's a Climacs project, | but they're just focused on providing an editor, not on providing a | full-fledged emacs. if nothing else, a proper Emacs in Common Lisp might give me a reason to learn Lisp properly. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | On Jun 23, 2:04 am, Robert Uhl [EMAIL PROTECTED] wrote: | Of course, emacs doesn't take years of mastery. It takes 30, 40 | minutes. | | I gave it twice that, and it failed to grow on me in that amount of | time. then it just wasn't meant to be. stick to Notepad. | If I haven't, it must be the case that finding this tutorial (or even | discovering that it exists) was nontrivial, or it wasn't built into | emacs, one or the other. when Emacs on my machine starts it says the following: Welcome to GNU Emacs, one component of a Linux-based GNU system. Get help C-h (Hold down CTRL and press h) Undo changes C-x u Exit Emacs C-x C-c Get a tutorial C-h t Use Info to read docsC-h i Ordering manuals C-h RET Activate menubar F10 or ESC ` or M-` (`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key. If you have no Meta key, you may instead type ESC followed by the character.) if you haven't found the tutorial, you haven't really tried very hard. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | and you said that depended on the definition of expert. Apparently | you believe there is a type of expert for whom beginner-friendly | software is intrinsically less usable than beginner-hostile | software. no, I was alluding to you thinking that posession of knowledge which is considered rudimentary basics for Emacs somehow elevates the person in question to an expert. just because you have not, by your own admission, been able to even locate the built-in tutorial, I don't think your definition of expert is very relevant. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Falcolas [EMAIL PROTECTED]] | | I guess ultimately I'm trying to argue the point that just because a | tool was written with a GUI or on Windows does not automatically make | it any less a productive tool than a text based terminal tool. Even in | windows, you can use the keyboard to do all of your work, if you learn | how (thanks to the magic of the alt key). as I see it, the debate isn't whether GUI tools are inferior per se, but whether Emacs is inferior since it has its own interaction concepts that do not map 1:1 to GUI conventions of Windows and OSX. the point I am trying to get across is that Emacs (and vi) is its own niche, and that if you want to improve them, there are more important things than fiddling around with superficial details (like keybindings -- which you can customize to your own liking anyway). for Emacs it would be far more helpful if the Lisp-implementation was replaced with one that is more efficient and Common Lisp-like. (indeed several friends of mine would like to see Emacs done in Common Lisp, and I seem to have some memory of such a project existing somewhere). -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Twisted [EMAIL PROTECTED]] | | I have observed similar opinions in other non-computer-freaks. people | who see the computer only as a tool and are only interested in getting | the job done. they have a surprising preference for Linux. | | But not emacs, I'll bet. I think emacs appeals to people who like | dealing with the mechanics of emacs or fiddling with and extending the | darn thing. But most people just want to get the job done, and the | editor or other tools they use have to get out of the way and simply | let them work. no, Emacs is not among the applications they use. nor are any IDEs or compilers. I don't think Emacs is that relevant to these users since what they do is mostly word-processing, spreadsheets, mail and web browsing. Emacs is not really targeted at Word processing as such. (although that doesn't stop some people from thinking that it would be a good idea to turn Emacs into a wordprocessing application with support for graphics, mixed fonts etc.) I use Emacs for creating documents, but this is very different since I use LaTeX and I'm a programmer, so it is very conventient for me to use a system that allows me to treat documents like code (with respect to revision control systems etc). outside academia or the technical community, not that many use LaTeX, but I have seen it in the past. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | That sort of negative-sum thinking is alien to me. Software being easy | for beginners to get started using does not in and of itself detract | from its value to expert users. the fact that you imply that this is my argument tells me that either you have not paid attention, or you have a raging inferiority complex. given the sum of your postings so far I'd say that you neither are, nor consider yourself, a cerebral sort of person, so this narrows it down somewhat (although not to the exclusion of you not having paid attention). -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | You end up having to memorize the help, because *you can't | have arbitrary parts of the help and your document open side by side | and be working on the document*. All because you can't simply tab or | click to the document. yes you can. you even have a lot of choice as to how you want to do it and it even works on the simplest of text terminals (which is useful when you are on the road and only have a computer with a browser availabe and you've had the foresight to set up the Mindterm SSH applet on a machine so you can log in and edit code from anywhere in the world). I use multiple frames on-screen most of the time. either to edit and view multiple files at once or to edit different locations of the same file. if you're a programmer it is often useful to be able to do this. you can look at more than one file at the same time, have documentation up on screen etc. | At minimum, you have to *memorize* some arcane key controls for | switching panes ... er, windows, that are totally unintuitive and | unlike what is normally used. following the built-in tutorial in Emacs I understood how to manipulate buffers and split windows in various ways. there are basically three commands you need to know. one of them is used to switch between active buffers in a given window, so it is not specific to splitting. it took me minutes to learn and within days I didn't even think about what I was doing -- I was just using the features. I think you fail to understand the approach. if you know an editor like VI or Emacs properly you have a much bigger bag of tricks, that are applicable to a wide range of scenarios, than what is encouraged by GUI intensive editors. and you don't think of them as tricks. it is just the way you edit text. | Oops. The interface design is a nightmare. The most basic requirement, | that it be easy to have the help open side by side with your document | and switch back and forth and navigate inside the help easily, is | broken. If you have to consult the help just to navigate the help or | to switch focus between document and help, then you're trapped, and | that is what happens with emacs. why don't you learn Emacs before you say what it can and can't do? it is so frustrating to debate editors with people who haven't even bothered to make a minimal effort to at least spend a day or two learning it. let's look at Word and word processing. how long does it take you to learn Word properly? to understand how to efficiently edit large documents, automate common tasks, use the built-in features for helping you organize documents? -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | I think it is quite relevant. Clunky computer interfaces may not be so | dramatically dangerous, but they certainly can hamper productivity. | Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix | clunkiness, billions of dollars of potential productivity is lost | worldwide every *month*. bah, UNIX is not user hostile; it is just selective about its friends. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Robert Uhl [EMAIL PROTECTED]] | | Why should the ignorant decide? Do you leave the decision of what great | art is to 3 year olds and their doting parents? Do you leave the | decision of what great food is to the ignorant, unwashed, | McDonald's-devouring masses? Why then do you leave the decision of | what's a useful interface to those with insufficient experience? Robert does have a point; however, one needs to take into account that it is very difficult to judge the quality of an interface if it is one that is very familiar to you or if the inner workings are obvious to you. this is why programmers often make bad UI designers: we are intimately familiar with the inner workings, and to us it is okay if the UI is just a thin layer on top of a system we've made. (I'd say the web is a better showcase for this. there seems to be no end to the number of websites that have awkward interaction modes. nor do people seem particularly shy about adding just one more thing to an already crowded interface -- because they're blind to the wall of complexity it presents to the occasional user). editors like Emacs is not something which is designed for the casual user, so what the casual user thinks is irrelevant. (also note that the definition of casual user has changed). -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Falcolas [EMAIL PROTECTED]] | | I took a moment to look at the gui editor which has been made | available to me, and short of the remove leading spaces commands, I | do not need to remove my hands from the keyboard if I do not want | to. well, that depends on the editing features you use. I use a lot of features I am not consciously aware of, so if I were to list what I require from an editor, I would have trouble enumerating them. I can't even tell you what keys they are bound to because I just use them instinctively. the same goes for VI. (VI having the added benefit of a really systematic way to organize editing actions into a sort of a matrix (a useful metaphor I was made aware of by an expert VI user who showed me how to make some editing operations more efficiently)) having people who are good at efficient editing show you some tricks really pays off btw. I can't bear to watch other people edit text because they are doing so much manual labor that could have been avoided if they had just bothered to learn more effective editing habits. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Martin Gregorie [EMAIL PROTECTED]] | | Yep, and the same people think a command line is to be avoided at all | costs. I mean, its so /last century/ and you can't do anything useful | with it anyway. I have a friend who is a carpenter. he switched to Linux a few years ago because he was tired of how slow windows was and how easily it was infested with malware. he really, really doesn't give a toss what it says on the tin, he's a _user_ and that's it. to my surprise, finds Linux as easy, if not easier to use, than windows. (he still has to use windows for his invoicing system. everything else he does in Linux). I have observed similar opinions in other non-computer-freaks. people who see the computer only as a tool and are only interested in getting the job done. they have a surprising preference for Linux. (not many of them have ever been exposed to OSX though, and I'd suspect they'd prefer that since it is far more streamlined). | Obligatory OT comment: right now I have two xterm sessions open with | which I've been writing a Swing/JDBC app using nowt but a bash shell, | cvs, microEmacs and (of course) J2SE. I don't need no steenking IDE. I used J2SE, Ant, Emacs, Xterm, bash and Firefox as my main tools when I wrote most of my production Java code. and it is not exactly what you'd call hobbyist projects either. :-) -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Kaldrenon [EMAIL PROTECTED]] | | I don't think anyone can make the argument that any (past or current) | graphics-based editor is as efficient when being used to its fullest | as a text-based editor. It's basic math - it takes measurably more | time to move a hand to the mouse, move/click the mouse, and more the | hand back to the touch-typing position than it does to execute even a | moderately complex series of keystrokes. Maybe not large amounts of | time -per action-, but it doesn't take too long for it to add up if | you spend a lot of time editing. a lot of IDE's are getting quite good and you don't have to mouse around all that much. I think the main reason I stick to Emacs is because I use it for a wider range of tasks -- not just programming. also, the IDE's I've used in the past were sluggish and for some reason the font-rendering was really hard to get right (if at all). when you spend the majority of your waking hours editing text, interactive response time and editing ergonomics matter a lot. this reminds me that it is probably time to give IDEs another chance. it has been a couple of years since the last time I tried a couple for Java. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[David Kastrup [EMAIL PROTECTED]] | | The idea is to start Emacs once and use it for everything. ...which is fine as long as you are only fiddling around on one machine or you have emacs windows running on all your machines. for my main use, I do start Emacs just once though. for instance at work my Emacs has been running for as long as the machine has been up. | so if the context was system administration, I'd vote for vi as | well. if the context was programming I'd vote Emacs. | | You know you can use something like | C-x C-f /su::/etc/fstab RET | (or /sudo::/etc/fstab) in order to edit files as root in a normal | Emacs session? sure, but often it is just simpler, while you are fiddling around in a shell, to just fire up vi to do some quick editing than to bounce back and forth between windows. it is usually quicker too if you have to navigate deep directory trees -- if you're already in the directory where the file is, it'd be fewer keystrokes to specify the file than opening it in emacs. even with tab-completion. also, I make extensive use of the readline and history features when fiddling about in the shell. shells have a lot of context if you use them effectively. context that isn't easy to transport between the shell and emacs -- and it isn't really easy to explain either. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Twisted [EMAIL PROTECTED]] | | Given that in its out-of-the-box configuration it's well-nigh unusable | without a printed-out cheat sheet of some kind, of the sort that | were supposed to have died out in the 80s, getting it customized poses | something of a catch-22 for anyone trying to get started using it. indeed, not adhering to the half a dozen keybinding and menu conventions that most newer applications use on OSX and Windows today is not ideal UI design, but it doesn't really present that much of a problem either; so it ends up being a non-issue to any regular user. (actually, it isn't merely a case of changing some keybindings and names -- the problem is that Emacs has a bunch of concepts that are not easily mapped to trivial editor semantics, so it would be hard to change without causing further confusion). Emacs isn't really meant for the casual user and there are editors far better suited for those who think spending an afternoon learning it is too much. (compare to VI or VIM, which probably takes even a bit longer to grasp, but which is beautifully practical once you understand how it works. there's this good tech-talk given by Bram Moolenaar available¹ on about text editing and VIM). ¹) http://video.google.com/videoplay?docid=2538831956647446078 -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Martin Gregorie [EMAIL PROTECTED]] | | As for documentation, lets look at vi. Not a great editor, but every | *nix variation has it installed and any fool can learn to use it in | about 2 hours flat and it does at least have good pattern matching. there's also the info system in Emacs, which not only covers Emacs itself, but usually also a lot of documentation available for Emacs extensions and other programs. again, this predates a lot of things that people are used to today, so just because it seems (and sometimes is) a bit more fiddly, it must necessarily be inferior. the most common theme when people have to choose between products is that they are not really comparing what it is like to use the products like they were intended -- they are merely underlining that X is not Y. for instance, Linux has come a long way in addressing the needs of desktop users, yet some people refuse to use Linux because it doesn't behave *exactly* like Windows (as if that was a worthwhile goal) and they are too lazy or don't think they can manage, to learn a new system. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[BartlebyScrivener [EMAIL PROTECTED]] | | http://www.debian-administration.org/polls/89 this is hardly surprising. I use both editors. for most sysadmin tasks I use vi(m). for programming i use Emacs. in part out of old habit (most UNIX systems had vi installed) and partly because vi(m) is faster (which makes it more suitable when you just need to change a couple of lines in a file). for programming I use Emacs since I have a gazillion extensions I use while programming that I don't even think about anymore. from various forms of automated text completion to syntax checking/highlighting, to enforcing style guides, look up symbol relationships, compile, debug etc. so if the context was system administration, I'd vote for vi as well. if the context was programming I'd vote Emacs. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | Being beginner-friendly doesn't have to be at the expense of power or | expert-user usability. depends on your definition of expert. :-) | On the other hand, being actively beginner-hostile leads to nobody | adopting the tool. Then again, if you don't mind being the last | generation that'll ever use it, then I guess you're okay with that. obviously I lie awake dreading the day this happens. on my tombstone will say here lies the last Emacs user on earth. M-x rip. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted [EMAIL PROTECTED]] | | Emacs does have documentation. The problem is you have to already know | a load of emacs navigation oddities^Wkeyboard commands to get to and | use it. that, or just start Emacs and follow the instructions that appear on the screen. indeed, I *am* aware that something demanding an attention span in excess of 3 seconds is a bit of a tall order for most users today. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Xah Lee [EMAIL PROTECTED]] | | | SIMPLE CHANGES if I were to suggest improvements to Emacs, the things you mention are probably among the last things I'd even consider. the problem with Emacs is not really the nomenclature or the keybindings. the problem is that it needs to do what it already does better. My frustration with Emacs has mostly been that Emacs-Lisp is a bit too limiting. It is too slow and the codebase is a bit messy. or at least it was the last time I tried to do something in Emacs-Lisp a couple of years ago. it would also be beneficial if there was a more proper and well-organized standard library for Emacs to make developing Emacs applications easier. for programmers, Emacs is a pretty good editor already, but there is a bit of a threshold for extending Emacs. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Xah Lee [EMAIL PROTECTED]] to be quite honest, your proposal seems to largely be based on ignorance. | A: The terminology “buffer” or “keybinding”, are technical terms | having to do with software programing. The term “keybinding” refers to | the association of a keystroke with a command in a technical, software | application programing context. That is to say, a programer “bind” a | keystroke to a command in a software application. The term “buffer” | refers to a abstract, temporary area for storing data, in the context | of programing or computer science. the term buffer is used extensively outside the computer science domain, so it is not a CS only term. in an editor it is actually a quite sensible name since it abstracts things a bit. for instance a buffer need not be associated with a file. nor does it make any assumptions about the way it is displayed (as opposed to window or tab). | These terms are irrelevant to the users of a software application. they are very relevant to me, and I am very much a user of Emacs. and again, they provide good abstractions. | As a user of a text editor, he works with files. learn Emacs before you criticize it. your assumption is wrong. in emacs you work on _buffers_. buffers often do not have files associated with them. | The terms “opened file” or “untitled file” are more appropriate than | “buffer”. Since emacs is also used for many things beside reading | files or writing to files, for example, file management, ftp/sftp, | shell, email, irc etc., the proper term can be “panel”, “window”, or | “work area”. panel and window refer to UI-elements. the buffer concept does not map 1:1 to any of these. substituting work area for buffer doesn't seem like a better abstraction. especially not if you see it in the context of how Emacs relates to buffer contents. | And, the term “keyboard shortcut” refers to typing of a key- | combination to activate a command. It is also more appropriate than | “binding” or “keybinding”. why? if anything the term shortcut seems to imply that there is a primary route to executing the function in question -- which more often than not isn't the case. keybinding is a more precise term. | Although concepts like “buffer” and “keybinding” are seemingly | interchangeable with “panel” or “keyboard shortcut”, but their | contexts set them apart. they are interchangeable only if you have no idea what you are talking about. you obviously have not bothered to have a proper look at Emacs and think these things through properly. | This is why in all modern software application's user | documentations, terms like “buffer” or “keybinding” are not to be | seen but “windows, panes, and keyboard shortcuts”. most modern editors are built on different premises than Emacs and many have a far simpler view of the world. extremely few of them even come close to Emacs in defining what is in practice an operating environment for applications. it makes sense to refer to windows when in fact you are referring to windows. it doesn't make sense to call buffers windows in Emacs; because they are not. | The reason emacs uses the technical terminologies throughout is | because when emacs started in the 1970s, there really isn't any other | text editors or even software applications. the abstractions you mention are sensible ones independently of when they were concieved. just because other people came along later and used different abstractions, doesn't mean that the ones used in Emacs are wrong, inferior or inappropriate. if you had bothered to understand Emacs properly, you would have found that some of the abstractions used make a lot of sense in an editor. | Changes in society are always resisted by old timers, but it is also a | main element behind progress. I've been in the computer industry long enough to have seen quite a few cycles of re-invention. each cycle you learn something about which inventions were good and which were bad. a common thread if you look at the survival rate of products and ideas is that it isn't always the best product or idea that wins. often something new comes along to replace something old. sometimes it is better than what you had before, but often it is not really better, just different. a good example is the web and the applications we implement in terms of the web. take forums for instance. in a strict technical sense, web-based forums are inferior to NNTP-based forums. (I am sure you can make the comparison yourself). yet NNTP-based discussion is not growing at the same rate as web forums. the net has chosen its preferred technology, and it wasn't because the web-based discussion forums were so much more technically refined that the majority chose them. for my uses, web forums are a huge step back from NNTP. | This terminology issue may seem trivial, but its importance lies in | making emacs palpable to the vast number of people who ever need to | use a computer to write. why? Emacs
Re: The Modernization of Emacs: terminology buffer and keybinding
[Giorgos Keramidas [EMAIL PROTECTED]] | | Educating the user to avoid confusion in this and other cases of made | up, 'user-friendly' descriptions is not a good enough answer. there are two types of user friendly. there's user friendly and then there is beginner friendly which is often mislabeled. the latter is more important for applications which are to be used casually. like utilities you only use once or twice per year -- those need to be beginner friendly. for applications you are likely to use for prolonged periods of time (like programming, video editing, music production etc), it does not make sense to optimize for beginner friendly. at least not at the cost of making the application less user friendly. applications you spend a lot of time using are worth an investment in learning how to use them. what creates friction in an application you know reasonably well is when common tasks are fiddly. for instance, while menus are often good for casual use and lower the initial threshold for absolute beginners, depending heavily on menu navigation becomes too fiddly if you are performing a certain task 2-3 times per minute. it is not _user_ friendly. Emacs is rather user friendly, but not very beginner friendly. when I was first confronted with it, the sort of text editors I was used to were Wordstar and derivatives of it. I was rather annoyed that it didn't do what I expected, so I just used a different editor. a few years later I bemoaned the fact that Emacs was so hard to use during a conversation with a friend. he asked me if I had actually made an effort to learn Emacs, which of course I hadn't. so I figured I might as well give it a shot. following the tutorial that comes with Emacs (and which is referred to in the startup message) I spent a couple of hours one afternoon learning the basics. already the next day I started using Emacs for programming. the week after I had progressed to using it as my newsreader (which I still do to this day) and eventually I started reading my email in Emacs. perhaps two months after I had sat down to learn Emacs I wrote my first Emacs extensions in Emacs Lisp. mostly simple stuff to make common programming tasks easier. I found Emacs to be user friendly, but in a different sense than the, IMHO faulty definition, beginner friendly. Emacs let me, as a user, do more with less effort and provides a lot less friction than many other developer tools I've used. at work I use it extensively, and we have lots of neat extensions that really save a lot of time. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Kaldrenon [EMAIL PROTECTED]] | Just so everyone's clear: | | Nothing he has said makes much sense, if any. (it'd be good if you explicitly specify who he is since pronouns by nature are extremely context sensitive, and in this context an unattentive reader might think you are referring to me. thanks :-). | Emacs' uniqueness may hurt its adoption rate, but it still has plenty | of users, who are all perfectly happy with how things are done. I don't see popularity as a goal in itself. I am selfish. I only care what the software can do for me and I think that this is the only way to write good software: make something you'd want to use yourself. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
