headers
Ed Swarthout | 1 May 2005 05:24
Picon

widen in pop-global-mark

pop-global-mark is doing a "widen" when the restored position is
not within the current region.  This breaks things such as Info 
which make heavy use of narrowing and never show the whole buffer.
Since set-mark isn't recording the current region, I think doing
a widen is is worse than leaving the cursor at the top.

It certainly breaks Info's navigational ability - "Node has no Up"

Ed Swarthout

In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-04-30 on den
Distributor `The XFree86 Project, Inc', version 11.0.40300001
configured using `configure '--with-x=yes' '--with-x-toolket=athena''

Recent messages:
For information about the GNU Project and its goals, type C-h C-p.
Loading info...
Loading easymenu...done
Loading info...done
Composing main Info directory...
Mark set
Composing main Info directory...done
Mark saved where search started
Info-extract-pointer: Node has no Up
Loading emacsbug...done
Permalink | Reply | 1 comment |
headers
martin rudalics | 1 May 2005 10:07
Picon
Picon

add-to-invisibility-spec adds element unconditionally

 From the Elisp manual:

  -- Function: add-to-invisibility-spec element
      This function adds the element ELEMENT to
      `buffer-invisibility-spec' (if it is not already present in that
      list). ...

But the element is added unconditionally:

(defun add-to-invisibility-spec (arg)
   ...
   (setq buffer-invisibility-spec
	(cons arg buffer-invisibility-spec)))

Also, the doc-strings of `add-to-invisibility-spec' and
`remove-from-invisibility-spec' should reference ARG.
Permalink | Reply | 1 comment |
headers
David Reitter | 1 May 2005 12:06
Picon
Gravatar

([16777315] . " (H-c)") in a menu-item

Since the list server is down this weekend, I'm sending this to you 
FYI. The effect is very robust and very annoying, because after 
changing some menu items, stuff in the Edit menu doesn't work any more 
and gives me an error (wrong argument commandp).

I've been poking around trying to trace this bug for hours, but no luck 
so far.

I'm trying hard to put together an Aquamacs release that works on Tiger 
quickly.

D
---
This is a little strange.

(assq 'copy (lookup-key global-map [menu-bar edit]))
--> (copy "Copy" "Copy text in region to the clipboard" ([16777315] . " 
  (H-c)") . clipboard-kill-ring-save)

What does this 16777315 do there? Is it supposed to be there??

Interestingly, it doesn't happen consistently. This is what it usually 
looks like:

(copy "Copy" "Copy text in region to the clipboard" . 
clipboard-kill-ring-save)

Now, at some point during my startup phase (many customizations), the 
menu item changes to the 'strange' entry. It is not easy to analyze 
when that change occurs. If I delete this and that in my init file, the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 May 2005 14:06
Picon
Picon

Re: add-to-invisibility-spec adds element unconditionally

I fixed this.  Thanks.
Permalink | Reply | 0 comments |
headers
martin rudalics | 1 May 2005 14:21
Picon
Picon

enlarge-window with preserve-before non-nil

Suppose I start with a single window called W1 (window names are
fictional)

W1

split W1 horizontally

W1 | W2

split W2 vertically

    | W2
W1 |---
    | W3

delete W1

W2
--
W3

split W2 horizontally

W2 | W4
-------
    W3

split W4 vertically

    | W4
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 May 2005 17:24
Picon

Re: xterm.el

> On the slowest machine that I have access to, a 500MHz P3 the
> xterm.elc load time (as reported by elp) goes from 2.2 seconds to 0.3
> seconds if all the substitute-key-definition calls are moved before
> (let ((map (make-sparse-keymap))) 

That's a good point: the keys we want to substitute are all in the
"original" map, so we can do the substitute first, on the smaller map, and
add our extra bindings afterwards.

> Stefan, do you have any idea what might be the problem here?

I don't see any problem.  substitute-key-definition takes time at least
proportional to the total size of the keymap and it's made slower in the
presence of keymap inheritance, so it's no wonder that the calls to
substitute-key-definition should be faster when done on the smaller
non-inheriting map.

        Stefan
Permalink | Reply | 0 comments |
headers
Dan Nicolaescu | 1 May 2005 02:23
Picon

Re: xterm.el

Nick Roberts <nickrob <at> snap.net.nz> writes:

  > xterm.el makes Emacs take about seven times as long to load for me (about 14
  > seconds on my 200MHz PC). I have tested this by setting term-file-prefix to
  > nil as described in startup.el
  > 
  > I think this is due to the recent changes in xterm.el e.g
  > substitute-key-definition is invoked 48 times.

On the slowest machine that I have access to, a 500MHz P3 the
xterm.elc load time (as reported by elp) goes from 2.2 seconds to 0.3
seconds if all the substitute-key-definition calls are moved before
(let ((map (make-sparse-keymap))) 

Stefan, do you have any idea what might be the problem here? (You are 
the last person to have done changes to substitute-key-definition, so
I hoped you might understand what is it doing, because I don't). 
Could you please take a look? 

The "let" at the beginning of xterm.el does this: 
  (set-keymap-parent map (keymap-parent function-key-map))
  (set-keymap-parent function-key-map map))

Does substitute-key-definition have a problem because of the way
function-key-map is modified above? 

                 --dan
Permalink | Reply | 2 comments |
headers
Timmy Douglas | 1 May 2005 04:19
Picon
Favicon

Re: crash when opening a newsgroup

Richard Stallman <rms <at> gnu.org> writes:

>     Side note: one thing that would be nice is if emacs would always crash
> 	  instead of aborting...sometimes I run it outside of gdb and
> 	  aborting is like exiting cleanly (I think?) so there is no way
> 	  to figure out what went wrong.
>
> I don't really understand that; I am not sure what you mean by
> "crash instead of aborting" or why you think that this affects
> whether you can figure out what went wrong.  Are you saying
> you want it to make a core dump?
>
> `abort' causes a fatal signal.  It ought to make a core dump
> if you have enabled core dumps.

ok, if this is the case then don't worry about it. I just remember not
running emacs from gdb before and then it aborted without leaving
behind a core file. I guess I didn't have core dumps enabled.

> Anyway, that backtrace looks really bizarre.  It seems that the stack
> has somehow been completely corrupted.  It makes no sense for
> funcall_lambda to have called send_process.  But it is not
> entirely nonsense; for instance, Ffuncall really does call
> funcall_lambda.

If something was using a foreign function call out to C land maybe? I
don't know.

> send_process really does call error, but the first argument
> is always a string constant, so it is strange that you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 May 2005 20:57
Picon
Picon

Re: widen in pop-global-mark

I fixed this.  Thanks.
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 May 2005 22:33
Picon

Re: Can't isearch 'รถ'

> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant.  If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicode and hence with Emacs 23.  (Unless I misunderstood.)

Indeed,

        Stefan
Permalink | Reply | 0 comments |

Gmane