I'm trying changing wallpaper using clx, but it do not work. What is wrong with my code?
(ql:quickload :clx)
(defpackage #:wm/uw
(:use #:cl #:xlib))
(in-package #:wm/uw)
(setf *display* (open-default-display))
(setf *screen* (display-default-screen *display*))
(setf *root* (screen-root *screen*))
(setf (window-background *root*) (screen-white-pixel *screen*))
(clear-area *root*)
(close-display *display*)
To improve network performance, many X11 client libraries do not directly execute X11 commands. Instead, the commands are stored and sent in batches to the XServer. Usually, this happens automatically before event handling. Since you are doing no event handling, it seems that the command queue is never flushed. If you execute
(xlib::buffer-flush *display*)
before closing the display, you should see the desired effect. CLX does not export the buffer-flush function, hence you need to explicitly state the package name.
Related
When I start emacs without an x-server running, some of the things in my init.el fail, eg:
(require 'sr-speedbar)
is inappropriate without a graphical server, where I should rather start
(require 'speedbar)
What do emacs experts recommend as an appropriate init.el configuration in instances where emacs can be called as often from no-x modes as x-based modes? Is there an established way to provide a general, parallel experience under either regime or graceful fallback?
A lot depends on what environments you typically run in and what level of
control you need. For example, if you are just wanting to distinguish between
running under a full graphics capable environment, you can use display-graphic-p
e.g.
(when (display-graphic-p)
;; do stuff which needs a graphic display)
However, if you need to distinguish between different platforms, such as when
running under OSX, you would need something like
(when (eq system-type 'darwin)
;; do stuff which should only run when on OSX'))
Finally, for situations where you need to only configure something when running
under a specific window system, you can use something like
(when (eq window-system 'x)
;; only under X window frame))
However, there are some subtleties to be aware of. Some of these variables, such
as window-system are a test of the current frame. So, you need to think about
when the code is executed. For example, if you run emacs as a daemon, what would
be the value of window-system at the time your init is loaded? Likewise, if you
use emacs as a daemon or use emacsclient to open a new 'frame' it may be opened
a either a graphic or a text frame. Sometimes, you may need to create a new
command which wraps around what you want to do and does the test at the point
you execute the command so that it can respond to the specific frame you are in
when you execute the command.
When serving large files from Clack/Hunchentoot with Slime connected, I sometimes see error messages like SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s"... Those are caused by the browser prematurely dropping connections (which is totally OK). The problem is that each time it happens, SLDB pops up. Which is annoying.
Is there a way I can inhibit certain errors in SLDB such as the above? I still would like to see them in an error log, but definitely not in SLDB.
You can subclass PROCESS-CONNECTION for your acceptor and do your own error handling for this error.
Let's start by defining a custom acceptor:
(defclass no-error-acceptor (hunchentoot:acceptor)
())
Then we can create a wrapper around PROCESS-CONNECTION that inhibits printing of a message for this specific error:
(defmethod hunchentoot:process-connection ((acceptor no-error-acceptor) (socket t))
(handler-case
(call-next-method)
(sb-impl::simple-stream-perror (condition)
;; Perhaps log the error here?
nil)))
Make sure you actually start the server using this acceptor in order for it to be used.
UPDATED
Since your system uses Hunchentoot, you could set the global variable HUNCHENTOOT:*CATCH-ERRORS-P* to T. This should guarantee that the all the conditions arising in code managed by Hunchentoot are catched by Hanchentoot itself and not passed to the debugger.
To disable the debugger in any Common Lisp implementation (both inside a shell REPL as well as the Slime REPL inside Emacs) you could use the predefined global variable *debugger-hook*, by assigning to it a two argument function. The function will receive the condition and the current value of *debugger-hook* when it is called, and can handle the condition or return normally, and in this case the debugger is invoked. For instance, you could simply print the condition:
* (defun my-debug(condition hook)
(declare (ignore hook))
(print condition)
(abort))
DEBUG-IGNORE
* (setf *debugger-hook* #'my-debug)
#<FUNCTION MY-DEBUG>
This second method however cannot work when using Hunchentoot together with Slime, due to the way the two packages interact with respect to the debugging strategies.
In this case one could adopt the solution found by Mike Ivanov, that redefines the swank-debugger-hook function before starting Swank:
(in-package swank)
(setq swank-debugger-hook-orig #'swank-debugger-hook)
(defun swank-debugger-hook (condition hook)
(etypecase condition
(sb-int:simple-stream-error
(progn
(princ "*** Stream error" *error-output*)
(abort)))
(t (funcall swank-debugger-hook-orig condition hook))))
(in-package cl-user)
(swank:create-server :port 4008 :dont-close t)
I am trying to program GNU Emacs 23 to issue require commands lazily, on demand, instead of up front in my .emacs file. If I wanted to delay the execution of a load command, I could use autoload. But require and load take different sorts of arguments.
Is there a predefined function that does for require the same job that autoload does for load? And if not, what tools would people recommend that I use to roll my own?
There is not difference between require and load with regards to autoload. require is just a frontend to load, which more or less comes down to:
(defun require (feature &optional filename noerror)
(unless (featurep feature)
(let ((filename (or filename (symbol-name feature))))
(load filename noerror))))
As you can see, the symbol name given to require is equal to the filename given to load. As a matter of fact, the first (require 'foo) evaluated in an Emacs session is equivalent to (load "foo").
Thus, you can just use (auto-load 'foo-function "foo") for foo-function from the library foo, that you can load with (require 'foo).
One more answer to help clarify (this was a little verbose for a comment):
autoload says "if this function isn't already defined, then load this file (if and when the function is called)."
require says "if this library isn't already loaded, then load this file (immediately)."
Note in particular that you don't need to use require to load a library; that's simply the way you ensure that you don't load it again (assuming you don't want to do that). The (provide 'FEATURE) expression in the library will be evaluated no matter how the library was loaded, which lets any future require know that it doesn't need to do anything.
It's a similar situation for autoload -- if the file has already been loaded (and therefore the function in question properly defined), then the autoload no longer has any effect.
What kind of "demand" do you have in mind for your "on demand"?
If a given command or other function needs (or soft-needs) a given library, then that function itself can use (require 'foo) or (require 'foo nil t). The library will be loaded on demand from that function.
Consider also whether you might need to load the file more than once, i.e., reload it in some situations, whether or not it has already been loaded.
For #2, for instance, my code that uses a library of Lisp macros, icicles-mac.el does not just use require, because I want to make sure that if a user gets a new version of that library (e.g., downloads a new source version and byte-compiles it) then that new version is used whenever s?he byte-compiles another library that needs it. (This is important -- when a library of macros changes, other libraries that use those macros generally need to be recompiled after loading the new macros file.) For that, instead of just (require 'icicles-mac) I use this:
(eval-when-compile
(or (condition-case nil
(load-library "icicles-mac") ; Use load-library to ensure latest .elc.
(error nil))
(require 'icicles-mac))) ; Require, so can load separately if not on `load-path'.
I use term-mode to run Bash shells within Emacs. On remote hosts, term-mode's directory tracking feature helpfully sets default-directory to have the host name in it, so that tab completion and file access is done remotely via Tramp. Sometimes, however, I use remote hosts that mostly share the same filesystems as my workstation, as they load the same directories from NFS. In these cases, Tramp slows me down too much. I would like, when using these systems, for Emacs to set the default-directory locally. To do this I have copied term-handle-ansi-terminal-messages from the system term.el to a new file loaded by my .emacs. I replace this part:
((= command-code ?h)
(setq term-ansi-at-host argument))
with this:
((= command-code ?h)
(setq term-ansi-at-host-real argument)
(setq term-ansi-at-host
;; if it has an equivalent filesystem group, set to system-name
(if (term-equivalent-filesystem-host-group-p argument)
(system-name)
argument)))
This calls a term-equivalent-filesystem-host-group-p function that tells whether a host should be treated as having an equivalent filesystem.
This method has the desired effect but copying and modifying system Lisp code isn't robust to any future changes in the code. I don't think advising the function would be possible without duplicating half its functionality (either the message loop or the setting of default-directory and ange-ftp-… variables).
Is there a better way to do this?
I think you can get darn close with advice. I'd define advice as follows:
(defadvice term-handle-ansi-terminal-messages
(before rewrite-remote-paths-to-local (message) activate)
(when (and (string-match ".*\eAnSiTh.\\([^\r\n]+\\)\r?\n" message)
(term-equivalent-filesystem-host-group-p (match-string 1 message)))
(setq term-ansi-at-host-real (match-string 1 message))
(setq message (replace-match (system-name) t t message 1))))
All this does is look for a substring of the input to term-handle-ansi-terminal-messages that's going to fall into the case in question, and proactively rewrite the path. Now there's no need to fiddle with the internals of term-handle-ansi-terminal-messages, since it'll never see the remote path.
Is this different than modifying the function? I'd say yes, but this is open to interpretation. In particular, I think that the only knowledge the above code depends on is the format of the submessage term-long-function-name-you-already-know is going to look for, which is really an attribute of the terminal protocol, not the internals of term-now-i'm-just-being-silly. There are some potential problems, such as new code that changes behavior based on the 7th character in the match. (This is the lone . in the string-match above.)
Needless to say, I didn't test this code at all.
So at work, I've got to work from two different repositories. The files map to essentially the same place, but one path has 'data' in it.
It's relatively trivial to write a defun that determines if the file is in the data directory or not, and so which repository I actually want to check out from. But I can't figure out a way to call my function before any p4 commands without explicitly rebinding the keys to do it, and even that is sort of a big hack. I'd really just like it to run every time I try to check out or revert a file and set the p4port as I want it to.
All the hooks in the p4 system seem to be called when I don't want them to be. I tried calling my defun on the p4-mode-hook, but that hook only runs when the mode is set, and files that aren't in the repository are rejected before I ever get my defun to do anything. :/
There are a couple of approaches that you could use. First, you could consider adding the desired functions to pre-command-hook, with a predicate to check whether the current buffer is operating in p4-mode, i.e.:
(add-hook
'pre-command-hook
(lambda ()
(when (eq major-mode 'p4-mode)
;;; specify whatever functions you desire
)))
This will indiscriminately execute the functions that you include in the body of the above lambda before any command in a p4-mode buffer. If that's overkill and you need to be more selective about when to execute said functions, you should probably individually advise each of the p4 commands that should first execute your functions before running, e.g.:
(defadvice
name-of-p4-function
(before name-of-p4-function-advice activate)
;;; functions to be executed
)
(ad-activate 'name-of-p4-function)
See the Advising functions section of the Emacs manual for additional details.