bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1724: marked as done (23.0.60; fringe appears in spite of specifica


From: Emacs bug Tracking System
Subject: bug#1724: marked as done (23.0.60; fringe appears in spite of specification)
Date: Tue, 30 Dec 2008 15:45:05 +0000

Your message dated Tue, 30 Dec 2008 23:38:19 +0800
with message-id <address@hidden>
and subject line Re: bug#1724: 23.0.60; fringe appears in spite of specification
has caused the Emacs bug report #1724,
regarding 23.0.60; fringe appears in spite of specification
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact address@hidden
immediately.)


-- 
1724: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1724
Emacs Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 23.0.60; fringe appears in spite of specification Date: Sun, 28 Dec 2008 16:34:45 -0800
This is a piece of bug #117, which describes several problems with
frame parameters.

This is the bug that, even when `default-frame-alist' specifies no
fringe, the initial frame has fringe. I'm creating a new bug
report for this small piece of 117, to simplify things.
 
Save the code below to a file named `bug-117-fringe.el", then do this:
 
runemacs.exe -Q --debug-init -l "bug-117-fringe.el" -f "foo"
 
;----------------------------------------------
(defun foo ()
  (setq default-frame-alist
        (append '((minibuffer)
                  (left-fringe . 0)
                  (right-fringe . 0))
                default-frame-alist))
  (setq minibuffer-frame-alist
        (append '((minibuffer . only))
                minibuffer-frame-alist)))
 
(add-hook 'after-make-frame-functions
          (lambda (fr) (set-frame-size fr 60 20)))
;----------------------------------------------
 
This code works in Emacs 20 through 22. In Emacs 23, the first,
non-minibuffer frame has both left and right fringe, in spite of the
value of `default-frame-alist'. Note that without the call to
`set-frame-size' in `after-make-frame-functions' the problem does not
appear.
 
The Elisp manual, node Initial Parameters, says this about
`default-frame-alist':
 
"This is an alist specifying default values of frame parameters for
 all Emacs frames--the first frame, and subsequent frames.  When
 using the X Window System, you can get the same results by means
 of X resources in many cases."
 
NB: "the first frame, and..."
         ^^^^^
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-12-19 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 




--- End Message ---
--- Begin Message --- Subject: Re: bug#1724: 23.0.60; fringe appears in spite of specification Date: Tue, 30 Dec 2008 23:38:19 +0800 User-agent: Thunderbird 2.0.0.18 (Windows/20081105)
martin rudalics wrote:
This happens because the relevant code has been commented out in
x_get_arg:

#ifndef WINDOWSNT /* w32fns.c has not yet been changed to cope with this. */
      Lisp_Object tail;
      XSETCAR (tem, Qnil);
      /* In case the parameter appears more than once in the alist,
     clear it out.  */
      for (tail = alist; CONSP (tail); tail = XCDR (tail))
    if (CONSP (XCAR (tail))
        && EQ (XCAR (XCAR (tail)), param))
      XSETCAR (XCAR (tail), Qnil);
#endif

I don't know what has to be done in w32fns.c to make this work.

Thanks for finding this. It seems the appropriate change was made to w32fns.c on 2008-07-14, from memory it fixed part of the problem Drew had reported.

Drew,

I am marking bug#117 as done, since the original bug reported seems to be gone now. There are however several other bugs mentioned later in the thread, which should have their own bug reports (I know at least some of them do, for example bug#119 is mentioned a couple of times, in one case referencing the report). If any bugs mentioned there still exist after this fix has been applied and do not have an open bug report of their own already, please file a separate report for them.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]