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
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
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
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
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
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
`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. (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'
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
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
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
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
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
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'
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
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
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
(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
(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
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 -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
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
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
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
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
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
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
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
---
`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
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
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
`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 -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
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
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
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
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
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
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
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
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
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.
`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
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
(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
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
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 ?-)
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
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.
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
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.
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,
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.
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
`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
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
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
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
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
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'
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
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 `_'
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
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
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
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
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)
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
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
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
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
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
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
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'
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
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
(_ (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
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
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
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.
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
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
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
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
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
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
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
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
emacs -Q
1. make-frame does not respect frame parameters that are not known:
(make-frame '((foo . 45)))
The manual seems to support this, saying:
The set of possible parameters depends in principle on what kind of
window system Emacs uses to display its frames. *Note Window
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)
I don't know the answer, because I don't know if
`customize-save-variable' is intended to work by program on
variables that have not yet been declared using defcustom.
I can't find any doc that speaks to this.
It might be argued that some of what `customize-save-variable' does
makes sense, even
The BUFFER arg needs to be described, and, in particular, it's type
(string or buffer) needs to be mentioned.
That arg exists for internal purposes; we do not need to advertise it.
What makes it for internal purposes only? Why wouldn't a Lisp programmer use
it? I use it, for instance.
Yes! Thanks very much.
Does this fix it?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
The doc string says this for code `N' in `interactive:
Raw prefix arg, or if none, do like code `n'.
However, the Elisp manual says this:
The numeric prefix argument; but if there is no prefix argument,
read a number as with `n'.
I imagine that the latter (numeric arg) is correct, not the
I do not want a discussion about redesigning the Custom interface now.
Of course not.
If the default sort order cannot be changed now, can the custom sort options
at least be autoloaded? That would let users know that there is a workaround
available.
The BUFFER arg needs to be described, and, in particular, it's type
(string or buffer) needs to be mentioned.
In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600)
of 2006-12-11 on LENNART-69DE564
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)
And how do you know what custom group to look in? These are
options that are not autoloaded (so unavailable to C-h v
and apropos) and are not mentioned in any manual.
One way is to browse through the structure of custom groups.
But it would be good if Custom buffers had some menu
- They are apparently not autoloaded, so `C-h v' doesn't
recognize them until customize has been loaded.
How can `C-h v' help you to find something you're not aware of?
That's not the point. The point is that these should be well
documented, and autoloaded so you can get to
Usually with :entry-format and :format.
No special formatting should be necessary, just to be able to
use a simple tag. I don't believe that was why :*format were
introduced.
You would have to specify what a simple tag is in the first place.
I would? My bug report was clear
They are customizable, so users should be able to find them.
Why would they look for them if they are not aware of them,
to use your logic?
If you want to change things about a certain feature (such as the
custom buffer interface), you look at its custom group and see
what's
1 - 100 of 550 matches
Mail list logo