headers
Kim F. Storm | 1 Oct 2006 01:34
Picon

Re: Building Emacs-cvs on Cygwin

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST)
>> From: Angelo Graziosi <Angelo.Graziosi <at> roma1.infn.it>
>> cc: storm <at> cua.dk, emacs-devel <at> gnu.org
>> 
>> The problem is localized between lines 
>> 
>> 
>>    1072      # People get bothered when...
>>    .....     .....
>>    
>>    1110      end
>
> This is somewhat tangential to the real problem at hand, but as long
> as we are talking about this: what happens if you remove all that
> block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and
> then manually type the commands in the offending block, one after the
> other?  I'm particularly interested to know whether you see any error
> messages from GDB, and if so, which line causes these messages.
>
>> (gdb) xpr
>> Lisp_Symbol
>> $2 = (struct Lisp_Symbol *) 0x7d8bf888
>> Cannot access memory at address 0x7d8bf88c
>> (gdb) 
>
> Kim, any clever ideas, before we ask Angelo to look in last_marked[]
> array etc.?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Stallman | 1 Oct 2006 02:03
Picon
Picon

Re: Recursive edits in `save-excursion'

    So -- just to make sure that I understand correctly -- `recursive-edit'
    acts like it was implemented as follows?

Yes, I think so.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Oct 2006 02:03
Picon
Picon

Re: list-processes and process sentinels not run.

    If a process status changes to exit and list-processes is called
    without there being idle time, then the process is removed in
    list_processes_1:

	  if (EQ (symbol, Qsignal) || EQ (symbol, Qexit))
	    remove_process (proc);

    and the process sentinel isn't run.

We should change that code to run the sentinel
if it needs to be run.  Would someone please do that?

      This can be demonstrated with:

	(let ((proc (start-process "test-seq" nil "/bin/sleep" "0")))
	  (set-process-sentinel proc (lambda (proc msg)
				       (message msg)))
	  (while (delq nil (mapcar (lambda (p)
				     (string-match "test-seq" (process-name p)))
				   (process-list)))
	    (list-processes)))
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Oct 2006 02:04
Picon
Picon

Re: smtpmail.el feature request: envelope-sender from From:

    I'd like the envelope-sender to be taken from the From: field.

We don't need to put options into Emacs itself for everything everyone
might want to do.  If this preference is a peculiar quirk of yours,
you can get what you want by editing the code.

Is there some reason why this is in general the right thing to do?
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Oct 2006 03:20
Picon
Favicon

Overlay before-string property

I use this, from Miles Bader's minibuf-depth.el (or whatever it's called
now):

;; This function goes on minibuffer-setup-hook
(defun minibuf-depth-setup-minibuffer ()
  "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
The prompt should already have been inserted."
  (when (> (minibuffer-depth) 1)
    (setq minibuf-depth-overlay
          (make-overlay (point-min) (1+ (point-min))))
    (overlay-put minibuf-depth-overlay 'before-string
		     (format "%d) " (minibuffer-depth)))
    (overlay-put minibuf-depth-overlay 'evaporate t)))

I also propertize the text used for the minibuffer prompt. I pass a
propertized prompt string to completing-read, and I remove the face property
from minibuffer-prompt-properties. That highlights particular parts of the
prompt the way I want.

Unfortunately, the depth-indicator overlay picks up the face used for the
first character of the prompt string. I don't want that - I want it to have
its own face (e.g. the default).

So, I tried adding this at the end of the above code:

    (overlay-put minibuf-depth-overlay 'face 'default)

However, that puts the default face on the entire prompt string, for some
reason. I want the depth overlay to appear in the default face (no
highlighting), and the prompt string to appear the way I propertized it.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Stefan Monnier | 1 Oct 2006 05:31
Picon

Re: Overlay before-string property

> Unfortunately, the depth-indicator overlay picks up the face used for the
> first character of the prompt string. I don't want that - I want it to have
> its own face (e.g. the default).

> So, I tried adding this at the end of the above code:

>     (overlay-put minibuf-depth-overlay 'face 'default)

Put the face property on the before-string string.

        Stefan
Permalink | Reply | 1 comment |
headers
Drew Adams | 1 Oct 2006 05:57
Picon
Favicon

RE: Overlay before-string property

    > Unfortunately, the depth-indicator overlay picks up the face
    > used for the first character of the prompt string. I don't
    > want that - I want it to have its own face (e.g. the default).
    > So, I tried adding this at the end of the above code:
    >     (overlay-put minibuf-depth-overlay 'face 'default)

    Put the face property on the before-string string.

OK, that makes sense (and it works). Thanks.

However, I'd like to be able to just use the existing code as is, without
redefining it. That is, I'd prefer to do something simple after loading the
file minibuf-depth.el, rather than rewriting part of it.

Can you explain what is going on here, so I can understand it? Is this a
quality of the `before-string' property, in general, or does it result from
something else?

And should Miles' code (presumably to be added to Emacs after the release)
not result in this stickiness, or is it intended (does it have some
benefit)?
Permalink | Reply | 0 comments |
headers
David Kastrup | 1 Oct 2006 08:12
Picon
Picon

Re: Overlay before-string property

"Drew Adams" <drew.adams <at> oracle.com> writes:

> I use this, from Miles Bader's minibuf-depth.el (or whatever it's called
> now):
>
> ;; This function goes on minibuffer-setup-hook
> (defun minibuf-depth-setup-minibuffer ()
>   "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
> The prompt should already have been inserted."
>   (when (> (minibuffer-depth) 1)
>     (setq minibuf-depth-overlay
>           (make-overlay (point-min) (1+ (point-min))))
>     (overlay-put minibuf-depth-overlay 'before-string
> 		     (format "%d) " (minibuffer-depth)))
>     (overlay-put minibuf-depth-overlay 'evaporate t)))
>
> Does this have something to do with text-property stickiness? I have
> not knowingly changed any sticky properties, and the manual seems to
> say that text is, by default, only rear sticky. The behavior seems
> to be as if the prompt-string text were front-sticky and the overlay
> were rear-sticky, IIUC.

You could read the DOC string of make-overlay.  It has optional
arguments.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Permalink | Reply | 3 comments |
headers
Drew Adams | 1 Oct 2006 08:26
Picon
Favicon

RE: Overlay before-string property

    > I use this, from Miles Bader's minibuf-depth.el (or whatever
    > it's called now):
    >
    > ;; This function goes on minibuffer-setup-hook
    > (defun minibuf-depth-setup-minibuffer ()
    >   "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
    > The prompt should already have been inserted."
    >   (when (> (minibuffer-depth) 1)
    >     (setq minibuf-depth-overlay
    >           (make-overlay (point-min) (1+ (point-min))))
    >     (overlay-put minibuf-depth-overlay 'before-string
    > 		     (format "%d) " (minibuffer-depth)))
    >     (overlay-put minibuf-depth-overlay 'evaporate t)))
    >
    > Does this have something to do with text-property stickiness? I have
    > not knowingly changed any sticky properties, and the manual seems to
    > say that text is, by default, only rear sticky. The behavior seems
    > to be as if the prompt-string text were front-sticky and the overlay
    > were rear-sticky, IIUC.

    You could read the DOC string of make-overlay.  It has optional
    arguments.

Thanks, but I don't see how that helps. Perhaps I'm misreading it or the
text has changed since July (my build), however. It speaks of FRONT-ADVANCE
and REAR-ADVANCE, but I don't see how that would be related to property
stickiness. The manual says about the same thing as the doc string.

Stefan provided a solution, but it requires rewriting the (soon-to-be)
standard function (Miles's code). I'd like to control this without rewriting
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Kastrup | 1 Oct 2006 08:34
Picon
Picon

Re: Overlay before-string property

"Drew Adams" <drew.adams <at> oracle.com> writes:

>     > I use this, from Miles Bader's minibuf-depth.el (or whatever
>     > it's called now):
>     >
>     > ;; This function goes on minibuffer-setup-hook
>     > (defun minibuf-depth-setup-minibuffer ()
>     >   "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
>     > The prompt should already have been inserted."
>     >   (when (> (minibuffer-depth) 1)
>     >     (setq minibuf-depth-overlay
>     >           (make-overlay (point-min) (1+ (point-min))))
>     >     (overlay-put minibuf-depth-overlay 'before-string
>     > 		     (format "%d) " (minibuffer-depth)))
>     >     (overlay-put minibuf-depth-overlay 'evaporate t)))
>     >
>     > Does this have something to do with text-property stickiness? I have
>     > not knowingly changed any sticky properties, and the manual seems to
>     > say that text is, by default, only rear sticky. The behavior seems
>     > to be as if the prompt-string text were front-sticky and the overlay
>     > were rear-sticky, IIUC.
>
>     You could read the DOC string of make-overlay.  It has optional
>     arguments.
>
> Thanks, but I don't see how that helps. Perhaps I'm misreading it or
> the text has changed since July (my build), however. It speaks of
> FRONT-ADVANCE and REAR-ADVANCE, but I don't see how that would be
> related to property stickiness. The manual says about the same thing
> as the doc string.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane