Grouping related buffers

Grouping related buffers

[Corey Foote]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]


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.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008

[-- Attachment #2: Type: text/html, Size: 1309 bytes --]

Re: Grouping related buffers

[Tassilo Horn]

Corey Foote <coreyfoote@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

RE: Grouping related buffers

[Corey Foote]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]


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-gnu-emacs@gnu.org
> From: tassilo@member.fsf.org
> Date: Mon, 10 Nov 2008 17:43:07 +0100
> Subject: Re: Grouping related buffers
> 
> Corey Foote <coreyfoote@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
> 
> 
> 

_________________________________________________________________
Get 5 GB of storage with Windows Live Hotmail.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008

[-- Attachment #2: Type: text/html, Size: 2112 bytes --]

learning Emacs Lisp [was: Grouping related buffers]

[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').

RE: Grouping related buffers

[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

Re: learning Emacs Lisp

[Richard Riley]

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

>> 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').

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.

Re: learning Emacs Lisp

[Tassilo Horn]

Richard Riley <rileyrgdev@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!

Re: learning Emacs Lisp

[Richard Riley]

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

> Richard Riley <rileyrgdev@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

RE: learning Emacs Lisp

[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.

Re: learning Emacs Lisp

[Niels Giesen]

Richard Riley <rileyrgdev@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.

Re: learning Emacs Lisp

[Richard Riley]

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

> Richard Riley <rileyrgdev@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.

Re: learning Emacs Lisp

[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/

☄

Re: learning Emacs Lisp

[Andreas Politz]

Richard Riley wrote:
> Tassilo Horn <tassilo@member.fsf.org> writes:
> 
>> Richard Riley <rileyrgdev@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.
> 

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

>> 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
> 

Re: learning Emacs Lisp

[Wei Weng]

Niels Giesen wrote:
> Richard Riley <rileyrgdev@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.

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

Re: learning Emacs Lisp

[Richard Riley]

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

> Richard Riley wrote:
>> Tassilo Horn <tassilo@member.fsf.org> writes:
>>
>>> Richard Riley <rileyrgdev@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.
>>
>
> 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?

Re: learning Emacs Lisp

[Andreas Politz]

Richard Riley wrote:
> Andreas Politz <politza@fh-trier.de> writes:
> 
>> Richard Riley wrote:
>>> Tassilo Horn <tassilo@member.fsf.org> writes:
>>>
>>>> Richard Riley <rileyrgdev@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.
>>>
>> 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. 

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

-ap

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?

Re: learning Emacs Lisp

[Lennart Borgman]

On Tue, Nov 11, 2008 at 9:48 AM, Richard Riley <rileyrgdev@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.

Re: learning Emacs Lisp

[Richard Riley]

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

> On Tue, Nov 11, 2008 at 9:48 AM, Richard Riley <rileyrgdev@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.
>

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.

Re: learning Emacs Lisp

[Juanma Barranquero]

On Tue, Nov 11, 2008 at 09:48, Richard Riley <rileyrgdev@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

Re: learning Emacs Lisp

[Richard Riley]

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

> On Tue, Nov 11, 2008 at 09:48, Richard Riley <rileyrgdev@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.

Re: learning Emacs Lisp

[Juanma Barranquero]

On Tue, Nov 11, 2008 at 12:04, Richard Riley <rileyrgdev@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

Re: learning Emacs Lisp

[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.

Re: learning Emacs Lisp

[B. T. Raven]

Xah wrote:
> 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.)

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

Re: learning Emacs Lisp

[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/

☄

Re: Grouping related buffers

[Stefan Kamphausen]

Hi,

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

> Corey Foote <coreyfoote@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.