In XMonad, when I start Emacs23, the minibuffer is very big:

To correct it to use just one line, you must split the window vertically with another window:

Then, when you make Emacs full screen again, the minibuffer will use only one line.
In XMonad, when I start Emacs23, the minibuffer is very big:

To correct it to use just one line, you must split the window vertically with another window:

Then, when you make Emacs full screen again, the minibuffer will use only one line.
when is a very nice perl program to keep track of appointments. I wanted to use more than one file as the input of when, so I made this make script:
#!/usr/bin/make -f
calendar = $(HOME)/.when/calendar
.PHONY: all
all: $(calendar)
when --nopaging
$(calendar): $(wildcard $(HOME)/.when/calendars/*.when)
cat $^ > $@
This is a simple way to make a code be executed from time to time, using alarm().
#include
#include
#include
static void
run(int signal)
{
printf("signal = %i\n", signal);
alarm(1);
}
int main(int argc, char **argv)
{
struct sigaction act;
act.sa_handler = run;
if(sigaction(SIGALRM, &act, NULL))
{
fprintf(stderr, "Error adding handler for SIGALRM.\n");
return 1;
}
alarm(1);
while(1);
return 0;
}
They don’t really create the directory. They just turn on and off listening to them.
When a signal is emitted a lot of times, and the processing of the action associated with the signal is expensive, it’s an option to only run the action when the system is idle. Using this function in this manner, this result can be achieved. I got to know this talking to pierlux in #champlain@irc.freenode.net and taking a look at champlain-marker.c from libchamplain. Thanks.
static gboolean scheduled;
static gboolean
run(gpointer user_data)
{
/* expensive code */
scheduled = FALSE;
return FALSE;
}
static void
on_event(GObject * object, gpointer user_data)
{
if(!scheduled)
{
scheduled = TRUE;
g_idle_add(run, (gpointer) parameter_name);
}
}
int main(int argc, char **argv)
{
/* initialization */
g_signal_connect(object, "event", G_CALLBACK(on_event), NULL);
/* enter main loop */
}
After building from git, the following command is necessary to avoid lock problems in local mail boxes, when evolution-data-server was built with –prefix=$dir and installed as a user.
# chown root:mail $dir/libexec/camel-lock-helper-1.2 # chmod ug+s $dir/libexec/camel-lock-helper-1.2
To add an accelerator to a GtkImageMenuItem, you must:
I’ve always seen the forall a types in some GHC messages or in other person’s code, but I couldn’t get the point of it until I needed to use it myself. I was writing a Gtk2hs application with some windows, and I noticed that for each created window, I was doing the same steps. So I created a function that does what is needed for each function:
basic :: WidgetClass widget => String -> IO (Widget, (GObject -> Widget) -> String -> IO widget)
basic gladeFile =
do
(windowGlade :: GladeXML) <- getGlade gladeFile
let
windowGet :: Get
windowGet = xmlGetWidget windowGlade
(window :: Widget) <- windowGet castToWidget "window"
(close :: Button) <- windowGet castToButton "close"
onClicked close $ widgetDestroy window
modifyIORef windows (window :)
return (window, windowGet)
Notice that this code uses GHC extension PatternSignatures, which I like a lot.
The problem was that the returned function, windowGet was not generalized enough, so I couldn’t use it with more than one type, even it being very general:
windowGet :: WidgetClass widget => (GObject -> widget) -> String -> IO widget
If I used it with, say, windowGet castToButton "ok" and WindowGet castToSpinButton "value", it would give, in the seconde line, the type error: Couldn’t match expected type `Button’ against inferred type `SpinButton’.
After asking in #haskell, and reading a little bit of the GHC User’s Guide, I got the point. This was only possible with Rank 2 Types. windowGet must be:
windowGet :: forall widget. WidgetClass widget => (GObject -> widget) -> String -> IO widget
So I changed the type signature for basic, and added Rank2Types to the LANGUAGE pragma, and it worked fine.
basic :: String -> IO (Widget, forall widget. WidgetClass widget => (GObject -> Widget) -> String -> IO widget)
In a message dialog, when I click in the … of the Image field, I get a tree of Objects. I don’t understand hat this means, and I don’t know where to get documentation from it. This is Glade 3.4.5-3 in Debian lenny.