Shared publicly  - 
real simple emacs lisp examples.
If you always wanted to get into emacs lisp, but never had time, these simple examples might help. Each one is less than 5 or 10 lines.

〈Emacs Lisp Examples ₁〉
This page shows several very simple elisp code. They illustrate the basic programing in elisp, but also, they are very useful themselves. To see a function's documentation, call describe-function 【 F1 f 】. A variable's documentation is describe-variable 【 F1 v 】.
Forrest Jordan's profile photoAndrew Grytsenko's profile photoEarl Jenkins's profile photoTong Hui (tonghuix)'s profile photo
If you're writing examples as tutorials, please use standard elisp style. (Jamming setqs on the end of a line containing another form is ugly.)
+Nick Alcock 
alas, this is when style war begins.

you must have seen the following?

Linux kernel coding style

This is a short document describing the preferred coding style for the
linux kernel.  Coding style is very personal, and I won't force my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too.  Please
at least consider the points made here.

First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it.  Burn them, it's a great symbolic gesture.
Er. Yeah. The Linux kernel follows Unix kernel coding styles, pretty much. Since it is a reimplementation of a Unix kernel this should not be remotely surprising. It is also not surprising that someone who spends all his time in that style finds the GNU coding style unpleasant (I used to be the other way round, but I can cope with either style now). There are five or six C coding styles in wide use (cc-mode knows all of them) and it is exceptionally rare to see substantial bodies of C code that don't fall into one of those styles. When you do, it tends to be a project you back away and and/or turn into a war story, like procmail.

Similarly, Lisp styles are... pretty invariant, and consistent enough that their layout can be entirely automated. I've read a lot of Lisp. I have never once seen people put multiple forms on the same level on a single line the way you're doing there. It looks ugly.
+Nick Alcock, not to mention the free closing parens. Those are incredibly rare in Lisp (for good reason).

+ErgoEmacs, he's right. You really should try to follow more normal coding conventions. Also, some of the actual code looks, shall we say, like "FORTRAN written in Lisp".
+Elias Mårtenson, I actually see quite a lot of people using free closing parens -- but their code never gets accepted upstream because, well, free closing parens look ugly and this is not Algol.
+Nick Alcock +Elias Mårtenson 
i think the concept of code formatting style is harmful, for a lang with regular syntax, such as lisp, xml, Mathematica. In the latter two, one don't hear much about code formatting style, yet we see it heavily in lisp. That impedes awareness and real progress of automatic formatter.

〈Programing: Lisp: Automatic Code Formatting, Lint, Auto Indentation〉

idioms are not that good to have in a lang. Similar in natural languages. They are basically quirks, irregularities, ad hoc, and hard to learn.

i think there's one type of idiom that's very good, that is, the type that effects algorithmic complexity (due to the lang's quirks and implementation detail). For example, python string are not mutable, so when one needs to append string in a loop, one use a list instead, then convert it to string.

〈Programing: Why Idiomatic Programing Are Bad〉

see also the article by Zed linked at bottom. He goes over Ruby.
for my tutorial, sometimes am sloppy, and the code is a learning process as well, and sometimes there's pedagogical constraints. I do appreciate comments, as well as criticisms. Thanks.
In your assessment that "idioms are bad", you are not fully defining what an idiom is nor do you cite any sources as to why your statement is true.

On one hand, you are yourself saying the irregularities are bad, but at the same time your code is full of them (hanging close parens being one).

If you are arguing that the principle of having immutable objects is good, then I agree with you in general (although there certainly are cases where they make the code more clear) but your code has plenty of unnecessary mutating of variables.
+Elias Mårtenson you are right about my article not very good, and no definition on what's idiom.

about hanging close parens, that's just formatting. I have a hard time understanding why lispers don't embrace the automatic formatting concept. What's wrong with automatic formatting?

about immutable object, i was just giving a example of useful idiom of python that comes to mind.
I did, and I can't say I like it very much. This is mainly because while he does have a valid point, he confuses the use of idioms with what the use of idioms by a developer says about the developer.

Every programming language has different styles, best practices etc, which most experienced programmer sin that language employ. They are usually employed because there are sound technical reasons behind them.

When a programmers learns a new language, he tends to try to adapt the practices of his old languages on the new one. In Lisp we can see this by them using standalone parens, excessive use of SETQ, global functions instead of local, etc. In Ruby, programmers tend to use for instead of foreach, simply because foreach wasn't available in his old language and as such he's not aware of the benefits (and drawbacks, of course) of these features.

So, when an experienced programmer looks ad code and sees that it's full of things like that, he can rightly conclude that this programmer is not very experienced, and probably needs to be educated in the best ways to do things in this language. The first place to start is usually to point out the most obvious mistakes, which is what you would call "not following the idioms".
+Elias Mårtenson yes, what you said is true. I agree. I've been there.

though, we can look deeper in this.

Idioms, just as in natural languages, are unavoidable. They develop naturally too. However, too often, we see the elitist type of programers, who insists on idioms, ways. This point Zed covered well. Often, these elitist programers do not see the nature of idioms, and kept on spreading something that's more coolness and fashion than real substance. Perl community is the best example of this. As such, it's like fashion, it comes and go.

what i wanted to point out in that essay, is a illustration that idioms are actually just quirks. Lang X speaker may not notice it, and thinks everyone must use it, but to all other speakers who are outsiders of X, they simply see it as full quirks and special cases, something that is not appetizing.

Again, idioms are not avoidable, but the zest for idioms, as typically seen in programing communities, are over-zealous.

as i mentioned, there is one type of idiom i can think of, that we should encourage their use. Namely, the type that makes a difference in algorithmic complexity. And the python immutable string case i posted before is a good example.

meanwhile, what i wanted to impart, is that as programers or languages designers, idioms should be actively avoided.

on elisp, i disagree somewhat with your stance, or in general with established norm. Note that, most conventions in programing, are simply habit, historical baggage. This includes formatting lines no longer than 80 chars.

the lisp convention of paren placement, is also a problem. Because, such convention lessen awareness of automated formatting. Thus, we have thousands of style guides and arguments about it, while, a automated system don't come to mind. This is especially ironic for lang with regular syntax such as lisp. Meanwhile, in xml, Mathematica community, they almost never talk about code formatting, because it's automatic and transparent to the user. This should happen to lisp. I usually do tug in my trailing parens, but i just don't take the extra mile to specifically care for this, because i consider it harmful to spread this lisp lore of certain formatting style.

why should we, tell each other about formatting, and spend the thousands hours manually do so perhaps with help of paredit, when we could have it to automatically and transparently?

some of these points i've been arguing with lispers in comp.lang.lisp for a decade. I have also written tens of articles on my site. It's a issue i'm afraid that cannot come to agreement, unless someday science based study on this became common. So, what you and many lisper's criticism of my elisp code i'm fully aware. Some are due to my code quality, but many are that way intentionally. We should throw out old precepts based on scientific validity. Newer generation usually adopt new style, without even thinking about it. (clojure comes to mind, many Common Lispers just don't like Clojure)

in summery, idioms are necessary, but by itself is not a good thing. Good idioms are those have computational effect on code.

code formatting, should be entirely eliminated. And this affect the direction of language design too. Language's syntax, it's chars, should have sematic markup built in. This is so with lisp and mathematica. For these languages, editors should be able to do it in real time, automatically, and transparent to user.
regarding setq vs tucked in let, it's also quite interesting.

one'd think we all just put var inside let, and that'd be it. But it can't be done, because setq is still needed in body of code when one wants to change the var.

So, maybe we can stick to a style where constants are inside let, while others we use set. But the thing is, elisp doesn't enforce this.

also, if we look at these 2 styles, one is nested, the other is more linear. Often, linear code is easier to read. Think of nested if vs cond. If we look at GNU Emacs Source code, one'll notice, when the code gets complex, it's always broken down into linear sequences, instead of huge nesting.

so, the above show a dilemma.

at one point, i nest everything possible. This is syntactically superior, due to lisp nesting nature, namely, the syntax contains info about code units.

even now, i still do, adding (progn ) "unnecessarily" to group/mark code units, such as in while or in if. And i tend to use heavily nested if else, then cond, because nested if has a more clear binary logic than one flow in cond.

at the other extreme, is to stick with linear forms as much as possible.

I've explored these two forms. I can't say if i reached any conclusion. The lisp convention, in some aspect is simply inconsistent and arbitrary.

Again, my tendency is that any sort of convention or style should be ban'd in languages. The languages itself, should have syntactical info, and its semantic dictate what form to use. This is i think impossible 100%, but the typical programer lore of recommending convention or style, is not good, in my opinion.
Of course you can do everything inside let and let* and eschew setq. Scheme does just that. You need a lot of nesting, but that's not a grave problem (and you can always reformulate it to make it less nesty). However, like 'one return at the end' models, it can require a lot of reformulation for really quite small changes: so setq is often used judiciously to keep that sort of thing down.

As for idioms being 'elitist', not hardly, They grow naturally in any language community. Yes, they do serve to distinguish members of that community from those outside it, but wailing about how awful they are is pointless: they increase the efficiency of language use, comprehensibility (by members of the idiom-using community), and expressiveness. One could perfectly well say that, just as human languages are little more than concretions of overlapping, long-forgotten metaphors, so too they are concretions of overlapping, long-forgotten idioms. I am certain you use idioms in every human language you speak, and I am certain you don't even realise what half of them are in languages you learned as a child unless you have formal linguistic training (and even then you'll only spot your use of them when you look back and consciously analyze your own speech).

Trying to eliminate idioms is as hopeless a quest as trying to eliminate metaphor or ban pronouns. They are a core part of human language, and can never be removed. If you want to invent a new human race, go right ahead, only of course we don't know that it is even possible to eliminate idiom from a language-using species and retain any language at all. Some songbirds have recognizable linguistic communities and could be said to have idioms (just as those songbirds have a form of grammar). If you call for wiping it out, you only show that you don't know what it is -- or perhaps that you're trying to fit into a new linguistic community and are tired of figuring out all these insane rules.
Well conventions flame war aside... I really like the "Highlighting Lines" example. I have been wanting to do something like this for the output of ant for a while, just did not realize that it would be so simple. Thanks! 
+Nick Alcock good point. This is verging on logic systems. Note that, computer languages are artificial langs (aka constructed lang), and also, it deals with machines, and is of a mathematical nature, again different from natural lang.

Constructed Lang, are usually without irregularities, and other ways to make language more powerful, flexible, easier to learn. Esperanto, Lojban, are prime examples.

Comp lang in this regard, is similar to a symbolic logic system. Do you rather want lots quirks, or a powerful system that is universal and uniform with the most simple grammar?
When you say "lots of quirks" it sounds to me that you are fighting a strawman.

Things like paren placement and use of SETQ (and similar things in other languages) are not quirks. They are established principles that are based on experience of a lot of programmers for a long time. Going against practice just for the sake of being different is not usually the best way to become a good developer.
+Elias Mårtenson have you seen Crockford's video on comp history?

it's worth checking out. Programers, are historically the one that persistently thwart progress in computing. Crockford gives a very good presentation.

just check the 1st video. The others are about JavaScript and others.
Add a comment...