headers
Michael Welsh Duggan | 9 Feb 22:17

Code in lisp reader and ,.

So, in common lisp, ,. is special in quasiquoted forms.  It is supposed
to work the same as ,@, except that ,. is a hint to the compiler that
the argument to ,. may be destructively modified.  Hence given:

  (setq foo '(a b) bar '(c d))
  (setq baz `(x ,@foo y ,.bar z))

baz will be (x a b y c d z), foo will be (a b), and bar could be
anything under the sun, but is probably either (c d) or (c d z), where
(eq bar (cddddr baz)) ==> t.

Now, emacs lisp's backquote macro does not handle the ,. form.  However,
the lisp reader does treat ,. specially:  `,.foo ==> (\,\. foo).

I suggest that either emacs lisp's backquote macro be modified to handle
,. (most simply by treating it as an alias of ,@), or the special
handling for it (lread.c:2838) should be removed.

--

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)
Permalink | Reply | 0 comments |
headers
Leo | 9 Feb 09:33
Face
Picon

Help debug an error in pre-command-hook?

I am seeing an error:

Error in pre-command-hook: 

(wrong-type-argument symbolp (lambda (&rest --cl-rest--) (interactive)
(apply (lambda (G91516 G91517 G91518) (setq
minor-mode-overriding-map-alist (symbol-value G91518)) (bury-buffer) (if
(and (symbol-value G91517) (not (one-window-p))) (delete-window)) (if
(window-live-p (symbol-value G91516)) (select-window (symbol-value
G91516)))) (quote --origwin--) (quote --delete-p--) (quote --old--)
--cl-rest--)))

Before the error, the value of pre-command-hook is:

   pre-command-hook is a variable defined in `C source code'.
   Its value is (t comint-preinput-scroll-to-bottom)

   Local in buffer *Python*; global value is 
   (delete-selection-pre-hook tooltip-hide)

But looking at the source of comint-preinput-scroll-to-bottom, I cannot
see where it can generate this error? Any idea how to debug this?

Thanks in advance.

Leo
Permalink | Reply | 2 comments |
headers
Deniz Dogan | 8 Feb 22:21
Picon

New hook for ERC

Hi,

I've been trying to "fix" the behavior of ERC's scroll-to-bottom module 
by hooking into erc-insert-post-hook.  I thought that the state when 
that hook is executed would be that point is back in the input area, but 
it does not seem like it.

I need point to be in the input area (after erc-input-marker) when the 
hook is executed to properly recenter the window.  I can't seem to find 
a hook for when that happens, so I made a new one and run that hook as 
the last thing that happens in the buffer in erc-display-line-1:

...snip...
	(erc-update-undo-list (- (or (marker-position erc-insert-marker)
				     (point-max))
				 insert-position)))
       (run-hooks 'erc-display-post-hook)))) ;; as such!

Then I add my own function to erc-display-post-hook as such:

(defun damd-erc-display-post-hook ()
   (let ((windows (get-buffer-window-list (current-buffer) nil 'visible)))
     (dolist (w windows)
       (when (>= (point) erc-input-marker)
         (with-selected-window w
           (recenter -1))))))
(add-hook 'erc-display-post-hook 'damd-erc-display-post-hook)

Is there any way to do this without introducing yet another hook like I 
just did?  If not, can I add the hook to trunk?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Teemu Likonen | 8 Feb 14:15
Picon
Picon
Favicon

Re: CL package serious deficiencies

* Lennart Borgman [2012-02-07 20:11:11 +0100] wrote:

> There are things that do not work if you include cl.el at run time.
> You may not notice the problems and tracking it down has been quite
> difficult some times.

About two weeks ago I noticed the opposite. I switched from Emacs 23.2
to 24.0 and experienced that some spam- or registry-related things in
Gnus didn't work _without_ run-time cl package. I support the idea of
making Emacs Lisp closer to CL so I don't care to complain about it.
Permalink | Reply | 2 comments |
headers
Alan Mackenzie | 8 Feb 18:26
Picon

Macro expansion: Why doesn't the invoked macro see (let (variables)) from the invoking one?

Hello, Emacs.

One macro FOO binds a let variable, then invokes another macro BAR.  BAR
doesn't see this let variable.  Why not?  Is there anything I can do
about this?

(defmacro BAR ()
  (message (if (boundp 'asdf) "asdf" "no asdf"))
  '(message "bar"))

(defmacro FOO ()
  (let (asdf)
    `(BAR)))

--

-- 
Alan Mackenzie (Nuremberg, Germany).
Permalink | Reply | 6 comments |
headers
John Yates | 8 Feb 06:46

hideshow: two minor tweaks

At present hs-show-block expands a hidden comment block irrespective
of where the cursor happens to be on the collapsed comment line.  It
also leaves the cursor position unchanged.

By contrast hs-hide-block's handling of comment blocks exhibits two rough edges:
(1) It fails to recognize a comment block if the cursor is in white
space to the left.  Fixed by having hs-inside-comment-p skip leading
white space.
(2) It always positions the cursor at the first character of the
collapsed comment.  Fixed by having hs-hide-comment-region maintian
the cursor column if possible.

--- cur/hideshow.el
+++ fix/hideshow.el
@@ -552,11 +552,13 @@
 (defun hs-hide-comment-region (beg end &optional repos-end)
   "Hide a region from BEG to END, marking it as a comment.
 Optional arg REPOS-END means reposition at end."
-  (let ((beg-eol (progn (goto-char beg) (line-end-position)))
+  (let ((goal-col (current-column))
+        (beg-bol (progn (goto-char beg) (line-beginning-position)))
+        (beg-eol (line-end-position))
         (end-eol (progn (goto-char end) (line-end-position))))
     (hs-discard-overlays beg-eol end-eol)
-    (hs-make-overlay beg-eol end-eol 'comment beg end))
-  (goto-char (if repos-end end beg)))
+    (hs-make-overlay beg-eol end-eol 'comment beg end)
+    (goto-char (if repos-end end (min end (+ beg-bol goal-col))))))

 (defun hs-hide-block-at-point (&optional end comment-reg)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dmitry Gutov | 8 Feb 00:32
Picon
Favicon
Gravatar

General delimited literals in ruby-mode patch


Hi all,

The bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6286.

I wrote a patch that fixes all examples except the last one (which is a
different issue), and also supports nesting delimiters of the same type
inside the literal: %r(//([^/])*/)

This would be my first patch for Emacs, so I'd love to have someone more
familiar with ruby-mode and/or font-lock look at it.

--

Do I submit the final patch here, or to the Ruby Redmine tracker?
As I understand, the upstream version is maintained to be compatible
with earlier Emacs versions, and I'm using the
syntax-propertize-function feature here.

Am I trying to be too clever with the syntax table in
`ruby-syntax-propertize-general-delimiters'? I figured it's the easiest
way to avoid reimplementing `scan-lists'.

In general, if I have an undercooked patch, should I post a message
here, or just attach it to the related bug?

Dmitry.


(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


John Wiegley
 | 
7 Feb 22:03






Picon

Gravatar





Re: CL package serious deficiencies


>>>>> Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> There are things that do not work if you include cl.el at run time.  You may
> not notice the problems and tracking it down has been quite difficult some
> times.

Can we move those breaking definitions into another file, say cl-ext.el, and
then allow library authors to require 'cl at runtime?  There are a lot of
useful routines in cl.el which are not harmful to other code.

John







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Nix
 | 
7 Feb 22:06






Picon





Re: CL package serious deficiencies


On 7 Feb 2012, Lennart Borgman verbalised:

> There are things that do not work if you include cl.el at run time.
> You may not notice the problems and tracking it down has been quite
> difficult some times.

If so, these are either bugs in cl.el, or bugs in the conflicting
packages, and should surely be fixed, rather than simply trying to avoid
using cl.

--

-- 
NULL && (void)







Permalink
| Reply
| 28 comments  
| 



  

  

  





headers


Juanma Barranquero
 | 
7 Feb 20:15






Picon

Gravatar





Re: CL package serious deficiencies


On Tue, Feb 7, 2012 at 20:11, Lennart Borgman <lennart.borgman <at> gmail.com> wrote:

> There are things that do not work if you include cl.el at run time.
> You may not notice the problems and tracking it down has been quite
> difficult some times.

I do (require 'cl) as one of the first things in my .emacs and I've
never seen a problem that was related to CL (I don't mean that CL has
no bugs, only that it hasn't triggered bugs in other code yet).

Do you have more specific info?

    Juanma







Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Lars Ingebrigtsen
 | 
6 Feb 21:20






Picon

Favicon

Gravatar





Two url.el issues


There are two url.el issues that I think should be resolved before Emacs
24 is released.

1) `url-retrieve' and friends cache everything they download, but
nothing is expired, so ~/.emacs.d/url/cache grows huge.  I think the
least intrusive way to fix this would be to have (say) every
(zerop (mod (incf url-counter-thing) 1000)) times the functions are
called do an expiry run.  Does this sound reasonable?

2) url stores and serves cookies by default, and that's a privacy
intrusion, especially when used by shr.el, which is a news-ish mail-ish
context.  But url.el has no easy way to disable cookies on a per-call
basis.  At this point there are three options: 1) Leave it as is.  2)
Disable cookies globally.  3) I can hack up some pretty invasive stuff
to allow per-connection cookie settings.  Opinions?

--

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome







Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane