headers
Stefan Monnier | 1 Dec 2010 03:57
Picon

bug#7509: 24.0.50; doc for `comment-style' and `comment-styles'

>> There's no such magic.
> Are you saying that `makunbound' should take care of it?

No.  I'm saying that there is no known trick to undo a defcustom.

> Also, it wouldn't hurt to include such tiny diagrams in the doc string
> for `comment-styles' (esp. since it is a defconst).  In this case,
> a set of pictures is worth more than a set of one-liner descriptions.

Again, that would amount to documenting the particular current value of
that variable, rather than the set of possible values and their meaning.
So that would be wrong.  Such documentation can't belong to
comment-styles's docstring; only to the doc of each style defined there.

> BTW, why are all of the various possibilities (align, extra, box etc.)
> defined only for indented comments?

The only reason `plain' exists is because that's what was used in
Emacs≤22.  I strongly discourage people from using it since it often
results in comments that aren't properly indented.

> plain      - Start in column 0 (do not indent)
> indent     - Full comment per line, ends not aligned
> aligned    - Full comment per line, ends aligned
> box        - Full comment per line, ends aligned, + top and bottom
> extra-line - One comment for all lines, end on a line by itself
> multi-line - One comment for all lines, end on last commented line
> box-multi  - One comment for all lines, + top and bottom

Thanks, that seems much better than what I have now.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Drew Adams | 1 Dec 2010 01:38
Picon
Favicon

bug#7520: 24.0.50; C-h k doesn't work for double-click bindings

emacs -Q

(defun foo (event)
 (interactive "e")
 (message "FOOOOOOOO"))

(global-set-key [double-mouse-3] 'foo)

`C-h k', then double-click mouse-3.

The double-click event is not handled by C-h k.  The doc you see is
for the command bound to `mouse-3', not the command bound to
`double-mouse-3'.

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-11-30 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Dec 2010 05:10
Picon
Favicon

bug#7509: 24.0.50; doc for `comment-style' and `comment-styles'

> > Also, it wouldn't hurt to include such tiny diagrams in the 
> > doc string for `comment-styles' (esp. since it is a defconst).
> > In this case, a set of pictures is worth more than a set of
> > one-liner descriptions.
> 
> Again, that would amount to documenting the particular 
> current value of that variable, rather than the set of
> possible values and their meaning.

No, we would be documenting the _default_ value.  Nothing wrong with that.  It
serves as a model, a particular value, yes, but also a good example.  And the
value that defines the behavior (the possibilities) out of the box - good to
know.

Both understanding the default behavior/value and having it as a model are
useful.

> So that would be wrong.  Such documentation can't belong to
> comment-styles's docstring; only to the doc of each style 
> defined there.

Either nothing is defined there (it's just one possible value, as you point out)
or everything is defined there (it's the default value, defining all the
behavior possibilities you get if you don't change anything).  You cannot have
it both ways. ;-)

I'd say that we should describe the default value in the doc string (and not
just inside the value itself), because I think that will help users.  The doc
string just needs to make clear that this description applies to the _default
value_, which serves as _an example_.
(Continue reading)

Permalink | Reply | 2 comments |
headers
martin rudalics | 1 Dec 2010 10:58
Picon
Picon

bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

 > If so, then both (a) it should be possible for the minibuffer frame to have a
 > menu-bar - just like a "normal" frame,

The code for such a menu-bar must be either designed specifically for
such a frame or the current menu-bar.el code must be redesigned to
accomodate the pecularities of the minibuffer frame.  Neither of these
is simple as the current problems indicate.

 > and (b) it should be possible for the
 > `Minibuf' menu-bar menu to be shown when you use a standalone minibuffer frame.

You mean a Minibuf entry from some other "normal" frame?  When you go to
such an entry with the mouse you very likely automatically select the
associated frame too and probably get some very convoluted semantics wrt
the selected frame.  Besides, what would you do when there's no "normal"
frame?

martin
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Dec 2010 07:10
Picon
Favicon

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

Evaluate this:

`("Foo" . (lambda ()
            "Four score and seven years ago
Our forefathers brought forth etc.
Etc., etc., etc."
            (message "HOWDY")))

That doc string is a literal string with two embedded newline chars.
Evaluation converts each of those chars to a string of two chars: "\n":

("Foo" lambda nil "Four score and seven years ago\nOur forefathers brought forth
etc.\nEtc., etc., etc."
 (message "Howdy"))

Shouldn't happen.  (This is particularly messy when used in defcustom
values.)

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-11-30 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
Permalink | Reply | 14 comments |
headers
martin rudalics | 1 Dec 2010 10:58
Picon
Picon

bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

 >> I still don't get it why a condition_case can't handle such an error.
 >
 > Because part of the recipe is to set debug-on-error non-nil?

Probably.  But what is `debug-on-error' good for when Emacs crashes?

martin
Permalink | Reply | 1 comment |
headers
Lennart Borgman | 1 Dec 2010 16:05
Picon
Gravatar

bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

On Tue, Nov 30, 2010 at 12:23 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Is it different from (menu-bar-lines . 0) ?  If not, do you happen to
> know why are we using two different conventions to convey the same
> information?

Is not that just because the way the parameters are passed?
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Dec 2010 16:13
Picon
Favicon

bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

>  > and (b) it should be possible for the
>  > `Minibuf' menu-bar menu to be shown when you use a 
>  > standalone minibuffer frame.
> 
> You mean a Minibuf entry from some other "normal" frame?  

I meant shown in the minibuffer frame's menu bar.

But I think I also mentioned being able to show the `Minibuf' menu in all other
frames, as an alternative (e.g. while waiting to get a minibuffer-frame menu
bar).  So no, that's not what I was saying, but yes, that too.

> When you go to such an entry with the mouse you very likely 
> automatically select the associated frame too

Not sure that matters, even it it's true.  And it's not difficult to fix that
menu's behavior to select the minibuffer window if it's not selected.

> and probably get some very convoluted semantics wrt
> the selected frame.

=?

> Besides, what would you do when there's no "normal" frame?

No frame that has a menu bar means no menu bar, so no `Minibuf' menu-bar menu.
Nothing new here.
Permalink | Reply | 1 comment |
headers
Stefan Monnier | 1 Dec 2010 17:04
Picon

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

> Evaluate this:
> `("Foo" . (lambda ()
>             "Four score and seven years ago
> Our forefathers brought forth etc.
> Etc., etc., etc."
>             (message "HOWDY")))

> That doc string is a literal string with two embedded newline chars.
> Evaluation converts each of those chars to a string of two chars: "\n":

> ("Foo" lambda nil "Four score and seven years ago\nOur forefathers brought forth
> etc.\nEtc., etc., etc."
>  (message "Howdy"))

It's got nothing to do with backquote.  It's just that

    "foo
    bar"

is just another way to write "foo\nbar": the Elisp reader will return
the exact same string in both cases.  So the Elisp printer can't know
which one was used originally and has to choose arbitrarily which form
to output.

> Shouldn't happen.

Unavoidable.  Tho you do get to choose somewhat the print format by
choosing between prin1 and princ (aka %s and %S in format).

> (This is particularly messy when used in defcustom values.)
(Continue reading)

Permalink | Reply | 13 comments |
headers
Stefan Monnier | 1 Dec 2010 16:48
Picon

bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

> `menu-bar-lines'
>      The number of lines to allocate at the top of the frame for a menu
>      bar.  The default is 1.  A value of `nil' means don't display a
>      menu bar.  *Note Menu Bar::.  (The X toolkit and GTK allow at most
>      one menu bar line; they treat larger values as 1.)

> so `nil' is a valid value and evaluating a menu bar item probably should
> know how to handle it.

I think the above doc only means that the C code interprets a nil as
meaning  "no menu bar" when you set that frame parameter.  Whether it
also means that this same C code can return nil when you query this
parameter is not quite so clear.

        Stefan
Permalink | Reply | 1 comment |

Gmane