In common understanding of emacs, its use of lisp recieves perhaps too much attention, while its overall wonderful architecture is underappreciated. Emacs isnt just an editor with embedded lisp, its more a vm for bootstrapping editors. You could do an emacs with python, but the hard part is providing an environment where the extensions dont interfere with the user input loop, with buffer redisplay etc., while still staying easy to write. The emacs buffer-based async handling of external processes is a masterpiece of software engineering, much better than things like unix pipes. Doing extension languages for interactive programs is much harder than it seems at first, and emacs is a prime example of doing it right.
I will try to explain. When I came to emacs as a user, a "buffer" seemed just a weird way of saying "tab" without displaying actual tabs. The word choice only started making more sense once I wrote non-trivial amounts of emacslisp. The buffer is the fundamental emacs data structure, like the file is the fundamental unix data structure, so it's really important to understand it well.
The definition is really simple: a buffer is just a bunch of text from some unknown source, but in fact it is a very powerful abstraction, for two reasons. First, every time you do something in Emacs when simply editing files, you are really executing emacslisp functions on the buffer that is currently displayed. A lot of things you learn in Emacs can be used in three ways: interactively in editing sessions, when automating editing tasks with emacslisp, and finally when doing programming in general, even when it has nothing to do with editing files.
Second, a buffer can represent anything, it can of course contain the text of a file, but also of only fragments of a file, or a directory file listing, and, what's really great, Emacs binds TCP/FTP/HTTP/... network connections and external processes to buffers as well, allowing asynchronous streaming of incoming data into buffers, so that a emacslisp callback is called every time new text arrives from the process or socket, you can transform it as you wish and insert into the buffer the part to be shown to the user or kept for future processing. Then there are lisp primitives implemented in C like save-excursion which let you execute functions on buffer off-screen, so the same commands that are used for editing can be used for processing HTTP requests or grep output without the user noticing the cursor jumping back and forth or anything of this kind. So, when I am processing HTTP requests in Emacs, I use the same commands I sometimes use in interactive editing sessions, for example I can use re-search-forward to check if the headers were sent completely already and to get number of bytes they contain (the location in the buffer of the end of the headers, in other words). A lot of the weird emacs word like point, mark etc. that seem like anachronistic words for interface elements really are powerful abstractions that apply as much to programming as to the interactive editing.
Then there is a lot of other stuff that makes this yet more powerful, you can have buffer-local variables, timers that check buffer input periodically, transaction queues for those asynchronous processes, modes that define buffer-specific key-bindings, menus and behaviours etc., it goes on an on. It's a lot like node.js or other asynchronous networking stacks. There is also lot of magic that makes all this work concurrently without Emacs having implemented threads, and that makes it not interfere with the user interface.
A lot of the cool things Emacs does follows from this architecture, like the SLIME package for interacting with Common Lisp interpreters (local or remote), Dired for editing directory contents, Tramp for editing files on remote servers, Comint for running interactive processes of various kind inside Emacs etc. It's a really great lesson in how naturally features flow out of powerful design ideas.
As for resources, I learnt by reading the GNU Emacs Lisp Reference [1], and have done a lot of M-x describe-function and source code reading in the process of writing some elisp more sophisticated than just small editing helpers. E.g. the process stuff is described here:
Thanks for taking the trouble to write all this (when all I asked for was a link). It gives a good flavor of what you're talking about. I used to read network news inside of emacs, using a mode called gnus, decades ago, and before I switched to vim. That's probably an example of a complex application that could be written within emacs because of the architecture that you describe. This extensibility is tempting me to try emacs again, because vim is so hard to extend, but I don't want to give up vim's pure editing efficiency. I guess I need to see how well evil (vim mode for emacs) works in practice.
IMHO, Evil Mode makes to use emacs doable OTOH, the fact that there are so much extensions and possibilities under the hood makes to use emacs mandatory! :P
I've been using emacs for a while (after vim for 6, 7... 8 years?) and have recently been looking at evil. I can't seem to find any really comprehensive tutorials for Evil mode, though I haven't put a lot of work towards it.
The great thing about evil is you can enable it in your .emacs and it mostly just works. But even better, because this is Emacs the vi layer is also easily extendable. Here's an example of adding other operators (adding `mit`, `mit>` etc): https://github.com/ZaneA/Dotfiles/blob/1858a02de25e25de20e96...
I'm tempted by emacs/evil as well, but everytime I try to make the switch I run into two problems:
1) intial emacs setup: it feels really tricky to just get basic editor sanity configured (auto-indent, syntax highlighting, etc.)
2) I worry that by using evil mode, I lose out on a lot of the goodness of emacs major and minor mode's. Do you remap everything to be more vi-ish for each mode that you use? I guess that is fine but the transition just seems daunting.
I second the idea of using Prelude to start with Emacs, along with the package manager which makes the initial setup and adding modes/stuff very easy (see http://melpa.milkbox.net).
I haven't seen any lost functionality by using evil; modes that define bindings continue to work, and the usual C-x/C-c/M-x/whatever works fine with evil. There is the odd major mode that doesn't work with evil out of the box (usually if it redefines j/k) but most have no problems. You can still use most (all?) regular Emacs movement commands with evil as well.
Getting the vim portions working in emacs was surprisingly easy. I didn't have a significantly modified vim so there wasn't much to port. Stuff like mapping jj to esc and Y to y$ was simple enough. I don't notice any difference between evil and vim.
I'm still trying to figure out the emacs portions of emacs. I don't have the work flow quite right; things like buffer management, saving sessions, shell in emacs, etc.
3. For 3 I just use built in shell-mode, but what is really neat is saving your shell session to a file "C-x C-w" every so often. Then if you reboot or crash or whatever, emacs-desktop will bring back all your open files and all your shells. I usually have 3, regular bash, a sql session, and maybe an ssh session to somewhere, all with a full record of what I've done, sometimes going back months.
Just wanted to recommend reading more Pratchett. :) I bought a couple more novels last week and couldn't help but finish one (Equal Rites) less than twenty four hours later.
Emacs is one of those things everybody knows is good, but few take the time to learn.
Over the years I've learnt quite a few languages, and what strikes me is that they're all so very alike. You find the same features with slight syntactic changes.
At the end of the day, what really makes a difference is not which language you chose but what tools you are using. Do you have to memorize every important method or are they helping you find the documentation? What happens when something is a little broken, wait for a fix or patch the code immediately? Give up and live with it?
With Emacs, the languages change but the tool stays the same, you just extend it. In a way akin to how programming enhances my mind to be able to solve tough problems, emacs enhances my capacity to hack by letting me hack the tool itself.
Having a userbase made of people hardcore enough to learn some Lisp so they can hack their tool is just a bonus. Please keep fearing the parens!
Learning something that takes time should be seen as investment. If you invest your time and effort, you want to know that your investment pays dividends in the future.
I feel that Emacs is one of those tools where my investment is safe and the code I write to ~/.emacs produces huge value over several decades. It's not going away. Development community is so big that it supports all new stuff that comes along.
> Over the years I've learnt quite a few languages, and what strikes me is that they're all so very alike.
I used to think this as well, then I learned some Prolog. For those who aren't familiar with it, Prolog is a logic programming language (as opposed to imperative and functional languages). Instead of telling Prolog how to solve a problem, you give it a set of facts and tell it what you want to know. Prolog takes care of the rest, without writing any conditionals, loops, etc. At least in theory; in my (small amount of) experience most non-trivial Prolog programs usually involve some imperative style code. Still, it's wildly different and a lot of fun.
There's also lambda calculus, which is crazy, and wonderful, and absurdly difficult, and one of the most joyous experiences I've ever had. It's a language with nothing but functions applied to other functions. Even numbers are functions in lambda calculus, which has some fascinating implications. I wouldn't want to build anything non-trivial in LC, but I've learned a lot about programming as a result of studying it.
Discovering how to create singly linked lists in LC using nothing but partially applied functions was a profound and emotional experience. I remember how hard I laughed when I noticed that LC's false function is the same as the Church-encoded numeral for zero. These are things most other developers don't think are funny because they have no idea what I'm talking about. I think a few of my co-workers suspect I should be institutionalized when I start talking about lambda calculus.
Of course, there's also Haskell. A lot of lambda calculus is applicable to Haskell, which makes sense as Haskell descends from the ML family of languages, which in turn come from lambda calculus. Haskell doesn't look or feel like most other languages, and it makes some decisions that seem really strange at first glance. Lazy evaluation, all functions are curried, no mutable state, all functions are pure, there are no variables, no exception handling... the language sounds almost unusable. Then you learn about monads and you realize that it's trivial to add support for something that looks and feels like mutable state, except it's a system of your own design. Imagine what would happen if you could change the way variable assignment works in your language of choice. For instance, software transactional memory was originally implemented in Haskell as a monad. They didn't have to modify the language to add support. I can't think of many other languages where that's the case, and it's a thing of beauty.
That's a long and rambling way to say that lots of languages are really similar, but there are some wonderful languages that are extremely different. I highly recommend experimenting with them, but be aware that your friends and co-workers are unlikely to have any idea what you're talking about. And on the off chance that they do understand, please let me know where you work. I want to work with you people.
Agree w/ siblings that this is a great comment. I'd like to amplify it.
A lot of imperative languages end up being really similar once you've learned a few of them. I'm not an expert on PL history but, AIUI, ALGOL was the progenitor for many modern languages, especially imperative ones. So it makes sense as to why, but there are paradigms other than imperative or even functional.
Of course this is not to say that all imperative languages are the same. Rather it is to say that alikeness is relative. Relative to C, Java is quite different. Relative to Prolog or Forth, C and Java are more similar than not.
If anyone really wants to expand their brain to new ways of thinking wrt programming, I think exploring these off-the-beaten-path programming languages is a great idea. I agree that many people around you will think you're nuts. As long as you don't lose your sense of practicality, pragmatism, and/or proportion, you shouldn't listen to them.
I second you on LC. It profoundly impacted my brain. Mostly for the reason you mentioned, Closures, Church Encoding[1], Y, Combinators. It's almost vacuous yet it works. I love to rewatch talks about LC in ruby or javascript (well named 'programming with nothing').
[1] I like the fact that CE'd numbers are structural, a CE 2 will apply twice another function, instead of the usual stored symbol to be read/interpreted in most systems. Reminds me of 2.times(<fun>) in ruby IIRC.
There are additional versions of this same presentation circulating with the code in Javascript and (I believe) Clojure. Full disclosure: Jim is a co-worker of mine.
With Emacs, the languages change but the tool stays the same, you just extend it. In a way akin to how programming enhances my mind to be able to solve tough problems, emacs enhances my capacity to hack by letting me hack the tool itself.
Two thing that I found lacking for less-than-good hackers like me :
- idiomatic (minor|major) mode organization (I found a book and a pdf which are old and might not represent the best way to do so)
- at emacs conf, jwiegley showed some old and tiny extensions (edebug, redshank) part of his workflow. Very interesting to discover dark corners of the large emacs extensions space and how people solve problems their way.
I'm a recovering Emacser, happy enough with less powerful but more modern text editors. It wasn't the program or the UI that finally did me in, but the community: I had a problem with how Emacs worked, I wanted to figure out a solution, so I asked on #emacs on Freenode and got nothing but abuse. I realised there's something about Emacs that attracts the sort of users I don't want to associate with: people who are smug, self-absorbed and utterly without empathy. Did I want to be one of them? No, I did not. Did I want to have to rely on them for help in my work and play? No, I did not. So I found a text editor that has sufficient extensibility and I installed that, and uninstalled all the emacsen on all my machines. And I felt a lot better afterward.
Actually I had exactly the same feeling when I started using Emacs: the very first thread on some newsgroup I remember reading was about moving lines up and down, like in sublime(?) with M-S-<up>/<down>. The poor guy who dared to ask was immediately told that this is "not the emacs way", that there are many better ways to do this and so on. Ofc, halfway through the thread I found working code which implemented this feature, but the impression it made was not very good.
But Emacs architecture and it's consequences, like extensibility and customizability, and giant heaps of free, working code are enough for me to just ignore people like this. Or rather to ignore most Emacs related discussions. It's good that Emacs makes it easy to just stay away from other people: all the docs, and the source, are there in the editor itself, so if you don't mind spending a bit of time you can figure anything on your own. Which is what I do and what I like doing.
But I certainly do understand your feelings in this matter and think they are justified.
And because of that, the Emacs community lost yet another potentially helpful member[0]. This here is an example of how toxic communities are formed. Once you reach a critical mass of abusive members, the community can only grow more toxic over time.
[0] I'm going to go ahead and assume that you aren't a smug, self-absorbed sociopath.
Er, I drop in on #emacs regularly, and people there are generally very nice, nothing like you describe.
Maybe you tried at the wrong moment and happened to get the attention of the rare jerk or two, or maybe you were doing something that managed to annoy people (you sometimes see people asking questions in very overbearing and demanding manner ... "Give me the answer now!!" etc).
Indeed, I'd say #emacs is actually a lot better than typical tech channels / mailing lists etc, and the stereotypical techy "attitude" is largely absent there. If anything the biggest problem with it is not attitude, it's that 95% of the discussion on #emacs is not about Emacs (it's kinda ... laid back), and your question might get lost in the noise...
They probably tried to make a common point: do not give the solution. For a given specific issue, the most you should give is pointers.
For the function that solves your problem saves the day but knowing how to find any when needed solves a lifetime of problems. Pointers help to put you on the right track so you're not discouraged.
I was asking all the right questions -- is this possible, what hooks should I consider, what should I take into account to make sure that the stuff I add doesn't stamp all over other stuff. I'm a programmer with thirty years experience and twenty years with Emacs; I know this stuff.
Basically, they shut me down. The thing I was asking was contrary to the whole philosophy of Emacs. I had, they assured me, no right to ask it. I was an idiot for having the problem that I was seeking to solve. And nobody, they told me, had ever had the problem ever in all of history.
Were they right? Well, no, not even slightly. They were horribly, evilly wrong. But even if they had been right, their response was wrong. Their argument was "if you have this problem that can be fixed by a change to Emacs, change yourself". This, in the most extensible editor on the planet. It was like being told that my car's tendency to pull sharply to the left when passing another car was normal and expected and I should take care not to pass other cars.
The camel was rather overloaded with straw by that stage. I had asked the question two or three times over a long period, and received approximately the same response each time.
I didn't just develop my contempt for the community all in one go. I had to WORK at it!
That's the kind of answer that I hate the most. It's basically "you can't and more importantly you shouldn't want that" If you don't know what kind is that just ask how to make PostgreSQL COUNTs as fast as MySQL ones. Conversly I love people who when someone asks them how to shoot himself in the head with a rifle carefully caution what a bullet does to a head but only after explaining how one could actually perform this trick.
Give a man a fish, he'll eat for a day.
Teach a man to fish, he'll eat for a lifetime.
And if you really hate the man, get RMS to design him a fishing rod.
I don't know. For a given specific issue, I've actually found the solution pretty helpful!
And pointers can be given at the same time; there's no reason why an answer can't include both, as is most usually practical. It's fun to play the role of delphic oracle, but only as a joke that all concerned are in on, as it's terribly frustrating to be on the receiving end of it.
> attracts the sort of users I don't want to associate with: people who are smug, self-absorbed and utterly without empathy.
I think you have just described the normal IRC experience for any software project in existence. IRC just tend to breed cliques and inside jokes, and the most common form of reply I have ever gotten while looking for help is "check the source code". Never mind that its a few thousands line of low level C, magic numbers and possible some assembler instructions.
My experience is otherwise. I've found the IRC groups for Python and PHP to be quite friendly. The one for Wordpress suffers a bit from "I don't know you, so I presume you're an idiot" but not to the same degree as the Emacs or Lisp ones. I think there's some interaction between IRC and Lisp that causes this sort of sociopathic behaviour in a small but loud subset of the community -- and the rest don't do enough to discourage it, which makes them all complicit.
I think you are exxagerating, some places tend to become like that and some don't.
I found the python, ruby and perl channels very nice when I was learning the languages a decade ago or so, and by my occasional lurking they still seem to be.
Recently I was on #elm on freenode and it also was a nice place.
Cliques and inside jokes obviously are part of what a community _is_ but that doesn't necessarily translate to smugness and lack of empathy.
The example you think was exaggeration was when someone told me to check a recent patch for the answer, and the patch was several thousand line of low level C. Worse case, sure, but an actually thing that did happen.
I have used the python django IRC channel when developing some sites, and "check the source" has been the most common answer when I run into walls. Usefully, the questions I make receives some basic "see if the documentation say something" which I had of course already done, and then after a few hours of silence, someone says "check the source". This was a 3-4 years ago so maybe it has been improved?
It is true that I don't go to an IRC channel except when documentation and extensive testing has failed to produce an answer. Maybe the smugness and lack of empathy is more a product of asking questions that are not easily answered?
Weird experience you had there. I have been to many IRC channels on Freenode and found pretty much all of them abusive and unfriendly with the big exception being #emacs, where people seem to be more open and tolerant, also very helpful.
I would say you had bad luck and met an ass (which could happen as anyone can go to #emacs and rant around)
Stackoverflow is a good place to get fast answers to emacs questions. By the way I use IDE's like PHP Storm, Intelli-J and Eclipse in conjunction with emacs. Switching between the two depending on the task. Sorry you decided emacs wasn't for you but it doesn't have to be an either/or. Use the best tool for the job at hand.
one thing I struggle with emacs is that I can't find a place which documents the emacs way of doing things. Emacs has multitude of features, there are just too many to master, yet even to know that they exist.
Perhaps I'm nerdly enough to go to the Terry Pratchett part of the story first.
This really reminds me of Terry Pratchett’s Igor clan. I discovered this amiable race in The Fifth Elephant. Igors are a people inspired from the typical hunchbacked Igor archetype, but in Discworld, they are also self-modifiers. Their bodies consist of mixed and matched and patched and swapped body parts among other members of their clan, of scars and self-adjustements. They are infinitely self-improving, self-experimenting. They might end up with a botched job and have to hobble around for a few days, but in the end it’s always fixable.
And they lisp.
Pratchett litters his books with lots of unexpected gems - I view it like Easter Eggs for books. Could he have possibly added the lisp on purpose???
beautiful post. the learning curve for getting into elisp land is steep. we need something like emacs in the future, something to evolve the emacs model as the self-evolutionary programmer's environment. the 1M LOC code is much too bloated for the modern age. it should be more tightly integrated with bash/linux/git, and have better exploration methods. i am not sure why nobody is working on this, besides lighttable. perhaps that is the problem with emacs/lisp. finding the valuable stuff out there takes time and is not build around sharing.
> the 1M LOC code is much too bloated for the modern age.
Why reinvent the wheel? Emacs works well enough, and computers are getting faster every generation. Many editors appeared, they all had the chance to make Emacs obsolete but they ALL failed. Every editor could challenge Emacs but obviously it is not so easy to compete.
I use Emacs for decades now because of its extreme stability (almost same version among many operationg systems) and extreme reliability (not a single crash ever). I have tested new editors from time to time but Emacs is still superior.
These are some raasons why Emacs is still alive today despite its ancient source code. Another reason is that Emacs depends on Lisp which is much more stable than modern standards like Python, Javascript and HTML5 which change pretty fast and make it difficult to keep big software up to date. For instance, imagine an Emacs like editor written in Python 2. Now the codebase would have to be changed to Python 3, and possibly soon to Python 4.
By the way, Haskell provides excellent support for DSLs. So it should be no problem to develop a tool which converts Haskell plugins (or Python or whatever) to Emacs elisp.
> By the way, Haskell provides excellent support for DSLs. So it should be no problem to develop a tool which converts Haskell plugins (or Python or whatever) to Emacs elisp.
I've been thinking about adding Haskell as an additional language for Emacs alongside Elisp. It would be nice to be able to use both.
I'll take issue with this claim: "Work environments are a very personal thing. They exist to serve only one person: you. Me-me-me is a winning attitude when dealing with your environment."
I think it's considerably more important to have a (basically good) work environment in which your colleagues can sit down and use fluently than to have one that's absolutely optimized to your individual tastes.
I do significant amounts of pair programming. But even more so, I don't think that your coworkers using your workstation should be a <1% use case even if you never pair.
My contention is that:
1. Work environments -- including ones that don't formally pair -- should be highly collaborative.
2. It's typically massively less efficient to help someone past a block or communicate a new coding technique via telling them what to do rather than doing it. Much less anything even remotely iterative, where you need to, say, write some code, look at some output, and write some more code.
3. The difference between "a basically good development environment" and "a development environment that is specifically optimized for just specifically you" is actually quite small. There's no real need to sacrifice much of anything in order to get an environment optimized specifically for you.
If you pair a majority of the time, sure, make a standardized workstation with your team. My team uses viemu in VS, which the rest of our office detests, but hey, we are the ones pairing 99% of the time.
When I am not pairing for the majority, I setup my machine to my tastes, and simply install a "default" editor for the few times someone else actually needs to type on my machine. Emacs and IDEA both have good ways to revert everything to defaults temporarily.
I do not believe, however, that a perfectly customized setup has only small gains. For example, consider two tools that I have never seen as defaults in any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens just highlights pairs: http://stevelosh.com/media/images/blog/2010/09/rainbow.png
When actually editing code, those two tools save me several hundred keystrokes an hour. And those are just the first two tools I thought to use as an example out of the entire toolbox that is emacs.
If I was to now give up just those two tools, I would be sentencing myself to the mental equivalent of tying five pound weights to my legs for the marathon that is the rest of my programming career. Why would I intentionally require myself to type more keys per hour to do the same editing, rather than just learning a faster way to edit? This is, obviously, also my argument for learning the vim editing system (which I also use in emacs).
I'm not advocating accepting an editor or IDE default, I'm advocating a standardized environment for a company. If rainbow parens are super-useful, then they can be super-useful for everybody.
And that's another thing that a standardized environment does: it gets techniques out there for the whole team. Because honestly I don't really believe that all that many people are truly getting their environments perfectly optimized for themselves. I think that most people in a shop where everyone does their own thing end up with high un-optimized environments.
Good environments for all, that everyone can use is better than perfect environments for a few, and mediocre environments for most, plus lack of interoperability.
I could see this for a small team _in the right circumstances_ but for a whole company? That seems difficult if you are larger than 20. Imagine the headache trying to get a tool approved for even a 100 person office. And who would approve it, the manager? I see the logic that says everyone should use the best, the problem is now you take the power from the individual who best knows his job and give it to some central person who might not understand people's needs as well.
Pivotal Labs, for example, does it with much larger than 100 person offices. They've got a repository here ( https://github.com/pivotal-sprout/sprout ) with their recipes for setting up their workstations. They have 72 contributors to the repo, so I guess it's not just a centralized manager.
You seem to have never read Pratchett, and should definitely fix that.
Pratchett often takes existing tropes, settings, historical and fictional characters, etc… and breaks, rearranges and/or reinvents them to make things more interesting and/or funnier.
In this case, he took Shelley's Igor (and hunchbacked assistants of a thousand films of the line) and made him into a clan, all called Igor. They're a clan of assistants, surgeons, bio-engineers and self-improvers, they're patched up because "what goeth around cometh around"[0], and with Igor it's parts. They'll exchange limbs, they'll replace eyes, etc… others and theirs both. They lithp for tradition and people's expectation (some of them regularly forget to lisp, or just can't seem to get the trick right) and have highly apparent stitches as something akin to clan markings (they've got dexterity enough for those not to be needed on patients).
The traditional funerals and wake of an Igor consist in other Igor swinging by and leaving with loot bags, with parts of the deceased inside (they'll generally make their parts's destinations known beforehand).
[0] the clan's full motto is "What goeth around, cometh around... or thtopth.": they will help anyone anytime at no charge, but if they have helped and provided a new spleen or replacement eyes they will come by and "rummage around" for healthy organs when the person dies. If they are turned around they will not make a fuss, but no Igor will come by the village ever again.
"This really reminds me of Terry Pratchett’s Igor clan. I discovered this amiable race in The Fifth Elephant. Igors are a people inspired from the typical hunchbacked Igor archetype, but in Discworld, they are also self-modifiers. Their bodies consist of mixed and matched and patched and swapped body parts among other members of their clan, of scars and self-adjustements. They are infinitely self-improving, self-experimenting. They might end up with a botched job and have to hobble around for a few days, but in the end it’s always fixable.
"Igor" as Dr. Frankenstein's assistant achieved prominence through Bela Lugosi's portrayal of the character "Ygor" in the film "The Ghost of Frankenstein". (No character named "Igor" appears in Mary Shelley's novel "Frankenstein: or the Modern Prometheus".)
"Igors" are a community of folks within the fictional "Discworld" universe created by author Terry Pratchet. Dr. Frankenstein's assistant is merely a lab assistant. Igors on Discworld are folks who remake themselves by way of transplants, as described in the article.
Yes, you're missing something. You need to read some Terry Pratchett. There are several entry points to the canon, some better suited than others to different readers. The Igors first arrive in The Fifth Elephat, or possibly Thief Of Time.
As an entry point (but without the Igors (yet)) I recommend "Guards! Guards!", YMMV.
