headers
Drew Adams | 1 Dec 2005 01:44
Picon
Favicon

view mode: `q' does not delete frame

See emacs-devel list messages of 9/8 and 9/9/2005, subject "quitting
help buffer". RMS's conclusion was "It doesn't fail for me, so there's
nothing I can do." By that he meant that for him `q' always deleted
the frame.

Here is a recipe to reproduce the bug. 

emacs -q

M-x set-variable RET pop-up-frames t

M-x apropos-zippy RET wash RET

Try `q' in the frame *Apropos Zippy*. It does nothing. I want it to
delete the frame.

Note: In other contexts, the frame is iconified instead of nothing
happening. I always want it to be deleted, never iconified.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on
 NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (3.3) --cflags
 -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
 -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
 -I../../zlib-1.2.2/include'
Permalink | Reply | 11 comments |
headers
Drew Adams | 1 Dec 2005 01:50
Picon
Favicon

RE: Setting key bindings in view-mode-hook

FYI - I just filed a bug for this.  Users should not have to customize Emacs
just to get a view-mode window to go away. This is a very annoying new
"feature".

`q' should not just do nothing; it should delete the frame if it is
one-window-p and it is not the sole frame. Or, at least, it should delete
the window (my delete-window will then delete a one-window frame). That is,
behavior like this should be the default behavior - quitting view mode
should get rid of the window, by default.
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Dec 2005 02:16
Picon
Favicon

RE: view mode: `q' does not delete frame

    See emacs-devel list messages of 9/8 and 9/9/2005, subject "quitting
    help buffer". RMS's conclusion was "It doesn't fail for me, so there's
    nothing I can do." By that he meant that for him `q' always deleted
    the frame.

    Here is a recipe to reproduce the bug.
    emacs -q
    M-x set-variable RET pop-up-frames t
    M-x apropos-zippy RET wash RET
    Try `q' in the frame *Apropos Zippy*.

    It does nothing. I want it to delete the frame.
    Note: In other contexts, the frame is iconified instead of nothing
    happening. I always want it to be deleted, never iconified.

I meant to send that to emacs-pretest, but since I sent it here, I'll
continue here with the followup.

Even without setting pop-up-frames = t, `q' does nothing in buffer *Apropos
Zippy*, which is in view-mode. Same recipe, without the `set-variable'. Use
`C-x o' to get to the buffer, then try `q'.

If you use `M-x apropos', on the other hand, using `q' in the *Apropos*
buffer gets rid of the buffer (it does `quit-window'). It doesn't get rid of
the window, but in my pop-up-frames=t case, `quit-window' does get rid of
the (dedicated-window) frame. If that behavior (get rid of the frame) could
be used always, I'd be happy.

*Apropos* is not in view-mode, however - the problem is with view-mode. In
*Apropos*, `q' does `quit-window', which is exactly what I wish it would do
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Dec 2005 02:55
Picon

Re: custom-save-variables: Unknown requested feature: nil

David Reitter wrote:

   I don't know what caused it. The below change makes the message go  
   away, but it's quite possibly not the right fix.

I believe that it is the right fix, but the same fix needs to be
applied to three other options, as I pointed out in my earlier reply.

   That `:require nil' came from the following change by Stefan Monnier
   on 2002-09-13:

	* simple.el: Provide `simple'.
	(transient-mark-mode, line-number-mode, column-number-mode):
	Pass an explicit `:require nil' argument.

   I do not know the reason for that change.

Whatever the reason for that change, it seems wrong.  I believe that
it tried to undo an at the time automatic :require written by
define-minor-mode.  It did not do that.  Instead it tried to require
the library nil.el _in addition_ to the other require, instead of
overwriting it.  (A defcustom can have more than one :require.  These
do not override each other.  Instead, all libraries are required by
the defcustom.)  This did not lead to an error, because of code in
custom-save-variables:

	    (when (and (symbolp request) (not (featurep request)))
	          (message "Unknown requested feature: %s" request)
		  (setq requests (delq request requests))))
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luc Teirlinck | 1 Dec 2005 03:05
Picon

Re: custom-save-variables: Unknown requested feature: nil

>From my earlier message:

      That `:require nil' came from the following change by Stefan Monnier
      on 2002-09-13:

	   * simple.el: Provide `simple'.
	   (transient-mark-mode, line-number-mode, column-number-mode):
	   Pass an explicit `:require nil' argument.

      I do not know the reason for that change.

In my earlier message, I inadvertently made this look like a quote
from David Reitter.  Instead I was quoting from a still earlier
message of mine.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Herbert Euler | 1 Dec 2005 03:21
Picon
Favicon

RE: Indentation problem in corporating major modes

I saw the following in etc/TODO:

>** Implement a clean way to use different major modes for
>   different parts of a buffer.  This could be useful in editing
>   Bison input files, for instance, or other kinds of text
>   where one language is embedded in another language.

What does clean mean here? Is mmm-mode not clean enough?

Regards,
Guanpeng Xu

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/
Permalink | Reply | 2 comments |
headers
Richard M. Stallman | 1 Dec 2005 07:05
Picon
Picon

Re: Slow Info startup

      When 
    you browse around, your Info history will be recorded as though 
    you are visiting the real "elisp" info file, at 
    /usr/share/info/elisp or wherever.  If you later visit the "real" 
    info file, those links will be fontified as "previously visited" 
    links.   Maybe that's an acceptable situation, however. 

Maybe it is acceptable, but first, could you explain why you think
this is the best solution?

Why is removing the directory related to making this code faster?
Permalink | Reply | 4 comments |
headers
Richard M. Stallman | 1 Dec 2005 07:07
Picon
Picon

Re: make-network-process(:nowait t) on MS-Windows

Your patches are big enough that we need some kind of legal papers
for them.

If the people who maintain Emacs support for Windoze want to use your
patches, they should tell me so, and I will make the necessary
arrangements with you.
Permalink | Reply | 1 comment |
headers
Richard M. Stallman | 1 Dec 2005 07:06
Picon
Picon

[ottomaddox <at> fastmail.fm: Foldout mode does not restore previous view correctly]

Could someone please look at this?

------- Start of forwarded message -------
X-Sasl-Enc: txkbtYB2orZITEL68nBs5gk84+Cd5JpaB2LrFRcVL/YV 1132761790
From: "Otto Maddox" <ottomaddox <at> fastmail.fm>
To: emacs-pretest-bug <at> gnu.org
Content-Disposition: inline
Date: Wed, 23 Nov 2005 16:03:10 +0000
Subject: Foldout mode does not restore previous view correctly
Sender: emacs-pretest-bug-bounces+rms=gnu.org <at> gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

Put the following text into a buffer in Outline mode:

- --- BEGIN ---
* Food
This is the body,
which says something about the topic of food.

** Delicious Food
This is the body of the second-level header.

** Distasteful Food
This could have
a body too, with
several lines.

*** Dormitory Food
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard M. Stallman | 1 Dec 2005 07:07
Picon
Picon

Re: emacs crash on SMP notebook only

    The last I checked, there were only harmless-looking bugfixes in the
    Debian patches.

Harmless-looking changes can cause real trouble when there is a
compiler bug.
Permalink | Reply | 0 comments |

Gmane