Re: Unicode Support in Ruby, Perl, Python, Emacs Lisp
Sean McAfee writes: > Xah Lee writes: >> Perl's exceedingly lousy unicode support hack is well known. In fact >> it is the primary reason i “switched” to python for my scripting needs >> in 2005. (See: Unicode in Perl and Python) > > I think your assessment is antiquated. I've been doing Unicode > programming with Perl for about three years, and it's generally quite > wonderfully transparent. > > On the programmers' web site stackoverflow.com, I flag questions with > the "unicode" tag, and of questions that mention a specific language, > Python and C++ seem to come up the most often. > >> I'll have to say, as far as text processing goes, the most beautiful >> lang with respect to unicode is emacs lisp. In elisp code (e.g. >> Generate a Web Links Report with Emacs Lisp ), i don't have to declare >> none of the unicode or encoding stuff. I simply write code to process >> string or buffer text, without even having to know what encoding it >> is. Emacs the environment takes care of all that. > > It's not quite perfect, though. I recently discovered that if I enter a > Chinese character using my Mac's Chinese input method, and then enter > the same character using a Japanese input method, Emacs regards them as > different characters, even though they have the same Unicode code point. > For example, from describe-char: > > character: 一 (43323, #o124473, #xa93b, U+4E00) > character: 一 (55404, #o154154, #xd86c, U+4E00) > > On saving and reverting a file containing such text, the characters are > "normalized" to the Japanese version. > > I suppose this might conceivably be the correct behavior, but it sure > was a surprise that (equal "一" "一") can be nil. Your headers state: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (darwin) That's an old version of Emacs, more than 2 years old. 23.1 has been released more than a year ago. The current version is 23.2. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
Hugh Aguilar writes: > On Aug 24, 5:16 pm, Paul Rubin wrote: >> Anyway, as someone else once said, studying a subject like CS isn't done >> by reading. It's done by writing out answers to problem after problem. >> Unless you've been doing that, you haven't been studying. > > What about using what I learned to write programs that work? Does that > count for anything? No. Having put together a cupboard that holds some books without falling apart does not make you a carpenter, much less an architect. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
John Bokma writes: > On the other hand: some people I knew during my studies had no problem > at all with introducing countless memory leaks in small programs (and > turning off compiler warnings, because it gave so much noise...) [...] > As for electrical engineering: done that (BSc) and one of my class > mates managed to connect a transformer the wrong way > around twice. Yet he had the highest mark in our class. Anybody worth his salt in his profession has a trail of broken things in his history. The faster it thinned out, the better he learned. The only reliable way never to break a thing is not to touch it in the first place. But that will not help you if it decides to break on its own. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
John Bokma writes: > David Kastrup writes: > >> John Passaniti writes: >> >>> Amen! All this academic talk is useless. Who cares about things like >>> the big-O notation for program complexity. Can't people just *look* >>> at code and see how complex it is?! And take things like the years of >>> wasted effort computer scientists have put into taking data structures >>> (like hashes and various kinds of trees) and extending them along >>> various problem domains and requirements. Real programmers don't >>> waste their time with learning that junk. What good did any of that >>> ever do anyone?! >> >> It is my experience that in particular graduated (and in particular Phd) >> computer scientists don't waste their time _applying_ that junk. > > Question: do you have a degree in computer science? > > Since in my experience: people who talk about their experience with > graduated people often missed the boat themselves and think that reading > a book or two equals years of study. I have a degree in electrical engineering. But that's similarly irrelevant. I have a rather thorough background with computers (started with punched cards), get along with about a dozen assembly languages and quite a few other higher level languages. I've had to write the BIOS for my first computer and a number of other stuff and did digital picture enhancement on DOS computers with EMM (programming 80387 assembly language and using a variant of Hartley transforms). I have rewritten digital map processing code from scratch that has been designed and optimized by graduated computer scientists (including one PhD) to a degree where it ran twice as fast as originally, at the cost of occasional crashes and utter unmaintainability. Twice as fast meaning somewhat less than a day of calculation time for medium size data sets (a few 10 of data points, on something like a 25MHz 68020 or something). So I knew the problem was not likely to be easy. Took me more than a week. After getting the thing to compile and fixing the first few crashing conditions, I got stuck in debugging. The thing just terminated after about 2 minutes of runtime without an apparent reason. I spent almost two more days trying to find the problem before bothering to even check the output. The program just finished regularly. That has not particularly helped my respect towards CS majors and PhDs in the function of programmers (and to be honest: their education is not intended to make them good programmers, but to enable them to _lead_ good programmers). That does not mean that I am incapable of analyzing, say quicksort and mergesort, and come up with something reasonably close to a closed form for average, min, and max comparisons (well, unless a close approximation is good enough, you have to sum about lg n terms which is near instantaneous, with a real closed form mostly available when n is special, like a power of 2). And I know how to work with more modern computer plagues, like the need for cache coherency. So in short, I have a somewhat related scientific education, but I can work the required math. And I can work the computers. > Oh, and rest assured, it works both ways: people who did graduate are > now and then thinking it's the holy grail and no body can beat it with > home study. > > Both are wrong, by the way. Depends. In my personal opinion, living close to the iron and being sharp enough can make a lot of a difference. Donald Knuth never studied computer science. He more or less founded it. As a programmer, he is too much artist and too little engineer for my taste: you can't take his proverbial masterpiece "TeX" apart without the pieces crumbling. He won't write inefficient programs: he has the respective gene and the knowledge to apply it. But the stuff he wrote is not well maintainable and reusable. Of course, he has no need for reuse if he can rewrite as fast as applying an interface. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
John Passaniti writes: > Amen! All this academic talk is useless. Who cares about things like > the big-O notation for program complexity. Can't people just *look* > at code and see how complex it is?! And take things like the years of > wasted effort computer scientists have put into taking data structures > (like hashes and various kinds of trees) and extending them along > various problem domains and requirements. Real programmers don't > waste their time with learning that junk. What good did any of that > ever do anyone?! It is my experience that in particular graduated (and in particular Phd) computer scientists don't waste their time _applying_ that junk. They have learnt to analyze it, they could tell you how bad their own algorithms are (if they actually bothered applying their knowledge), but it does not occur to them to replace them by better ones. Or even factor their solutions in a way that the algorithms and data structures are actually isolated. I think there must be some programmer gene. It is not enough to be able to recognize O(n^k) or worse (though it helps having a more exact rather than a fuzzy notion of them _if_ you have that gene). You have to fear it. It has to hurt. You need to feel compassion with the CPU. It's not enough to sit there in your easychair, occasionally sucking on your pipeline and listen to its story about a hard realtime youth and its strained connection to its motherboard. When it stops, you have to see its benchmarks and feel their pain in your own backplane. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: Fascinating interview by Richard Stallman on Russia TV
Emmy Noether writes:
> On Jul 18, 12:27 am, David Kastrup wrote:
>
>> What did you ever do to _deserve_ others working for you?
>
> What did we do to deserve him to write that elisp manual of 800+
> pages ? NOTHING.
So once one gives you something, you demand everything?
> He gave it to us in the hope that his software will spread like a
> VIRUS.
Yup. It is called "culture". It is _supposed_ to spread exponentially.
That's what the peculiar brain structure of humans is good for.
Communicating knowledge instead of inheriting it. That's the
fundamental advantage we have over other animals. Not something lightly
given up.
> A person arrives in the state of a newbie and wants to exit in a state
> of having made a contribution to FSF.
That's the problem of the person. It has not been a goal of the GNU
project to turn every person into somebody useful. They have the
freedom to try, getting everything for their start that anybody else has
available.
> How can one do it without adequate documentation ?
Emacs development is active, so there are people considering the
documentation adequate for starting to work on Emacs.
> Xah Lee has been complaining for a year. First you deprive people of
> ESSENTIAL documentation to contribute.
You can't "deprive" anybody of anything that is not there to start with.
> DEFUN ("or", For, Sor, 0, UNEVALLED, 0,
> "Eval args until one of them yields non-NIL, then return that value.
> \n\
> The remaining args are not evalled at all.\n\
> If all args return NIL, return NIL.")
> (args)
> Lisp_Object args;
> {
> register Lisp_Object val;
> Lisp_Object args_left;
> struct gcpro gcpro1;
>
> if (NULL(args))
> return Qnil;
>
> args_left = args;
> GCPRO1 (args_left);
>
> do
> {
> val = Feval (Fcar (args_left));
> if (!NULL (val))
> break;
> args_left = Fcdr (args_left);
> }
> while (!NULL(args_left));
>
> UNGCPRO;
> return val;
> }
>
> I saw that on comp.lang.c and found no one capable of explaining it.
If you see other context-free stuff on comp.lang.c, the situation will
not be different. The above code is rather trivial. But you'll find
the respective parts explained in the Emacs Lisp manual. In fact, the
above is likely extracted from exactly there, from
(info "(elisp) Writing Emacs Primitives")
I append the whole at the bottom to not interrupt the flow of
non-thought.
> And where does the manual explain the C struct or ADT of the basic
> cons cell ? which file has the definition ? where is his eval_quote
> function definition ?
eval_quote? What's that?
> Basically, Richard Mathew Stall man is a STALLER of PROGRESS. He
> expected the XEMACS people to EXPLAIN HIM EVERY SINGLE line of code.
> What did he do to expect all this ?
He was the maintainer of upstream Emacs, and it was his decision what
code was going there. And he had to keep maintainability in mind.
Something which was less of a priority with XEmacs developers, and
likely part of the reason that they are running out of fresh blood much
worse than Emacs these days.
> He was even paid money , as claimed by the XEMACS people.
>
> What did he do to deserve and EXPECT a line by line explanation from
> them ?!! ANSWER this question and dont run away !!
There was nothing to "deserve". It was his job to keep Emacs going
forward, and his opinion and decision that throwing the Lucid Emacs code
in would not have been good in the long run. It has not been good for
XEmacs in the long run. Whether it would have been better or worse for
a grand unified Emacs, noone will ever know. He decided to play it safe
given the information he had at that time, and Emacs is still there and
going forward.
In spite of trolls like you spouting abuse by the hundreds.
More than can be said for many other projects.
File: elisp, Node: Writing Emacs Primitives, Next: Object Internals,
Prev: Memory Usage, Up: GNU Emacs Internals
E.5 Writing Emacs Primitives
Lisp primitives are Lisp functions implemented in C. The details of
interfacing the C function so that Lisp can call it are handled by a few
C macros. The only way to really understand how to write new C code is
to read the source, but we can explain some things here.
An example of a special form is the definition of `or', from
`eval.c'. (An ordinary function would have the same general
appearance.)
DEFUN ("or", For, Sor, 0, UNEVALLED, 0,
doc: /* Eval args until one of them yields non-nil, then return that
value. The remaining args are not evalled at all.
If all args return nil, retur
Re: Fascinating interview by Richard Stallman on Russia TV
Emmy Noether writes: >> Some entity, AKA David Kastrup , >> wrote this mindboggling stuff: >> (selectively-snipped-or-not-p) > >>>> Software is a puzzle and it must be explained to be able to do that, >>>> its like a lock > >>> There is no unfreedom involved here. Freedom does not hand you a free >>> ride. Only a free road. > > No one asks for a free ride. A free road is good enough. Obviously you don't understand what you are talking about. > Perhaps we do the same to him and break into his FSF office and leave > a "friend" note we came to get the docs he has not released. You can't "get" anything that has not been written. > The concise answer: We want a free road but not a free puzzle. You have the freedom to walk the forest you perceive. You have the freedom to build the road that you want, in that forest. If it is a puzzle to you, that is your own problem. It is not a puzzle because somebody would have cut a whole into pieces and scattered them around. It is a puzzle because nobody put it together yet. Feel free to do so, doing others the service you want done. > Now, dont run away from this argument and bring each and every of the > boys from his mailing list to tackle this question. He is a manager > and he can put the volunteers to the task of documenting, illuminating > and revealing the operation of his softwares and its evolution. You want a free ride, very obviously. > He owes it to others And you think your whining entitles you to it. What did you ever do to _deserve_ others working for you? -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: Fascinating interview by Richard Stallman on Russia TV
Emmy Noether writes: > On Jul 7, 1:57 pm, bolega wrote: >> "Democracy is sick in the US, government monitors your >> Internet"http://www.youtube.com/watch?v=2BfCJq_zIdk&feature=fvsr >> >> Enjoy . > > In this video, Stall man makes 4 promises to public but stalls on 2nd > of them. > > > http://www.youtube.com/watch?v=2BfCJq_zIdk&feature=fvsr > > > 1/ Freedom to Run to the Program > 2/ Freedom to study the source code, you control it <-- Software > is a puzzle and it must be explained to be able to do that, its like > a > lock > 3/ Freedom to help your neightbors, share with them > 4/ Freedom to contribute to your community > > > Software is a puzzle and it must be explained to be able to do that, > its like a lock There is no unfreedom involved here. Freedom does not hand you a free ride. Only a free road. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: Ban Xah Lee
"Bruce C. Miller" writes: > On Mar 7, 6:52 pm, Xah Lee wrote: >> Of interest: >> >> • Why Can't You Be Normal? > > Though I doubt this will do any good, I'll offer some advice that > hasn't been mentioned here and solved a lot of the problems I've had > early in life with resistance to overly-emotional negative reactions > to my opinions. > > Say a person spends a great deal of time and energy researching some > topic and, based upon the evidence uncovered, comes to a conclusion > about it that is contrary to the established position within a > community, like, that RMS is a crackpot, as a simple example, which is > something I happen to agree with but that won't win many friends in > #emacs. Now, you could go in #emacs and declare your discovery of this > important fact (and, if true, it is important, since RMS is > influential), but what do you suppose will happen? People will think about it a lot and decide that our society could greatly benefit from increasing the number of crackpots. The non-crackpots come and go without leaving much of a trace. However, being a crackpot is not sufficient in itself (this probably being more of a side effect rather than the main gist), so the message might not actually be helpful. So what is there to gain? -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
George Neuner writes: > Yes and no. General continuations, as you describe, are not the > only form continuations take. Nor are they the most common form > used. The most common continuations are function calls and returns. > Upward one-shot continuations (exceptions or non-local returns) are > the next most common form used, even in Scheme. > > Upward continuations can be stack implemented. On many CPU's, using > the hardware stack (where possible) is faster than using heap > allocated structures. For performance, some Scheme compilers go to > great lengths to identify upward continuations and nested functions > that can be stack implemented. There is a Scheme implementation (I keep forgetting the name) which actually does both: it actually uses the call stack but never returns, and the garbage collection includes the stack. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
[EMAIL PROTECTED] writes: > Again I am depressed to encounter a fundamentally new concept that I > was all along unheard of. Its not even in paul graham's book where i > learnt part of Lisp. Its in Marc Feeley's video. > > Can anyone explain: > > (1) its origin > (2) its syntax and semantics in emacs lisp, common lisp, scheme > (3) Is it present in python and java ? > (4) Its implementation in assembly. for example in the manner that > pointer fundamentally arises from indirect addressing and nothing new. > So how do you juggle PC to do it. > (5) how does it compare to and superior to a function or subroutine > call. how does it differ. Basically, there is no difference to function/subroutine call. The difference is just that there is no "call stack": the dynamic context for a call is created on the heap and is garbage-collected when it is no longer accessible. A continuation is just a reference to the state of the current dynamic context. As long as a continuation remains accessible, you can return to it as often as you like. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[EMAIL PROTECTED] (Bent C Dalager) writes: > In article <[EMAIL PROTECTED]>, David Kastrup <[EMAIL PROTECTED]> wrote: >>[EMAIL PROTECTED] (Bent C Dalager) writes: >> >>Not as much "been" liberated, but "turned" liberated. > > I expect that either way you split this hair, using "free" in the > sense of "possessing liberty" is still going to be quite reasonable. > >>But picking just a single word from a whole explanation of _one_ >>naming and declaring it as equivalent is not really being careful with >>language at all. > > I have never claimed equivalence. What I have made claims about are > the properties of one of the meanings of a word. Specifically, my > claim is that "free" is a reasonable description of some one or some > thing that has been "liberated". But it suggests that the natural state would be the unfree state. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[EMAIL PROTECTED] (Bent C Dalager) writes: > In article <[EMAIL PROTECTED]>, > George Neuner wrote: >>On Wed, 3 Oct 2007 09:36:40 + (UTC), [EMAIL PROTECTED] (Bent C >>Dalager) wrote: >> >>> >>>Only if you're being exceedingly pedantic and probably not even >>>then. Webster 1913 lists, among other meanings, >>> >>>Free >>>(...) >>>"Liberated, by arriving at a certain age, from the control >>>of parents, guardian, or master." >>> >>>The point presumably being that having been "liberated", you are now >>>"free". Not as much "been" liberated, but "turned" liberated. >>Dictionaries used to be the arbiters of the language - any word or >>meaning of a word not found in the dictionary was considered a >>colloquial (slang) use. Since the 1980's, an entry in the >>dictionary has become little more than evidence of popularity as the >>major dictionaries (OED, Webster, Cambridge, etc.) will now consider >>any word they can find used in print. > > Apparantly, you missed the part where I referred to the 1913 edition > of Webster. I have kept it in the quoted text above for your > convenience. I can assure you that 1913 is both more than 30 years > ago /and/ it is before 1980, in case that was in doubt. But picking just a single word from a whole explanation of _one_ naming and declaring it as equivalent is not really being careful with language at all. And even when using a Thesaurus, it should be clear that the offered alternatives are not supposed to or capable of capturing all nuances of the keyword. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[EMAIL PROTECTED] (Bent C Dalager) writes: > In article <[EMAIL PROTECTED]>, > Frank Goenninger <[EMAIL PROTECTED]> wrote: >> >>Well, I didn't start the discussion. So you should ask the OP about the >>why. I jumped in when I came across the so often mentioned "hey, it's >>all well defined" statement was brought in. I simply said that if that >>"well-definedness" is against "common understanding" then I don't give >>a damn about that clever definitions. Because I have to know that there >>are such definitions - always also knowing that free is not really >>free. > > "Liberated" is a valid meaning of the word "free". No. It is a valid meaning of the word "freed". Xpost+Fup2 gnu.misc.discuss: this is not really relevant for most of the touched Usenet groups. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jul 8, 4:28 am, Adriano Varoli Piazza <[EMAIL PROTECTED]> wrote: >> b) If you do want to keep an antediluvian copy of emacs -probably >> versioned in the negative numbers, for all you've said- please do. Do >> be so kind as to send a copy, since it might be quite valuable as an >> antique. > > Judging by the existence of the newsgroup comp.emacs, emacs is > indeed considered by some to be a quite valuable antique. Otherwise > why on earth would it have an apparently fairly active newsgroup a > full seven years into the 21st century? As opposed to your brain, Emacs has not undergone fossilization 10 years ago. While a newsgroup discussing your dim recollections of Emacs would indeed be boring (apart from the amusement value of your pomposity), a newsgroup discussing current (and evolving) versions and use of Emacs has its place. And anyway, the language C has changed much less in the last 10 years than Emacs has, and you'll still find active discussion groups for that, too: it is still very much in use, like Emacs. As a note aside, you'd be hard put to find an editor that manages a similar multitude of encodings as well as Emacs does. While it is to be expected that in the long term utf-8-encoded Unicode is the way of the future (and Emacs is going to focus more on that in future versions, too), at the moment there are few editors which keep up with the existing multitude of multibyte encodings as well as Emacs does. Emacs also makes it fairly easy to input stuff without much hassle, so you can easily write things like ἐν ἀρχῇ ἦν ὁ λόγος or каша гречневая. So even if you don't like the user interface of Emacs from 10 years ago and delight in assuming that it did not change in all that time, there would be valid reasons for using it nevertheless. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jul 7, 6:12 pm, Lew <[EMAIL PROTECTED]> wrote: >> Twisted wrote: >> Edward Dodge wrote: >> >> So -- what magical computer app illuminates the entire room and shows >> >> you how to use everything at the flip of a switch? This brilliant >> >> discovery would put Sam's, O'Reilly, the for-Dummies series, and >> >> virtually every other computer book publisher out of business in weeks. >> >> Naturally, this would include the publishers of books on "easy-to-use" >> >> Microsoft products. >> >> > I don't know, but it sure as hell isn't emacs. >> >> The reason you don't know, and Edward Dodge's point, is that there is no such >> app, whether emacs or not. > > 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? I recommend you just shut up _until_ you have checked out a recent version of Emacs. You just have no clue what you are talking about and are still stuck in the eighties. Emacs has an obvious "Help" toolbar button in the standard place, it has a "Help" menu in the standard place, it reacts to presses of F1 by delivering help, it has tooltips all over the mode line and for pretty much every menu entry (and the menus are plenty and well-sorted for doing the most-frequent tasks). In addition, the quality of those help items is far above average. But you would not know since you prefer babbling about some passing decade-old experience. If you had invested half of the time using Emacs you have invested for complaining about it, you'd at least have a chance not to look like the totally pompous clueless idiot you do now. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Bjorn Borud <[EMAIL PROTECTED]> writes: > [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. Since he did not ever download a copy of Emacs in the last 10 years (and won't according to his own statements download anything or look at any web page because his computer incompetency makes him incapable of avoiding or detecting viruses) one can hardly blame him for not finding the tutorial in software he did not download. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Matthias Buelow <[EMAIL PROTECTED]> writes: > Twisted wrote: > > [...] > > Hey dude, > > get back to selling used cars and leave us computer geeks alone, > will ya? Well, how will his customers react to the stories about avoiding Mercedes cars because of people getting hit in the face by the crank start? -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > 2. Regarding these graphical derivatives (apparently plural) of > emacs, Emacs is a graphical derivative of Emacs? What nonsense. The canonical Emacs as distributed and copyrighted by the FSF is a GUI application on a large number of platforms. > has nobody considered that this means that Xah had already won > before he'd even fired his shot? :P It just means that you have no clue what Xah has been talking about. Xah was concerned about keybindings and terminology. Never mind that there are menus (with keyboard shortcuts displayed automatically), toolbars, scrollbars, multiple frames, font support, mouse support and so forth and so on. Xah knows this since he actually _uses_ Emacs. > Someone obviously felt the need for a more usable emacs and > delivered one. In that case it's a fait accompli. Criticisms leveled > at original-emacs shouldn't bother users of the graphical versions > regardless. The graphical versions _are_ original Emacs. > The one complaint might be that both of us had out of date > information and were fighting a war our side had already won years > ago. :) You just have no clue what Xah has been talking about. > Unless of course these are all klunky bolted-on GUIs of the sort all > too common when porting unix software to Windows or the Mac or for > use under X, which don't work quite right or are clearly poorly > integrated with the application's internals...about which I > currently have no information. You have had no information about _anything_ right from the start. > And no, I'm not about to spend hours downloading half a gig of > bloated who-knows-what just to find out, tyvm. :) You could start with the current NEWS file at http://cvs.savannah.gnu.org/viewvc/emacs/etc/NEWS?root=emacs&view=markup&pathrev=EMACS_22_1> which describes everything which is new in Emacs 22.1 (and will give quite a few ideas about what has already been there in earlier versions). Of course, you'll whine together some excuse why you can't be bothered getting some information about Emacs, never mind that you post several dozens of embarrassing tirades that are completely based on nonsense of your own imagination. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Cor Gest <[EMAIL PROTECTED]> writes: > Some entity, AKA JackT <[EMAIL PROTECTED]>, > wrote this mindboggling stuff: > (selectively-snipped-or-not-p) > >> We don't care about the 1970 version of Emacs, >> because of course back then there WAS NO GUI. > > But if you are blind as bat, any 2007's GUI is useless. Have you actually talked to a blind person about that? They often prefer the GUI applications since they tend to interact better with screen readers and the accessibility software available for the GUI's toolkits. Sounds crazy, I know. Anyway, Emacs plays in a league of its own for blind people due to Emacspeak. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 23, 8:35 pm, Robert Uhl <[EMAIL PROTECTED]> wrote: >> Twisted <[EMAIL PROTECTED]> writes: >> >> > For an example of the latter, consider opening a file. Can't remember >> > the exact spelling and capitalization of the file name? Sorry, bud, >> > you're SOL. Go find it in some other app and memorize the name, then >> > return to emacs. >> >> 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. >> >> Or of course you could use directory mode, which enables you to navigate >> around a directory tree, performing actions on files (including editing >> them). >> >> Then of course there's ido.el, which is even better: type a few >> characters from anywhere in the name, and it displays files matching >> those characters. > > 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. It definitely _does_ when you are using the mouse to open your file dialog. Again, _try_ a current version of Emacs before showing your ignorance. [Other nonsensical speculation deleted] -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
t; > That looks like three commands, although I can't be sure -- my > Swahili is a little rusty from years of disuse. ;) > > I'd normally use at least eight -- open, save, quit, find/find next, > replace, cut, copy, and paste. All of those are on the toolbar (not to mention in the menus). > That's not counting arrows, page up, page down, del, backspace, and > the like, and unixy tools don't let you take even THOSE for > granted. All of those work with Emacs. > And if I needed more, add help. Add the four arrows, page up, page > down, delete-forwards, backspace, and help to the original eight and > we now have 17 commands. I seriously doubt that your short chunk of > Swahili up above encompasses all of them. All of that is available by clicking on icons, using scrollbars and dedicated arrow/pageup/dn keys. >> Do you realise that emacs has a GUI these days? I'm writing this >> in a 70-line window, with gtk+ widgets. Which means >> full-resolution, full-colour. > > What are you talking about? Clearly not emacs, which is a console > app for unix systems (with the inevitable MS-DOS ports and > others). Some sort of bastardized Windows port I suppose? You are so clueless. Take a look at the web page for AUCTeX http://www.gnu.org/software/auctex/screenshots.html>. That are screenshots from a somewhat current version of Emacs. > I've seen the occasional attempt at a Windows port of a unix tool, > and the results are fairly uniformly awful. Everything looks mostly > right, and nothing works quite right. They're often actually more > unstable than native Windows apps, probably because the porters > don't know half as many of the landmines littering the windoze APIs > as real Windows application programmers do (and *they* only know > maybe half of the total, to judge by the stability of even > higher-quality Windows apps) and because they are bolting on a thin > layer of Windows widgets onto a core that works in ways > fundamentally alien to those same APIs. No real Windows app dares to > try spawning around 700 threads to service a request to copy two > lines of text to the clipboard, for example. :) The Windows port of Emacs is full-quality and full-functionality and tightly integrated with Windows' GUI. You can get it with an installer from the EmacsW32 web page http://ourcomments.org/Emacs/EmacsW32.html>, for example, or from the main Emacs distribution site from the FSF. You are babbling uninformed outdated nonsense, and have been pointed to the relevant info dozens of times over months. Yet you choose to stay ignorant and continue looking like an uneducatable idiot. Uneducatable idiots should not choose to work in the computing business since things move fast there, and uneducatability (and the unwillingness to reevaluate decade-old experience) are plainly a hinderance. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Matthias Buelow <[EMAIL PROTECTED]> writes: > Tim Roberts wrote: > >> Editors are like underwear. We each have our own favorite brand, and >> nothing you say will convince me to change mine. > > You really should have stopped here :) Well if "It stinks!" is not incentive enough for him to change his underwear, what will? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[EMAIL PROTECTED] writes: > PS you'll have to stop posting such a high volume here. I'm getting > BS from Google Groups about posting limits being exceeded again. Oh, but that just means that _YOU_ will have to stop posting such a high volume here. Others are not affected. Though I have no doubt they'll welcome a thinning out of this thread (followups directed to comp.emacs for that reason). > Apparently they've lowered it still further, from 25 in a 24 hour > period to 12 or so in a 24 hour period. Fuckers. How about making _summary_ answers then? Your whole contributions boil down to "You must be lying. This can't be Emacs you are talking about, since I know Emacs intimately because of having looked at an old version of it for half an hour about 10 years ago." anyway. You don't need to post this 12 times per day. You don't even need to post this at all. It does not get any less stupid by repetition. What _is_ sort of amusing is that years ago you already accused me of forgery when I pointed you to the Emacs screenshots on the preview-latex http://www.gnu.org/software/auctex/preview-latex.html> page. It appears that you still have not bothered educating yourself, years after you were pretty much universally derided in comp.text.tex for making a spectacle of your self-chosen ignorance. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD > TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?! Because there is a menu called "HELP" and because the "standard" keybinding for help, f1, brings up help? And because there is that standard GNOME icon of a lifesaver which you can click? Not to mention that there is an initial splash screen pointing most of this out? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Falcolas <[EMAIL PROTECTED]> writes: > On Jun 22, 11:28 am, Robert Uhl <[EMAIL PROTECTED]> wrote: > >> It's Mac OS and Windows which are inconsistent. Emacs has been >> around since they were mere glimmers in the eye of Jobs & Gates... > > Inconsistent? I would have to disagree. They changed paradigms - > terminal text based interfaces to GUIs. You wouldn't expect a piece > of software built for a terminal to be backwards compatibility to > punch card interfaces, would you? You are aware that the ubiquitous standard terminal width of 80 columns has been chosen to match the 80-column punch card standard? > Why would a GUI based program limit itself to functionality as > defined by a terminal application? Emacs uses variable width fonts, can deal with a larger-than-8bit variety of GUI-based input events and can display images. Take a look at the screen shots for preview-latex http://www.gnu.org/software/auctex/preview-latex.html> illustrating WYSIWYG LaTeX editing in Emacs windows. So what is your problem? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Pascal Bourguignon <[EMAIL PROTECTED]> writes: > Falcolas <[EMAIL PROTECTED]> writes: >> >> Would you mind elaborating on *what* took 3 hours to do, as opposed >> to just throwing around unquantified numbers? Would you also mind >> explaining the user's familiarity with the tools they were using on >> the mac? > > Anything that the user have to do repeatitively with the GUI, like > copy-and-paste, or reformating of a lot of paragraphs or table > entries, and which is done automatically by writting a one-liner > program in emacs or shell. Actually, in Emacs the task more often than not is solved by using C-h a or M-x apropos and then finding the command that already does the job. >> It's just as easy for me to say that it took me 30 minutes to >> simply exit emacs, and use that to justify that emacs, and by >> extension Linux, is a terrible tool. Somebody who needs 30 minutes to find the File/Exit Emacs menu is not qualified for reporting _any_ computing experience. It is like letting yourself get a report about the points of violin playing from somebody who has just had his first exposure to music, incidentally in the form of a violin lesson. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD > TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?! Because there is a menu called "HELP" and because the "standard" keybinding for help, f1, brings up help? Not to mention that there is an initial splash screen pointing this out? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > That's entirely orthogonal to the issue of interface learning curve > OR interface ease-of-use. Emacs has deficiencies in both areas, if > principally the former. (For an example of the latter, consider > opening a file. Can't remember the exact spelling and capitalization > of the file name? Sorry, bud, you're SOL. Go find it in some other > app and memorize the name, then return to emacs. Now THAT is what I > call disruptive context switching. Again, you are talking nonsense out of ignorance. When you are _not_ using filename completion, any case entry on a case insensitive file system will work (even when we are talking about a FAT/NT file system mounted on Unix). And _when_ you are using filename completion, on _those_ systems where case insensitive file names are standard (DOS/Windows/VMS/MacOSX), Emacs will notice and replace stuff with the proper case _when completing_ (in all other cases, there is no problem in mixing up case in the context of case insensitive file systems). If you want a different standard than that of your operating system, customize the variable `read-file-name-completion-ignore-case'. It would probably be most clever if Emacs completed case-independently only on those parts of a file name which are on a case-independent file system (or a case independent context) so that a file name like /[EMAIL PROTECTED]:/media/usbstick/Photos/nice.jpg ~~~ ~~~ would get case-insensitive completion just on the underlines areas. In practice, it is actually more the users than the operating systems which are or are not comfortable with the consequences of case sensitivity, and so making the default depend on the default convention of the system seems reasonable. So please: before you continue spewing about a system you don't even know, could you educate yourself about the state of affairs? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
notbob <[EMAIL PROTECTED]> writes: > On 2007-06-21, David Kastrup <[EMAIL PROTECTED]> wrote: > >> 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? > > As I understand it, this will only work for ver 22 and later or if > you have tramp(?) installed. I have 2.3.1 (no tramp) and all I get is: > > ftp> open su > ftp: su: Unknown host I should think that version 2.3.1 would not even try ftp. Is that on Multics? > I'm looking at upgrading to 22 for a couple other features, too. You'll find that the last 30 years of development indeed make a difference. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[EMAIL PROTECTED] (Joel J. Adamson) writes: > Twisted <[EMAIL PROTECTED]> writes: > >> On Jun 20, 5:03 pm, Kaldrenon <[EMAIL PROTECTED]> wrote: >>> I still have a good deal to learn, even of the basics, but I've toyed >>> with it casually for a little bit (a total of two hours at most, but >>> almost certainly less) and I already know enough that finding out how >>> to do anything else IS trivial. It's not a program whose controls >>> throw themselves at you, exactly, but with a touch of patience and a >>> genuine interest in learning, it's not too bad. >> >> I don't know what software you're describing, but it's obviously not >> emacs, unless there have been some HUGE changes to (at minimum) the >> help and pane-navigation (er, excuse me, "window"-navigation) >> controls... > > We're talking about Emacs. In particular we're referring to > > C-h t > C-h i > C-h ? > > Or, since Emacs is customizable, for me it would be > > t > i > ? Huh? The latter are available by default on Emacs 22.1. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Lew <[EMAIL PROTECTED]> writes: > Bjorn Borud <[EMAIL PROTECTED]> writes: >>> so if the context was system administration, I'd vote for vi as >>> well. if the context was programming I'd vote Emacs. > > David Kastrup wrote: >> 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? > > I've been using emacs for something like twenty years and never knew > that before. The package "tramp" will provide that (as well as editing files over ssh, scp, rsync, telnet, plink...). It is already preinstalled in Emacs 22.1, but can also be installed for earlier versions. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Bjorn Borud <[EMAIL PROTECTED]> writes: > [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). The idea is to start Emacs once and use it for everything. > 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? -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Roy Smith <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, David Kastrup <[EMAIL PROTECTED]> > wrote: > >> Kaldrenon <[EMAIL PROTECTED]> writes: >> >> > I'm very, very new to emacs. I used it a little this past year in >> > college, but I didn't try at all to delve into its features. I'm >> > starting that process now, and frankly, the thought of it changing - >> > already- upsets me. I don't feel like the program ought to change in >> > order to accommodate me. >> >> Actually, the "E" in "Emacs" stands for "extensible". Part of the >> appeal of Emacs is that you can change it to accommodate you. > > Actually, the "E" in Emacs stands for "Editor". And the macs part > stands for "Macros". As in "Editor Macros". It started out as a > bunch of macros written in TECO. It's not like I did not know this. Don't ask me what got into my head here. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 5:37 pm, David Kastrup <[EMAIL PROTECTED]> wrote: >> ...spewing...babbling... > > I won't dignify your insulting twaddle and random ad-hominem verbiage > with any more responses after this one. Something with actual logical > argumentation to rebut may be another matter of course. > > One more GG issue: those stupid star ratings. So potentially > prejudicial. So easy to game, as evidenced by your managing to somehow > vote 82 times(!) against one of my posts in a matter of minutes. It has not occured to you that actually thousands of people read those postings? And they are heavily crossposted to boot (redirecting followup to comp.emacs, I would suggest everybody else do the same). And you have really nothing worthwhile to contribute. So if there is some rating system (I don't use Google Groups so can't tell) in place, your postings would certainly be good candidates for downrating. Not that this posting of mine is much better, and actually the followup-to comp.emacs would indicate that this is about Emacs. However, you have still not given any information about what, if any, version of Emacs your very vaguely expressed experiences are supposed to have come from. > So far I've found a less-impressive method to game them -- it's not > hard to get throwaway accounts elsewhere, send yourself there a > gmail invite, and create many GG accounts. And you wonder that people don't find it worthwhile reading you... > Handy to get around their onerous posting limits. Handy for stuffing > the star-vote ballot boxes with multiple votes, too, but there's no > way I can see to generate 82 of them that fast by that method, and > that much logging in and out in that short a time using different > accounts but from just one IP address is sure to come up on Google's > radar somehow, with unpredictable but probably bad results. Uh, is there some monetary compensation for star ratings? Or what's the deal? Really, if somebody can come up with a better group for followups, feel free to direct there. > How did you do it? I'm guessing they stop the link for voting > appearing as a usable link on the page for a) your own posts and b) > the ones you've voted for, but the link's URL still works, so if you > use a script to keep fetching the appropriate URL ... What a crazy obsession. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 12:39 pm, [EMAIL PROTECTED] (Joel J. Adamson) wrote: >> The point is that the responsibility to customize is on the user. > > 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. "Catch 22" is the right phrase here: just catch Emacs 22 and get started. Its out-of-the-box configuration is quite sensible. What was the last version you said you actually tried out? -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 5:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > >> But Emacs does not have a "clunky" interface. > > That's for the everyday novice-to-intermediate user to decide. And they do. > Your gnu.org email address (and attitude) clearly marks you as not a > normal user, and so your opinion doesn't count. Your email address and attitude marks you as an anonymous troll. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 5:22 pm, Matthias Buelow <[EMAIL PROTECTED]> wrote: >> Twisted wrote: >> > That's a joke, right? I tried it a time or two. Every time it was >> > rapidly apparent that doing anything non-trivial would require >> > consulting a cheat sheet. The printed-out kind, since navigating to >> > the help and back without already having the help displayed and open >> > to the command reference was also non-trivial. >> >> Ah, yes.. we live in a time where no-one seems to have the patience to >> read documentation anymore. Maybe that's why there is such a scarcity of >> good documentation with many "modern" software packages. > > 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. Menus and toolbars exist. > Also, basic tasks should not require consulting the documentation, > unless the application genre is new to the user. And they don't. Really, what is the last version of Emacs you actually tried? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 5:03 pm, Kaldrenon <[EMAIL PROTECTED]> wrote: >> I still have a good deal to learn, even of the basics, but I've toyed >> with it casually for a little bit (a total of two hours at most, but >> almost certainly less) and I already know enough that finding out how >> to do anything else IS trivial. It's not a program whose controls >> throw themselves at you, exactly, but with a touch of patience and a >> genuine interest in learning, it's not too bad. > > I don't know what software you're describing, but it's obviously not > emacs, unless there have been some HUGE changes to (at minimum) the > help and pane-navigation (er, excuse me, "window"-navigation) > controls... So what version are you babbling about? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 5:21 pm, David Kastrup <[EMAIL PROTECTED]> wrote: >> Twisted <[EMAIL PROTECTED]> writes: >> > On Jun 20, 4:49 pm, Twisted <[EMAIL PROTECTED]> wrote: >> >> On Jun 20, 4:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: >> >> > Twisted <[EMAIL PROTECTED]> writes: >> >> > > I continue to suspect that there's an ulterior motive for making and >> >> > > keeping certain software actively beginner-hostile; a certain macho >> >> > > elitism also seen with light aircraft pilots and commented on at >> >> > >www.asktog.com(exactURLescapes me; sorry). >> >> >> > You are babbling. >> >> >> No, I am not. You, however, are being gratuitously insulting. >> >> > I have that exact URL now -- >> >http://www.asktog.com/columns/027InterfacesThatKill.html >> >> Utterly unrelated to Emacs. > > I think it is quite relevant. Clunky computer interfaces may not be > so dramatically dangerous, but they certainly can hamper > productivity. But Emacs does not have a "clunky" interface. > Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix > clunkiness, billions of dollars of potential productivity is lost > worldwide every *month*. You are spewing again. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > On Jun 20, 4:49 pm, Twisted <[EMAIL PROTECTED]> wrote: >> On Jun 20, 4:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: >> > Twisted <[EMAIL PROTECTED]> writes: >> > > I continue to suspect that there's an ulterior motive for making and >> > > keeping certain software actively beginner-hostile; a certain macho >> > > elitism also seen with light aircraft pilots and commented on at >> > >www.asktog.com(exactURL escapes me; sorry). >> >> > You are babbling. >> >> No, I am not. You, however, are being gratuitously insulting. > > I have that exact URL now -- > http://www.asktog.com/columns/027InterfacesThatKill.html Utterly unrelated to Emacs. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted <[EMAIL PROTECTED]> writes: > 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. If it suits its existing users, the rest of us will just > continue to use something else. > > I continue to suspect that there's an ulterior motive for making and > keeping certain software actively beginner-hostile; a certain macho > elitism also seen with light aircraft pilots and commented on at > www.asktog.com (exact URL escapes me; sorry). You are babbling. Emacs is amazingly beginner-friendly for the power and flexibility it provides. You can sit a beginner at an Emacs session and have him start editing and learning. You can't do the same, say, with vi or a clone: the least you need is a vi helpsheet/cheat cup. With Emacs, the help sheet is helpful but optional (most people would be eyed strangely anyway if they kept a cheat barrel around at their workplace). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Kaldrenon <[EMAIL PROTECTED]> writes: > I'm very, very new to emacs. I used it a little this past year in > college, but I didn't try at all to delve into its features. I'm > starting that process now, and frankly, the thought of it changing - > already- upsets me. I don't feel like the program ought to change in > order to accommodate me. Actually, the "E" in "Emacs" stands for "extensible". Part of the appeal of Emacs is that you can change it to accommodate you. > I'm excited about the prospect of mastering something new and > different. The fewer resemblances to the common- denominator, > extra-friendly stuff I've worked with in the past, the better. > > Emacs' uniqueness may hurt its adoption rate, but it still has > plenty of users, who are all perfectly happy with how things are > done. Oh, but Emacs is not TeX: it _is_ being developed further. And some changes are done in order to synchronize Emacs with the "other world" where the latter has been oversleeping. For example, Emacs 23 will internally use utf-8/Unicode as its encoding when it has used emacs-mule up to now, a multibyte code of its own. In spirit, this will not change Emacs much, yet it will remove other-world friction and make Emacs more obviously the incarnation of editing descended into this world. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Harry George <[EMAIL PROTECTED]> writes: > I don't mind folks using any editor they want, as long as they are > proficient. In those cases, I have no problem doing Extreme > Programming with them -- code a bit, save, the other guy codes a > bit. But when someone uses vi and then forgets how to do block > moves, or uses eclipse and bogs down the session, or uses MS Notepad > and can't enforce language-specific indents, I get frustrated. My favorite killing offence is /* vi:set ts=4: */. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
