<?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://permalink.gmane.org/gmane.emacs.help">
    <title>gmane.emacs.help</title>
    <link>http://permalink.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/90968"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90967"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90966"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90965"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90964"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90963"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90962"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90961"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90960"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90959"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90958"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90957"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90956"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90955"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90954"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90953"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90952"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90951"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90950"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.help/90949"/>
      </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/90968">
    <title>Re: Returning variable "references" under lexical binding</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90968</link>
    <description>&lt;pre&gt;
I said:



Emphasis added.  And later I elaborated on my example:


"later" was meant to indicate "later in time, after the function
returns."

Because it's not too long, here's the actual code that inspired my
question.  It manages a number of idle timers to implement a new kind of
timer that repeats at regular intervals as long as Emacs remains idle,
and as long as the callback it's given returns true:

--------------------
;; -*- lexical-binding: t; -*-

(defun run-periodically-when-idle (seconds func)
  (let (timer count)
    (labels ((on-first-idle ()
               (when timer
                 (cancel-timer timer))
               (setq count 1)
               (run-and-schedule-next))
             (run-and-schedule-next ()
               (setq timer
                 (and (funcall func count)
                      (run-with-idle-timer
                       (* seconds (incf count))
                       nil
                       #'run-and-schedule-next)))))
      (list (run-with-idle-timer seconds t #&lt;/pre&gt;</description>
    <dc:creator>Sean McAfee</dc:creator>
    <dc:date>2013-05-21T22:43:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90967">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90967</link>
    <description>&lt;pre&gt;


I've seen that in the docs but it doesn't seem to matter (with ver.
23.3). In my .emacs (together with a couple of dozen other similar
forms) I have:

(global-set-key [(meta super s)] 'search-forward-regexp)

This works and C-hf search-forward-regexp shows this:

"
search-forward-regexp is an interactive built-in function in
`subr.el'.

It is bound to M-s-s.

(search-forward-regexp REGEXP &amp;amp;optional BOUND NOERROR COUNT)
"

But maybe I've just been lucky not to have something masking the ?q
interpretation of q. Anyway it seems to work without specifying that q
is a char.


Ed

&lt;/pre&gt;</description>
    <dc:creator>B. T. Raven</dc:creator>
    <dc:date>2013-05-21T20:44:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90966">
    <title>Re: OS X System Key Combinations</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90966</link>
    <description>&lt;pre&gt;
Am 21.05.2013 um 23:59 schrieb tshanno&amp;lt; at &amp;gt;bearingthenews.com:


And this means: GNU Emacs is swallowing the key combination, it does not reach the operating system. You can either try to find a key combination that bypasses GNU Emacs or create functions that perform the service calls and bind them to the key combinations.

The NS variant performs the latter. Check out what M-m or M-h do!

The "Carbon AppKit" Emacs does not see M-h. C-h k M-h hides it at once and when you open it, you see the prompt in mini-buffer.

--
Greetings

  Pete

Experience is what you get when you don't get what you want.



&lt;/pre&gt;</description>
    <dc:creator>Peter Dyballa</dc:creator>
    <dc:date>2013-05-21T22:30:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90965">
    <title>Re: OS X System Key Combinations</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90965</link>
    <description>&lt;pre&gt;Hi, Pete.

The command key is the Emacs super key here.  The option key is the Emacs meta key.  The control key is, of course, Emacs control.

In the Emacs system preferences, for instance, I have a service which inserts a date stamp.  This service is bound to command-option-control-d.  The service is defined and available for all applications (not just Emacs).  It, along with all of the other combinations defined there, works fine with my other applications.   But Emacs reports:

&amp;lt;C-M-s-268632068&amp;gt; is undefined

Which, of course, it is in Emacs.

Thanks again for the response.

Tom

On May 22, 2013, at 7:41 AM, Peter Dyballa &amp;lt;Peter_Dyballa&amp;lt; at &amp;gt;Web.DE&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>tshanno&lt; at &gt;bearingthenews.com</dc:creator>
    <dc:date>2013-05-21T21:59:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90964">
    <title>Re: OS X System Key Combinations</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90964</link>
    <description>&lt;pre&gt;
Am 21.05.2013 um 23:18 schrieb tshanno&amp;lt; at &amp;gt;bearingthenews.com:


No, it looks like the NS variant from the unpatched GNU Emacs 24.3.50 sources. It will report on M-x emacs-version RET something like:

GNU Emacs 24.3.50 (i386-apple-darwin10.8.0, NS apple-appkit-1038.36) of 2013-05-20 on …
                                                    **

The "AppKit Emacs", with a history as Carbon Emacs, will report something like this:

GNU Emacs 23.4.1 (x86_64-apple-darwin10.8.0, Carbon Version 1.6.0 AppKit 1038.36) of 2012-09-11 on …
                                                     ******


It should. But both Emacsen change the meaning of the alt, cmd, and maybe more keys by default. With C-h k you can find out what alt-a and cmd-a are and you can also look via Emacs -&amp;gt; Services from the  menu bar at the services your Emacs sees. The modifier keys I mentioned have, presumingly, names like

ns-alternate-modifier
   This variable describes the behavior of the alternate or option
   key.
ns-command-modif&lt;/pre&gt;</description>
    <dc:creator>Peter Dyballa</dc:creator>
    <dc:date>2013-05-21T21:41:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90963">
    <title>Re: outline-flag-region: Variable binding depth exceedsmax-specpdl-size</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90963</link>
    <description>&lt;pre&gt;

[...snip...] 


Following up to my own post, help and source code of
'outline-flag-region' and 'max-specpdl-size' do give some hints:

,---------------------------------------------------------------------------
| max-specpdl-size is a variable defined in `C source code'.
| Its value is 1340
| Original value was 1300
|
|   This variable can be risky when used as a file-local variable.
|
| Documentation:
| Limit on number of Lisp variable bindings and `unwind-protect's.
| If Lisp code tries to increase the total number past this amount,
| an error is signaled.
| You can safely use a value considerably larger than the default value,
| if that proves inconveniently small.  However, if you increase it too far,
| Emacs could run out of memory trying to make the stack bigger.
|
| You can customize this variable.
`---------------------------------------------------------------------------

so it appears that in a call to 'outline-flag-region' more than 1340
Lisp variable bindings and `unwind-protect's are created&lt;/pre&gt;</description>
    <dc:creator>Thorsten Jolitz</dc:creator>
    <dc:date>2013-05-21T21:28:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90962">
    <title>Re: OS X System Key Combinations</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90962</link>
    <description>&lt;pre&gt;Hi Peter.

Well, I would agree that its an understanding type.  Most questions usually are.  :)

I'm using GNU Emacs version 24.3  It was obtained here:

http://emacsformacosx.com

As far as I know the X server on my system is not running.  At least not of the type I've used for almost 20 years under Linux.  It doesn't say it explicitly on the website but it certainly looks like it is, indeed, the "AppKit Emacs".

I take it from your response that this should, indeed, be passing the key combinations through to the system using this version of Emacs and that there is something wrong with my installation.  Is that correct?

Thanks for the response and for any further help.

Tom S.

On May 21, 2013, at 7:07 PM, Peter Dyballa &amp;lt;Peter_Dyballa&amp;lt; at &amp;gt;Web.DE&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>tshanno&lt; at &gt;bearingthenews.com</dc:creator>
    <dc:date>2013-05-21T21:18:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90961">
    <title>RE: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90961</link>
    <description>&lt;pre&gt;
You are confusing a lot of things.  I merely wanted to say that [(meta q)] should be [(meta ?q)]: ?q is the character; q is not.  Other people have mentioned other, orthogonal corrections.

Yes, (kbd "M-q") is perfectly clear.  No, there is no advantage in one's init file to using [(meta ?q)] instead.  No one suggested otherwise.&lt;/pre&gt;</description>
    <dc:creator>Drew Adams</dc:creator>
    <dc:date>2013-05-21T20:29:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90960">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90960</link>
    <description>&lt;pre&gt;Op dinsdag 21 mei 2013 18:44 CEST schreef Drew Adams:


Does not work either. I'll try with -Q as in the other post.
On the other hand I do not find
    (local-set-key (kbd "M-q") 'ignore)

less clear. I even think it is more clear. Or is there a reason to
prefer this solution above the ignore solution?

&lt;/pre&gt;</description>
    <dc:creator>Cecil Westerhof</dc:creator>
    <dc:date>2013-05-21T18:35:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90959">
    <title>Re: Returning variable "references" under lexical binding</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90959</link>
    <description>&lt;pre&gt;In article &amp;lt;87bo84b85k.fsf&amp;lt; at &amp;gt;gmail.com&amp;gt;, Sean McAfee &amp;lt;eefacm&amp;lt; at &amp;gt;gmail.com&amp;gt; 
wrote:


This is different, because now you have something with state that can 
change, and want to be able to inspect. it.


What "new values"? Your code didn't have any way to change the value of 
timer.  All it did was wrap it in a closure, but that closure doesn't do 
anything other than return the initial value. Did you leave something 
out of the original example?

&lt;/pre&gt;</description>
    <dc:creator>Barry Margolin</dc:creator>
    <dc:date>2013-05-21T18:06:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90958">
    <title>Re: global-auto-revert-mode and file time stamps</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90958</link>
    <description>&lt;pre&gt;
I don't want emacs to return the file to its previous state. 
global-auto-revert-mode doesn't do that, anyway. global-auto-revert-mode 
detects that a file has been changed on disc, and if I haven't made any 
edits to that file, it reverts the file _AUTOMATICALL_, without asking 
any questions. So that works as expected.

What doesn't work is, if only the timestamp of the file changes (touch 
filename), then emacs doesn't autorevert it, and instead tells me that 
it changed and asks whether I want to really edit it.

Hope this makes it clear...

&lt;/pre&gt;</description>
    <dc:creator>Timur Aydin</dc:creator>
    <dc:date>2013-05-21T17:54:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90957">
    <title>Re: global-auto-revert-mode and file time stamps</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90957</link>
    <description>&lt;pre&gt;
Am 21.05.2013 um 15:36 schrieb Timur Aydin:


GNU Emacs will never automatically return to a previous state of the file. That's left up to you. What it does is, that it warns you, that it gives you information to make better decisions.

This is OK with me.

--
Greetings

  Pete

Don't just do something, sit there.



&lt;/pre&gt;</description>
    <dc:creator>Peter Dyballa</dc:creator>
    <dc:date>2013-05-21T17:26:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90956">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90956</link>
    <description>&lt;pre&gt;

It's weird that both you and the third party are having the same
problem. If one of you tries the same experiments on an emacs -Q
invocation, does the problem disappear?

Ed



&lt;/pre&gt;</description>
    <dc:creator>B. T. Raven</dc:creator>
    <dc:date>2013-05-21T16:57:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90955">
    <title>outline-flag-region: Variable binding depth exceeds max-specpdl-size</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90955</link>
    <description>&lt;pre&gt;
Hi List, 

I implemented a new (optional and customizable) feature for 'outshine.el':
behind every folded headline, a little 'cookie' can show the number of
hidden lines till the next visible headline. 

E.g., an  Emacs Lisp buffer structured the 'outshine-way' with
outline-minor-mode and outshine.el activated might look like this after
evaluating 'outshine-show-hidden-lines-cookies':

,-------------------------------------------------------------------------------
| ;; * navi-mode.el --- major-mode for easy buffer-navigation [#13]
| ;; ** Commentary [#1]
| ;; *** About navi-mode
| 
| ;; This file implements extensions for occur-mode. You can think of a
| ;; navi-buffer as a kind of 'remote-control' for an (adecuately)
| ;; outline-structured original-buffer. It enables quick navigation and basic
| ;; structure editing in the original-buffer without (necessarily) leaving the
| ;; navi-buffer. When switching to the original-buffer and coming back after
| ;; some modifications, the navi-buffer is always rever&lt;/pre&gt;</description>
    <dc:creator>Thorsten Jolitz</dc:creator>
    <dc:date>2013-05-21T17:00:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90954">
    <title>Re: Returning variable "references" under lexical binding</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90954</link>
    <description>&lt;pre&gt;
Sure there is.  OK, forget about timers, let's go even simpler:

;; -*- lexical-binding: t; -*-

(defun return-variable-n ()
  (let ((n 1))
    (in-five-seconds (lambda () (setq n 2)))
    SOMETHING))

(setq foo (return-variable-n))

I want to return SOMETHING such that if I inspect it immediately, I'll
get 1, but if I save it and inspect it after five seconds have passed,
I'll get 2.  SOMETHING can't be just "n", because the function returns
by value and foo would only ever contain 1.

Similarly, in my original code, I can't just return "timer", because the
calling code would only ever see the very first timer created, and would
not be able to see the new values for timer that the callbacks store
later.

Without lexical variables, I could do this:

(defun return-variable-n ()
  (let ((n (gensym)))
    (set n 1)
    (in-five-seconds (lambda () (set n 2)))
    n))

...and then get the current value of n using symbol-value.

Using lexical variables, SOMETHING can be (lambda () n), which can be
called to get t&lt;/pre&gt;</description>
    <dc:creator>Sean McAfee</dc:creator>
    <dc:date>2013-05-21T16:38:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90953">
    <title>RE: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90953</link>
    <description>&lt;pre&gt;
You must use [(meta ?q)], not [(meta q)].


&lt;/pre&gt;</description>
    <dc:creator>Drew Adams</dc:creator>
    <dc:date>2013-05-21T16:44:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90952">
    <title>Re: Disabling auto indentation</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90952</link>
    <description>&lt;pre&gt;Stefan Monnier [2013-05-20T23:09-0400]:

[...]

yeah, sorry, I mean to say auto-fill-mode. (The former was for
another question that now I've resolved.)



&lt;/pre&gt;</description>
    <dc:creator>f gr</dc:creator>
    <dc:date>2013-05-21T16:42:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90951">
    <title>RE: sending function arguments to recursive function calls</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90951</link>
    <description>&lt;pre&gt;
Which is just to say that Emacs Lisp now aims to end up like Common Lisp (30 years later): lexical scoping unless the variable is "special" (which for Emacs Lisp means defvar'd, so far).

IOW, nothing new here.  No rejection of dynamic scoping.  Reasonable cohabitation of lexical and dynamic scoping.  That's still the aim, AFAIU, and a good one.


&lt;/pre&gt;</description>
    <dc:creator>Drew Adams</dc:creator>
    <dc:date>2013-05-21T16:34:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90950">
    <title>Re: Returning variable "references" under lexical binding</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90950</link>
    <description>&lt;pre&gt;In article &amp;lt;87fvxgc2mz.fsf&amp;lt; at &amp;gt;gmail.com&amp;gt;, Sean McAfee &amp;lt;eefacm&amp;lt; at &amp;gt;gmail.com&amp;gt; 
wrote:


But it's not the same lexical variable in your example. Each time you 
call start-my-timer you're creating a new closure over that variable. 
The caller has to save that closure somewhere, so that it can pass it to 
cancel-my-timer later. There's no functional difference between that and 
saving the timer itself.

What you're talking about would be using a closure to implement an 
object-oriented approach:

(defun new-timer ()
  (let (timer)
    #'(lambda (operation)
        (case operation
          ((start)
           (setq timer (make-timer ...)))
          ((update)
           (if timer (stop-timer timer))
           (setq timer (make-timer ...)))
          ((stop)
           (if timer (stop-timer timer)))))))

(setq timer (new-timer))
(funcall timer 'start)
(funcall timer 'stop)

&lt;/pre&gt;</description>
    <dc:creator>Barry Margolin</dc:creator>
    <dc:date>2013-05-21T14:23:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90949">
    <title>Re: Returning variable "references" under lexical binding</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90949</link>
    <description>&lt;pre&gt;
But you said:


How is the above start-my-timer inadequate then?


Each invocation of this start-my-timer will return a different closure.
Whether start-my-timer returns a timer or a closure, you still have to keep
track of which one to pass to cancel-my-timer. So the use of closures
doesn't facilitate anything that I can see.

&lt;/pre&gt;</description>
    <dc:creator>Barry OReilly</dc:creator>
    <dc:date>2013-05-21T14:41:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.help/90948">
    <title>Re: Disabling M-q</title>
    <link>http://permalink.gmane.org/gmane.emacs.help/90948</link>
    <description>&lt;pre&gt;Op donderdag 16 mei 2013 04:59 CEST schreef Yuri Khan:


I have tried (I am not using it):
    (local-set-key (kbd "M-q") 'ignore)

and it works. I send the improved solution to my friend.

&lt;/pre&gt;</description>
    <dc:creator>Cecil Westerhof</dc:creator>
    <dc:date>2013-05-21T08:13:22</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>
