Grouping related buffers

[Corey Foote]

Hi everybody,

As you probably already know, modern window managers support virtual desktops, which extend the workspace to multiple desktop areas. This allows users to spread the windows they have open across multiple workspaces, as an alternative to crowding them all on to one screen. I find this helpful because I work on multiple projects at a time, and having multiple desktops allows me to group the windows for each project together in separate desktops.

I was wondering if there was a way to group related buffers in Emacs through the use of, say, multiple buffer workspaces. For example, it would be nice if when I display a list of existing buffers by typing C-x C-b it would be possible to group the buffers in the list, and when I called C-x b only the buffers in the current grouping would be available. (To get at the others it would be necessary to change the current buffer workspace.)

Thanks!

---

Windows Live Hotmail now works up to 70% faster. Sign up today.

[Tassilo Horn]

Corey Foote <corey...@hotmail.com> writes:

Hi Corey!

> I was wondering if there was a way to group related buffers in Emacs
> through the use of, say, multiple buffer workspaces.

There's desktop-save-mode which can be used therefore. See

(info "(emacs)Saving Emacs Sessions")

for details. It's not exactly like the grouping you'd like to have,
because there's only one open workspace at a time and switching
workspaces involves closing all files/buffers of the current one and
loading the new ones. So quickly jumping between buffers of different
workspaces is not possible.

So many people open one emacs instance per workspace, which has other
drawbacks of course.

Hope that helps,
Tassilo

[Corey Foote]

I actually don't think it would be too difficult to write something like this. It would involved modifying a few functions, and giving each buffer a variable which would identify it with one of the groups. I'm in the process of learning emacs lisp right now, but an no where near experienced enough to make a customization like this!

By the way, does anybody have any recommendations on the best way to learn emacs lisp? I've got two books... the emacs lisp manual and an old O'Reilly book called Writing GNU Emacs Extensions by Bob Glickstein. It would be cool if there were a course I could take in programming this stuff... :-)

> To: help-gn...@gnu.org
> From: tas...@member.fsf.org
> Date: Mon, 10 Nov 2008 17:43:07 +0100
> Subject: Re: Grouping related buffers

---

Get 5 GB of storage with Windows Live Hotmail. Sign up today.

[Drew Adams]

> By the way, does anybody have any recommendations on the
> best way to learn emacs lisp? I've got two books... the
> emacs lisp manual and an old O'Reilly book called Writing
> GNU Emacs Extensions by Bob Glickstein. It would be cool
> if there were a course I could take in programming this
> stuff... :-)

[Please use plain text, not HTML, and please start a new thread for a new
topic.]

The Emacs Wiki has some help about this:
http://www.emacswiki.org/emacs/LearningEmacs#LearnEmacsLisp

I would also recommend this:

Think of something simple that you would like to make Emacs do, and try to do
it. In particular, try to modify some existing Lisp function or command in some
way that you're interested in.

This will get you to look at how things are done in the existing code, which is
a great source for models. And the existing code works (!), so any departures
you make from it can be compared when your changes don't do exactly what you
expect.

Another help is to get familiar with an Emacs-Lisp debugger - either edebug or
the classic debugger (`debug-on-entry', put (debug) calls in your code, etc.).
Likewise, functions `message', `sit-for', and `sleep-for' (for use with
`message').

[Drew Adams]

> I was wondering if there was a way to group related buffers
> in Emacs through the use of, say, multiple buffer workspaces.

> For example, it would be nice if when I display a list of
> existing buffers by typing C-x C-b it would be possible to
> group the buffers in the list, and when I called C-x b only
> the buffers in the current grouping would be available. (To
> get at the others it would be necessary to change the
> current buffer workspace.)

[Please use plain text, not HTML, for this mailing list.]

There are probably several ways to do what you want. Look on Emacs Wiki, and
perhaps take a look also at Ibuffer (dunno about that).

Here is another. In Icicles, you can define any number of named buffer
configurations. Each buffer config represents a named set of buffers, together
with a sort function and other parameters that control buffer-name completion.

* config name
* regexp that buffer names must match
* regexp that buffer names must not match
* predicate that buffer names must satisfy
* explicit list of additional buffers
* buffer-name sort function

For example, here is a buffer config named `Files and Scratch' that includes
only buffer `*scratch*' and buffers visiting files. By default, the buffer names
are sorted alphabetically.

("Files and Scratch" ; config name
nil ; must-match regexp
nil ; must-not-match regexp
(lambda (bufname) ; predicate
(buffer-file-name
(get-buffer bufname)))
("*scratch*") ; extra buffers
string-lessp) ; sort function

See:
http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects

http://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#icicle-b
uffer-configs

Independently of any buffer configs, you can also save (persistently or not) any
set of buffer-name completion candidates to reuse for completion later. (You can
also save and then reuse file names or any other set of completion candidates.)

See:
http://www.emacswiki.org/emacs/Icicles_-_Candidate_Sets

[Richard Riley]

"Drew Adams" <drew....@oracle.com> writes:

He's not popular with some on the more established Emacs users because
of his outspokenness on the some of the more newbie unfriendly aspects of
Emacs, but Xah Lee is an excellent resource with carefully argued points
and practical approach to, amongst other things, eLisp usage :-;

http://xahlee.org/emacs/elisp.html

It is a learn by doing approach and might work well for you

regards

Richard.

[Scott Frazer]

Corey Foote wrote:
> Hi everybody,
>
> As you probably already know, modern window managers support virtual
> desktops, which extend the workspace to multiple desktop areas. This
> allows users to spread the windows they have open across multiple
> workspaces, as an alternative to crowding them all on to one screen. I
> find this helpful because I work on multiple projects at a time, and
> having multiple desktops allows me to group the windows for each project
> together in separate desktops.
>
> I was wondering if there was a way to group related buffers in Emacs
> through the use of, say, multiple buffer workspaces. For example, it
> would be nice if when I display a list of existing buffers by typing C-x
> C-b it would be possible to group the buffers in the list, and when I
> called C-x b only the buffers in the current grouping would be
> available. (To get at the others it would be necessary to change the
> current buffer workspace.)

I'd suggest using the buffer-show package. Here's some skeleton code
that works but is pretty lame (no completion, showing of current or
all tags, etc. is left as an exercise for the student :) ):

(require 'bs)

(defvar bs-group-buffer-tags nil
"*List of group tags for a buffer")
(make-variable-buffer-local 'bs-group-buffer-tags)

(defvar bs-group-active-tag nil
"*Active tag for showing buffer list")

(defun bs-group-add-buffer-tag (tag)
(interactive "sAdd buffer tag: ")
(setq bs-group-buffer-tags (add-to-list 'bs-group-buffer-tags tag)))

(defun bs-group-delete-buffer-tag (tag)
(interactive "sRemove buffer tag: ")
(setq bs-group-buffer-tags (delete tag bs-group-buffer-tags)))

(defun bs-group-set-active-tag (tag)
(interactive "sSet active tag: ")
(setq bs-group-active-tag tag))

(defun bs-group-must-show-function (buf)
(save-excursion
(set-buffer buf)
(member bs-group-active-tag bs-group-buffer-tags)))

(defun bs-group-dont-show-function (buf)
(not (bs-group-must-show-function buf)))

(setq bs-configurations
(add-to-list 'bs-configurations
'("tagged"
nil bs-group-must-show-function
nil bs-group-dont-show-function
nil)))

[Tassilo Horn]

Richard Riley <riley...@gmail.com> writes:

Hi Richard,

> [...] but Xah Lee is an excellent resource with carefully argued
> points and practical approach to, amongst other things, eLisp usage.

This is a joke, isn't it?

When learning a language it's better to take a look at polished code
that uses this language's idioms. Xah's on a crusade against even the
most basic stuff like correct indentation...

The best resources for elisp are

(info "(eintr)Top")

and

(info "(elisp)Top")

together with the online help (`C-h ?'). All of these are included in
emacs.

And of course, you learn a language best by speaking/programming in it.
But Drew already said that.

Ah, and there's this (and other emacs related newsgroups) + #emacs on
freenode where you can ask your questions.

Bye,
Tassilo
--
A child of five could understand this! Fetch me a child of five!

[Richard Riley]

Tassilo Horn <tas...@member.fsf.org> writes:

> Richard Riley <riley...@gmail.com> writes:
>
> Hi Richard,
>
>> [...] but Xah Lee is an excellent resource with carefully argued
>> points and practical approach to, amongst other things, eLisp usage.
>
> This is a joke, isn't it?

Not in the slightest. I can only assume the bit you snipped about some
more established Emacs users disagreeing with him applies to you? Or the
tone suggests that.

>
> When learning a language it's better to take a look at polished code
> that uses this language's idioms. Xah's on a crusade against even the
> most basic stuff like correct indentation...

By correct indentation I guess you mean the established custom? I cant
disagree that customs are good but personally I think the established
custom in elisp is rather awkward to the extreme. Not that i dont try to
adhere to it :-; But even looking around the C world we see various
indentation standards and everyone is entitled to their view. A constant
style is, of course, better for everyone although it does not
immediately mean that constant style is the best. As a programmer for
years I can not even begin to understand how and why eLisp bracketing
standards became as they did other than maybe to save screen real estate
in the VT100 type days. FWIW, I think saving space is better for the eye
too in some ways but I find "at a glance" analysis of most eLisp code
almost impossible because of the standard of grouping all closing
brackets.

>
> The best resources for elisp are
>
> (info "(eintr)Top")
>
> and
>
> (info "(elisp)Top")

For eLisp reference maybe. But I found Xah Lee's tutorial very
good. Its a programmers introduction and gets to the key points quickly
in an ordered manner and grouped in logical sections.

*shrug*

We all prefer different methods. But I like his practical learn by doing
approach.

>
> together with the online help (`C-h ?'). All of these are included in
> emacs.

If I might be so bold as to mention I added a context help addition which
shows you the function or variable under point as an extension to eldoc:

http://www.emacswiki.org/emacs-fr/ElDoc#toc6

>
> And of course, you learn a language best by speaking/programming in it.
> But Drew already said that.

Of course. But eLisp is special in that its almost unreadable to the
typical procedural programmer fluent in C/C++ etc until you know a lot
if it already. Or that was my experience. And we all have different
experiences so it does no harm to remain open as to what suits other
people.

I found Xah Lee's tutorial very useful and feel it would certainly
benefit some others too.

>
> Ah, and there's this (and other emacs related newsgroups) + #emacs on
> freenode where you can ask your questions.
>
> Bye,
> Tassilo

--
important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday. ~Dennis Gabor, Innovations: Scientific, Technological and Social, 1970

[Drew Adams]

> I'd suggest using the buffer-show package....
> (require 'bs)

I should perhaps have mentioned that Icicles buffer configs were inspired by
those of bs. (The Icicles doc I pointed to makes that clear.)

[Drew Adams]

> The best resources for elisp are
> (info "(eintr)Top") and (info "(elisp)Top")

> together with the online help (`C-h ?').

Yes!

Here's something to keep in mind. Lisp is a bit peculiar wrt things such as data
structures and variables. Do yourself a favor and learn about things such as
lists (list structure) and symbols from the above-mentioned sources or from
other texts specifically about Lisp.

Do not try to learn about such things from loose analogies with other languages,
especially from writers who might not be all that Lispian.

I'm not trying to denigrate any given text that tries to help you learn. I'm
just saying beware of being misled by writings that tell you that symbols are
variables or are like variables, or that Lisp passes arguments by value or
reference or whatever - and so forth. Learn Lisp as Lisp, not wearing C or Java
or Haskell glasses. Learn about symbols and conses and quote. Then go forth and
cons.

The Emacs-Lisp Intro mentioned above is definitely the place to start, as well
as the first few chapters of the Elisp manual.

Any book about Lisp is also bound to help, in spite of the fact that each Lisp
dialect is a bit different. What's important is to grasp the basics of Lisp
itself.

[Niels Giesen]

Richard Riley <riley...@gmail.com> writes:
[...]

> Of course. But eLisp is special in that its almost unreadable to the
> typical procedural programmer fluent in C/C++ etc until you know a lot
> if it already. Or that was my experience. And we all have different
> experiences so it does no harm to remain open as to what suits other
> people.

Where is there any evidence that the original OP is a `typical
procedural programmer fluent in C/C++'?

It annoys me to pieces that so many textbooks assume that everyone out
there is a C/C++/Java programmer. For me, Lisp was my first
programming language (thanks to Emacs, which I started using to write
law papers in), and I do not need textbooks to explain for instance
Ruby to me in Lisp (which is perfectly feasible) but I even less need
comparisons with Java or C. Even worse, doing so is a major
distraction from the real object of learning.

Consider teaching Dutch to someone from Morocco but using English
during the lessons: that's just plain silly and simply leads to
unnecessary confusion. Using analogies from Slovak to teach Polish
however may be insightful, but only when the student already has
knowledge of a Slavic language. Same goes with programming languages:
do not assume.

When teaching something, teach it by itself; people willing to learn a
new language are most likely not stupid, and if they are somewhat
smart, they will find out for themselves what differences and
similarities there are between languages known already.

For me, it would have been nice when learning JavaScript if the books
had warned me that not everything is an expression (invalid left-hand
assignment anyone?), that you have to explicitly return something,
that there are things such as keywords, and it would be nice if
textbooks explain how to take advantage of closures instead of trying
to get rid of them, hide them, and how to build an ugly half-assed
Class system.

The first few of those would cause people coming from C or Java at
least to frown but most probably to get irritated ("Why would I care
about all these strange incomprehensible things from some dead
language with too many parens, when all I want to do is simply to
learn JavaScript?????"). Therefore, I would not recommend such in a
learning text on JavaScript.

The second however, how to make good use of lexical scoping, is
interesting to learn, and should be explained by itself, as should be
prototype based inheritance and functions as first-class things (two
of which could - but should not - be explained by comparison with
Lisp).

Comparisons with Java-style OOP however should not be in a basic
textbook on learning JavaScript, and certainly no attempt should be
made to mimic it -- for the very same reasons that comparisons with
Lisp should not be made in a general textbook.

[Richard Riley]

Niels Giesen <niels....@gmail.com> writes:

> Richard Riley <riley...@gmail.com> writes:
> [...]
>> Of course. But eLisp is special in that its almost unreadable to the
>> typical procedural programmer fluent in C/C++ etc until you know a lot
>> if it already. Or that was my experience. And we all have different
>> experiences so it does no harm to remain open as to what suits other
>> people.
>
> Where is there any evidence that the original OP is a `typical
> procedural programmer fluent in C/C++'?

There isn't any. Why do you ask? I am and I found Xah Lee's tutorial
helpful. I didn't assume he was or wasn't. I just added the link
to allow the OP to evaluate the usefulness himself.

Since you seem to be quite sure I am doing a mis-service I think its
only fair to defend myself and point something out -

If you read the paragraph above I specifically say:

,----

| And we all have different experiences so it does no harm to remain open
| as to what suits other people.

`----

So I am somewhat surprised by your reading of my reply.

>
> It annoys me to pieces that so many textbooks assume that everyone out
> there is a C/C++/Java programmer. For me, Lisp was my first

It would me too. But I didn't and nothing I said indicated I did. Had he
been though it might be useful. Others read this threads too following a
Google.

If Lisp was your first language great. There are many, many more where
it won't be. eLisp is a minority language and people familiar with
others will frequently be looking to learn a little. This is obvious
from reading this group and the #emacs irc channel.

> programming language (thanks to Emacs, which I started using to write
> law papers in), and I do not need textbooks to explain for instance
> Ruby to me in Lisp (which is perfectly feasible) but I even less need
> comparisons with Java or C. Even worse, doing so is a major
> distraction from the real object of learning.

Yes, that is all really nice. But others might benefit from the
link. You seem quite adamant that it should not have been posted. I can
not begin to think why. It is another eLisp resource that people MIGHT
find useful depending on their skill levels, background and needs. Let
them decide.

>
> Consider teaching Dutch to someone from Morocco but using English
> during the lessons: that's just plain silly and simply leads to
> unnecessary confusion. Using analogies from Slovak to teach Polish
> however may be insightful, but only when the student already has
> knowledge of a Slavic language. Same goes with programming languages:
> do not assume.

I don't. But I also don't decide for the person asking. Providing the
link can do no harm.

Ir is often forgotten that SOME programmers are looking for a quick and
dirty introduction in order to do one thing and one thing only. They
have neither the time, resources nor desire to learn something like Lisp
from the bottom up and some readily available patterns and programming
snippets are more than enough.

i can only state once more : I personally found Xah Lee's tutorial
useful and consider that others might too.

[grischka]

You might want to try "eproject".

http://tromey.com/elpa
http://tromey.com/elpa/eproject-0.1.tar

It doesn't exactly group buffers, but it stores workspaces and allows
to switch from one to another quickly.

With eproject, a workspace includes a set of files and their positioning
in the editor, a separate menu that shows only these files (i.e. not mixed
with nonfile-buffers), and another menu with custom commands (typically make
commands) which can be optionally bound to shortcut keys.

Another feature is that when you close emacs it remembers the current
project and reopens it automatically when you start emacs the other day.

Basically it implements some of the behavior that is known from common IDEs.

As to working on two projects at the same time, I'd just open two instances
of emacs.

--- grischka

[Xah]

On Nov 10, 12:59 pm, Niels Giesen <niels.gie...@gmail.com> wrote:

> Richard Riley <rileyrg...@gmail.com> writes:
>
> [...]
>
> > Of course. But eLisp is special in that its almost unreadable to the
> > typical procedural programmer fluent in C/C++ etc until you know a lot
> > if it already. Or that was my experience. And we all have different
> > experiences so it does no harm to remain open as to what suits other
> > people.
>
> Where is there any evidence that the original OP is a `typical
> procedural programmer fluent in C/C++'?

Vast majority of programers coming to emacs is familiar with
procedural languages, such as C, C++, Java, perl, php, visual basic.

The original poster may be a exception, but it is reasonable to make a
general assumption when giving tips.

> It annoys me to pieces that so many textbooks assume that everyone out
> there is a C/C++/Java programmer. For me, Lisp was my first
> programming language (thanks to Emacs, which I started using to write
> law papers in), and I do not need textbooks to explain for instance
> Ruby to me in Lisp (which is perfectly feasible) but I even less need
> comparisons with Java or C. Even worse, doing so is a major
> distraction from the real object of learning.
>
> Consider teaching Dutch to someone from Morocco but using English
> during the lessons: that's just plain silly and simply leads to
> unnecessary confusion. Using analogies from Slovak to teach Polish
> however may be insightful, but only when the student already has
> knowledge of a Slavic language. Same goes with programming languages:
> do not assume.

it is relevant to consider something vast majority of readers are
already familiar of.

Vast majority of programers, are familiar with one of procedural lang
such as C, Java, C++, perl, visual basic. These are roughly maybe 95%
of all programers. So, when teaching a new programing language,
mentioning tips related to procedural lang is fruitful and effective.

Similarly, when teaching a foreign lang, it makes sense to mention
tips contrasting to the lang English.

> When teaching something, teach it by itself; people willing to learn a
> new language are most likely not stupid, and if they are somewhat
> smart, they will find out for themselves what differences and
> similarities there are between languages known already.

you are of course just bitching. Of course, most tutorials do try to
teach the lang itself, and very few are entirely based on transition
from another lang, such as “Python for Perl programers” or “Java for C+
+ programers”, “PHP for Perl programers”, “Haskell for Lispers”, etc.

> For me, it would have been nice when learning JavaScript if the books
> had warned me that not everything is an expression (invalid left-hand
> assignment anyone?), that you have to explicitly return something,
> that there are things such as keywords, and it would be nice if
> textbooks explain how to take advantage of closures instead of trying
> to get rid of them, hide them, and how to build an ugly half-assed
> Class system.
>
> The first few of those would cause people coming from C or Java at
> least to frown but most probably to get irritated ("Why would I care
> about all these strange incomprehensible things from some dead
> language with too many parens, when all I want to do is simply to
> learn JavaScript?????"). Therefore, I would not recommend such in a
> learning text on JavaScript.

You were complaining about books giving tips of procedural lang tips.
But now you are using a example of giving tips about lisp to
illustrate how silly it is. Note that the books we are discussing, do
not give tips about lisp, because it is a lang very few people know.

However, books about functional langs do sometimes give relevant info
for programers familiar with lisp. The principle is the same, namely,
that for a significant portion of the readership, they are familiar
with lang x, so the book give tips for lang x programers. For example,
the official elisp reference gives many tips and warnings to those
familiar with Common Lisp, and about C too.

(to me, it is entirely distracting because i do not have working
familiarity with Common Lisp or C, nor do i care about them. However,
i'm the world's top expert in Mathematica, but vast majority of
potential readers of elisp doc are not familiar with Mathematica.)

Similarly, Perl doc or books often contain tips, warnings, about C,
awk, unix shell. Books on regex will often give tips or mention about
Perl lang's regex.

All in all, these tips mentioning another lang is useful. They are
useful because learning is faster when we can borrow knowledge from
somethnig we already know.

In summary, when a programing lang x book gives tips for lang y
programers, it is because a significant portion of its potential
readers are familiar with lang y, therefore the tips is effective.

-----------------

There are other extremes. For example, some books do not mention any
other lang for tips or comparison at all. Examples include
Mathematica's doc (The Mathematica Book), Java Doc (so-called the
“Java API” Java™2 Platform Standard Edition 5.0 API Specification),
Java Lang Spec, Scheme's r4rs.

Typically, these are lang spec or official reference.

On the other extreme, some books gets abusive in mentioning lots other
langs instead of a proper description of the lang itself, often to the
degree of making the doc itself unclear, confusing, or less useful.
Example of this is Perl's doc (perldoc), Python doc.

Typically, tutorial type of books tends to mention other langs, and
some of them to a degree that's more damaging then helpful.

As a example of the abusive use of mentioning other lang, here's a
excerpt from Python doc on it's chapter about Python's class. It start
thus:

«
Python's class mechanism adds classes to the language with a
minimum of new syntax and semantics. It is a mixture of the class
mechanisms found in C++ and Modula-3. As is true for modules, classes
in Python do not put an absolute barrier between definition and user,
but rather rely on the politeness of the user not to ``break into the
definition.'' The most important features of classes are retained with
full power, however: the class inheritance mechanism allows multiple
base classes, a derived class can override any methods of its base
class or classes, a method can call the method of a base class with
the same name. Objects can contain an arbitrary amount of private
data.

In C++ terminology, all class members (including the data members)
are public, and all member functions are virtual. There are no special
constructors or destructors. As in Modula-3, there are no shorthands
for referencing the object's members from its methods: the method
function is declared with an explicit first argument representing the
object, which is provided implicitly by the call. As in Smalltalk,
classes themselves are objects, albeit in the wider sense of the word:
in Python, all data types are objects. This provides semantics for
importing and renaming. Unlike C++ and Modula-3, built-in types can be
used as base classes for extension by the user. Also, like in C++ but
unlike in Modula-3, most built-in operators with special syntax
(arithmetic operators, subscripting etc.) can be redefined for class
instances.
»

It is a form of author masterbation.

In the case of Perl's official doc (perldoc), the workings of unix
shell, awk, C is frequently mentioned in the doc as a way of
explanation, just about every page on every function, instead of
proper documentation independent of other langs. (partly for this
reason, learning perl is difficult for those not from the unix/c
background) The only perl book that properly discuss perl without
borrowing other langs is “Perl: The Programmer's Companion” (1997) by
Nigel Chapman.

Similarly, unix docs (the “man pages”) are also like like. Instead of
proper spec of what a function or tool do, it is written in a way that
assumes you know C and much of the workings of unix, and mentions them
throughout in a confusing way.

For much more discussion about documentation, see:

• Python Documentation Problems
http://xahlee.org/perl-python/python_doc_index.html
(collection of 11 essays on python documentation problems, and on
documentation in general)

• survey of perl books
http://xahlee.org/UnixResource_dir/perlr.html

Xah
∑ http://xahlee.org/

☄

[Andreas Politz]

That darn old emacs again ! Seriously this has more to do with lisp in
general than specifically with elisp. I doubt you'd find any _one_ serious
programmer or author in the whole lisp community who proposes this kind of
style ( each closing paren on a seperate line ).

-ap

[Wei Weng]

This is a very typical case of "Too many words, too few substances".

You spent all these time typing out all these words, I can summarize in 1 line:

Elisp is very different from C/C++/Java, and it is my (Niels) first language.

Thanks
Wei

[Richard Riley]

Andreas Politz <pol...@fh-trier.de> writes:

You will notice that I did not propose it. I said the standard is hard
for me to read as someone who is not an eLisp magician. I still do not
understand (other than the reasons I postulated about above) why it is
as it is. I find it very hard to indent and match (ok, emacs helps with
matching brackets), but would find it very difficult to read from a
printout for example. But this is more my lack of experience
possibly. All hindrances can become less so with experience. But would
aligned brackets really hurt anyone? I dont think so. It is convention
(and convention is a good thing at times) which has the style as it
is. Or?

[Andreas Politz]

Yes, I misunderstood you. I thought you were impying this, by the comparison with C.

-ap

[Lennart Borgman]

On Tue, Nov 11, 2008 at 9:48 AM, Richard Riley <riley...@gmail.com> wrote:
>> That darn old emacs again ! Seriously this has more to do with lisp in
>> general than specifically with elisp. I doubt you'd find any _one_ serious
>> programmer or author in the whole lisp community who proposes this kind of
>> style ( each closing paren on a seperate line ).
>
> You will notice that I did not propose it. I said the standard is hard
> for me to read as someone who is not an eLisp magician. I still do not
> understand (other than the reasons I postulated about above) why it is
> as it is. I find it very hard to indent and match (ok, emacs helps with
> matching brackets), but would find it very difficult to read from a
> printout for example. But this is more my lack of experience
> possibly. All hindrances can become less so with experience. But would
> aligned brackets really hurt anyone? I dont think so. It is convention
> (and convention is a good thing at times) which has the style as it
> is. Or?

I think that most elisp programmers will look at the indentation when
reading the code on paper. You can compare with python where only the
indentation matters. I do not like that, but the combination of
indentation (for the eyes) and parenthesis (for the parser) seems very
good to me.

[Richard Riley]

"Lennart Borgman" <lennart...@gmail.com> writes:

While I am not surprised at some of the reactions to my recommendations
for Xah Lee's tutorial, I feel I should defend it further from the
perspective of the programmer coming to eLisp for the first time. I know
for me going to php, , java, bash script and elisp (as some examples),
I knew what I wanted to do. It was a question of how.

I wanted to

+ display some stuff in the result are/log/status buffer
+ compare some values using standard operators
+ loop on things
+ define variables with varying scope
+ manipulate and merge some strings
+ create and use a function or two
+ handle arrays/lists of data and manipulate them

If the following does not make that clear to a programmer then I think
nothing will:

http://xahlee.org/emacs/elisp_basics.html

From that quick intro I could get into other people's code and read it a
lot more comfortably. It reminds me very much of K&R's excellent
tutorial section at the beginning of the C Programming language in that
its written for the programmer who knows what he wants to do, just not
in that particular language at that moment in time. I recommend it
completely.

[Juanma Barranquero]

On Tue, Nov 11, 2008 at 09:48, Richard Riley <riley...@gmail.com> wrote:

> But would
> aligned brackets really hurt anyone? I dont think so.

Depend on your definition of "hurt". For many people, myself included,
is ugly to the point of being almost unbearable.

I suppose writing Pascal code like this

if my_condition then begin
{ ... }
end else begin
{ ... }
end;

or C code like this

if (my_condition) { /*...*/ }
else { /*...*/ }

or worse:

#define BEGIN {
#define END }
#define THEN
#define ELSE else
#define IF(c) if ((c))

IF(my_condition) THEN
BEGIN
/* ...*/
END
ELSE
BEGIN
/*...*/
END

doesn't really *hurt* anyone. But still...

Juanma

[Richard Riley]

"Juanma Barranquero" <lek...@gmail.com> writes:

> On Tue, Nov 11, 2008 at 09:48, Richard Riley <riley...@gmail.com> wrote:
>

>> But would
>> aligned brackets really hurt anyone? I dont think so.
>

> Depend on your definition of "hurt". For many people, myself included,
> is ugly to the point of being almost unbearable.
>
> I suppose writing Pascal code like this
>
> if my_condition then begin
> { ... }
> end else begin
> { ... }
> end;

I like the

if(f){
/**/
}else{
/**/
}

K&R style.

Still, one man's meat is another man's poison.

[Juanma Barranquero]

On Tue, Nov 11, 2008 at 12:04, Richard Riley <riley...@googlemail.com> wrote:

> I like the
>
> if(f){
> /**/
> }else{
> /**/
> }
>
> K&R style.

I like it too, more or less, but the equivalent in Pascal is quite ugly IMO.

But, as you say, that's K&R style, so it is widely known. Of course
indentation styles are conventions; we find them ugly or beautiful,
mostly, out of familiarity. And in the Lisp family of languages,
aligned brackets are unusual, except in very deeply indented code; and
even so, it's often not that brackets are aligned, as that a bunch of
them are moved to the next line to avoid having too many closing
parenthesis put together.

> Still, one man's meat is another man's poison.

Sure.

Juanma

[Niels Giesen]

Reply to all

First of all I'd like to say I do not think Xah's tutorial is in the
category of texts I described. It is a fine introduction and teaches
by example, by explaining in plain English the set goals and in Lisp
the ways to achieve. The link to his tutorial is fine with me.

Xah get's it right /not/ to draw on knowledge of other languages and
it is no use advertising his tutorial as being suitable for average
C&c programmers (which it sure may be, but other people can be scared
away from it precisely because of that). Which is what I read in
Richards post, but I may be reading too much between the lines there.

I might have read the original message by Richard better, and admit
having jumped at the 'average C/C++ programmer' bit. This comes from
my perceived habit of writers assuming working knowledge in Y, and not
properly advertising it as 'X for Yniks', while all the reader wants
is to learn X. I thought this was such a case. Apparently not.

[B. T. Raven]

I thought that Stephen Wolfram (author of _A New Kind of Science_) was
the top expert. Is this another exaggeration like the statistics you
pull out of a hat?: e.g. "99.9999% of all southpaws are touch typists."
Remember that all majorities are not "vast," in fact the vast majority
of them are not even majorities but only pluralities.

Ed

[Xah]

Xah Lee wrote:
> > (to me, it is entirely distracting because i do not have working
> > familiarity with Common Lisp or C, nor do i care about them. However,
> > i'm the world's top expert in Mathematica, but vast majority of
> > potential readers of elisp doc are not familiar with Mathematica.)

B. T. Raven wrote:

> I thought that Stephen Wolfram (author of _A New Kind of Science_) was
> the top expert.

Yes, he's one of the top expert in programing Mathematica.

> Is this another exaggeration like the statistics you
> pull out of a hat?: e.g. "99.9999% of all southpaws are touch typists."

did u pull that out of a hat?

> Remember that all majorities are not "vast," in fact the vast majority
> of them are not even majorities but only pluralities.

pluralities? how about multitudality? News: Xah discovered that
multitudality of tech geekers are idiotic when it comes to critical
thinking.

can you try the command-frequency.el and let me know your results?
because recently someone made it into a full featured minor mode and
it's now very easy to use. It also saves between emacs restart.

bottom: http://xahlee.org/emacs/command-frequency.html

Xah
∑ http://xahlee.org/

☄

[Stefan Kamphausen]

Hi,

Tassilo Horn <tas...@member.fsf.org> writes:

> Corey Foote <corey...@hotmail.com> writes:
>
> Hi Corey!
>

>> I was wondering if there was a way to group related buffers in Emacs
>> through the use of, say, multiple buffer workspaces.

please excuse the self-plug but here it is nevertheless...

I've written something like that for my own use:
http://www.skamphausen.de/cgi-bin/ska/mtorus

You can create a "ring of rings" where the inner rings are markers and
the outer ring organizes the inner rings. Ah, complicated to explain, I
already tried that in the comments of mtorus.el and failed. Maybe you
just give it a try.

Cheers,
Stefan
--
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.

[rustom]

On Nov 10, 8:21 pm, Corey Foote <coreyfo...@hotmail.com> wrote:
> Hi everybody,
>
> As you probably already know, modern window managers support virtual desktops, which extend the workspace to multiple desktop areas. This allows users to spread the windows they have open across multiple workspaces, as an alternative to crowding them all on to one screen. I find this helpful because I work on multiple projects at a time, and having multiple desktops allows me to group the windows for each project together in separate desktops.
>
> I was wondering if there was a way to group related buffers in Emacs through the use of, say, multiple buffer workspaces. For example, it would be nice if when I display a list of existing buffers by typing C-x C-b it would be possible to group the buffers in the list, and when I called C-x b only the buffers in the current grouping would be available. (To get at the others it would be necessary to change the current buffer workspace.)

Have you seen tabbar mode?
[Sorry if others have mentioned it already]