bind a hotkey to toggle variable

bind a hotkey to toggle variable

[tiefeng wu]

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

hello all!I'm trying to bind f6 key to toggle 'pop-up-frames' variable by
insert following line in my .emacs file:

(global-set-key [f6] (lambda () (setq pop-up-frames (not pop-up-frames)))

and after restart emacs and press f6, emacs says "Wrong type argument:
commandp, (lambda nil (setq pop-up-frames (not pop-up-frames)))"

please give me some help, thanks!

tiefeng wu
2009-07-12

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

RE: bind a hotkey to toggle variable

[Drew Adams]

See reply to your thread "emacs and window placement", which asked the same
question (using the exact same text!).

(And please use plain-text mail, not HTML, for this mailing list.)

Re: bind a hotkey to toggle variable

[tiefeng wu]

I think it's better move discussion of my question here to not bother
henry - poster of thread "emacs and window placement", sorry again!

2009/7/13 Drew Adams <drew.adams@oracle.com>:
> What you bind to a key must be a command. For a function to be a command, it
> must have an `interactive' spec. So you need this:
>
>  (global-set-key [f6]
>   (lambda () (interactive) (setq pop-up-frames (not pop-up-frames)))
>
> See the Elisp manual, node `Defining Commands'.
>

thanks Adams, I'll read the manual carefully.

btw, I'm using your elisp library and having my pop-up-frames variable
default setting to t,
Recently I'm trying IDE-like 'nav' mode from google code, and the
setting of pop-up-frames
starts conflict with nav, because for 'nav' it's better open files in
same frame. So this question
occured.

tiefeng wu
2009-07-13

RE: bind a hotkey to toggle variable

[Drew Adams]

> > See the Elisp manual, node `Defining Commands'.
>
> thanks Adams, I'll read the manual carefully.
> 
> btw, I'm using your elisp library and having my pop-up-frames variable
> default setting to t, Recently I'm trying IDE-like 'nav' mode from
> google code, and the setting of pop-up-frames starts conflict with
> nav, because for 'nav' it's better open files in same frame. So this 
> question occured.

I'm not familiar with `nav' mode, and I don't know which of my libraries you
mean. But I'm not surprised that some other code (e.g. `nav') has some problems
with non-nil `pop-up-frames'.

Unfortunately, it's all too common that code, including some vanilla Emacs
distribution code, does not play well with non-nil `pop-up-frames'. Developers
who use nil `pop-up-frames' seem too often not to test their code also with the
value non-nil. (And they especially seem not to test it using a standalone
minibuffer frame.)

To be able to use non-nil `pop-up-frames', users really have to jump through
quite a few hoops, and few actually bother. One-On-One Emacs helps make life
with non-nil `pop-up-frames' easier, but you can still run into other code that
can't handle it.

Frankly, I'm always surprised that, 20-30 years after the introduction of
graphic displays and window managers, most people still use Emacs windows, not
frames, for most buffers. That Emacs doesn't play very well with non-nil
`pop-up-frames' could explain that in part, but why people still use Emacs
windows so much is generally a mystery to me.

I've preferred frames over Emacs windows ever since frames became available, but
we're a tiny minority in that camp. And my impression is that each of us tames
the attendant problems slightly differently.

Wrt working with `nav': I know nothing about it, but perhaps there is an easy
way (e.g., using a mode hook or `same-window-*'), to use nil `pop-up-frames' for
`nav' buffers only. That should be doable, I would think.

BTW, googling a bit for `emacs nav' gives me the impression that `nav' is used
in particular with a terminal, not necessarily with a window manager. In that
case (i.e., if you are not using a window manager), is there much value in
having non-nil `pop-up-frames'? Dunno.

Re: bind a hotkey to toggle variable

[Peter Dyballa]

Am 13.07.2009 um 08:50 schrieb Drew Adams:

> Frankly, I'm always surprised that, 20-30 years after the  
> introduction of
> graphic displays and window managers, most people still use Emacs  
> windows, not
> frames, for most buffers. That Emacs doesn't play very well with  
> non-nil
> `pop-up-frames' could explain that in part, but why people still  
> use Emacs
> windows so much is generally a mystery to me.


For me it's easier to find the GNU Emacs running on host (or server)  
A and then navigating through its buffers than to find buffer frame 1  
which could have log from host (or server) A or B or C or…

--
Greetings

   Pete

I love deadlines. I love the whooshing noise they make as they go by.
				– Douglas Adams

RE: bind a hotkey to toggle variable

[Drew Adams]

> > Frankly, I'm always surprised that, 20-30 years after the  
> > introduction of graphic displays and window managers, most
> > people still use Emacs windows, not frames, for most buffers.
> > That Emacs doesn't play very well with non-nil
> > `pop-up-frames' could explain that in part, but why people
> > still use Emacs windows so much is generally a mystery to me.
> 
> For me it's easier to find the GNU Emacs running on host (or server)  
> A and then navigating through its buffers than to find buffer 
> frame 1 which could have log from host (or server) A or B or C or.

Easier than what?

I have no idea what you're talking about. Perhaps you're referring to
terminal-mode frames? If so, that's a different subject - I was speaking of
using a graphic display (window mgr) with Emacs frames vs using it with Emacs
windows. I wasn't talking about the new multi-term thing for non-graphic use of
Emacs.

And there is no problem choosing among buffers, whether you use Emacs windows or
frames. FWIW, I rarely choose among frames (if that's what you meant to
contrast); I typically choose among buffers.

Whether a buffer that is chosen is displayed in a one-window frame or in a
window among several in a frame is irrelevant to choosing the buffer. I mention
this because I get the impression you are perhaps contrasting choosing a buffer
with choosing a frame (?). But I really don't know what you're trying to say.

Re: bind a hotkey to toggle variable

[Peter Dyballa]

Am 13.07.2009 um 10:47 schrieb Drew Adams:

> Easier than what?


It's easier to choose an Emacs running remotely on some host with  
dozens of buffers inside than choosing one frame out of N times  
dozens of them outside (possibly with colliding names).

My local computer is a hub. The number of spokes (frames, X clients)  
therefore is restricted.

--
Greetings

   Pete

Think of XML as Lisp for COBOL programmers.
				- Tony-A (some guy on /.)

RE: bind a hotkey to toggle variable

[Drew Adams]

> > Easier than what?
> 
> It's easier to choose an Emacs running remotely on some host with  
> dozens of buffers inside than choosing one frame out of N times  
> dozens of them outside (possibly with colliding names).

I see. As I said, nothing prevents one from choosing among buffers instead of
among frames. That's what I do. How a buffer is then displayed (one-window frame
or split window) is a separate question, logically, from how you choose it. (Of
course, you _can_ choose from a set of frames or windows instead of a set of
buffers, but you need not.)

> My local computer is a hub. The number of spokes (frames, X clients)  
> therefore is restricted.

I see. That's not so common. Anyway, my remarks were not in the context of such
a restriction. Most Emacs users, I suspect, have no special limitations on how
many frames they display, yet they often never use more than one or two.

Re: bind a hotkey to toggle variable

[tiefeng wu]

> I'm not familiar with `nav' mode, and I don't know which of my libraries you
> mean. But I'm not surprised that some other code (e.g. `nav') has some problems
> with non-nil `pop-up-frames'.

I'm using most of your enhancement libs like "dired+, grep+,
tool-bar+...", "icicles",
"one on one" and some others

> Unfortunately, it's all too common that code, including some vanilla Emacs
> distribution code, does not play well with non-nil `pop-up-frames'. Developers
> who use nil `pop-up-frames' seem too often not to test their code also with the
> value non-nil. (And they especially seem not to test it using a standalone
> minibuffer frame.)

To be honest, idea of standalone minibuffer frame get me confused and now I'm
not using it. But stuffs like autofit, thumbnail, move-frame-*, frame
enlarge/shrink, etc.
features are very handy.

> Frankly, I'm always surprised that, 20-30 years after the introduction of
> graphic displays and window managers, most people still use Emacs windows, not
> frames, for most buffers. That Emacs doesn't play very well with non-nil
> `pop-up-frames' could explain that in part, but why people still use Emacs
> windows so much is generally a mystery to me.

I use ntemacs under windows xp, maybe pop up frames more suitable for
people who work
under ms windows. Unix/Linux guys are more comfortablely work under
shell environment.
This is just my own opinion as a newbie to Unix/Linux world. (I force
myself to use ntemacs,
cygwin at work like Unix/Linux training.)

> Wrt working with `nav': I know nothing about it, but perhaps there is an easy
> way (e.g., using a mode hook or `same-window-*'), to use nil `pop-up-frames' for
> `nav' buffers only. That should be doable, I would think.

thanks! I'll try.

PS. I'm not a english-speaking person, and it's hard to me to write
things clearly, please ignore
parts that not understandable.

tiefeng wu
2009-07-13

Re: bind a hotkey to toggle variable

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Frankly, I'm always surprised that, 20-30 years after the introduction of
> graphic displays and window managers, most people still use Emacs windows, not
> frames, for most buffers.

Doesn't seem particular surprising -- Emacs windows are generally much
easier to manipulate and behave better than frames controlled by the
system's window manager, especially for short-lived windows (and this is
despite many well-known shortcomings in Emacs window manipulation, e.g.,
those which ECB tries to hack around).

If you look at many other modern apps, they do exactly the same thing,
though they may not use the term "window" for their internal windows
(maybe they call them "panels" or "widgets' or whatever) and may not
allow as much user manipulation as Emacs does.  Still, the division in
to large relatively static system-controlled windows (emacs frames) and
small more dynamic app-controlled windows within them seems like a
pretty well established practice.

-Miles

-- 
Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
man's head.

Re: bind a hotkey to toggle variable

[Peter Dyballa]

Am 13.07.2009 um 12:10 schrieb Miles Bader:

> If you look at many other modern apps, they do exactly the same thing,
> though they may not use the term "window" for their internal windows
> (maybe they call them "panels" or "widgets' or whatever)

Or "tabs" (in WWW browsers).

I'm really happy with this: short-lived frames to put on some other  
virtual desktop, to resize them, or whatever. And the real bundle,  
stack, heap of tabs I work with all time or at least longer than just  
a few minutes.

--
Greetings

   Pete

I love deadlines. I love the whooshing noise they make as they go by.
				– Douglas Adams

RE: bind a hotkey to toggle variable

[Drew Adams]

> > Frankly, I'm always surprised that, 20-30 years after the 
> > introduction of graphic displays and window managers, most
> > people still use Emacs windows, not frames, for most buffers.
> 
> Doesn't seem particular surprising -- Emacs windows are generally much
> easier to manipulate and behave better than frames controlled by the
> system's window manager, especially for short-lived windows 
> (and this is despite many well-known shortcomings in Emacs window 
> manipulation, e.g., those which ECB tries to hack around).

Chicken and egg. If you make the easiest way to get in and out of a car the back
window, then, sure, most users will get in and out using the back window.

So out of the box, yes, you're right; vanilla Emacs doesn't provide the same
degree of user control for frames as it provides for windows. That's part of
what I meant by Emacs dev being window-oriented. So users who want that must, on
their own, provide code and bind keys to manipulate frames easily (move/resize
in various ways, promote/demote, select, delete, whatever).

Otherwise, with such additions, no, there is no necessary advantage, IMO. A
short-lived frame is no more difficult to use than a short-lived window (unless
your window manager is slow). On the contrary; frames can provide more
options/flexibility for UI. A window either exists or it doesn't. A window can
exist and not be displayed, but users generally do not or cannot take much
advantage of that. Frames, on the other hand, can exist or not; they can be
visible or invisible or iconified (or thumbified, with thumb-frm.el).

> If you look at many other modern apps, they do exactly the same thing,

No, please, stop with the "modern" stuff. Apps with windows inside windows have
been around since the dark ages. Some apps fit well with that approach; others
fit less well with it. That's all. It has nothing to do with "modern". We're not
selling soap here.

> though they may not use the term "window" for their internal windows
> (maybe they call them "panels" or "widgets' or whatever) and may not
> allow as much user manipulation as Emacs does.  Still, the division in
> to large relatively static system-controlled windows (emacs 
> frames) and small more dynamic app-controlled windows within them
> seems like a pretty well established practice.

Sure it is. But no more well-established than not putting everything in the same
window-mgr window.

The point is that in Emacs you can have it all, and use whatever you like most
for a particular context. Nothing prevents you from using multiple windows in a
frame, even if you have non-nil `pop-up-frames'. Nothing prevents you from using
various features together: tabs, multiple windows, multiple frames.

But the other side of the point is that most users don't - most just use the
default behavior, which privileges windows considerably. Tabs in Emacs are still
a poor cousin, and frames are not far behind that status. And that systemic
privileging of windows in Emacs has nothing to do with fit for a particular app
or being "modern".

Those arguments are beside the point, even if we were to accord them. The reason
that Emacs privileges windows is, well, simply that Emacs privileges windows.
And the reason that Emacs users privilege windows is, well, that Emacs makes
windows the easiest way to go.

And yes, it does still surprise me a bit, after all this time.

Note: Frames and tabs are things that Emacs already has - the basis is (has
been, for a long time) there for making them useful. These are not like other
things in the wide world that are still weak or nonexistent in Emacs - "modern"
rendering, graphics, widgetry, and such.

Anyway, this is not the best place for such a discussion. That's all I have to
say about it here. We can discuss it more in emacs-devel, if you like.

Re: bind a hotkey to toggle variable

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> > Frankly, I'm always surprised that, 20-30 years after the 
>> > introduction of graphic displays and window managers, most
>> > people still use Emacs windows, not frames, for most buffers.
>> 
>> Doesn't seem particular surprising -- Emacs windows are generally much
>> easier to manipulate and behave better than frames controlled by the
>> system's window manager, especially for short-lived windows 
>
> So out of the box, yes, you're right; vanilla Emacs doesn't provide
> the same degree of user control for frames as it provides for
> windows. That's part of what I meant by Emacs dev being
> window-oriented. So users who want that must, on their own, provide
> code and bind keys to manipulate frames easily (move/resize in various
> ways, promote/demote, select, delete, whatever).

Emacs simply doesn't _have_ as much control over them.  There are many
complicating factors that arise when using WM windows that don't when
using "internal" windows (which Emacs obviously has full control over).

For instance:

  * WM window abstractions and details can differ vastly between
    platforms, limiting the number of assumptions Emacs can make, and
    the amount of control it has over position/size/etc.  Even on a
    _single_ platform you can never really be sure, e.g., when using
    different WMs in X (typical overlapping WM, vs. tiling WM, etc).

  * WMs typically let the user do what he wants outside of Emacs (and in
    the case of tiling WMs, the WM itself may make other changes),
    meaning that while Emacs can notice layout changes, it doesn't have
    much control over them.  Together with overlapping windows, this
    means that it's hard to maintain layout constraints.

  * The presence of extraneous things like title bars, frames, etc, make
    it harder to do layout.

I emphasize layout issues because that's actually one thing that makes
Emacs internal windows nice -- the simpler, more controlled and
dependable, tiled layout means that it's easier to automatically do
something reasonable when the window configuration changes often.

There have been attempts to provide an "emacsy" experience using only WM
windows; Hemlock (and its predecessors), is the example that comes to
come to mind (they tried very hard to make it work, e.g. "C-x 2" would
shrink the current WM window, and create a new window in the space).
My recollection is that while there was an initial "oh cool" factor, it
always felt a bit more flaky than Emacs internal windows do.

-Miles

-- 
Alone, adj. In bad company.