key binding of `M-' shows up in menu as (M-)
emacs -Q Bind a command `foo' in a minibuffer completion map to `M-'. Add `foo' to the Minibuf menu: (define-key map [menu-bar minibuf foo] '(menu-item Foo It foo)) In the Minibuf menu, the item appears with the wrong binding: Foo It (M-) The `' was removed - it should show (M-). Perhaps the `' needs to be automatically escaped? In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: key binding of `M-' shows up in menu as (M-)
I think this is specific to w32. Yes needs to be escaped there. I hope you mean that Emacs or Emacs W32 should do the escaping. These binding indications are added automatically. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: key binding of `M-' shows up in menu as (M-)
I think this is specific to w32. Yes needs to be escaped there. I hope you mean that Emacs or Emacs W32 should do the escaping. These binding indications are added automatically. I am not sure I understand you, but is the character you put before a character in the menu string on w32 to mark that character as an accelerator in menu. (It will be shown underlined then.) An example: Help will show Help in the menu with H underlined. So fixing this is a w32 specific problem. We discussed a little bit before adding the possibility to use accelerators in the menus. Perhaps this should be fixed when that is done to avoid splitting the code to much? The key-binding indication, e.g. (`C-x C-f') or (`M-'), is added automatically by Emacs. This is not text that I added as a user (e.g. using :keys). So the problem needs to be fixed at the program level (Emacs W32 or Emacs), not at the user level. That's all I am saying. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RET binding in *scratch*
emacs -Q C-x b *scratch* Type (frame-parameters), then C-u C-x C-e (yes, there are other ways in *scratch* to get the same result). Put the cursor on the opening paren after (frame-parameters). Hit RET. I would expect RET to be bound to `newline', and just insert a newline. Instead, it is bound to `last-sexp-toggle-display'. Why, oh why? Why not put that toggle on some other key; there are lots of keys available in *scratch*. How is one supposed to insert a newline? I resorted to C-q C-j, but perhaps there is something more clever. This doesn't seem like great design, to me, but I'm probably missing something. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: document custom-variable-p
Lisp programs should use `custom-variable-p', not `user-variable-p', whenever they want to test whether a variable is something that a user can customize and save. By the latter, I meant user Lisp programs, not just internal Lisp programs - Why do you think this is something user Lisp programs are likely to want to do? Customize is good for interactive editing and saving of options etc. But its UI is fixed and somewhat limited. I expect that users (e.g. third-party libraries) may well want to provide commands or other UI thingies that let you interface with the functionalities provided by custom: editing that respects specified types, and possibly saving changes. To create such UI extensions, it would be useful to be able to recognize variables that are editable and savable in custom from other user variables (those that just have *... as doc string). This would also be useful for user Lisp code that provides information (help) about variables. More generally, I think it makes sense for such type predicates to be advertised. Whether such a type test actually is used in user code is less important than being able to identify the possible types and their associated predicates. IOW, as a general principle, I think type predicates should be exposed (documented). Exceptions can be made for types that are little more than different internal representations (if such types exist). But being a subtype of `user-variable-p' that corresponds to customizable options seems like an important type, to me. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
frame-background-mode is in Elisp manual, but not Emacs manual
frame-background-mode is a _user_ option. Presumably it should be in the Emacs manual. It is only in the Elisp manual. How is a user to know about this option? In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: document custom-variable-p
`user-variable-p' is documented in the Elisp manual, but `custom-variable-p' is not. In general, the internals of Custom are documented only in regard to how to write definitions. Why is it important to document `custom-variable-p'? In my bug report I gave this reason: `custom-variable-p' is apparently the predicate for variables that are `user-variable-p' and are also customizable with Customize. Lisp programs should use `custom-variable-p', not `user-variable-p', whenever they want to test whether a variable is something that a user can customize and save. By the latter, I meant user Lisp programs, not just internal Lisp programs - the Elisp manual is for users who program in Emacs Lisp. A user program might well want to distinguish customizable options from other user options. I don't see `custom-variable-p' as being any more internal than `user-variable-p'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
document custom-variable-p
`custom-variable-p' is apparently the predicate for variables that are `user-variable-p' and are also customizable with Customize. (Some `user-variable-p' variables are not Customizable; they can be updated with `set-variable', but they cannot be edited or saved in Customize.) `user-variable-p' is documented in the Elisp manual, but `custom-variable-p' is not. The doc string of `user-variable-p' itemizes the possibilities, but the description of the possibility of being `custom-variable-p' (item #2) does not mention that predicate explicitly: Return t if VARIABLE is intended to be set and modified by users. (The alternative is a variable used internally in a Lisp program.) A variable is a user variable if (1) the first character of its documentation is `*', or (2) it is customizable (its property list contains a non-nil value of `standard-value' or `custom-autoload'), or (3) it is an alias for another user variable. Return nil if VARIABLE is an alias and there is a loop in the chain of symbols. The result is that `custom-variable-p' is mentioned nowhere. Yet Lisp programs should use `custom-variable-p', not `user-variable-p', whenever they want to test whether a variable is something that a user can customize and save. Suggestion: a. Update the Elisp manual to explicitly list the possibilities for `user-variable-p', as is done now in its doc string, and for item #2, explicitly mention predicate `custom-variable-p'. b. Reference `custom-variable-p' explicitly also in the doc string of `user-variable-p'. We can then shorten the description of item #2 there: no need to describe what `custom-variable-p' means. c. Update the doc string of `custom-variable-p' to include what is said now in item #2 for `user-variable-p': the variable has non-nil `standard-value' or `custom-autoload'. (The current doc string of `custom-variable-p' explains nothing.) In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
no doc for `group' in custom :type
In the Elisp manual, I find nothing about `group' as a type symbol. There is an example, in node Simple Types, that uses `group' when explaining type symbol `alist', but `group' is explained nowhere. This is the example: (defcustom list-alist '((foo 1) (bar 2) (baz 3)) Each element is a list of the form (KEY VALUE). :type '(alist :value-type (group integer))) The only explanation is this, given in passing: The `group' widget is used here instead of `list' only because the formatting is better suited for the purpose. What formatting? How is a reader supposed to understand this? Why does the manual speak of widget here, anyway? `group' should be explained as a symbol that you can use when defining a :type value in a `defcustom', just as `alist' and :value-type are explained in that context. `group' is not something specific to `alist', in any case. I find this, for instance, in file `cus-edit.el' (as well as many other uses of `group'). :type '(repeat (group (regexp :tag Match) (sexp :tag Type))) It seems that it is quite common to use `group' in `defcustom' :type specs, but it is not documented. If users are to understand `group' only by reading the widget doc, then there should at least be a cross reference to that doc here. How can Elisp programmers know about using `group' in :type specs if it is not documented? Furthermore, if you do go to the trouble of looking up `group' in the Widget manual, this is all you find (in node `group'): The `group' Widget -- This widget simply group other widgets together. Syntax: TYPE ::= (group [KEYWORD ARGUMENT]... TYPE...) The value is a list, with one member for each TYPE. There are no other occurrences of group in the Widget manual. And that node certainly doesn't teach us anything about formatting, or how the formatting is different from using `list' in :type. Please document `group' fully in the context of `defcustom' :type specs, explaining how it can be used and how it differs from using `list'. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
custom-guess-type-alist doesn't exist, but is mentioned in doc string
The doc string of `custom-variable-type' mentions `custom-guess-type-alist', but this does not exist. There is a `custom-guess-doc-alist' and a `custom-guess-name-alist', but no type alist. There is a function `custom-guess-type' - that is what is used in function `custom-variable-type'. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of find-tag
The doc string says: A marker representing the point when this command is invoked is pushed onto a ring and may be popped back to with \\[pop-tag-mark]. Contrast this with the ring of marks gone to by the command. Is there a command name missing before the last word here - e.g. gone to by the `foobar' command? If not, which command is the command? This is not clear to me. And what is the contrast being hinted at - can't we just explain what is meant directly? In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
add-to-invisibility-spec produces multiple occurrences
This is the definition of `add-to-invisibility-spec': (defun add-to-invisibility-spec (element) ... (if (eq buffer-invisibility-spec t) (setq buffer-invisibility-spec (list t))) (setq buffer-invisibility-spec (cons element buffer-invisibility-spec))) This is what it should be: (defun add-to-invisibility-spec (element) ... (if (eq buffer-invisibility-spec t) (setq buffer-invisibility-spec (list t))) (add-to-list 'buffer-invisibility-spec element)) Multiple elements should not be introduced. They serve no purpose, and could complicate code that manipulates `buffer-invisibility-spec'. In any case, `buffer-invisibility-spec' is not likely to be extremely long, so nothing is gained by not preventing duplicates. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mail-bury should use one-window-p, not window-dedicated-p
This line in the definition of `mail-bury' should be changed: (window-dedicated-p (frame-selected-window)) to this: (and pop-up-frames (one-window-p)) I use pop-up-frames = t, so that, by default, each buffer gets its own frame. That is not the same thing as requiring each window to be dedicated: I often reuse the same frame for a different buffer, and I sometimes use `C-x 2' or `C-x 3' to use multiple buffers in the same frame. pop-up-frames = t does not prevent using different or multiple buffers per frame - it does not impose dedicated windows; it simply says that, by default, you want a new frame, instead of a new window, created to display a buffer. When someone uses a one-frame-per-buffer-by-default approach, just as when someone uses a dedicated-window-per-buffer approach, it is common to want the frame to be deleted when the buffer is no longer used. The existing code caters to the latter use case, but it does not DTRT for the former. It should delete the frame in both cases. That is, it should delete the frame whenever pop-up-frames=t and the window is alone in the frame. That covers both use cases, and it doesn't interfere with the use case of most users: pop-up-frames=nil (whether one-window-p or not). Note that `mail-bury' is used not just by people who use gnus, or even just by people who use Emacs for mail. It is also used whenever an Emacs user submits a bug report. So, it is not enough that it cater to a gnus context; it should fit all expected Emacs use cases. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: eldoc-mode: t display-time-mode: t recentf-mode: t icomplete-mode: t tool-bar-pop-up-mode: t icicle-mode: t minibuffer-indicate-depth-mode: t pretty-control-l-mode: t delete-selection-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: mouse-movement drag-mouse-1 o n e - w i n d o w C-h f return down-mouse-1 mouse-1 left C-h f return down-mouse-1 mouse-1 C-h f return help-echo down-mouse-1 mouse-movement mouse-movement drag-mouse-1 backspace C-M-x help-echo help-echo help-echo menu-bar help-menu report-emacs-bug m a i l - b u f backspace r y SPC s h o u l d SPC u s e SPC o n e - w i n d o w - p SPC backspace , SPC n o t SPC w i n d o w - d e d i c a t e d - p switch-frame help-echo switch-frame return switch-frame help-echo down-mouse-1 mouse-movement mouse-1 j j j j j j j j j j j j j j j j C-c C-c y e s return switch-frame down-mouse-1 mouse-movement mouse-1 C-M-x switch-frame down-mouse-1 mouse-movement mouse-1 help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug f f f f f f f f f f f return switch-frame down-mouse-1 mouse-movement mouse-1 k k k k k k k k k k k k C-c C-c y e s return switch-frame switch-frame switch-frame switch-frame down-mouse-1 mouse-movement mouse-1 C-M-x switch-frame switch-frame C-x 5 2 switch-frame help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug f f f f f f f f f return switch-frame down-mouse-1 mouse-movement mouse-1 f f f f f f f f f f f f f f C-c C-c y e s return switch-frame switch-frame switch-frame switch-frame down-mouse-1 mouse-movement mouse-1 C-M-x switch-frame down-mouse-1 mouse-movement mouse-1 C-x 5 2 switch-frame help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug M-p M-p M-p return switch-frame down-mouse-1 mouse-1 j j j j j j j j j j j j j j j j j C-c C-c y e s return switch-frame switch-frame help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Quit [2 times] Mark set [4 times] mail-bury Sending...done mail-bury Sending...done mail-bury Sending...done mail-bury Sending...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Elisp manual doc of `fontified' property
The doc says this: `fontified' This property says whether the character has a face assigned to it by font locking. The display engine tests it to decide whether a buffer portion needs refontifying before display. *Note Auto Faces::. It takes one of three values: `nil' Font locking is disabled, or the character's `face' property, if any, is invalid. `defer' This value is only used when just in time font locking is enabled and it means that the character's `face' property is invalid and needs deferred fontification. `t' The character's `face' property, or absence of one, is valid. However, some emails from Stefan in emacs-devel suggest that the `fontified' property is something to be reserved for jit-lock: * I'd rather keep this property as something used internally in jit-lock and that nobody else should use or look at (unless they're reimplementing some kind of alternative to jit-lock). (2006-03-19, subject Suboptimal documentation of and handling of the 'fontified textproperty) * `fontified' is a jit-lock thing, so don't expect to be able to use it to solve font-lock problems. (2007-03-23, subject how to prevent font-lock from messing with a portion of text?) If property `fontified' (and not just its `defer' value) is to be reserved for jit-lock and not intended for general use, shouldn't this be mentioned in the doc? It would help if the doc were clarified to explain a bit more about this: what property `fontified' is for and how it is used (use cases etc.). On the other hand, if property `fontified' is something truly internal, then perhaps it should not be documented at all? As it stands now, the doc for this property is hardly intelligible (confusing, at the least), and the status (internal or not) seems problematic. See also node Auto Faces. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Elisp manual doc on `intangible' is incomplete
Elisp manual node Special Properties says this about `intangible': If a group of consecutive characters have equal and non-`nil' `intangible' properties, then you cannot place point between them. If you try to move point forward into the group, point actually moves to the end of the group. If you try to move point backward into the group, point actually moves to the start of the group. When the variable `inhibit-point-motion-hooks' is non-`nil', the `intangible' property is ignored. It does not say anything about what the meaning or behavior is if consecutive characters have unequal but non-nil `intangible' values. Why the qualification of having equal values? What is a user to understand about this? Is it not a corallary that the values does not have to be equal? Even consecutive characters with non-nil, but unequal values will form a group behaving the same way. I think it would help to add an explicit statement that you can place point between groups (which are defined as consecutive characters with the same `intangible' value). That is, clarify that you can place point between groups, but not within a group. The text might imply this, but it would be clearer to say it explicitly. That way, the purpose of such groups is made clear. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of buffer-invisibility-spec
The doc string says: Invisibility spec of this buffer. The default is t, which means that text is invisible if it has a non-nil `invisible' property. If the value is a list, a text character is invisible if its `invisible' property is an element in that list. If an element is a cons cell of the form (PROP . ELLIPSIS), then characters with property value PROP are invisible, and they have an ellipsis as well if ELLIPSIS is non-nil. It does not say anything about the situation where the `invisible' property is itself a list. The Elisp manual, node Invisible Text says this, in addition (where ATOM is a member of the `buffer-invisibility-spec' value): A character is invisible if its `invisible' property value is ATOM or if it is a list with ATOM as a member. The last part is what is missing from the doc string; or if it is a list with ATOM as a member. IIUC, this implies, e.g., that if `buffer-invisibility-spec' is (foo bar toto) and some text has property `invisible' with value (foo bar), then it will be invisible, as will text with `invisible' value `foo' and text with value (bar toto titi). The doc string only covers the case where the value is `foo', `bar', or `toto', not the possible list-value cases. It might even be helpful in the manual to explicitly point out an example such as value (toto titi), where `b-i-s' is, say, (foo toto) - to show that the value need not be a subset of `b-i-s', that any non-empty intersection will make the text invisible. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo C-h i help-echo help-echo down-mouse-2 mouse-2 g i n v i s i b l e SPC tab return C-h v b u f f e r - i n v i s tab return help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading dired...done 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...done Loading help-fns...done Loading pp...done Type C-x 1 to remove help window. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of next-single-char-property-change
The doc string is missing this important info that is in the Elisp manual (node Property Search): what value is returned if no such property change is found. The manual says it succinctly: if no change is found before the end of the OBJECT, it returns the maximum valid position in OBJECT This is all the more important as this behavior is different from that of `next-single-property-change'. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mail-bury should use one-window-p, not window-dedicated-p
(window-dedicated-p (frame-selected-window)) to this: (and pop-up-frames (one-window-p)) I think it is correct to test the first one. It may be desirable to test the second as well. Let's try it out for a while. I hope you mean try both tests, not just the first. You're right that the two cases are independent: some people might use dedicated windows (here and there, or everywhere); others might use non-nil `pop-up-frames'; and neither test covers the other. Using non-nil `pop-up-frames' is more general (less restrictive) than using dedicated windows. It requires only that `display-buffer' create a new frame if the buffer is not already displayed. You can still split windows and reuse windows with different buffers. It is closer to the mainstream Emacs use of windows than is a generalized use of dedicated windows. If you have a single-window frame and you've elected `pop-up-frames', then I think it makes sense for the frame to be discarded when the buffer displayed there is. Here, I'm making an interpretation, admittedly. It's true that that does not follow simply from a choice to let `display-buffer' use a new frame. It is based on my experience with `pop-up-frames' and questions and requests I've seen from others: I think that most people, once they adopt non-nil `pop-up-frames', expect the frame to go bye-bye when they kill its current buffer, and they are surprised when it sometimes does not. To ensure that behavior, some of us end up redefining miscellaneous functions such as `mail-bury' locally, which shouldn't be necessary. If Emacs developers feel that one-window-p frame deletion should not be tightly coupled with `pop-up-frames' = t, then perhaps we should let `pop-up-frames' have three values: nil and t as now, and `auto-discard', the latter causing the behavior that I prefer: whenever the frame is one-window-p and the current buffer is discarded (e.g. buried or killed), delete the frame also. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: display problem
(defun make-glyph-code (char optional face) Return a glyph code representing char CHAR with face FACE. (if face (logior char (lsh (face-id face) 19)) char)) ... I admit to not understanding a lot about glyphs, character codes, or Unicode. Perhaps it is silly to expect that `make-glyph-code' would work as proposed for Emacs 23 also. Please explain. Otherwise, if this is a bug, HTH. The 19 should be 21 in the unicode branch. Actually, it should be 22. [I'll make that change in the CVS tree, as make-glyph-code already exists there.] I've already installed that change in emacs-unicode-2 branch. Great. Glad the report served some purpose. Thx - Drew ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: display problem
What does Emacs mean by Emacs 23? There are currently two branches in CVS identifying themselves as Emacs 23 AFAIK. When you are using CVS versions, it helps considerably if you tell us details about which branch you are using, rather than relying on version numbers. I suspect you are using emacs-unicode-2, in which case the change of internal coding from emacs-mule to unicode would explain why you can't just reuse integer values to refer to the same characters. Sorry, I don't know more than what Emacs tells me. I have no idea whether I'm using emacs-unicode-2. If you need such a description, then I suggest that Emacs should provide it when I choose Send bug report. Perhaps there should also be an Emacs variable that holds such a semi-verbose description of a build; I don't know. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
display problem
emacs -Q (aset standard-display-table ?\014 [10 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030227 33030245 33030243 33030260 33030249 33030255 33030254 33030176 33030184 33030224 33030258 33030249 33030254 33030260 33030241 33030242 33030252 33030245 33030176 33030224 33030241 33030247 33030245 33030185 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176]) See two attached images. In Emacs 22 (all recent builds), this is displays correctly. In Emacs 23: 1) Each character appears as an empty rectangle. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Emacs-23-2007-01-02/etc/DEBUG for instructions. In GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) of 2007-01-01 on DTOP X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.1) --cflags -O2 -g0 -march=i386 -mtune=i686 -pipe -IC:/gnuwin32/include_ emacs -IC:/gnuwin32/lib -IC:/gnuwin32/src --ldflags -s ' 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 value of $LANG: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t attachment: bug-display-emacs-23-22-OK.pngattachment: bug-display-emacs-23-23-KO.png___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: display problem
Drew Adams wrote: emacs -Q (aset standard-display-table ?\014 [10 33030176 33030176 33030176 See two attached images. In Emacs 22 (all recent builds), this is displays correctly. In Emacs 23: 1) Each character appears as an empty rectangle. What do you mean by Emacs 23? Thinking about this might help with your problem. What does Emacs mean by Emacs 23? See my mail, where Help Send bug report reported the version and build information. If you understand the problem, and it is in fact user ignorance, please feel free to explain. FYI, the display-table entries were generated using Kim's proposal for a post-Emacs 22 release `make-glyph-code': (defun make-glyph-code (char optional face) Return a glyph code representing char CHAR with face FACE. (if face (logior char (lsh (face-id face) 19)) char)) The face used was this: (defface my-highlight 'type x w32 mac graphic) (class color)) (:box (:line-width 3 :style pressed-button))) (t (:inverse-video t))) ... :group 'faces) The vector was generated using this: (aset standard-display-table ?\014 (vconcat \n (mapcar (lambda (c) (make-glyph-code c 'my-highlight)) Section (Printable Page) ))) I admit to not understanding a lot about glyphs, character codes, or Unicode. Perhaps it is silly to expect that `make-glyph-code' would work as proposed for Emacs 23 also. Please explain. Otherwise, if this is a bug, HTH. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of make-directory
The doc string of make-directory should say that it does nothing if the directory already exists. It says that for the parent directories, but it doesn't say that for the first arg. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: cannot find :enable in Elisp manual index
Same problem for :type. It would be useful to be able to enter :type at the `i' prompt and go to manual pages that mention :type (not just type). From: Drew Adams Sent: Tuesday, May 22, 2007 8:26 AM emacs -Q C-h i, choose Elisp manual i :enable There is no index entry for :enable. Also, entries for enable are shown, even though I type :enable. That is, the `:' is ignored, instead of narrowing the set of matches. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
charset-list function - is it deprecated?
The doc (doc string and Elisp manual) for function charset-list does not say that this function is deprecated; it says only that it is provided for backward compatibility. Shouldn't the doc say that it is deprecated or obsolete as of Emacs 22? Otherwise, users are not explicitly encouraged to use the variable. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
cannot find :enable in Elisp manual index
emacs -Q C-h i, choose Elisp manual i :enable There is no index entry for :enable. Also, entries for enable are shown, even though I type :enable. That is, the `:' is ignored, instead of narrowing the set of matches. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: icicle-mode: t encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo down-mouse-1 mouse-1 M-x help-echo help-echo C-g C-g M-: 9 s e t backspace backspace backspace backspace ( s e q backspace t q SPC l o a d - p a t h SPC ( c o n s SPC . SPC l o a d - p a t h ) ) return M-x l o a d - l i b return i c i tab return M-x i c y return M-x help-echo menu-bar minibuf icicle-narrow-candidates C-g C-g help-echo down-mouse-1 mouse-1 C-h v i c i c l e - c o m p l e t i o n - c a n d i d a t e s return C-x 1 help-echo M-x help-echo C-g C-g help-echo help-echo M-x C-g C-g C-h k C-g C-g C-x 1 help-echo help-echo help-echo down-mouse-1 mouse-1 C-h i help-echo help-echo down-mouse-2 mouse-2 i : e n a b l e return , , , , , , , , , , , , , , , , , , , , , , , , u u u return s : e n a b l e return help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Found `enable-local-variables' in Index. (12 total; use `,' for next) Found `enable-multibyte-characters' in Index. (12 total; use `,' for next) Found `enable-recursive-minibuffers' in Index. (12 total; use `,' for next) Found `normal-backup-enable-predicate' in Index. (12 total; use `,' for next) Found `x-select-enable-clipboard' in Index. (12 total; use `,' for next) Found `ad-enable-advice' in Index. (12 total; use `,' for next) Searching subfile elisp-2... Searching subfile elisp-3... Searching subfile elisp-4... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
inconsistent naming of minibuffer-local.*-filename.*-map
The naming convention for these names is not consistent: minibuffer-local-filename-completion-map minibuffer-local-must-match-filename-map In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
\\{...} produces duplicate entries
emacs -Q
(define-key minibuffer-local-map [(control ?=)] 'foo)
(define-key minibuffer-local-completion-map [(control ?=)] 'foo)
(defun toto () \\{minibuffer-local-completion-map} 4)
C-h f toto shows a duplicate entry for C-=:
toto is a Lisp function.
(toto)
key binding
--- ---
C-g abort-recursive-edit
TAB minibuffer-complete
C-j exit-minibuffer
RET exit-minibuffer
ESC Prefix Command
SPC minibuffer-complete-word
? minibuffer-completion-help
C-= foo
C-= foo
...
Only a single C-= entry is present in Emacs 20 and Emacs 21.
In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600)
of 2007-03-21 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
variable `replace-count' should have a defvar
`replace-count' is bound in replace.el (e.g. replace-eval-replacement, replace-loop-through-replacements), but it is also referenced from functions that don't bind it. It should have a defvar. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: M-x grep in buffer *grep* puts you at the end of the grep output
From: Drew Adams Sent: Monday, December 11, 2006 3:21 PM Previously in Emacs 22, as well as in previous releases, , repeating grep in the *grep* buffer would put you at the top of the buffer. This was true at least as late as a build from 2006-07-19. Now, it puts you at the end of the buffer, so you must do M- to get back to the beginning. Quite annoying. This is still broken. Are there plans to fix this? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of compilation-next-error
Shouldn't the doc string mention what the return value is? At least one use of the function in the Emacs source code makes use of this value: (let* ((columns compilation-error-screen-columns) ; buffer's local value (last 1) (loc (compilation-next-error (or n 1) nil (or compilation-current-error compilation-messages-start (point-min (end-loc (nth 2 loc)) (marker (point-marker))) ...) In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No doc string for `read-number'
`read-number' should have a doc string. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
read-number: Ask again if error reading input
emacs -Q M-: (read-number : 5) Type (foo End of file during parsing Minor patch to `read-number': (cond ((zerop (length str)) default) ((stringp str) (read str))) (unless (numberp n)... Should be: (cond ((zerop (length str)) default) ((stringp str) (condition-case nil (read str) (error nil (unless (numberp n)... That way, if the user inputs something that causes a read error, s?he is just asked again, instead of getting an error message that s?he might not understand. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs manual node Query Replace needs cross ref to Unconditional Replace
Emacs manual node Query Replace says things such as this: Aside from querying, `query-replace' works just like `replace-string'. It preserves case, like `replace-string', provided `case-replace' is non-`nil', as it normally is. You cannot understand this text without knowing details about `replace-string', which is described in node Unconditional Replace. So, we need a cross reference to that node. Otherwise, we force users to search for `replace-string' or look it up in the index (`i'). In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Emacs manual node Query Replace needs cross ref to Unconditional Replace
Emacs manual node Query Replace says things such as this: Aside from querying, `query-replace' works just like `replace-string'. It preserves case, like `replace-string', provided `case-replace' is non-`nil', as it normally is. You cannot understand this text without knowing details about `replace-string', which is described in node Unconditional Replace. So, we need a cross reference to that node. Otherwise, we force users to search for `replace-string' or look it up in the index (`i'). In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 2. Furthermore, there is no discussion of case in node Unconditional Replace, which is the only node indexed for `replace-string'. 3. Actually, it looks as if the proper target for the missing cross reference (in both nodes mentioned) should be node Replacement and Case. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: C-u C-SPC: doc string and behavior if mark = point
3. A run-on sentence results from joining independent clauses (or sentences) without using any punctuation for the join. 4. Independent clauses joined using a comma, and without a conjunction, form a comma splice, not a run-on sentence. A semicolon should be used to join independent clauses (as you indicated), or the sentence should be split. I was taught a different definition. It's not important. My point was not that the sentence was grammatically incorrect. I thought it would be easier to read if split; that's all. FWIW: http://en.wikipedia.org/wiki/Run-on_sentence http://en.wikipedia.org/wiki/Comma_splice ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: C-u C-SPC: doc string and behavior if mark = point
Split the run-on sentence that starts With no prefix at ; also. That was not a run-on sentence. A semicolon is the correct way to join two independent clauses in one sentence. A run-on sentence is what results from using a comma for this. 1. It was just a suggestion. 2. I should have said long sentence, not run-on sentence. It's a judgment call whether a sentence should be split for readability. 3. A run-on sentence results from joining independent clauses (or sentences) without using any punctuation for the join. 4. Independent clauses joined using a comma, and without a conjunction, form a comma splice, not a run-on sentence. A semicolon should be used to join independent clauses (as you indicated), or the sentence should be split. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs manual node Query Replace should link to node Regexp Replace
Where it says this, it would be good to add a cross reference to node Replace Regexp: `C-M-%' performs regexp search and replace (`query-replace-regexp'). It works like `replace-regexp' except that it queries like `query-replace'. Otherwise, readers might not know where to find info about `replace-regexp'. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-b ug Recent messages: (C:\Emacs-22-2007-03-21\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: C-u C-SPC: doc string and behavior if mark = point
1. Doc string for `set-mark-command': Thanks, I implemented some of your suggestions. The new doc string appears at the end of this message. Get rid of e.g. C-u C-@. I don't see any reason to get rid of this, as it's a valuable advice to novices who could otherwise do something like M-1, which is much less convenient. Get rid of With a double C-u prefix argument, e.g. C-u C-u C-@; just say With `C-u C-u'. Ditto. Remove quotes around region. Remove , which is the closest thing Remove the paragraph about setting the region altogether (the region is not set). Just say The region is the buffer area between the mark and the cursor position. Some people call it the selection. Didn't change any of these, since I see nothing wrong with the current wording. - set-mark-command is an interactive compiled Lisp function in `simple.el'. It is bound to C-@, C-SPC. (set-mark-command arg) Set mark where point is, or jump to mark. Setting the mark also sets the region, which is the closest equivalent in Emacs to what some editors call the selection. With no prefix argument, set mark and push old mark position on local mark ring. Also, push mark on global mark ring if last mark was set in another buffer. Immediately repeating the command activates `transient-mark-mode' temporarily. With prefix argument (e.g., C-u C-@), jump to mark, and set mark from position popped off the local mark ring (this does not affect the global mark ring). Use C-x C-@ to jump to a mark popped off the global mark ring (see `pop-global-mark'). If `set-mark-command-repeat-pop' is non-nil, repeating the C-@ command with no prefix argument pops the next position off the local (or global) mark ring and jumps there. With a double C-u prefix argument (e.g., C-u C-u C-@), unconditionally set mark where point is, even if `set-mark-command-repeat-pop' is non-nil. Novice Emacs Lisp programmers often try to use the mark for the wrong purposes. See the documentation of `set-mark' for more information. Looks better. Thanks, Eli. You can drop the quote marks around region, but not around selection. `C-@' defines (sets, if you like) the region itself, not the word region. You can drop e.g., because `C-u C-u C-@' is not an example of a double prefix arg with C-@; it is the same thing as using a double prefix arg with [EMAIL PROTECTED] If you want, you can use i.e. or, better, that is, but neither is needed here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C-u C-SPC: doc string and behavior if mark = point
1. Doc string for `set-mark-command': Set mark at where point is... Should be Set mark at point... or Set mark where the cursor is... Point is a position, and at where is not correct English. Split the run-on sentence that starts With no prefix at ; also. Get rid of e.g. C-u C-@. Argument and prefix alone should be prefix argument everywhere. Don't speak of a new position for mark. The mark is a (marked) position, as far as users are concerned (yes, it also has buffer info). Point and mark in the doc should stand for buffer positions, not what is at those positions (e.g. the cursor). Get rid of With a double C-u prefix argument, e.g. C-u C-u C-@; just say With `C-u C-u'. Remove quotes around region. Remove , which is the closest thing Remove the paragraph about setting the region altogether (the region is not set). Just say The region is the buffer area between the mark and the cursor position. Some people call it the selection. 2. In a buffer in which there is no mark, `C-u C-SPC' gives the error No mark set in this buffer. When point /= mark, the user sees the cursor move. But when point = mark, there is no feedback. As an enhancement, perhaps it would help to provide a message when mark = point: Mark removed at point. I don't know if this is a good idea, but it can be disorienting when Emacs provides no feedback that an action took place. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc of text-properties-at needs to be clarified
Doc string: Return the list of properties of the character at POSITION in OBJECT list of properties is misleading here. One might easily think that the value would be a simple list of the text properties at that position (e.g (face category display)), whereas it is a property list of such text properties and their values. That is, the list includes both the text properties and their values. Elisp manual: This function returns the entire property list of the character at POSITION in the string or buffer OBJECT. If OBJECT is `nil', it defaults to the current buffer. This is much better. However, this (like the doc string), never mentions that the properties in the returned property list are text properties. Property list of the character is not a good way to describe this, because we don't usually think of characters as having property lists. Symbols have property lists (and there are disembodied property lists); characters have text properties, which have values. This is a list that has the form of a property list, and it is composed of the character's text properties with their values. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: get-lru-window should mention what lru stands for
Presumably, lru stands for least recently used. That should be mentioned in the doc string, to avoid confusion. (We should still say that used means selected.) get-lru-window is a built-in function in `C source code'. Return the window least recently selected or used for display. I don't think it could be much clearer. It's clear what the function does, but what lru stands for is not stated. Either that acronym should be defined or the function should be renamed (e.g. `get-least-recently-selected-window', or just `least-recent-window'). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of indent-to should mention the return value
`indent-to' returns the column. I've seen code that depends upon this feature. The doc string doesn't mention the return value, but the Elisp manual does. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
completion-setup-function shouldn't set default-directory to nil
I ran into some problems, but I'm not sure if this is the cause, and I can't give a recipe to reproduce the problems. I wonder whether this code at the beginning of `completion-setup-function': (if minibuffer-completing-file-name (with-current-buffer mainbuf (setq default-directory (file-name-directory mbuf-contents shouldn't perhaps be more like this, to avoid setting default-directory to nil: (when (and minibuffer-completing-file-name (file-name-directory mbuf-contents)) (with-current-buffer mainbuf (setq default-directory (file-name-directory mbuf-contents In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: completion-setup-function shouldn't set default-directory to nil
(when (and minibuffer-completing-file-name (file-name-directory mbuf-contents)) (with-current-buffer mainbuf (setq default-directory (file-name-directory mbuf-contents Or rather (when minibuffer-completing-file-name (with-current-buffer mainbuf (setq default-directory (file-name-directory (expand-file-name mbuf-contents) I don't know about that. Perhaps you're right. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
unclear doc for existence of mark
emacs -Q C-h i, choose Elisp manual, g Mark This text is not clear: Each buffer has its own value of the mark that is independent of the value of the mark in other buffers. When a buffer is created, the mark exists but does not point anywhere. We consider this state as the absence of a mark in that buffer. Once the mark exists in a buffer, it normally never ceases to exist. The notion of mark existence is unclear here. In a virgin buffer, it says, the mark exists. Yet, in this state the mark is absent. So, the last sentence presumably wants to talk about lack of absence (i.e. presence), rather than existence. Otherwise, it contradicts the first statement that the mark exists from the beginning, as well as its own statement that the mark never ceases to exist (if it has always existed and it always will exist, then once the mark 'exists' says nothing useful. The first statement, that the mark exists from the beginning but points nowhere, could be kept as the consistent point of view throughout, but that is not currently the case. In that case, instead of absence and then, later, existence (presence), we would speak of the mark pointing nowhere and then pointing somewhere. Alternatively, the starting point of the explanation could be changed, to say that in the beginning the mark does not exist. The rest would follow more or less as is, with non-existence/existence replacing absence/presence (no need for two terms, which increases confusion). Either of these approaches would be consistent; the current text is not consistent, and is confusing. My own preference is the second alternative: Don't say that the mark exists from the beginning. We might want to introduce the function `mark' here, saying that when (mark t) returns nil it means that the mark does not yet exist - that is, it indicates that virgin state. Also, quotation marks should not be used in this text, in any case - they add nothing but more confusion. New terms that are defined can be put in a different font (e.g. bold), but should not be between quotation marks. I don't know what the Emacs doc convention is on this. In any case, even if the Emacs doc convention were to quote the defining occurrence of a new term, the sections quoted here should not be quoted. In that case, only absence would be quoted. Certainly, exists should not be quoted in the last sentence cited. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu re port-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
I don't think this a real life problem that is worth making the code less readable over. I agree. There are more simple solutions. Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) Check the current code. It's a mix of the two. I changed it not because of any web server/client issue, but simply because the resulting code is more readable. Yes, thank you. That's in fact what I meant. It helps that the two characters appear different, and the comment makes it clear what the intention is. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character in buff-menu.el
Complete disagreement. The coding system is clearly written in the -*- coding -*- tag, so there's no ambiguity, Does this mean that even when the text gets garbled by those browsers it will still be decoded correctly when the resulting file is visited in Emacs? Yes. Stefan On that, I definitely disagree. My experience proves the contrary. I suppose it depends what is meant by text gets garbled by those browsers. What I see is that the characters are themselves changed in the file, and the coding tag therefore has no way of recuperating; it cannot know what characters were intended originally. You have only to download the file from http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/ to see what I mean. Save it directly to disk and then open it in Emacs (22). I don't know whether this represents a browser problem or a Web site problem, however. I used the most common browser (still), IE6. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. However it is that the characters got messed up (Web site, browser, user error, cosmic rays, CIA, Al Qaeda), there is no reason not to use the escape sequence, for portability and better code legibility. I did it twice with two different methods: . Clicked the download link and saved the file to disk. . Clicked the view link; then, after seeing that the Unicode characters are displayed incorrectly, clicked View-Encoding from the menu bar, selected Unicode UTF-8, which fixed the display; then File-Save As, selected Text files and made sure the encoding is set to UTF-8; clicked OK. Both methods gave me a valid UTF-8 encoded file that displayed correctly in Emacs 22. I used the view link, clicking mouse-1 on it, because I wanted to look at the code before saving it. I did not scan the entire file to notice that two of the characters were displayed incorrectly, so I did not change my browser encoding - after all, this is code, which displays as plain text. And how would one know that those two characters were in fact displayed incorrectly? How would you know what they were supposed to be? Did you read all of the code comments, and analyze the code, to come to the conclusion that the browser encoding for those two characters was incorrect? Or did you in fact know just what to look for, because you had read my bug report? That's cheating ;-). Or did you notice the -*- coding: utf-8 -*- in the header, and realize that your current browser encoding didn't correspond to that? You said, however, that you noticed that the (two) Unicode characters were displayed incorrectly - a much harder thing to spot. Some other methods a user might use to try to retrieve the code: - Right-click the download link, and use Save As (as I assume you meant by clicked the 'download' link). Here, you can Save as type All Files. This works. - Right-click the view link, use Save Target As, and Save as type All Files, changing the suffix to el. For some reason, this does nothing, for me - no file is saved. - Click mouse-1 on the download link, and use Save As. This does default to the Unicode encoding, but, at least in my IE6 browser, there is no filter option for All Files at that point, and you must choose Save as type Text File (*.txt) (the other options involving saving as HTML pages). When I open the resulting file in Emacs 22, C-h C shows raw-text-unix, not Unicode, and the buffer is filled with null bytes (^@) - every other byte. C-x RET r utf-8 does not change what I see. The -*- coding never takes effect because each of its characters is preceded by a null character. There are multiple ways a user might try to retrieve this code from that site, and there will be other sites that also offer the code, perhaps in other ways. As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. You might not care about the Emacs Wiki, but you might care that such a problem exists there, because other sites might present similar problems. The real point is that there is no good reason *not* to use the escape sequence in this case, and there are good reasons to use it: easier file exchange using email and Internet, and better code legibility. The only reason given so far not to use the escape sequence was code legibility, and I pointed out that the code is in fact less legible without the escape sequence, because the em-dash and hyphen characters are indistinguishable in a fixed font. They both appear as ?-, making it impossible to tell which is which (without a comment). This seems a no-brainer, to me. Further resistance to using the escape sequence in this case seems to me to reflect only unwillingness to see the obvious. If, on the other hand, your concern was the Web site and how to ensure that users download Unicode code correctly, then I share that concern. You might want to include explicit instructions for how to download, and explicit mention that view of code that includes Unicode characters might require that you change your browser encoding to Unicode. Or something like that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? Dunno. Perhaps it has to do with the scripts used on the Wiki. The problem here is more general than Unicode, in fact. For example, it also strips out control characters (e.g. ^L) inserted in the code. In one library, for instance, I use escape sequences instead of embedded ^G and ^J characters. However, the loss of ^L page separators is regrettable. You can upload a file to the wiki using the alternative method, instead of editing a wiki page, and in that case there is no problem. But in that case there is also no syntactic highlighting of the code on the page. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. [] Well, you did say I don't know whether this represents a browser problem or a Web site problem, however. All I did was try to help you find out what went wrong. No good deed goes unpunished, sigh... It was not clear to me that that was all you were doing. It seemed to me that you were also arguing that the real problem was browser, Web site, or user error, not the file contents, and that therefore the file need not be fixed. This was the main point of my last message: What went wrong in downloading the file is not the real point of my bug report. I would like the file itself to be fixed, so that no such problem can possibly arise, regardless of how the file might be downloaded. Yes, a possible problem with the Web site is a secondary concern. It was not obvious to me that you were not also arguing for not fixing the file. So, I argued again for fixing it, and I argued that Web site or user error is not a good reason not to fix the bug. It did occur to me that you might *only* be trying to help find out what went wrong, which is why I also wrote If, on the other hand, your concern was the site and how to ensure that users download Unicode code correctly, then I share that concern... I tried to understand your intent and your message, but I was not sure what your point was. My main concern is the file's Unicode characters. Arguments against fixing the file are the first thing I wanted to rebut. And my interpretation #1 of your response was that you were essentially saying that the real problem is one of correctly downloading the file: just download correctly; no need to fix the file. Not knowing quite what you meant, I tried to reply to both of my interpretations of your good deed, with priority to what I think is most important: fixing the file. If you had made it clear that you supported fixing the file and you were only offering help to find out what went wrong with the download, then I wouldn't have said anything about interpretation #1. Sorry if I misunderstood you. I was only trying to separate the bug report from a possible Web-page download problem. No good deed goes unpunished, it seems... ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. I didn't think so, but I just made a test on the wiki, and I think you are probably right. I was able to insert Unicode characters in a new lisp-file page, and they were retained properly after saving - so what I said before is apparently wrong. I don't know if there was a change to the wiki recently or if this was always the case. I do know that, with the same browser and the same browser encoding, I ran into a problem before, but perhaps it was something I did. FWIW, I just noticed that my browser is set to Unicode for the encoding, and it was when I picked up the file with the broken characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character in buff-menu.el
Hmm... I skipped straight to the general argument, with which I eindeed strongly disagree, but in the specific case of buff-menu.el, I believe you're right: the \u escape would be better. Thanks. And sorry for the long-winded argument. I suspect we actually agree about the general case, as well: when Unicode is important for the library in question, it makes sense to use it in the code. And in a few years, avoiding Unicode won't make so much sense in any case. For now, there are still lots of tools around that are not very Unicode-friendly. Thx - Drew ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
list-buffers-noselect: `when' should be `and'
`when' should be `and' in this code, for clarity. I don't think this has an effect on functioning, but `when' should generally not be used when its value is important, as in this case. Here, the return value is an argument to function `buffer-list'. (dolist (buffer (or buffer-list (buffer-list (when Buffer-menu-use-frame-buffer-list (selected-frame) ...) In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
please use ?\u2014 instead of the unicode character in buff-menu.el
Downloading buff-menu.el from http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/, at least in some common Web browsers, leads to incorrect characters in the code. This problem goes away if you use the escape sequence ?\u2014 instead of embedding the equivalent unicode character in the source file. IMO, this should be the standard practice for such characters in the source code: use escape sequences. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character in buff-menu.el
Downloading buff-menu.el from http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/, at least in some common Web browsers, leads to incorrect characters in the code. This problem goes away if you use the escape sequence ?\u2014 instead of embedding the equivalent unicode character in the source file. Complete disagreement. The coding system is clearly written in the -*- coding -*- tag, so there's no ambiguity, and seeing the actual char rather than some arcane escape sequence for it makes the code more readable. IMO, this should be the standard practice for such characters in the source code: use escape sequences. 100% disagreement. The coding system is written in the -*- coding tag. Fine. But if the character in the file, as pulled from the Web, is wrong, then the -*- coding tag doesn't help. The coding tag is for use inside Emacs; it doesn't help outside Emacs. What I'm referring to is the ability to pass the file around the Web and via email easily, as will be done - as is already being done. The escape sequence is perfect for that; it allows for plain ASCII communication. Tools such as scripts and wikis that might, today at least, choke on some characters, are perfectly happy to handle the string of ASCII characters ?\u2014. I first noticed this problem with a minor enhancement that I use for this same file. On Emacs Wiki, the Unicode em dash is not transferred correctly, so my enhancement code was broken, simply by uploading or downloading. Sure, it's the fault of the wiki scripts or the browser or my local system's language support, but so what? I didn't report the problem at that time (a year or so ago), figuring that you folks might not care much about code exchange via Emacs Wiki. I reported the problem only when I ran into it again, but this time at http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/. I expected you might care about that. It's a general problem, and I see no reason why GNU wouldn't want to maximize the ease of communication and exchange of its code by using ASCII - when possible and other things being equal. In this case, in particular, nothing special is gained by resisting using the escape sequence, and something is lost by not using it - lots of people will be unable to use the code, and many will not figure out why or how to correct the problem. For a library that deals heavily in Unicode characters, and for which the legibility of the code itself would be hampered by using escape sequences, I would agree with you - no reason to deprive the code of legibility, when it really matters. But for a library like buff-menu.el, for which the use of Unicode is completely incidental (only to simulate underlining when the header line is not used - not even the default case), I think the library is shooting itself in the foot. It could even be argued that it was silly to use em-dash characters for this in the first place. It is all the more silly to reduce the transfer and exchange of the code, just for the sake of showing two em dash characters in the code. We're not even talking about a string of em-dash characters, to show a visible line in the code; we're talking about an isolated character: ?- (but with an em dash, not a hyphen). Here's how it appears in the code on http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/, as shown by my browser: (if (char-displayable-p ?a?) ?a? ?-))). So much for legibility and WYSIWYG, but more importantly, that code is broken: the em-dash character has been replaced in the code by stuff that makes it impossible to even load the library. This is the fault of the Web site or the browser (in my case, IE6) or the language support on the user's machine, perhaps, but it is Emacs and Emacs users that suffer, IMO. Why make users jump through hoops, just so we can show off that we can now put a Unicode character in an Emacs library? We go to incredible lengths in Emacs to make sure that Emacs still works without a window manager, on slow machines, over slow connections, without colors, and so on. There are many, many more people and tools that will not be able to digest this single Unicode character than there are users with such limited hardware, to whom we (rightfully) still cater. Please humor those of us who aren't yet 100% Unicode-able, at least when the cost is trivial, as it is in buff-menu.el. Anyway, you will do as you like. I'm just letting you know that fewer people and fewer Web sites will digest this file easily, because of those two em-dash characters and your refusal to use Emacs's fine escape sequence mechanism. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character in buff-menu.el
One more argument - How many people use a proportional font to view Emacs-Lisp code? With a fixed font, the code is _less_ legible using the em-dash character than the escape sequence. Why? Because the difference between a normal hyphen character and an em-dash character in most fixed-width fonts is imperceptible. IOW, when the code is not broken because of Web access or browser problems, it looks pretty much like this: (let ((underline (if (char-displayable-p ?-) ?- ?-))) ... So much for legibility of the code, bis. Hence the big honkin comment: ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) So much for avoiding the nastiness of ?\u2014. U+2014 is much better... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of display-buffer: search?
The doc string of display-buffer makes no mention of searching for anything, and then suddenly it starts talking about where some unmentioned searching is carried out: If optional argument frame is `visible', search all visible frames. If frame is 0, search all visible and iconified frames. If frame is t, search all frames. If frame is a frame, search only that frame. If frame is nil, search only the selected frame (actually the last nonminibuffer frame), unless `pop-up-frames' or `display-buffer-reuse-frames' is non-nil, which means search visible and iconified frames. There is no explanation of what is being searched for on these various frames, or what the search is all about. Please clarify the language. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Elisp manual node Glyphs, typo
Normally glyph come from vectors - Normally glyphs come from vectors In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of window-display-table doesn't describe nil WINDOW
Doc string: Return the display-table that WINDOW is using. But WINDOW is optional. What if it is nil? In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Emacs manual node Specifying File Variables typo
This is the typo: _If `mode' is used to set a major mode should be
If `mode' is used to set a major mode.
No, this is not a typo, this is how the @emph markup is expressed in
Info files (which are almost plain ASCII files, and therefore cannot
use a slant font). Note that a matching `_' appears at the end of the
sentence.
The Texinfo source is:
@emph{If @code{mode} is used to set a major mode, it should be the
first ``variable'' in the list.}
I see. I didn't notice the closing _.
That seems like a bug, to me. The effect in Info is not to emphasize the
text in any way; rather, the _ characters appear there as extraneous
artefacts.
Perhaps the conversion to Info should simply strip (i.e. ignore) @emph.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Emacs manual node Specifying File Variables typo
This is the typo: _If `mode' is used to set a major mode should be If `mode' is used to set a major mode. Look at the whole sentence. It looks correct to me. Please see my reply to Eli. It has no place in Info, IMO. It does not indicate emphasis in any way in Info. It makes sense only if it is in fact rendered somehow as emphasis. So, currently it makes sense only in the printed manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Emacs manual node Specifying File Variables typo
That seems like a bug, to me. The effect in Info is not to emphasize the text in any way; rather, the _ characters appear there as extraneous artefacts. This is up to the Info reader; we could, for example, render the text inside _.._ as italics. That would be fine. Perhaps the conversion to Info should simply strip (i.e. ignore) @emph. This suggestion should go to the appropriate Texinfo mailing list (but I doubt that it will be accepted, since it loses information, and because this is what @emph produced since long ago). Btw, @strong is similarly converted to *..*. Same problem, IMO. I'm all for rendering @emph and @strong, but if we don't do that, I think it's unclear to just add _ and *. In practice, it works OK for short terms (esp without spaces), but you can see the problem when a long phrase is emphasized. That kind of markup is also better for email than for doc, IMO. Anyway, do what you think is best. I obviously was misled in this case, not noticing the other _ and so not thinking that I was seeing emphasis. Perhaps, in this case, if people don't want to tinker with the _ * convention, that particular passage should have the emphasis removed or confined to just a few choice words. If it is really important to emphasize a long sentence, it can be placed in a para of its own, and even indented, to draw attention to it. I don't think the _'s draw any attention to it at all. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc for try-completion etc. conflicts with doc for completing-read
Thanks. `test-completion' is in the same boat, BTW. Not AFAICS: it calls that argument ALIST, not TABLE. That's what I meant. It is in the same category as `try-completion' and `all-completions' - they all call it ALIST, not TABLE. But `test-completion' is only a problem if some other function which uses TABLE refers to it in the doc string. Are there any functions like that? Not now, but as I think I said, someone might decide to fix an existing doc string to make it more complete by referring also to `test-completion'. Anyway, your fix is fine for now, and it would be good to rename the arg consistently after the release. Thx. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No link to File Local Variables from Local Variables in Elisp manual
emacs -Q C-h i, choose Elisp manual `i' local variable, then `,' - you never get to anything about file local variables `i' file local shows no hits. Likewise, `i' file local variable In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs manual node Specifying File Variables typo
This is the typo: _If `mode' is used to set a major mode should be If `mode' is used to set a major mode. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Elisp manual Errors section of TOC needs link to Standard Errors node
emacs -Q In the Elisp manual, section Errors of the Detailed Node Listing on the first page (TOC menu) does not list node Standard Errors. It should. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Unused variable in mouse.el: make-cursor-line-fully-visible
mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? If so, perhaps add a comment indicating the reason. (_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: (when (and (functionp fun) (= start-hscroll (window-hscroll start-window)) (or end-point ... From: Drew Adams Sent: Saturday, January 27, 2007 9:01 AM mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
Also, there are multiple functions defined in mouse.el that have no doc strings. Some even have no comments that could substitute for doc strings. I think the mouse.el code could use a bit of cleaning up, generally. From: Drew Adams Sent: Saturday, January 27, 2007 9:15 AM Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? If so, perhaps add a comment indicating the reason. (_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: (when (and (functionp fun) (= start-hscroll (window-hscroll start-window)) (or end-point ... From: Drew Adams Sent: Saturday, January 27, 2007 9:01 AM mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
It is used in xdisp.c. For primitives written in C, having a Lisp binding for a variable that controls the behavior of the primitive is the way to go. I think the doc string of the variable goes a long way towards hinting that this variable _is_, in fact, used in the C code. So I'm curious why you thought it was unused. My bad. No coffee yet. I grepped for the variable without first trying `C-h v'! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? Looks like a witty way of calling a function inside a let* binding. I don't see why. I thought maybe point needed to be set at that point so that subsequent bindings would have the right value, but I don't see that being done - no subsequent binding examines (point), AFAICT. I suspect that at one time a subsequent binding tested point, and that value depended on point having been previously set by the `_' binding code. I don't see that this is the case now. Perhaps I'm missing something, however. Witty ways should generally be documented by comments. One person's clever! is another, later maintainer's huh?. Even naming the variable `ignored' instead of `_' improves readability (but still doesn't address the question raised). The bound variable is unused. Even if the function did in fact need to be called before subsequent bindings were made (which I don't see), the clean way to do that is with a nested `let'. If a single `let' is better for some reason for performance (or some other reason), then a comment is in order, explaining why such a witty binding is employed. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: Thanks, I fixed the whitespace. Thx. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc for try-completion etc. conflicts with doc for completing-read
The doc for `completing-read-multiple' refers you to the doc of `completing-read' for explanation of arg TABLE. Click the `completing-read' link. The doc for `completing-read' refers you to the doc for `try-completion' etc. for explanation of arg TABLE. Click the `try-completion' link. The doc for `try-completion' does not mention TABLE; it mentions ALIST. In sum, we send users to the doc of `try-completion' etc. for info about TABLE, but they cannot find its explanation there. Please change the doc of `try-completion' etc. to use TABLE, not ALIST, for consistency. Thanks. I didn't want to rename the argument so close to the release, so I added a few more words to the doc string of completing-read, and mentioned the fact that TABLE is called ALIST in try-completion and all-completions. Thanks. `test-completion' is in the same boat, BTW. Please make a note somewhere (e.g. TODO) that the right fix, after the release, is to rename the parameter to TABLE, in each of `try-completion', `test-completion', and `all-completions'. Today, `completing-read-multiple' refers to `completing-read' for an explanation of TABLE, so you need only tweak the doc of `completing-read'. But tomorrow someone might refer `completing-read-multiple' directly to `try-completion' or `test-completion' or `all-completions'. If that happens, the problem will resurface. IOW, if the fix is made where we send people elsewhere for the explanation, then it needs to be made everywhere we might do that. If the fix (renaming) is made at the target, not the source, then there is no such problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
emacs -Q Help Emacs Tutorial You see this, in red, at the top: NOTICE: The main purpose of the Emacs tutorial is to teach you the most important standard Emacs commands (key bindings). However, your Emacs has been customized by changing some of these basic editing commands, so it doesn't correspond to the tutorial. We have inserted colored notices where the altered commands have been introduced. [More] This is wrong - nothing has been customized in emacs -Q. The wording is also bad: standard Emacs commands are not the same thing as key bindings. So already we're teaching the vocabulary incorrectly. has been customized by changing some of these basic editing commands. Customizing a key binding doesn't change a command. The wording is not good. We have inserted colored notices sounds horrible too. Who's we? The user is just following a tutorial; it is only the tutorial that should be speaking to the user - there is no need of 1) the user, 2) the tutorial, and 3) some we who comments about modifications they made to the tutorial by inserting colored notices. If this doesn't appear to users to be an UGLY hack, then I don't know what would. If the idea is to adapt the tutorial so that it reflects the user's customized key bindings, then that is done poorly (or not at all). Similarly, if the idea is to mark all of the places in the tutorial that mention standard bindings that are not currently in effect because of customization. I really think this hack does more harm than good, at least the way it's done now. Just say that the tutorial reflects the standard Emacs bindings. That's all. We are trying to be too clever, and it hurts the user. Anyway... Clicking [More] then shows this: The following key bindings used in the tutorial had been changed from the Emacs default in the TUTORIAL (English) buffer: Key Standard BindingIs Now On Remark M-backspace backward-kill-word C-backspace more info backspace delete-backward-char DEL more info It is OK to change key bindings, but changed bindings do not correspond to what the tutorial says. This is also wrong: had been changed is incorrect grammatically here. Perhaps have was meant. What is the point of from the Emacs default in the TUTORIAL (English) buffer? Buffer? English? Why is TUTORIAL uppercase? I don't understand this sentence AT ALL. What are we trying to say here? And why are we telling the user that s?he can change bindings? (during the tutorial? in the future? in the past?) The help shown from clicking [More] is also not aligned well, as can be seen above. It is also unclear: What does Is Now On mean? What is now on what? Does it mean that the Standard Binding (command), which is the second column, is now on that key? The order seems backward (German? ;-)). The order should be: Command Current KeyStandard Key (emacs -Q) --- ------ backward-kill-word C-backspace M-backspace Or, better perhaps (depending on what the intention is - I'm lost): Key mentioned in tutorial Key in your Emacs Command - - --- M-backspace C-backspace backward-kill-word In any case, however this is done, it is bound to confuse. Another bug, unrelated to the tutorial: Clicking `delete-backward-char' does not show its binding (DEL). The doc string needs to mention this. Clicking either of the more info links leads to further incorrect information... Most importantly: Do we really need this? What is the point of scaring users with a huge red NOTICE, and inviting them to click for more information that details ALL of the bindings that are different from the default bindings. (Not to mention that it does so erroneously.) This is crazy. This is the FIRST thing that a newbie will see, when trying to learn about Emacs. It sends only one message: You will never understand Emacs. It is far too difficult for you to learn. You can't even figure out what we're trying to say about customized bindings. What a dummy you are - move along. Please, let's drop this or redo it completely. If we keep it, it needs to be 1) simple, 2) unalarming, 3) obviously of secondary importance. A tutorial should hold you by the hand in the beginning, not scare and confuse you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc for try-completion etc. conflicts with doc for completing-read
Thanks. `test-completion' is in the same boat, BTW. Not AFAICS: it calls that argument ALIST, not TABLE. That's what I meant. It is in the same category as `try-completion' and `all-completions' - they all call it ALIST, not TABLE. IOW, if the fix is made where we send people elsewhere for the explanation, then it needs to be made everywhere we might do that. If the fix (renaming) is made at the target, not the source, then there is no such problem. I generally don't like sending people to read doc strings of other symbols at all, so if it were up to me, I'd just spill everything about TABLE and PREDICATE into each function that calls the low-level primitives. But the explanations are very long, so I will let Richard decide. I know that you're trying to make a quick and unrisky fix for this release. That is fine. I was only mentioning the rest for the future. Thanks for the fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
(_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. It's probably my code, influenced by my SML hacking. In Prolog, Haskell, SML, (and probably all other ML dialects and many logic programming languages) _ is a special variable used as here, to ignore arguments or return values. Yes, I'm used to it in Prolog and Haskell. I don't see why any variable should be bound here, however, anonymous or not. It is no doubt compiled away, but I think the code is a bit less clear. It's not a big deal, though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
Could you please propose a better text? As I said, I prefer that we not use this. I think it has a negative effect. I am not quite sure had is incorrect here. The state of the TUTORIAL buffer may have changed since the link was created. Is not had the correct word then? Or how would you say it? I wouldn't say it. I would just say something generic, without trying to determine whether the user had actually customized Emacs. Something short and simple, such as this: Keys mentioned in this tutorial are those defined by default. If Emacs has been customized, then some keys might differ from those mentioned here. If you want to use the tutorial with the standard Emacs keys, then start Emacs again using `emacs -Q'. IOW, YMMV. This need not be in red, and it need not be the very first thing the user reads. It should not be. Put it after the first place where the tutorial asks you to use a key, as a footnote. YMMV belongs in the fine print (more or less). These text should only be showed if some of the key bindings used in the tutorial have been changed. In other words they are only showed when the tutorial does not work. I don't agree that that is worthwhile. Just let users know that the tutorial is written for standard (i.e. default) Emacs bindings. That's all. The tutorial should not (IMO) be mostly about teaching keys, anyway. If it is, then that's a mistake. Keys are only a means to Emacs functionalities; we shouldn't concentrate too much on them. Users can learn Emacs using emacs -Q, and they can then learn different bindings afterward, if need be, for their customized version. We discussed what to do in this case earlier. We decided then that the best way to handle it was to tell the user about the problem. Other alternatives was to refuse to run the tutorial or to change the key bindings in the tutorial buffer so that they matched the tutorial. I think the cure is worse than the disease. There is no reason to refuse to run the tutorial or to try to adapt it. Just let users know that it assumes standard (default) bindings. Keep it simple. Users should get the same behavior each time they use the tutorial, whether with customized or vanilla Emacs - any other behavior is confusing. Referential transparency and all... Some more work can be done on this. It fails with very long names if I remember correctly now. But I felt this was good enough. It's not needed. I don't think users who have customized versions of Emacs really need to be told just which bindings have changed. It's true that some of the tutorial won't work or even make sense to them without knowing which keys to use, but it should be clear that they can always use the tutorial with emacs -Q. We don't need to make the tutorial work for customized bindings. I am not sure what is best. Of your proposals I like the first one best. What do others think? None of them are needed. I shouldn't even have mentioned them. My point was that what is there now is harmful, because confusing (and scary). Another bug, unrelated to the tutorial: Clicking `delete-backward-char' does not show its binding (DEL). The doc string needs to mention this. This is disturbing but maybe a bit hard to fix right now. I would rather put that in TO-DO for after the release. `delete-backward-char' is a built-in function. It should be possible to fix this detail. (Again, it has nothing to do with the tutorial.) Most importantly: Do we really need this? Yes, I believe we need it. The idea is simply to tell the user let the user run the tutorial even though some things have changed, but inform the user what has changed. I think without this the user may get very confused when the tutorial does not work. The confusion is 100x now. I see no need for the user to run the tutorial using customized bindings. If you could automatically adapt the entire tutorial to reflect the user's bindings perfectly, then I guess it could be OK (but see above, about same, repeated behavior). However, that is too difficult, and any half measure is worse than none at all. Whether this is the best way to handle the problem with changed key bindings that affects the tutorial is another question (see above). That's the question. My answer is No. This is crazy. This is the FIRST thing that a newbie will see, when trying to learn about Emacs. If no key bindings have been changed the user will not see this. (When the bug has been fixed.) That bug really needs to be fixed, at a minimum. Right now, we're scaring 100% of the people who try the tutorial 100% of the time. Messing their minds, to no good end. Please, let's drop this or redo it completely. If we keep it, it needs to be 1) simple, 2) unalarming, 3) obviously of secondary importance. A tutorial should hold you by the hand in the beginning, not scare and confuse you. IMO this is the wrong level to discuss it on. We should rather discuss the GUI instead and how that can be
read-face-name PROMPT arg should be self-contained, including :
emacs -Q `read-face-name' has changed the meaning and behavior of its PROMPT arg since Emacs 20, and it is now unconventional, conflicting with standard Emacs treatment of PROMPT args. It should not append : . Instead, calling functions should do that themselves as they deem appropriate. This change was made in Emacs 21, but it is not a good change. It is presumably an attempt to be smart, but it reduces flexibility for calling functions. `read-face-name' should treat its PROMPT arg the same way that other Emacs prompting functions, such as `completing-read', treat their PROMPT args. Furthermore, there are several prompts used in calls to `read-face-name' in library `faces.el' that are non-standard and non-English: all of those that begin with Make which face. In these cases, the final prompt reads like this: Make which face bold: or Make which face bold (default font-lock-function-name-face): You might say that every prompt is an implicit question: the program is asking the user for input. However, it is really a request, not a question, and the proper mode for most prompts is the imperative, not the interrogative. Usually, therefore, a prompt is expressed imperatively. Confirmation questions (e.g. `y-or-n-p') are a notable exception, where the point is to draw extra attention to a user choice. In any case, whenever a prompt is expressed as an explicit question, for whatever reason, it needs to be followed by a question mark (`?'). Obviously, with the automatic appending of : here, it would have been inappropriate to include the question mark also: Make which face bold?: . The implementation thus ends up distorting the punctuation to be used. The proper fix, however is not to use a question at all here. Conventional, and better, Emacs prompts for this are imperative: Make face bold: or Make face bold (default font-lock-function-name-face): `read-face-name' has slowly progressed from Emacs 20 (where it didn't even have a doc string), but it is still not up to snuff. Please bring it up to the standard of `completing-read' by correcting this PROMPT bug and fixing the question prompts. There is at least one other function that is non-standard wrt tacking on : instead of expecting the PROMPT arg to include it if needed: `bookmark-completing-read'. This problem should be fixed for `bookmark-completing-read' also. It's better to leave : to the calling function. In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2006-12-30 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2006-12-30\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc for try-completion etc. conflicts with doc for completing-read
emacs -Q C-h f completing-read-multiple The doc for `completing-read-multiple' refers you to the doc of `completing-read' for explanation of arg TABLE. Click the `completing-read' link. The doc for `completing-read' refers you to the doc for `try-completion' etc. for explanation of arg TABLE. Click the `try-completion' link. The doc for `try-completion' does not mention TABLE; it mentions ALIST. In sum, we send users to the doc of `try-completion' etc. for info about TABLE, but they cannot find its explanation there. Please change the doc of `try-completion' etc. to use TABLE, not ALIST, for consistency. In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2006-12-30 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu re port-emacs-bug Recent messages: (C:\Emacs-22-2006-12-30\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: describe-mode problem if called with minibuffer window selected
I recall fixing something like this a few weeks ago. Yes, I just picked up a build from Dec 30, and it is fixed in that build. Thx. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
describe-mode problem if called with minibuffer window selected
Not sure if it is describe-mode that needs to be fixed or fill-paragraph. emacs -Q M-: (progn (select-window (minibuffer-window)) (describe-mode *Help*)) Produces this backtrace: Debugger entered--Lisp error: (error Lisp nesting exceeds `max-lisp-eval-depth') (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function (and ... ...)) (let (... ... fill-paragraph-function) (funcall function arg))) (or (and (or fill-paragraph-function ...) (let ... ...)) (and fill-paragraph-handle-comment comment-start (equal comment-end ) (let ... ...)) (let (... ... fill-pfx) (when ... ...) (save-excursion ... ...) fill-pfx)) fill-paragraph(nil) (save-restriction (narrow-to-region (minibuffer-prompt-end) (point-max)) (fill-paragraph arg)) fill-minibuffer-function(nil) funcall(fill-minibuffer-function nil) (let ((function ...) (fill-paragraph-handle-comment nil) fill-paragraph-function) (funcall function arg)) (and (or fill-paragraph-function
RE: iswitchb-mode and iswitchb-global-map
1. Shouldn't `iswitchb-global-map' be renamed `iswitchb-mode-map'? Wouldn't that better follow the minor-mode naming convention? Yes, but iswitchb-mode-map is already used for something else, so it would be an incompatible change. I see. I didn't know that. Is that map perhaps for a local version of the minor mode? That is, are there two different maps, one for global use and one for local use? I'm just curious - this is new to me. If so, is there a naming convention for that, or should there be one? How about `iswitch-global-mode-map', instead, to signal that a (minor) mode is involved? 2. Shouldn't `iswitchb-global-map' be redefined anew each time `iswitchb-mode' is turned on? Kind of, yes. I've changed the code to use command remapping instead to get the same kind of result. I'm interested, so I'll take a look when I get a chance. Perhaps a similar approach would be useful for my code as well. I guess perhaps you mean that you used remapping in place of substitute-key-definition. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: iswitchb-mode and iswitchb-global-map
2. Shouldn't `iswitchb-global-map' be redefined anew each time `iswitchb-mode' is turned on? Kind of, yes. I've changed the code to use command remapping instead to get the same kind of result. I haven't yet given it a try, but I took a quick look at the code. Since there is no remapping equivalent of the 4th arg to substitute-key-definition, I suppose that the code now captures whatever the current bindings of `switch-to-buffer' etc. are, instead of capturing only their `global-map' bindings. Is that correct? Maybe that would be a good thing (better), maybe not. I'm not sure - I guess so. The behavior would be different from before, in any case. Now, the bindings set up might be different, depending on what they are when the mode is turned on. Am I right that the remapping will cause (part of) `iswitchb-global-map' to be redefined anew each time its keys are looked up? That's even better than renewing it each time `iswitchb-mode' is turned on, which was what I proposed (#2). I'm not too sure how command remapping works. The map is created only once here, and put onto `minor-mode-map-alist' once and for all, as before. But, IIUC, the bindings for this in the map are remappings, which are essentially dynamic bindings. That is, the map itself is static and isn't updated each time the mode is entered (as I had suggested), but those bindings are always calculated dynamically, by remapping. If that's how it works, that's pretty cool. I hadn't thought about remapping that way before: the binding takes place at the time of key lookup. Very late binding binding ;-). Another difference from my idea of updating `minor-mode-map-alist' each time the mode is turned on, and using `substitute-key-definition' with `global-map', comes from the fact that remapping only works through a single level. I'm not sure what that would mean in practice, if two or more modes remap the same commands. Precedence in `minor-mode-map-alist' is what counts, so there would be a difference in behavior, in any case. My approach of deleting and reinserting the map in `minor-mode-map-alist' would give users some flexibility when dealing with dueling minor modes: they could turn two modes on in a particular order to choose which one grabs contested bindings. Command remapping doesn't allow that, by itself; to get that effect, I think you would still need to dynamically change the order of `minor-mode-map-alist'. Let me know if this makes no sense or I'm missing something. It's late and I'm tired. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: shouldn't customize-save-variable raise an error if var is not anoption?
I don't know the answer, because I don't know if `customize-save-variable' is intended to work by program on variables that have not yet been declared using defcustom. I can't find any doc that speaks to this. I don't know. However, given that `customize-variable' will operate (if you force it to) on a variable defined thus (defvar foo45 nil *Foo you) and does allow saving a value for that variable, I guess it is reasonable that `customize-save-variable' also allows that variable. I wasn't aware that `customize-option' would do that. What you say makes sense, in that case. I have always thought that there are user options, which are customizable variables, defined by defcustom, and there are additional, non-option (i.e. not customizable) variables that you can set via `set-variable' but you cannot customize: those whose doc strings start with *. I expected that both `customize-option' and `customize-save-variable' would be reserved for options, that is, for variables that are in fact customizable (using Customize), and I didn't think that applied to all variables whose doc string begins with *. I think that the fact that you can customize all variables that you can set with set-variable must be new with Emacs 22. I do not see any bugs in what you described. I was afraid that the option created might not be a full-fledged option, and that that might lead to some problems (unknown to me) down the road. I guess that your do not see any bugs reply means that there is nothing to worry about? The effect seems to be, in fact, to create an option, just as if defcustom had been used. I am not sure if everything needed is done, however. If not, isn't it misleading for a non-option variable to have values for the properties `saved-value', `variable-comment', and `saved-variable-comment'? Might some programs that examine such properties not be misled by this? Similarly, does it make sense for the variable to be saved with the value to the user's custom file? Maybe, maybe not, depending on what the design intends, and whether the result of calling `customize-save-variable' is an option in all aspects. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
iswitchb-mode and iswitchb-global-map
I think these are both bugs, but you might not think so. You might want to think them over, in any case. 1. Shouldn't `iswitchb-global-map' be renamed `iswitchb-mode-map'? Wouldn't that better follow the minor-mode naming convention? 2. Shouldn't `iswitchb-global-map' be redefined anew each time `iswitchb-mode' is turned on? I say this because it uses `substitute-key-definition'. New global bindings for the commands in question (e.g. `switch-to-buffer') will not be taken into account, otherwise. This has an impact in two ways: 1) If `switch-to-buffer' is later bound globally to something different from `C-x b' (an additional binding or a substituted binding), then that binding won't be picked up when `iswitchb-mode' is re-entered later. 2) If some other command is later bound to `C-x b', even if `iswitch-mode' is re-entered later than that, `iswitch-mode' will still co-opt `C-x b' (I think it should not, in that case). In one of my own libraries, the minor mode function, `icicle-mode', unbinds the mode-map variable, `icicle-mode-map', whenever the mode is turned off. Whenever the mode is turned on, `icicle-mode' calls a function that does the following. Shouldn't `iswitchb-mode' do something similar (because it too uses `substitute-key-definition')? a. Delete `icicle-mode's entry from `minor-mode-map-alist' (if present from previously turning on the mode). b. Define `icicle-mode-map' from scratch. Like the code that defines `iswitchb-global-map', this code uses `substitute-key-definition' for `switch-to-buffer': (substitute-key-definition 'switch-to-buffer 'icicle-buffer icicle-mode-map (current-global-map)) c. Add the mode entry to `minor-mode-map-alist' (this is thus done anew each time the mode is turned on). In effect, this is all just a way to render the minor-mode map definition dynamic. Because the mode map is defined using `substitute-key-definition', I want the bindings to reflect the latest state of the global keymap. I wish there were an easier way to do this. I wish, for instance, that you could just provide, as the cdr of an entry to `minor-mode-map-alist', an expression to be evaled to a keymap value, or perhaps a function that is called to return a keymap value. That's not possible today, IIUC: you must provide, as the cdr, a literal keymap or a symbol whose symbol-function is a keymap (the function cell is looked up; the function is not called). I'd like that expression to be evaled, or that function to be called, whenever the mode is turned on. If that were not practical, it could be evaled/called each time `minor-mode-map-alist' were consulted for a key lookup. In that case, the expression or function would then need to determine if it needed to refresh the map (i.e. if the mode was just entered). BTW, something I don't understand, and don't see documented: Does `define-minor-mode' somehow add an entry to `minor-mode-map-alist'? Looking at the `iswitchb-mode' code, I don't see where that is done there. Yet the entry (iswitchb-mode . iswitchb-global-map) is nevertheless present in `minor-mode-map-alist'. I'm wondering what code put it there? I looked at the `define-minor-mode' macro definition too, but I didn't see anything that updated `minor-mode-map-alist'. It's a mystery to me. I wonder if others are also confused about this and think, like I was thinking, that a minor-mode definition must itself push the mode entry onto `minor-mode-map-alist'. Perhaps the doc should say something about this not being necessary, because it happens automatically. But how does it happen? In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Elisp manual node Active Keymaps: above is dangling ref
I've updated this. Thanks. thanks ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Elisp manual node Active Keymaps: above is dangling ref
emacs -Q C-h i; pick Elisp manual Node Active Keymaps contains this sentence: The argument ACCEPT-DEFAULTS controls checking for default bindings, as in `lookup-key' (above). There is no (above): `lookup-key' is not mentioned in this node prior to this. A real cross reference to the correct node is needed. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo down-mouse-1 mouse-1 C-h i help-echo help-echo help-echo help-echo help-echo help-echo help-echo down-mouse-2 mouse-2 help-echo help-echo help-echo down-mouse-1 mouse-1 g s backspace a c t i v e SPC k e y m return C-s a b o v e C-a help-echo help-echo help-echo help-echo help-echo down-mouse-1 mouse-1 C-s C-w C-w C-g C-g C-s C-w - k e y C-r C-r C-g C-g help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading regexp-opt...done Loading dired...done 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...done Mark saved where search started Quit [3 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
make-frame doesn't create frame parameters it is passed
emacs -Q 1. make-frame does not respect frame parameters that are not known: (make-frame '((foo . 45))) The manual seems to support this, saying: The set of possible parameters depends in principle on what kind of window system Emacs uses to display its frames. *Note Window Frame Parameters::, for documentation of individual parameters you can specify. Why doesn't make-frame just create all parameters you give it? Programs can add any parameters they want using modify-frame-parameters, so why are only some parameters respected by make-frame? 2. In particular, if you want to add a frame-local variable, you can't just do this: (make-frame-local-variable 'foo) (make-frame '((foo . 45)...)); with lots of other frame parameters. Instead, you must do something like this: (make-frame-local-variable 'foo) (modify-frame-parameters (make-frame '(...)) ; with the other frame paramters '((foo . 45))) I'd call this non-respect of arbitrary frame parameters by make-frame a bug. If you don't agree, please consider my suggestion as an enhancement request: Change make-frame so that it adds all frame parameters the user specifies. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo switch-frame help-echo help-echo help-echo switch-frame help-echo down-mouse-1 mouse-movement mouse-1 down-mouse-1 mouse-1 return ( m o d i f y - f r a m e - p a r e m e backspace backspace backspace a m e t e r s SPC n i l SPC down-mouse-1 mouse-movement mouse-movement drag-mouse-1 down-mouse-2 mouse-2 down-mouse-1 mouse-1 C-d 5 5 5 C-e backspace ) C-x C-e down M-x p p - e v a l - l a s t return help-echo down-mouse-1 mouse-1 down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Mark set foo #frame [EMAIL PROTECTED] 0x140fa00 ((parent-id) (display . ) (visibility . t) (icon-name) (window-id . 2426810) (top . 116) (left . 88) (buffer-list #buffer *scratch* #buffer *Minibuf-1*) (unsplittable) (minibuffer . #window 7 on *Minibuf-0*) (modeline . t) (width . 80) ...) [2 times] Loading pp...done Loading help-mode...done Quit [3 times] Mark set nil Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: cursor-color frame parameter cannot equal background-color
Put these sexps in buffer *scratch*: 1. (setq default-frame-alist '((foreground-color . Blue) (mouse-color . Red) (cursor-color . Red))) 2. (modify-frame-parameters (selected-frame) '(;;(background-color . Black) (cursor-color . Black))) Eval #1. C-x 5 2 to create a new frame. The new frame's cursor color is Red Eval #2 (in the new frame). The new frame's cursor is now black - no problem. Delete the new frame. Uncomment the background-color in #2. Eval #1 again and C-x 5 2 to create a new frame. Eval #2 (in the new frame). The new frame's cursor is still red - the spec change had no effect in this regard. This is the main bug. It is not a bug, it is intentionally coded in x_set_cursor_color. It is trying to avoid making the cursor invisible because of a careless choice of colors. Actually, since I filed that bug, I found a way around it. However, I still would prefer that there be some way to prevent x_set_cursor_color or whatever from being so smart in particular contexts. AFAIK, there is nothing preventing you from setting the foreground and background colors to be the same. I would prefer the same for the cursor, foreground, background, and pointer colors. At least let Lisp programs override this prohibition somehow. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
shouldn't customize-save-variable raise an error if var is not an option?
I don't know the answer, because I don't know if `customize-save-variable' is intended to work by program on variables that have not yet been declared using defcustom. I can't find any doc that speaks to this. It might be argued that some of what `customize-save-variable' does makes sense, even to a (possibly existing) variable that is not yet declared via defcustom (but might be in the future), but I think that at least some of what `customize-save-variable' does should not be done to a non-option variable. The effect seems to be, in fact, to create an option, just as if defcustom had been used. I am not sure if everything needed is done, however. If not, isn't it misleading for a non-option variable to have values for the properties `saved-value', `variable-comment', and `saved-variable-comment'? Might some programs that examine such properties not be misled by this? Similarly, does it make sense for the variable to be saved with the value to the user's custom file? Maybe, maybe not, depending on what the design intends, and whether the result of calling `customize-save-variable' is an option in all aspects. So, is it a bug for `customize-save-variable' not to first ensure that its variable arg is an option, and raise an error otherwise? Interactively, a non-option cannot be input, but a Lisp program can call `customize-save-variable' on a non-option name and thus effectively create an option, which thereafter can be customized interactively. And `customize-save-variable' can also be used interactively on such an option that was, in effect, created by a Lisp call to `customize-save-variable'. This all seems a bit fuzzy to me. If the design is thought to be clear, then please at least document this in some way (the intention, the behavior). In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2006-12-11-Lennart\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: describe-mode doc string doesn't describe BUFFER arg
The BUFFER arg needs to be described, and, in particular, it's type (string or buffer) needs to be mentioned. That arg exists for internal purposes; we do not need to advertise it. What makes it for internal purposes only? Why wouldn't a Lisp programmer use it? I use it, for instance. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: infinite recursion in describe-mode
Yes! Thanks very much. Does this fix it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of `interactive' for `N'
The doc string says this for code `N' in `interactive: Raw prefix arg, or if none, do like code `n'. However, the Elisp manual says this: The numeric prefix argument; but if there is no prefix argument, read a number as with `n'. I imagine that the latter (numeric arg) is correct, not the former (raw arg). BTW, this bug is very old: it appears in Emacs 20 also. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Help Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t view-mode: t Recent input: down-mouse-1 mouse-1 C-h i help-echo help-echo down-mouse-2 mouse-2 help-echo help-echo help-echo help-echo down-mouse-1 mouse-1 i i n t e r a c t i v e return C-v C-v C-v SPC SPC SPC SPC down-mouse-1 mouse-1 C-h f i n t e r a c t i v e return down-mouse-1 mouse-1 C-v C-v help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading dired...done 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...done Found `interactive' in Index. (24 total; use `,' for next) Loading help-fns...done Type C-x 1 to remove help window. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
I do not want a discussion about redesigning the Custom interface now. Of course not. If the default sort order cannot be changed now, can the custom sort options at least be autoloaded? That would let users know that there is a workaround available. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
describe-mode doc string doesn't describe BUFFER arg
The BUFFER arg needs to be described, and, in particular, it's type (string or buffer) needs to be mentioned. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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 value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: down-mouse-1 mouse-1 C-h f d e s c r i b e - m o d e return help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2006-12-11-Lennart\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading help-fns...done Type C-x 1 to remove help window. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
And how do you know what custom group to look in? These are options that are not autoloaded (so unavailable to C-h v and apropos) and are not mentioned in any manual. One way is to browse through the structure of custom groups. But it would be good if Custom buffers had some menu bar item leading to customizing the custom group for custom buffers. Would someone please add that? 1. Reminder: The bug report was about the default order of options in a custom buffer. If it were alphabetical, users could find options there easier. I don't see the utility of the current default order, which I mistook to be more or less random. The explanation I got was that this default order reflects the guideline to write options such that an option `bar' depending on an option `foo' appears in the customization buffer after `foo' unless the user deliberately changed that order. What is the reason for that guideline, and just what kind of dependency are we talking about here? What makes the default order a good one for users? 2. If the current default order is kept, is there a reason that the custom sort options shouldn't be autoloaded, so that users can find out about them through `C-h v' or `apropos'? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
- They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. How can `C-h v' help you to find something you're not aware of? That's not the point. The point is that these should be well documented, and autoloaded so you can get to the documentation. Many Emacs users don't care about customization. So? Bug reports about customization don't concern such users, so ignore them in the present context. If you don't care about customization either, then perhaps someone else should respond to this bug report. I do care about customization, and that's why I reported the bug. I would appreciate a lot if you tried to improve its documentation. I try to improve it by pointing out problems with it. FYI, GNU will not accept my patches, doc or code, because my employer will not sign papers. My contribution is bug reports and general suggestions - if they help, fine; if not, ignore. In this case, one needed improvement is to autoload (or equivalent) the defcustoms. However, C-h v can easily help you find something you are not aware of, by showing you what's available with completion. I do it every day. C-h v with completion is hardly an option for beginners and hardly useful when there are many completions. I disagree. Completion is a real aid for beginners, as well as for non-beginners. Apropos is another aid in this context. It is also rendered impotent if the variables have not been loaded or autoloaded. - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? They would browse customization groups, try options, and use them. OK, that's one way to find them. C-h v or apropos is another. That the former way is available as an alternative is no solution for the problem that the latter way is broken. - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? The nil order is the one chosen by the designer of the option. Emacs maintainers are now responsible. I don't know what the designer's rationale was, and I don't see a good rationale. I was asking if there is one. The designers of an option are the persons who invented the option, assigned a name to it, and wrote the customization definition. Their rationale should be to write options such that an option `bar' depending on an option `foo' appears in the customization buffer after `foo' unless the user deliberately changed that order. I see. I guess you're saying that that is the default order that I was calling random. I don't know if the guideline you just mentioned is documented for designers, but the resulting order is, IMO, not obvious or understandable to users - it might as well be random. In any case, the designer is out of the loop now, for this bug fix, unless a maintainer wants to contact the designer for some reason. I don't understand why we would even have such options - who would ever want a random order? Why do you think it's random? I said apparently. I have no idea what determines the order. It is not an obvious, understandable, or obviously useful order. I don't care if it's actually random. I asked if there was a good reason for it, and you essentially told me to go ask the designer. Indeed. You should tell the designers of the options for a specific group whenever you think they wrote them in an inappropriate way. This is a standard GNU-Emacs library. I don't know (or care) who the designers of these options is. I reported a bug; that's all. If a bug fixer wants to contact the designer to understand the original rationale, feel free. I'm just reporting a bug. As always, it's your prerogative to decide not to fix the bug or to decide that there is in fact no bug. I would think that bug reports would be welcomed, as an aid, instead of resisted, as if they were imposing unnecessary chores. This push-back is not helpful, IMO. I personally won't be discouraged, by your attitude, from reporting other bugs, but I expect that some others might be. Please don't adopt this attitude as a general response to bug reports, or we will lose lots of good input from users. A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag None nil) function)) I personally don't see why anyone would want an order other
RE: Value menu value should be listed on a separate line
Usually with :entry-format and :format. No special formatting should be necessary, just to be able to use a simple tag. I don't believe that was why :*format were introduced. You would have to specify what a simple tag is in the first place. I would? My bug report was clear enough, I think, for someone who really wants to understand. I did give a concrete example, however: a literal string of less than 80 characters. Formatting tags is for handling non-standard cases like, for example, options whose values may be variable-length strings. Such options are not necessarily preceded by a [Value Menu]. Then why do you bring them up? The bug report is about option values that are preceded by [Value Menu], and it doesn't mention formatting tags - you brought that up. The examples I gave were not variable-length strings. Why introduce a distraction unrelated to the reported problem? No formatting should be necessary for the simple cases reported. Writers of defcustom's shouldn't need to concern themselves with the layout of the Customize buffer, anyway. They should be able to define a :tag string without the preoccupation of its starting position and the number of characters already taken up by the option name and the button widths. I'm convinced that writers of defcustoms should care about the layout. OK, you're convinced. I said that they should not *need* to concern themselves with the layout of stuff, beyond their own creations. This is a flaw in the basic layout, which should not be shoved off onto the definers of individual values, to work around. It should be trivial to fix, no less - why not fix the general case, instead of making writers of each value work around it over and over? Your general case is based on the presence of the term [Value Menu]. Often that term is followed by a fixed-length string That's exactly the case I reported: [Value Menu] followed by a (fixed-length) :tag string. or an integer as in the following excerpt from the comment group: [snip] Moving the text after [Value Menu] to a new line would render this customization buffer completely unreadable. I disagree. There is no reason that the value should follow [Value Menu] on the same line. What compelling reason is there? How does that enhance readability? If, however, you are convinced that they must remain together, then consider starting [Value Menu] and the value together on a new line. That is, if you don't like this: ...xxx [Value Menu] the-value then consider this: ...xxx [Value Menu] the-value I see no reason why [Value Menu] needs to be next to the value, nor why either needs to be at the end of a possibly long line of stuff (option name, buttons). It makes sense to always start the value in column 1, especially since 1) values can be of any length and 2) a very common case is the use of a :tag, which provides a string value, in a `choice'. That is the case I reported. Hence, I'm against a trivial fix. I think you are against any fix at all. The ball is in your hands; if you don't want to fix it, then you won't fix it. I've done my reporting job; it's your turn. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? If you want to change things about a certain feature (such as the custom buffer interface), you look at its custom group and see what's available. And how do you know what custom group to look in? These are options that are not autoloaded (so unavailable to C-h v and apropos) and are not mentioned in any manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
