<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.emacs.help">
    <title>gmane.emacs.help</title>
    <link>http://blog.gmane.org/gmane.emacs.help</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90915"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90914"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90913"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90912"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90911"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90910"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90909"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90908"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90907"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90906"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90905"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90904"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90903"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90902"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90901"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90900"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90899"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90898"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90897"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90896"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90915">
    <title>Re: How to get hook var of the current major mode?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90915</link>
    <description>&lt;pre&gt;This is what I want.  In fact, I have defined a function which turns on 
yasnippet minor mode, auto complete mode, etc, and a macro which can run 
some code for all buffers in the same mode as the current. I want to 
turn on some modes only when editing source code, not when viewing, and 
not for buffers other than source code, which is not too usefull for 
chinese.
Thank you.


&lt;/pre&gt;</description>
    <dc:creator>Jun</dc:creator>
    <dc:date>2013-05-19T09:52:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90914">
    <title>Re: problems with X11 forwarding inside frame</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90914</link>
    <description>&lt;pre&gt;wgreenhouse&amp;lt; at &amp;gt;riseup.net (W. Greenhouse)
writes:



I think you're right.  Unfortunately , with "ssh -X host emacsclient
-c", you have to have a terminal open for each remote emacsclient.  I
was thinking/hoping it would be possible to do something like this.  In
stumpwm, you can do C-t !, to bring up a little dialog box to run
commands.  So, running C-t ! ssh -f remote-host emacsclient -nc results
in one windows opening, the remote emacsclient frame.  Anyway, I think I'll
stop obsessing now and just accept that it doesn't seem to work.

Thanks for all your input,

Joseph



&lt;/pre&gt;</description>
    <dc:creator>Joseph Mingrone</dc:creator>
    <dc:date>2013-05-19T01:46:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90913">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90913</link>
    <description>&lt;pre&gt;
Barry Margolin writes:


indeed, this also works, very nice!

Thanks, Barry.

Cheers,

Marius



&lt;/pre&gt;</description>
    <dc:creator>Marius Hofert</dc:creator>
    <dc:date>2013-05-18T21:19:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90912">
    <title>Re: How to get hook var of the current major mode?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90912</link>
    <description>&lt;pre&gt;

Actually, sorry, I take that back. Even in lexical-binding environment,
(lambda () (abc)) is `equal' to another (lambda () (abc)), at least
currently. And `add-hook' checks if the given function is already
present in the list, with `member'. So there won't be duplicates in the
hook value.

Still, like I wrote previously, adding function to the hook of the
current major mode doesn't make much sense.


&lt;/pre&gt;</description>
    <dc:creator>Dmitry Gutov</dc:creator>
    <dc:date>2013-05-18T20:38:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90911">
    <title>Re: How to get hook var of the current major mode?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90911</link>
    <description>&lt;pre&gt;

When the hook fires, are all those lambda executed (doing the same
thing)?

&lt;/pre&gt;</description>
    <dc:creator>Emanuel Berg</dc:creator>
    <dc:date>2013-05-18T19:45:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90910">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90910</link>
    <description>&lt;pre&gt;


This was the original question. Should M be escaped in a string here?
Did you try the vector description of "M-q"? I notice that (kbd &amp;lt;key&amp;gt;...
returns a specific vector but the vector [(meta q)] just evaluates to
itself. Have you tried:

(define-key (current-local-map) [(meta q)] nil)

??




&lt;/pre&gt;</description>
    <dc:creator>B. T. Raven</dc:creator>
    <dc:date>2013-05-18T17:44:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90909">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90909</link>
    <description>&lt;pre&gt;In article &amp;lt;mailman.41.1368897044.22516.help-gnu-emacs&amp;lt; at &amp;gt;gnu.org&amp;gt;,
 Andreas RÃ¶hler &amp;lt;andreas.roehler&amp;lt; at &amp;gt;easy-emacs.de&amp;gt; wrote:


This is essentially the same as using M-!, isn't it, except that it 
automatically fills in the filename argument? If you don't use the 
ampersand, Emacs waits for the command to finish, and then displays the 
output in *Shell Command Output*. If you use ampersand, it doesn't wait, 
and displays the output incrementally in *Async Shell Command*.

Either way, the output has to be put somewhere.

However, the synchronous mode has a feature: if the command produces 
little or no output, it doesn't switch to the *Shell Command Output* 
buffer, it just displays it in the minibuffer.  Here's a trick that I 
think should do what you want: Run the backgrounded command in a 
subshell (wrap it in parentheses):

! (command ? &amp;amp;&amp;gt;/dev/null &amp;amp;)

As far as Emacs is concerned, that's a synchronous command, because it 
doesn't end in "&amp;amp;". But it runs in the background within the subshell. 
Redirect the output so that Emacs immediately reads EOF, and has nothing 
to display in the minibuffer (it may display "(Shell command completed 
with no output)").

&lt;/pre&gt;</description>
    <dc:creator>Barry Margolin</dc:creator>
    <dc:date>2013-05-18T17:48:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90908">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90908</link>
    <description>&lt;pre&gt;Am 18.05.2013 20:03, schrieb Marius Hofert:
[ ... ]

In case you didn't find a solution already, setting

file-name-handler-alist

might open a way to solve it. I.e. it's about to pass a process-buffer name differently from the hard-coded one you don't want to see.

Andreas


&lt;/pre&gt;</description>
    <dc:creator>Andreas Röhler</dc:creator>
    <dc:date>2013-05-18T18:58:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90907">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90907</link>
    <description>&lt;pre&gt;
Hongxu Chen writes:


This is indeed interesting, thanks a lot. Both approaches use
'start-process' (which seems good). The approach by Lee seems to be
fine. It calls xdg-open.

I tried with "!" -&amp;gt; "xdg-open ?" and it opens foo.pdf externally (in a
persistent way), but emacs is blocked. However, when I use 'xdg-open ?
&amp;amp;' then *Messages* says "xdg-open rank.pdf: finished." but nothing is
opened. ... Do you know why?  Was just wondering...


Indeed, many thanks!

Cheers,

Marius



&lt;/pre&gt;</description>
    <dc:creator>Marius Hofert</dc:creator>
    <dc:date>2013-05-18T18:52:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90906">
    <title>Re: setenv and find-file</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90906</link>
    <description>&lt;pre&gt;
Am 18.05.2013 um 13:36 schrieb Barry Margolin:


And when a shell in *shell* buffer is started afterwards it can inherit that setting… Yes, that could be another away! (Given that either a corresponding GNU Emacs variable is also defined or (getenv "VARIABLE") is used.)

--
Greetings

  Pete                           &amp;lt;]
             o        __o         |__    o       HPV, the real
    ___o    /I       -\&amp;lt;,         |o \  -\),-%     high speed!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________



&lt;/pre&gt;</description>
    <dc:creator>Peter Dyballa</dc:creator>
    <dc:date>2013-05-18T18:09:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90905">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90905</link>
    <description>&lt;pre&gt;
Andreas Röhler writes:


Yes, this runs the command *asynchronously* (that's where the name of
the annoying buffer comes from).

If not run asynchronously (i.e., if run without ampersand), emacs is
blocked. Also, closing emacs closes the external application, too. Both
behaviors I find strange / are undesirable.


When run asynchronously, closing emacs does *not* close the external
application. I like this behavior very much.


Then no buffer is open (which was clear since the command is not run
asynchronously). The question is how to avoid the buffer being opened
*when* using the command asynchronously.

I currently do some testing with the suggestions of Hongxu. I reply later.

Cheers,

Marius




&lt;/pre&gt;</description>
    <dc:creator>Marius Hofert</dc:creator>
    <dc:date>2013-05-18T18:03:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90904">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90904</link>
    <description>&lt;pre&gt;Am 18.05.2013 16:37, schrieb Marius Hofert:

Okay, see dired-do-shell-command reads it


Nothing. It's the ampersand following ? which matters.


Which seems the buffer Emacs connects the process to.
Deleting it should end the processes, probably not a good idea.

So the ampersand seems the culprit - not the question mark.
What happens when calling your stuff without it?

Andreas




&lt;/pre&gt;</description>
    <dc:creator>Andreas Röhler</dc:creator>
    <dc:date>2013-05-18T17:13:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90903">
    <title>Re: formatting C++ code which includes SWIG macros</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90903</link>
    <description>&lt;pre&gt;Hi, Doug.

Douglas Meyer &amp;lt;dbmeyer030&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


I think the problem is that it's _not_ C++, rather it's an idiosyncratic
extension, which (ab)uses the modulus operator to introduce a new type of
macro.



Presumably, there's some sort of preprocessor which converts these SWIG
files to standard C++ before they get to the compiler



Let me guess a few things about SWIG:
1. All SWIG keywords start with a %.
2. There are several such keywords rather than many.
3. A SWIG construct is always on a line of its own.
4. A SWIG construct is never continued onto a new line by \ (or anything
  else).
5. Standard C++ lines are syntactically independent of SWIG lines.


To do this properly would involve extending C++ Mode and this would be an
enormous amount of work.  A more realistic approach might be to treat all
SWIG lines as being terminated by a "virtual semicolon" thus preventing
lines like "class MyClass" as being parsed as the continuation of a SWIG
line.

I could probably manage to do this for you, but first, could you confirm
(or correct) my 5 guesses above, and supply a list of SWIG keywords.


No problem!


[ .... ]

&lt;/pre&gt;</description>
    <dc:creator>Alan Mackenzie</dc:creator>
    <dc:date>2013-05-18T16:26:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90902">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90902</link>
    <description>&lt;pre&gt;

I wrote a couple of lines you can experiment with. Use `C-h w' for the
functions and `C-x C-e' to change keybinding.

The local binding will shadow the global. If the global is shadowed,
it won't report any key on `C-h w'. But, as soon as you unset the
local, or set it to the nils, the global is back on. When the local is
set to the empty string, the shadow is on (i.e., the global is off)
only this "shadow" doesn't do anything.

Like I said, play around with it.

(defun test-message-local  () (interactive) (message "local check"))
(defun test-message-global () (interactive) (message "global check"))
(global-unset-key (kbd "C-M-w")) ; either unset both
(local-unset-key  (kbd "C-M-w"))
(global-set-key   (kbd "C-M-w") 'test-message-global) ; test C-h w here
(local-set-key    (kbd "C-M-w") 'test-message-local)  ; shadows global
(local-set-key    (kbd "C-M-w")  nil) ; these four - global *on*
(local-set-key    (kbd "C-M-w") 'nil)
(local-set-key    (kbd "C-M-w")  ())
(local-set-key    (kbd "C-M-w") '())
(local-set-key    (kbd "C-M-w") "")   ; this - local "nothing" shadow

&lt;/pre&gt;</description>
    <dc:creator>Emanuel Berg</dc:creator>
    <dc:date>2013-05-18T10:26:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90901">
    <title>EIEIO defmethod broken if symbol already bound?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90901</link>
    <description>&lt;pre&gt;Hi folks

I think this might be an Emacs bug, but I'm not familiar enough with EIEIO
to be certain. Suppose I want to assign a method foo to a class some-class:

(require 'eieio)

(defclass some-class ()
  ((bar :initform 42)))

(defmethod foo ((s some-class))
  1)

This works fine. However, if the function definition of foo is already
bound to t, it doesn't work:

(require 'eieio)

(defclass some-class ()
  ((bar :initform 42)))

(defalias 'foo 't)

(defmethod foo ((s some-class))
  1) ;; Debugger entered--Lisp error: (void-function foo)

I'm forced to set foo to a function (e.g. (defalias 'foo 'method)) before I
can use (defmethod foo ...). In fact, calling M-x describe-function &amp;lt;RET&amp;gt;
foo &amp;lt;RET&amp;gt; says 'file a bug report'.

Now, I know that (defalias 'foo 't) is silly thing to do. However, I
accidentally ended up in this state when hacking on some code.

Is this a legitimate bug? Emacs 24.2.1.

Thanks :)

&lt;/pre&gt;</description>
    <dc:creator>Wilfred Hughes</dc:creator>
    <dc:date>2013-05-18T15:10:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90900">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90900</link>
    <description>&lt;pre&gt;Hi Andreas,

Thanks a lot for helping.

The purpose is simply for opening them (asynchronously), viewing the pdf
(continuing to work in Emacs), (maybe add annotations to the pdf and save
it).

I use 'dired-mode' as 'file manager' and often would like to open and view
pdfs in Okular. I also have other 'dired-guess-shell-alist-user' settings
like opening pngs in eog or mp3s in VLC. But everytime I open a file, I get
this annoying *Async Shell Command* buffer (either empty or with debug
output) and I have to manually close it via C-x 0 etc. to get rid of it. I
know that it might contain useful information sometimes and I wouldn't be
against it appearing hidden (in the buffer list). But being distracted by
this buffer in dired-mode is really unpleasant. If I only knew more emacs
lisp...

Cheers,

Marius

&lt;/pre&gt;</description>
    <dc:creator>Marius Hofert</dc:creator>
    <dc:date>2013-05-18T10:05:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90899">
    <title>Re: setenv and find-file</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90899</link>
    <description>&lt;pre&gt;In article &amp;lt;mailman.27.1368871635.22516.help-gnu-emacs&amp;lt; at &amp;gt;gnu.org&amp;gt;,
 Peter Dyballa &amp;lt;Peter_Dyballa&amp;lt; at &amp;gt;Web.DE&amp;gt; wrote:


But if you do:

M-: (setenv "VARIABLE" "/shorter/path")

inside Emacs, you're setting an environment variable in the Emacs 
process, not just within a program that's hosted by Emacs.

&lt;/pre&gt;</description>
    <dc:creator>Barry Margolin</dc:creator>
    <dc:date>2013-05-18T11:36:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90898">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90898</link>
    <description>&lt;pre&gt;

How about either

(global-unset-key [(meta q)]

or

(local-unset-key [(meta q)]

??


&lt;/pre&gt;</description>
    <dc:creator>B. T. Raven</dc:creator>
    <dc:date>2013-05-18T04:43:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90897">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90897</link>
    <description>&lt;pre&gt;
There is a tool called `openwith' that might meet your needs; you might
see this page for details:
http://www.emacswiki.org/emacs/OpenWith
It is available in elpa but I recommend that you customize the external
apps yourself.

Also Lee Xah has written a snippet for this issue, and you can just map
some key.
http://ergoemacs.org/emacs/emacs_dired_open_file_in_ext_apps.html

Hope these would be helpful.

Marius Hofert &amp;lt;marius.hofert&amp;lt; at &amp;gt;math.ethz.ch&amp;gt; writes:


&lt;/pre&gt;</description>
    <dc:creator>Hongxu Chen</dc:creator>
    <dc:date>2013-05-18T14:39:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90896">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90896</link>
    <description>&lt;pre&gt;Hi Andreas,

what do you mean by 'caused'?

The question mark is a place holder for the file (foo.pdf).
What does this have to do with *Async Shell Command* being opened?

Note: The behavior of "!" on foo.pdf in dired mode is fine (in the sense
that Okular opens, the pdf is shown, everything asynchronously), I just want
to avoid the buffer *Async Shell Command* being opened.

Let me know if anything isn't clear.

Cheers,

Marius



Andreas Röhler writes:




&lt;/pre&gt;</description>
    <dc:creator>Marius Hofert</dc:creator>
    <dc:date>2013-05-18T14:37:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90895">
    <title>Re: How to suppress/avoid *Async Shell Command* buffer?</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90895</link>
    <description>&lt;pre&gt;Am 18.05.2013 15:58, schrieb Marius Hofert:

Looks like caused by the question mark after okular

(("\\.\\(?:pdf\\|djvu\\|jp?g\\)\\'" "okular ? &amp;amp;")


&lt;/pre&gt;</description>
    <dc:creator>Andreas Röhler</dc:creator>
    <dc:date>2013-05-18T14:33:34</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.emacs.help">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.emacs.help</link>
  </textinput>
</rdf:RDF>
