headers
Emacs bug Tracking System | 1 Feb 2009 04:40

bug#2139: Acknowledgement (Check out hot deals)


Thank you for filing a new bug report with Emacs.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Emacs Bugs <bug-gnu-emacs <at> gnu.org>

If you wish to submit further information on this problem, please
send it to 2139 <at> emacsbugs.donarmstrong.com, as before.

Please do not send mail to owner <at> emacsbugs.donarmstrong.com unless you wish
to report a problem with the Bug-tracking system.

--

-- 
2139: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2139
Emacs Bug Tracking System
Contact owner <at> emacsbugs.donarmstrong.com with problems
Permalink | Reply | 0 comments |
headers
Dan Nicolaescu | 1 Feb 2009 04:43
Picon

bug#2136: cleanup: Fresume_tty and Fsuspend_tty

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

  > > Date: Sat, 31 Jan 2009 13:22:16 -0800 (PST)
  > > From: Dan Nicolaescu <dann <at> ics.uci.edu>
  > > Cc: 2136 <at> emacsbugs.donarmstrong.com
  > > 
  > > Can you have multiple ttys in MSDOS?
  > 
  > No, of course not.  Not if by ``tty'' you mean an interactive
  > terminal.
  > 
  > > Otherwise suspend-frame won't call supend-tty.
  > 
  > It can be tricked into doing that, since the test in controlling-tty-p
  > is very naive.

Then the test needs to be improved...

  > >   >  For resume-tty, I just invoked it directly.
  > > 
  > > See above, this function only makes sens when using multiple ttys. 
  > 
  > If you mean the full functionality, then yes, I agree.  However, since
  > the current uses of these two functions are so few, I cannot yet say
  > that having them not fboundp will or won't do harm for the DOS port.
  > For now, they are more or less no-ops, which certainly doesn't do any
  > harm, at least AFAICS.

It complicates the code, I just recently fixed in bug there, that's how
I run into this.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Nicolaescu | 1 Feb 2009 07:05
Picon

bug#2138: 23.0.60; --daemon and ediff-window-setup-function

Stephen Berman <stephen.berman <at> gmx.net> writes:

  > Start Emacs like this:
  > 
  > 1. emacs -Q --eval "(require 'ediff)"
  > 2. emacsclient -c
  > 3. C-h v ediff-window-setup-function
  > => ediff-setup-windows-multiframe
  > 
  > Now start Emacs like this:
  > 
  > 1. emacs -Q --daemon --eval "(require 'ediff)"
  > 2. emacsclient -c
  > 3. C-h v ediff-window-setup-function
  > => ediff-setup-windows-plain
  > 
  > 
  > I haven't tried debugging this, but my first guess is that
  > ediff-setup-windows-multiframe requires non-nil window-system but (still
  > guessing) when there is no frame window-system evaluates to nil.

You can take --daemon out of this equation, you'd  get the same when
doing 
emacs -Q and emacs -Q -nw
Permalink | Reply | 4 comments |
headers
Richard M Stallman | 1 Feb 2009 07:30
Picon
Picon

bug#2135: 23.0.60; Rmail's `g' command marks old messages ``unseen''

I think this means that the right place to set the "unseen" attribute
is when _creating_ the header field that records the attributes.
Permalink | Reply | 0 comments |
headers
Torsten Bronger | 1 Feb 2009 09:59
X-Face
Picon
Picon
Picon
Picon
Favicon
Gravatar

bug#1854: 23.0.60; Gnus opens browser tab twice

Hallöchen!

Torsten Bronger writes:

> If I open an email in Gnus with an HTML link, it is clickable.  If
> I click on it, it opens the tab in Firefox *twice*.  This is
> behaviour that was introduced in the CVS version only recently
> (well, I don't update often, so it may be a few months old).

This problem vanished somehow yesterday.  I checked the logfile of
my package manager but I could found any automatic update which
could be responsible for it (unless it was libc, gcc, or ldap, which
is hardly the case).  Additionally, I haven't installed a new CVS
Emacs.

So unfortunately, I can't tell you what is responsible.  I can only
say the e.g. my instant messager never exhibited this behaviour, it
was only Emacs.  I'm ready for answering any questions nevertheless
of course.

Tschö,
Torsten.

--

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger <at> jabber.rwth-aachen.de
Permalink | Reply | 1 comment |
headers
Jari Aalto | 1 Feb 2009 11:46
Favicon
Gravatar

bug#2134: [PATCH] progmodes/compile.el: check global-font-lock-mode

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Here is patch to not to turn on font-lock unconditionally. Patch is
>> against Emacs version control tree check out 2009-01-31.
>
> If you read the rest of the compile.el code, you'll see that it uses
> font-lock to do its job, which is why it's turned on unconditionally.
>

The buffer handling could be improved to work without font lock. In some
cases the colors distract reading; thus font-lock is turned offm, but
RET no longer intreprets the line.

SUGGESTION

There could be be alternative handler to read the current line and
respond to RET (etc.) when font-lock is turned off. I'm supposing here
that standard grep syntax would be easy to handle:

   default-directory: DIR

   FILE:LINE:MATCH

Jari
Permalink | Reply | 1 comment |
headers
Stephen Berman | 1 Feb 2009 12:20
Picon

bug#2138: 23.0.60; --daemon and ediff-window-setup-function

On Sat, 31 Jan 2009 22:05:07 -0800 (PST) Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>   > Start Emacs like this:
>   > 
>   > 1. emacs -Q --eval "(require 'ediff)"
>   > 2. emacsclient -c
>   > 3. C-h v ediff-window-setup-function
>   > => ediff-setup-windows-multiframe
>   > 
>   > Now start Emacs like this:
>   > 
>   > 1. emacs -Q --daemon --eval "(require 'ediff)"
>   > 2. emacsclient -c
>   > 3. C-h v ediff-window-setup-function
>   > => ediff-setup-windows-plain
>   > 
>   > 
>   > I haven't tried debugging this, but my first guess is that
>   > ediff-setup-windows-multiframe requires non-nil window-system but (still
>   > guessing) when there is no frame window-system evaluates to nil.
>
> You can take --daemon out of this equation, you'd  get the same when
> doing 
> emacs -Q and emacs -Q -nw

I should have been more explicit about the point of this bug report,
which is this: when I invoke `emacsclient -c' under X11, I expect the
usual behavior under X11, but in the above case, --daemon apparently
(Continue reading)

Permalink | Reply | 3 comments |
headers
Karl Berry | 1 Feb 2009 15:37

bug#1988: Making the license statement visible in the Emacs Manual

Jesse,

    Simply adding  <at> insertcopying seems best to me, but any of the 
    alternatives are fine.  If it would help, I'd be happy to make patches 
    for the various manuals.

Since evidently no one else has a strong opinion, I suggest we go with
the plain  <at> insertcopying.  It would be great if you could prepare the
patches.  Thanks.
Permalink | Reply | 6 comments |
headers
Dan Nicolaescu | 1 Feb 2009 15:50
Picon

bug#2138: 23.0.60; --daemon and ediff-window-setup-function

Stephen Berman <stephen.berman <at> gmx.net> writes:

  > On Sat, 31 Jan 2009 22:05:07 -0800 (PST) Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
  > 
  > > Stephen Berman <stephen.berman <at> gmx.net> writes:
  > >
  > >   > Start Emacs like this:
  > >   > 
  > >   > 1. emacs -Q --eval "(require 'ediff)"
  > >   > 2. emacsclient -c
  > >   > 3. C-h v ediff-window-setup-function
  > >   > => ediff-setup-windows-multiframe
  > >   > 
  > >   > Now start Emacs like this:
  > >   > 
  > >   > 1. emacs -Q --daemon --eval "(require 'ediff)"
  > >   > 2. emacsclient -c
  > >   > 3. C-h v ediff-window-setup-function
  > >   > => ediff-setup-windows-plain
  > >   > 
  > >   > 
  > >   > I haven't tried debugging this, but my first guess is that
  > >   > ediff-setup-windows-multiframe requires non-nil window-system but (still
  > >   > guessing) when there is no frame window-system evaluates to nil.
  > >
  > > You can take --daemon out of this equation, you'd  get the same when
  > > doing 
  > > emacs -Q and emacs -Q -nw
  > 
  > I should have been more explicit about the point of this bug report,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Berman | 1 Feb 2009 16:30
Picon

bug#2138: 23.0.60; --daemon and ediff-window-setup-function

On Sun, 1 Feb 2009 06:50:11 -0800 (PST) Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>   > On Sat, 31 Jan 2009 22:05:07 -0800 (PST) Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
>   > 
>   > > Stephen Berman <stephen.berman <at> gmx.net> writes:
>   > >
>   > >   > Start Emacs like this:
>   > >   > 
>   > >   > 1. emacs -Q --eval "(require 'ediff)"
>   > >   > 2. emacsclient -c
>   > >   > 3. C-h v ediff-window-setup-function
>   > >   > => ediff-setup-windows-multiframe
>   > >   > 
>   > >   > Now start Emacs like this:
>   > >   > 
>   > >   > 1. emacs -Q --daemon --eval "(require 'ediff)"
>   > >   > 2. emacsclient -c
>   > >   > 3. C-h v ediff-window-setup-function
>   > >   > => ediff-setup-windows-plain
>   > >   > 
>   > >   > 
>   > >   > I haven't tried debugging this, but my first guess is that
>   > >   > ediff-setup-windows-multiframe requires non-nil window-system but (still
>   > >   > guessing) when there is no frame window-system evaluates to nil.
>   > >
>   > > You can take --daemon out of this equation, you'd  get the same when
>   > > doing 
>   > > emacs -Q and emacs -Q -nw
(Continue reading)

Permalink | Reply | 0 comments |

Gmane