RE: key binding of `M-&' shows up in menu as (M-)
> > Unfortunately I do not think that is the right change. This totally > > spoils the possibility to use accelerators for the menus on w32. I do > > not think the minor problem it solves justifies that. > > > > I think the change should be reverted and added back later when it is > > clear how menu accelerators should be supported in Emacs. > > So you are saying that a fix for a clear and present bug should be > postponed pending a future decision about adding a feature? That > doesn't sound like the right idea to me. I'd rather say that when the > support for menu accelerators is added to Emacs, we will have to > figure out how to do that without smashing & characters in menu items > and keybindings shown next to them. > > If you still aren't convinced, please start a thread on emacs-devel > about this, and let's hear what others think. I agree with Eli on this one, unless there is some obviously better way to fix this now that will also facilitate treatment of the accelerators later. It sounds as if the best way to treat the accelerators has not yet been decided, so I think this should be fixed now without worrying about a possible new feature. ___ 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
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
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
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
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
> "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
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
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
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
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
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
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
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
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
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: C-h i g i n v i s i b l e SPC C-h v b u f f e r - i n v i s 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
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
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
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? 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: o n e - w i n d o w C-h f C-h fC-h f C-M-x m a i l - b u f 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 , SPC n o t SPC w i n d o w - d e d i c a t e d - p j j j j j j j j j j j j j j j j C-c C-c y e s C-M-x f f f f f f f f f f f k k k k k k k k k k k k C-c C-c y e s C-M-x C-x 5 2 f f f f f f f f f f f f f f f f f f f f f f f C-c C-c y e s C-M-x C-x 5 2 M-p M-p M-p j j j j j j j j j j j j j j j j j C-c C-c y e s 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 needs xrefs for text properties and point after cmds
Node Adjusting Point of the Elisp manual is in the Command Loop section - far from help about text properties. It should cross reference node Special Properties, and vice versa, so users can understand the relation between properties such as intangible and point adjustment. 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: 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
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
> 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
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 <><>___ 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: M-x C-g C-g M-: 9 s e t ( s e q 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 ) ) M-x l o a d - l i b i c i M-x i c y M-x C-g C-g 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 C-x 1 M-x C-g C-g M-x C-g C-g C-h k C-g C-g C-x 1 C-h i i : e n a b l e , , , , , , , , , , , , , , , , , , , , , , , , u u u s : e n a b l e 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
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
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
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: 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
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: 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: 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
> Do you know what car or cdr stand for? If not, has it stopped > you from using them? Good point, Nick. Let's change all Emacs functions to have incomprehensible names - after the release, of course. As long as their doc strings and source code are clear, there is no point in having names that make sense. As a matter of fact, why not mix the doc strings up a bit too - `dissociated-press' them into disservice. That wouldn't stop anyone from using them, and it would be a lot more interesting. ___ 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
> > I don't think it could be much clearer.
>
> "Return the window least recently used or selected for display"
No, because those are not two different options ("or"); they denote the same
thing. "Lru" stands for "least recently used", but least recently selected
is what is meant by that.
It is not good to use acronyms that are either 1) not common (previously
known) or 2) not used elsewhere. There is no sense introducing an acronym
unless you are going to use it in several places to avoid repetition of
lengthy phrases. There is never any sense in using an acronym that has never
been introduced anywhere (defined).
The function should be renamed. If that is not possible, then this (useless)
acronym needs to be introduced as standing for "least recently used", and
"selected" needs to be given as the definition of "used" in that phrase.
When people are lazy or sloppy about naming things, it makes for much
wordier and clumsier doc and code, in the long run. Always.
___
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
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.) 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: Please consider using highlightening in occur-mode-display-occurrence
Juri Linkov wrote: > > When using occur, I just found out that there was a command > > occur-mode-display-occurrence (C-o) that let me stay in the > > *occur*-buffer. Nice! > > > > Wouldn't it be a good idea to highlight the occurrence, at least > > temporarily, instead of just putting the not-so-easily-seen point on > > it? > > Obviously, occur should be extended with more features already available > in grep buffers. And one of them is using the next-error face to > highlight matches in the source buffer. Sadly, now is the wrong time > to add these features. (I also have tons of other improvements patiently > waiting for the feature unfreeze.) From: Matzi Kratzi Date: 2007-03-12 Stefan Monnier asked me if I had used hl-line-mode in the occur buffers. I think Juri got what I meant: I think the corresponding location in the "source" buffer is not marked enough. A behaviour like grep where there location is temporarily highlighted is nice. (But there you end up in the source buffer, and I would like to be able to stay in the *occur* or the *grep* buffer.) /Mats Mats, I agree with Juri that it would be good to improve Occur in Emacs in various ways after the release. While waiting for that, you can get what you requested now, with library replace+.el: http://www.emacswiki.org/cgi-bin/wiki/replace%2b.el. Here's some explanation: http://www.emacswiki.org/cgi-bin/wiki/ReplacePlus#OccurImprovements. HTH - Drew ___ 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
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
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: 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
(push-mark N t t) doesn't activate region in virgin buffer
emacs -Q M-x transient-mark-mode ; turn it on M-: (goto-char (point-min)) M-: (mark t) ; returns nil M-: (push-mark 20 t t) M-: (mark t) ; returns 20 M-: mark-active ; returns nil The region is not activated by the call to push-mark, but it should be, IMO. (point) = 1, mark = 20, and transient-mark-mode is on. The doc of push-mark says that it activates the mark if the third arg is non-nil. The same bug exists in Emacs 21. In Emacs 20, however, the region is active (as it should be). 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 transient-mark-mode: t Recent input: M-: ( p u t r a n C-g M-x t r a n s i e n t - m a r k - m o d e M-: ( p u s h - m a r k SPC 5 0 SPC t SPC t ) Recent messages: 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. Quit Transient-Mark mode enabled nil 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
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: 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
> Yes, I know you're arguing that buff-menu.el contains just one > non-ASCII char and it would be friendlier to use an escape (It's me > who added the comment line just above the one which is causing you so > much grief.) Perhaps you're right. But you said yourself your fix > wouldn't work for packages with lots of Unicode chars. Where do you > intend to put the line? At ten chars? A thousand? I don't intend to establish a line. Judgement is needed, perhaps case by case. What I said, in an earlier mail, was this: "When Unicode is important for the library in question, it makes sense to use it in the code." That is clearly _not_ the case here. Make that judgement of relative importance as you see fit, for any given library. I'll entertain arguments that buff-menu.el needs Unicode encoding, but I don't yet have an opinion about the use of Unicode in any other particular libraries. > And how do you > propose to inform the user, used to "code which displays as plain > text", that suddenly this other code isn't downloadable with broken > tools anymore? Good question, and one that I raised in response to Eli's mail. I suggested perhaps providing instructions on the Web site, perhaps drawing attention to the -*- coding declaration. But I don't have a good answer. Because many people will not be aware of this potential gotcha, it behooves us to somehow draw their attention to it. Maybe we should say explicitly that all code should be downloaded using a Unicode encoding - I don't know. As you point out, and I pointed out previously, this is a problem more and more, as Unicode is adopted progressively but there are still plenty of tools that are not yet there 100%. We will have to live with it, until the world (including Emacs ;-)) is Unicode through and through. And even then, things might not be so simple. Our best recourse, at least in this transitional period, is to be aware of the potential gotchas and use our best judgement to help users avoid problems. That's all; I don't have a better suggestion than that. Maybe someone else does. My bug report was not aimed at fixing this problem, in any case - this is off topic. My report was aimed at preventing this problem from arising for file buff-menu.el, and, secondarily, improving the legibility of that library. Nothing more. > I don't care about buff-menu.el, and won't argue for or against > changing one character; but the fix for the problem you're struggling > with is educating the users, and pointing them to non-broken tools. No, the fix for the problem that I reported is to use an escape sequence in buff-menu.el. The fix for general Web site, browser, and user error problems, is education and fixing and updating tools, but that is not the problem I asked that we fix now. This sideline discussion (this problem that you are apparently struggling with, and that you think I am struggling with) arose because someone asked how the buff-menu broken character problem could have arisen in the first place. I tried to explain that it doesn't matter how it arose, that the bug report is about unnecessary em-dash characters - for which explanation I was accused of being ungrateful for help offered to solve the ancillary problem of downloading etc. So here we are, off track. I explained that these characters should be replaced by escape sequences, not just because they might cause encoding problems for some users, Web sites, or tools, but also because they reduce legibility. And because of Occam's razor: there is no need to introduce Unicode characters here, with their potential problems for users, because _nothing is gained_ here by doing so. That's three reasons: 1) possible encoding gotchas, 2) reduced legibility, 3) unnecessary complication for no gain. We will all be struggling with the problem of not recognizing Unicode and properly adjusting to it for quite some time, I'm afraid. I didn't report that general problem, and I don't have a general solution for it. We can at least do what we can to prevent that problem from arising in no-brainer cases such as buff-menu.el. There is no good reason to invite that problem to rear its ugly head _in this case_. > Obviously, we can't (nor should) force anyone to change their ways; > but I don't see why should we make extraordinary efforts to suit them, > either. Preventing a stupid problem, with no loss, and with some gain (legibility) is not catering to anyone's underdeveloped ways. It's just common sense. And replacing two em-dash characters with \u2014 is hardly making "extraordinary efforts". It does, however, sometimes seem to take extraordinary efforts to get the slightest suggestion across to change something, even something trivial, in the Emacs code. I don't know why. I don't care so much, for myself, but I'm sad to think of others who might have given up helping long ago, when their efforts met with stubborn resistance and sidetrack arguments. It really d
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 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
> > 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. 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 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 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
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
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
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
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
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
doc string of move-to-column does not describe ARG for interactive use
The doc string needs to say that, when used interactively, COLUMN is the numeric prefix argument. 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
> > 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: 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
> > 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
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
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
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
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
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
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: 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
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 backward-kill-word more info 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 Or, better perhaps (depending on what the intention is - I'm lost): Key mentioned in tutorial Key in your Emacs Command - - --- 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
> > 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
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: 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
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: > > > > > > > > > > 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: > > > > > 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
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: 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
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: 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
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: 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-p
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: 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
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
Emacs manual: Should change customize-variable to customize-option
C-h f customize-variable shows this: customize-variable is an alias for `customize-option' in `cus-edit.el'. (customize-variable symbol) Customize symbol, which must be a user option variable. That is, `customize-option' is the preferred name. However, `customize-option' does not appear in the Emacs manual, and `customize-variable' does appear there, including in the index. Please replace `customize-variable' with `customize-option'. 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: - o p t i o n i c u s t o m i z e - v a r i a b l e C-h f c u s t o m i z e - o p C-h f u u u u s c u s t o m i z - e - o p t i o n Recent messages: Loading vc-cvs...done Searching subfile emacs-2... Searching subfile emacs-3... Searching subfile emacs-4... Searching subfile emacs-5... Searching subfile emacs-6... Searching subfile emacs-7... Searching subfile emacs-8... Info-search: Search failed: "customize-option" Loading emacsbug...done ___ 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
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: C-h i g s a c t i v e SPC k e y m C-s a b o v e C-a 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 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
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
