Markus Triska | 1 Apr 01:10 2007
Picon
Picon

Re: emacs.c (main): fix profiling instructions

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

> Why change the flags when running ./configure?  Why not simply add
> LDFLAGS to the `make' command line?

That could inadvertently override options passed to ./configure.

> Doing that at `make' time has the advantage of being correct for the
> MinGW build as well

The patched line is valid on MinGW as well ("do something like ...").
Richard Stallman | 1 Apr 01:21 2007
Picon
Picon

Re: Toolbar and info mode (and others)

    I'm sorry.  I didn't intend to install it prematurely.  I thought 48
    hours (after your objection) was sufficient.  If Richard changes his
    decision, I will revert the move of the icon.

I see nothing drastic about moving an icon, so no issue
about doing it now.

Is there a general tendency to put "exit" on the right?
Eli Zaretskii | 1 Apr 05:07 2007
Picon

Re: emacs.c (main): fix profiling instructions

> Cc: emacs-pretest-bug <at> gnu.org
> From: Markus Triska <markus.triska <at> gmx.at>
> Date: Sun, 01 Apr 2007 01:10:45 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Why change the flags when running ./configure?  Why not simply add
> > LDFLAGS to the `make' command line?
> 
> That could inadvertently override options passed to ./configure.

But your suggestion has the same problem, doesn't it?  You never told
in your instructions that the profiling options are _in_addition_to_
the others.

> > Doing that at `make' time has the advantage of being correct for the
> > MinGW build as well
> 
> The patched line is valid on MinGW as well ("do something like ...").

There's no ``like'', unfortunately.

Anyway, I understand the motivation now, and will install an
appropriate patch.  Thanks.
Leo | 1 Apr 10:50 2007
Picon

Screen flickers with high CPU usage in Emacs unicode 2 branch


[It is on a laptop's LCD screen]

I noticed Emacs unicode 2 branch has something weird but was not able
to reproduce the bug until today. I falsely reported this bug to
emacs-w3m list: http://article.gmane.org/gmane.emacs.w3m/6658. It
might contains useful information if you cannot reproduce the bug by
the following:

  1.  emacs -q
  2.  C-u 32 M-x hanoi

Now you will see the screen flickers like crazy and my laptop CPU was
put to its full speed.

In GNU Emacs 23.0.0.7 (i686-pc-linux-gnu, X toolkit)
 of 2007-03-29 on sl392.st-edmunds.cam.ac.uk
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--prefix=/usr/local/packages/emacs23' '--with-kerberos5'
'--enable-locallisppath=/usr/local/share/emacs/site-lisp' '--without-toolkit-scroll-bars'
'--with-xft' '--enable-font-backend' '--with-x-toolkit=yes''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
(Continue reading)

Chris Moore | 1 Apr 14:42 2007
Picon

display problem after renaming open image files

Have a PNG image in /tmp/pic.png, then:

$ cd /tmp
$ mkdir emacs
$ cd emacs
$ cp ../pic.png pic1.png
$ cp ../pic.png pic2.png
$ emacs -Q

open the directory using dired:
  C-x d RET

open the first file in the other window, go back to the direct window, go down a line:
  o C-x o n

open the 2nd file in the other window, close that window, leaving only the dired window:
 o C-x 0

go back to the first file line, rename pic1.png to pic3.png:
p R pic3.png RET

revisit the first file (now called pic3.png):
 f

The image shows up as a small square rather than the real image.

(variations on the above theme, like renaming pic2 instead of pic1, or visiting pic2 after the rename don't
seem to cause the problem).

In GNU Emacs 22.0.96.22 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
(Continue reading)

Richard Stallman | 1 Apr 16:00 2007
Picon
Picon

Re: mark not set after a yank

    Very often when I do a move of the point using M-< followed by a C-w emacs
    complains about the mark not being set. emacs-21.3 abd prior always seems to
    work as it should. My work around is to do c-x c-x and then c-w

    This seems to indicate the c-x c-x knows about the mark but not c-w

That is what would happen in Transient Mark mode, I think.
Is it possible you enabled that mode?
Leo | 1 Apr 18:12 2007
Face
Picon

Re: Screen flickers with high CPU usage in Emacs unicode 2 branch

I caught a crash (backtrace attached). I am not sure if it is related
to this bug so I guess I'd just put it here.

Attachment (crash_20070401.log.bz2): application/x-bzip2, 9 KiB

--

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Chong Yidong | 1 Apr 19:26 2007

Re: narrowing *shell* buffer causes odd error

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

> We should fix that not to get an error at all.
> There is no reason why it has to fail.
>
> Would someone like to debug this?

I don't think this calls for any change.

The OP accidentally narrowed his shell buffer, and tried to send input
to the comint prompt.  The error popped up because the comint prompt
was now outside the accessible part of the buffer.  Widening the
buffer solves the problem.

Let's remove this from FOR-RELEASE.
Chong Yidong | 1 Apr 20:35 2007

Re: display problem after renaming open image files

Chris Moore <dooglus <at> gmail.com> writes:

> $ cp ../pic.png pic1.png
>
> open the first file
>
> rename pic1.png to pic3.png:
> p R pic3.png RET
>
> revisit the first file (now called pic3.png):
>  f

The image isn't displayed because pic1.png, which is the file
associated with this buffer, doesn't exist anymore.
Stefan Monnier | 1 Apr 20:50 2007
Picon

Re: Stack overflow in regexp matcher

> The regexp in question looks like: ".*some text.*". When used with
> string-match, removing both ".*"s shouldn't affect the matching
> semantically, right?

Differences (off the top of my head):
- match-beginning (as well as the return value of string-match)
- .* only matches chars other than \n
- .* matches greedily, so (string-match "foo" "foofoo") will only match the
  first "foo", whereas (string-match ".*foo" "foofoo") will match the whole
  string (the .* matches the first "foo").

> If so, would it be wise to add a regexp simplification step that, for
> example, could remove leading and trailing ".*"s in regular expressions
> passed to string-match?

In the code that calls string-match, yes, but within string-match it would
be terribly difficult to figure out whether the optimization is harmless.

> I realise now is not the time to talk about feature additions, but it
> would certainly make my life simpler if any regular expression that *can*
> be compiled to a DFA is.

I don't think you'll find much disagreement here.

> (I also wonder where "regular expressions" that are more than regular
> came from.  Just because they are useful?)

No idea.  Originally, only the \N backref was non-regular, but PCRE
introduced many others.  Note that using a DFA to implement unix
regexp-matching is actually pretty difficult because of the precise
(Continue reading)


Gmane