unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [drew.adams@oracle.com: links in Help buffer aren't always correct]
@ 2005-12-13  3:15 Richard Stallman
  2005-12-13 17:17 ` Kevin Rodgers
  0 siblings, 1 reply; 25+ messages in thread
From: Richard Stallman @ 2005-12-13  3:15 UTC (permalink / raw)


Would someone please DTRT about this, then ack?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Mon, 28 Nov 2005 08:58:08 -0800
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
Subject: links in Help buffer aren't always correct
Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

For example, C-h f buffer-list shows this text:

 buffer-list is a built-in function in `C source code'.
 (buffer-list &optional frame)

 Return a list of all existing live buffers.
 If the optional arg frame is a frame, we return the buffer list
 in the proper order for that frame: the buffers in frame's `buffer-list'
 frame parameter come first, followed by the rest of the buffers.

 [back]

The text "buffer-list" in the last sentence is linked to the help for the
`buffer-list' function, not the `buffer-list' frame parameter. Either there
should be no link here (if there is no way to show help on the parameter) or
the link should point to help on the frame parameter.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2005-06-26 on NONIQPC
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
ude'



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren't always correct]
  2005-12-13  3:15 [drew.adams@oracle.com: links in Help buffer aren't always correct] Richard Stallman
@ 2005-12-13 17:17 ` Kevin Rodgers
  2005-12-13 19:52   ` [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect] Drew Adams
  0 siblings, 1 reply; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-13 17:17 UTC (permalink / raw)


Richard Stallman wrote:
> Would someone please DTRT about this, then ack?
> 
> ------- Start of forwarded message -------
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
> Date: Mon, 28 Nov 2005 08:58:08 -0800
> X-Brightmail-Tracker: AAAAAQAAAAI=
> X-Whitelist: TRUE
> Subject: links in Help buffer aren't always correct
> Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
> X-Spam-Level: 
> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
> 
> For example, C-h f buffer-list shows this text:
> 
>  buffer-list is a built-in function in `C source code'.
>  (buffer-list &optional frame)
> 
>  Return a list of all existing live buffers.
>  If the optional arg frame is a frame, we return the buffer list
>  in the proper order for that frame: the buffers in frame's `buffer-list'
>  frame parameter come first, followed by the rest of the buffers.

I think it would be better to say:
   the buffers in FRAME's `buffer-list' frame parameter come first,
or:
   the buffers in the frame's `buffer-list' frame parameter come first,
or:
   the buffers in its `buffer-list' frame parameter come first,

>  [back]
> 
> The text "buffer-list" in the last sentence is linked to the help for the
> `buffer-list' function, not the `buffer-list' frame parameter. Either there
> should be no link here (if there is no way to show help on the parameter) or
> the link should point to help on the frame parameter.

Since there is no describe-frame-parameter command, and the phrase
"frame paramter" follows the quoted symbol (unlike the phrases listed
in help-xref-symbol-regexp, which precede quoted symbols), we can avoid
hyperlinking such phrases by changing help-make-xrefs in help-mode.el
from:

               ;; Quoted symbols
               (save-excursion
                 (while (re-search-forward help-xref-symbol-regexp nil t)
                   (let* ((data (match-string 8))
                          (sym (intern-soft data)))
                     (if sym

to:

               ;; Quoted symbols
               (save-excursion
                 (while (re-search-forward help-xref-symbol-regexp nil t)
                   (let* ((data (match-string 8))
                          (sym (intern-soft data)))
                     (if (and sym
                              (save-match-data
                                (not (looking-at "[ \t\n]+frame 
parameter"))))

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect]
  2005-12-13 17:17 ` Kevin Rodgers
@ 2005-12-13 19:52   ` Drew Adams
  2005-12-13 23:53     ` Kevin Rodgers
  0 siblings, 1 reply; 25+ messages in thread
From: Drew Adams @ 2005-12-13 19:52 UTC (permalink / raw)


    > The text "buffer-list" in the last sentence is linked to the
    > help for the `buffer-list' function, not the `buffer-list' frame
    > parameter. Either there should be no link here (if there is no
    > way to show help on the parameter) or
    > the link should point to help on the frame parameter.

    Since there is no describe-frame-parameter command, and the phrase
    "frame paramter" follows the quoted symbol (unlike the phrases listed
    in help-xref-symbol-regexp, which precede quoted symbols), we can avoid
    hyperlinking such phrases by changing help-make-xrefs in help-mode.el
    from:

                   ;; Quoted symbols
                   (save-excursion
                     (while (re-search-forward
    help-xref-symbol-regexp nil t)
                       (let* ((data (match-string 8))
                              (sym (intern-soft data)))
                         (if sym

    to:

                   ;; Quoted symbols
                   (save-excursion
                     (while (re-search-forward
    help-xref-symbol-regexp nil t)
                       (let* ((data (match-string 8))
                              (sym (intern-soft data)))
                         (if (and sym
                                  (save-match-data
                                    (not (looking-at "[ \t\n]+frame
    parameter"))))

I agree with the intention, but have doubts about the implementation - it
seems fragile, depending as it does on the exact text in the doc string. If
someone writes "frame parameter `buffer-list'" instead of "the `buffer-list'
frame parameter" then it won't work correctly. Likewise, if someone writes a
French doc string for a function or var that refers to a frame parameter.

But I guess the same could be said for the use of `help-xref-symbol-regexp',
generally. Given that we do use `help-xref-symbol-regexp' in a way that
depends on the exact doc-string text, wouldn't it be better to add the
doc-string convention to always precede the specific name by the type, so,
for instance, this doc string would say "frame parameter `buffer-list'"?
Then, "frame parameter could be added to `help-xref-symbol-regexp'.

There may not be a `describe-frame-parameter' function, but the
`help-make-xrefs' code could use a preceding "frame parameter" to link to
the Info section describing the `buffer-list' parameter. Or, at the very
least, it could test for preceding "frame parameter" in order to do nothing
(add no link) if it is present.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect]
  2005-12-13 19:52   ` [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect] Drew Adams
@ 2005-12-13 23:53     ` Kevin Rodgers
  2005-12-14 18:10       ` Kevin Rodgers
  2005-12-14 20:02       ` Richard M. Stallman
  0 siblings, 2 replies; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-13 23:53 UTC (permalink / raw)


Drew Adams wrote:
 > There may not be a `describe-frame-parameter' function, but the
 > `help-make-xrefs' code could use a preceding "frame parameter" to link to
 > the Info section describing the `buffer-list' parameter. Or, at the very
 > least, it could test for preceding "frame parameter" in order to do 
nothing
 > (add no link) if it is present.

Here's a start, cobbled together from describe-variable and your idea of
linking to the Info node:

(defun describe-frame-parameter (parameter &optional frame)
   "Display the full documentation of frame PARAMETER (a symbol) in FRAME.
If FRAME is nil, describe the selected frame's parameter value."
   (interactive
    (let* ((enable-recursive-minibuffers t)
           (default-param (symbol-at-point))
           (param-alist (frame-parameters nil))
           (param-name
            (completing-read (if (assq default-param param-alist)
                                 (format "Describe parameter (default %s): "
                                         default-param)
                               "Describe parameter: ")
                             obarray
                             (lambda (p) (assq p param-alist))
                             t nil nil
                             (if default-param (symbol-name 
default-param)))))
      (list (if (equal param-name "")
                default-param
              (intern param-name)))))
   (if (null frame)
       (setq frame (selected-frame)))
   (if (null parameter)
       (message "You did not specify a frame parameter")
     (with-output-to-temp-buffer "*Help*"
       (prin1 parameter)
       (princ "'s value is ")
       (terpri)
       (let ((param-value (frame-parameter frame parameter)))
         (with-current-buffer standard-output
           (let ((from (point)))
             (pp param-value)
             ;; (help-xref-on-pp from (point))
             (if (< (point) (+ from 20))
                 (save-excursion
                   (goto-char from)
                   (delete-char -1))))))
       (terpri)
       (terpri)
       (princ "Documentation (see Info node `(elisp)Window Frame 
Parameters'):")
       (terpri)
       (save-excursion
         (save-window-excursion
           (Info-goto-node "(elisp)Window Frame Parameters")
           (princ (buffer-substring
                   (re-search-forward (concat "^`" (symbol-name 
parameter) "'"))
                   (1- (or (re-search-forward "^`" nil t) 
(point-max))))))))))

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect]
  2005-12-13 23:53     ` Kevin Rodgers
@ 2005-12-14 18:10       ` Kevin Rodgers
  2005-12-14 20:02       ` Richard M. Stallman
  1 sibling, 0 replies; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-14 18:10 UTC (permalink / raw)


Kevin Rodgers wrote:
 >            (completing-read (if (assq default-param param-alist)
 >                                 (format "Describe parameter (default 
%s): "
 >                                         default-param)
 >                               "Describe parameter: ")
 >                             obarray
 >                             (lambda (p) (assq p param-alist))
 >                             t nil nil
 >                             (if default-param (symbol-name 
default-param)))))

It probably makes more sense to complete on the frame parameter alist
(with no predicate) than the entire obarray (with a predicate to check
the alist):

            (completing-read (if (assq default-param param-alist)
                                 (format "Describe parameter (default %s): "
                                         default-param)
                               "Describe parameter: ")
                             (mapcar (lambda (assoc)
                                       (list (symbol-name (car assoc))))
                                     param-alist)
                             nil t nil nil
                             (if default-param (symbol-name default-param)))

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect]
  2005-12-13 23:53     ` Kevin Rodgers
  2005-12-14 18:10       ` Kevin Rodgers
@ 2005-12-14 20:02       ` Richard M. Stallman
  2005-12-14 22:48         ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Drew Adams
  1 sibling, 1 reply; 25+ messages in thread
From: Richard M. Stallman @ 2005-12-14 20:02 UTC (permalink / raw)
  Cc: emacs-devel

describe-frame-parameter seems to work usefully, but it has one
problem: its completion list is incomplete.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-14 20:02       ` Richard M. Stallman
@ 2005-12-14 22:48         ` Drew Adams
  2005-12-15  1:11           ` Kevin Rodgers
                             ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Drew Adams @ 2005-12-14 22:48 UTC (permalink / raw)


    describe-frame-parameter seems to work usefully, but it has one
    problem: its completion list is incomplete.

Do you mean because it iterates only over the parameters of the selected
frame?

It might also include user-defined parameters that won't be documented in
Info. Perhaps it should instead iterate over an explicit list of all of the
Info-documented (built-in) frame parameters.

Perhaps too, the doc string should mention that it only works on documented
built-in frame parameters, not user-defined parameters.

I noticed too that in emacs -q, M-x describe-frame-parameter RET
cursor-color gives an error because Info-find-node is not defined
(autoloaded).

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-14 22:48         ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Drew Adams
@ 2005-12-15  1:11           ` Kevin Rodgers
  2005-12-15  2:01             ` [drew.adams@oracle.com: links in Help bufferaren'talwayscorrect] Drew Adams
                               ` (2 more replies)
  2005-12-15  4:39           ` Eli Zaretskii
  2005-12-15 17:08           ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Richard M. Stallman
  2 siblings, 3 replies; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-15  1:11 UTC (permalink / raw)


Drew Adams wrote:
>     describe-frame-parameter seems to work usefully, but it has one
>     problem: its completion list is incomplete.
> 
> Do you mean because it iterates only over the parameters of the selected
> frame?
> 
> It might also include user-defined parameters that won't be documented in
> Info. Perhaps it should instead iterate over an explicit list of all of the
> Info-documented (built-in) frame parameters.

I'm sure that's what he means.  But by analogy, `M-x describe-variable'
doesn't complete on void symbols, and it is well understood that an
unset frame parameter's value is effectively void: frame-parameter
actually returns nil, but it means the parameter has no effect.

So why provide completion on all documented frame parameters?  So that
the user can simply type ? at the prompt to see the entire list of frame
parameters.  That would be really useful, if there was also a
set-frame-parameter command.

And if there were a define-frame-parameter function and/or defframeparam
macro that would maintain a global list (or obarray) of frame
parameters, it would allow `M-x describe-frame-parameter' and `M-x
set-frame-parameter' to reliably complete over both documented and
user-defined frame parameters.

> Perhaps too, the doc string should mention that it only works on documented
> built-in frame parameters, not user-defined parameters.

That seems like the right thing to do, unless we define a global
list (or obarray) of frame parameters to complete over.

> I noticed too that in emacs -q, M-x describe-frame-parameter RET
> cursor-color gives an error because Info-find-node is not defined
> (autoloaded).

Good point.  I think that since Info-goto-node displays the *Info*
buffer, it should be declared as an (interactive) command, and
therefore that it should be autoloaded.

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [drew.adams@oracle.com: links in Help bufferaren'talwayscorrect]
  2005-12-15  1:11           ` Kevin Rodgers
@ 2005-12-15  2:01             ` Drew Adams
  2005-12-15  3:16             ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Stefan Monnier
  2005-12-15 17:08             ` Richard M. Stallman
  2 siblings, 0 replies; 25+ messages in thread
From: Drew Adams @ 2005-12-15  2:01 UTC (permalink / raw)


    And if there were a define-frame-parameter function and/or defframeparam
    macro that would maintain a global list (or obarray) of frame
    parameters, it would allow `M-x describe-frame-parameter' and `M-x
    set-frame-parameter' to reliably complete over both documented and
    user-defined frame parameters.

Yes, that would be useful: letting users document user-defined params with a
doc string. (After the release... waiting for godot... after the release...)

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-15  1:11           ` Kevin Rodgers
  2005-12-15  2:01             ` [drew.adams@oracle.com: links in Help bufferaren'talwayscorrect] Drew Adams
@ 2005-12-15  3:16             ` Stefan Monnier
  2005-12-15 17:08             ` Richard M. Stallman
  2 siblings, 0 replies; 25+ messages in thread
From: Stefan Monnier @ 2005-12-15  3:16 UTC (permalink / raw)
  Cc: emacs-devel

> Good point.  I think that since Info-goto-node displays the *Info*
> buffer, it should be declared as an (interactive) command, and
> therefore that it should be autoloaded.

Use the `info' function, that's what it's for.


        Stefan

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-14 22:48         ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Drew Adams
  2005-12-15  1:11           ` Kevin Rodgers
@ 2005-12-15  4:39           ` Eli Zaretskii
  2005-12-15 15:39             ` bad mailer Subject meddling (was: links in Help buffer aren't always correct) Drew Adams
  2005-12-15 17:08           ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Richard M. Stallman
  2 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2005-12-15  4:39 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 14 Dec 2005 14:48:04 -0800

Drew, could you please do something about your #$%^&* mailer? Look how
it butchers the Subject lines when it thinks they are too long: it
removes whitespace and splices words, which makes it a pain to read
and use "C-c C-n" in Rmail.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* bad mailer Subject meddling (was: links in Help buffer aren't always correct)
  2005-12-15  4:39           ` Eli Zaretskii
@ 2005-12-15 15:39             ` Drew Adams
  2005-12-15 18:47               ` Alfred M. Szmidt
  2005-12-15 19:43               ` Eli Zaretskii
  0 siblings, 2 replies; 25+ messages in thread
From: Drew Adams @ 2005-12-15 15:39 UTC (permalink / raw)


    -----Original Message-----
    Subject: Re: [drew.adams@oracle.com: links in Help
    bufferaren'talwayscorrect]

    Drew, could you please do something about your #$%^&* mailer? Look how
    it butchers the Subject lines when it thinks they are too long: it
    removes whitespace and splices words, which makes it a pain to read
    and use "C-c C-n" in Rmail.

Sorry, I don't know how to fix that in Outlook. I use Outlook 2000, for
various reasons related to work. It's old, but still a very common (the most
common?) email client in use. I don't defend it, but it's the one I use.

If it produces brain-dead subject lines, but it is a very common mailer,
maybe Rmail's C-c C-n could somehow deal with it by adding extra
intelligence to handle the retarded output ;-)?  No flames please - I don't
even know what C-c C-n does, and I'm not proposing that good, free programs
bend to the idiosyncrasies of bad MS products.  I can also try to remember
to edit the Subject line, to shorten it - but that will mess up sorting
messages by Subject. Another alternative is, sad to say, using the Delete
key on posts from Drew.

Another problem I noticed with Outlook, BTW, is that even if I set the
format explicitly to "plain text", when I reply to a Unicode post the result
appears formatted. In that case, at least, I found a workaround (provided I
notice it in time): explicitly change the encoding of the message from
Unicode.

On a related subject: Unlike the posts to emacs-devel, bug reports get the
original sender's email address (e.g. "[drew.adams@oracle.com]") prepended
to the subject line, as in this one (but I removed that). That makes the
subject much longer (m u c h  longer, in some cases). Is that "feature"
really necessary or a good idea?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-14 22:48         ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Drew Adams
  2005-12-15  1:11           ` Kevin Rodgers
  2005-12-15  4:39           ` Eli Zaretskii
@ 2005-12-15 17:08           ` Richard M. Stallman
  2005-12-16 18:53             ` Kevin Rodgers
  2 siblings, 1 reply; 25+ messages in thread
From: Richard M. Stallman @ 2005-12-15 17:08 UTC (permalink / raw)
  Cc: emacs-devel

	describe-frame-parameter seems to work usefully, but it has one
	problem: its completion list is incomplete.

    Do you mean because it iterates only over the parameters of the selected
    frame?

I wasn't sure exactly what it does, but it certainly omits many
standard frame parameter names.  I don't think whether the selected
frame has a setting for a particular frame parameter ought to affect
whether I can complete its name.

    It might also include user-defined parameters that won't be documented in
    Info. Perhaps it should instead iterate over an explicit list of all of the
    Info-documented (built-in) frame parameters.

I think that is the best thing to do.  Or else get that from the
manual too.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-15  1:11           ` Kevin Rodgers
  2005-12-15  2:01             ` [drew.adams@oracle.com: links in Help bufferaren'talwayscorrect] Drew Adams
  2005-12-15  3:16             ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Stefan Monnier
@ 2005-12-15 17:08             ` Richard M. Stallman
  2 siblings, 0 replies; 25+ messages in thread
From: Richard M. Stallman @ 2005-12-15 17:08 UTC (permalink / raw)
  Cc: emacs-devel

    > Perhaps too, the doc string should mention that it only works on documented
    > built-in frame parameters, not user-defined parameters.

That goes without saying, since the point of the command is to show
the documentation, and only frame parameters with standard meanings
have standard documentation.

    Good point.  I think that since Info-goto-node displays the *Info*
    buffer, it should be declared as an (interactive) command, and
    therefore that it should be autoloaded.

It is already interactive.  However, programs normally do this
job by calling `info' or `info-other-window'.  They are autoloaded.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct)
  2005-12-15 15:39             ` bad mailer Subject meddling (was: links in Help buffer aren't always correct) Drew Adams
@ 2005-12-15 18:47               ` Alfred M. Szmidt
  2005-12-16  5:08                 ` Richard M. Stallman
  2005-12-16  7:55                 ` Eli Zaretskii
  2005-12-15 19:43               ` Eli Zaretskii
  1 sibling, 2 replies; 25+ messages in thread
From: Alfred M. Szmidt @ 2005-12-15 18:47 UTC (permalink / raw)
  Cc: emacs-devel

   If it produces brain-dead subject lines, but it is a very common mailer,
   maybe Rmail's C-c C-n could somehow deal with it by adding extra
   intelligence to handle the retarded output ;-)?  No flames please - I don't
   even know what C-c C-n does,

C-c C-n moves to the next message with the same subject.  What would
be nice is if C-c C-n (and C-c C-p) would move thread-wise based on
Message-ID, and then based on the subject.

   On a related subject: Unlike the posts to emacs-devel, bug reports get the
   original sender's email address (e.g. "[drew.adams@oracle.com]") prepended
   to the subject line, as in this one (but I removed that). That makes the
   subject much longer (m u c h  longer, in some cases). Is that "feature"
   really necessary or a good idea?

It happens when one forwards a message from rmail to someone (in this
case, emacs-devel).

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct)
  2005-12-15 15:39             ` bad mailer Subject meddling (was: links in Help buffer aren't always correct) Drew Adams
  2005-12-15 18:47               ` Alfred M. Szmidt
@ 2005-12-15 19:43               ` Eli Zaretskii
  1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2005-12-15 19:43 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 15 Dec 2005 07:39:25 -0800
> 
> Sorry, I don't know how to fix that in Outlook. I use Outlook 2000, for
> various reasons related to work. It's old, but still a very common (the most
> common?) email client in use. I don't defend it, but it's the one I use.

Perhaps you could try Emacs, if only for posting to Emacs-related
forums.

> If it produces brain-dead subject lines, but it is a very common mailer,
> maybe Rmail's C-c C-n could somehow deal with it by adding extra
> intelligence to handle the retarded output ;-)?

I thought about that, but eventually rejected the idea: it could cause
too many errors due to wrong matches.

> I don't even know what C-c C-n does

It finds the next message with the same subject.

> On a related subject: Unlike the posts to emacs-devel, bug reports get the
> original sender's email address (e.g. "[drew.adams@oracle.com]") prepended
> to the subject line

That's how Emacs formats forwarded messages.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct)
  2005-12-15 18:47               ` Alfred M. Szmidt
@ 2005-12-16  5:08                 ` Richard M. Stallman
  2005-12-16  7:55                 ` Eli Zaretskii
  1 sibling, 0 replies; 25+ messages in thread
From: Richard M. Stallman @ 2005-12-16  5:08 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

Now is the wrong time to install new features,
but we could put this into a branch that we use for Rmail improvements,
if someone wants to implement it.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: bad mailer Subject meddling (was: links in Help buffer aren't always correct)
  2005-12-15 18:47               ` Alfred M. Szmidt
  2005-12-16  5:08                 ` Richard M. Stallman
@ 2005-12-16  7:55                 ` Eli Zaretskii
  1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2005-12-16  7:55 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

> From: "Alfred M\. Szmidt" <ams@gnu.org>
> Date: Thu, 15 Dec 2005 19:47:45 +0100
> Cc: emacs-devel@gnu.org
> 
> What would be nice is if C-c C-n (and C-c C-p) would move
> thread-wise based on Message-ID, and then based on the subject.

I think this would require a total rewrite of the current code;
patches welcome (although they probably won't be released with v22.1 ;-)

I committed small changes to C-c C-n just a few days ago to fix some
problems with following tricky subjects, like those which had "Re:"
not at the beginning, and those that are broken into multiple lines in
arbitrary places.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-15 17:08           ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Richard M. Stallman
@ 2005-12-16 18:53             ` Kevin Rodgers
  0 siblings, 0 replies; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-16 18:53 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

Richard M. Stallman wrote:
> 	describe-frame-parameter seems to work usefully, but it has one
> 	problem: its completion list is incomplete.
> 
>     Do you mean because it iterates only over the parameters of the selected
>     frame?
> 
> I wasn't sure exactly what it does, but it certainly omits many
> standard frame parameter names.  I don't think whether the selected
> frame has a setting for a particular frame parameter ought to affect
> whether I can complete its name.
> 
>     It might also include user-defined parameters that won't be documented in
>     Info. Perhaps it should instead iterate over an explicit list of all of the
>     Info-documented (built-in) frame parameters.
> 
> I think that is the best thing to do.  Or else get that from the
> manual too.

OK, the attached version addresses all the points that have been raised:

* It defines a global list of documented frame parameters, which is
   initialized from the manual (using info, not Info-goto-node), and
   which can be augmented with user-defined parameters.

* The global list is actually an alist mapping parameters to their doc
   strings, so the doc strings are only extracted once from the manual
   and cached there.

* Completion uses the union of the documented frame parameters and any
   other parameters set in the selected frame.  The symbol at point is
   only provided as a default if it's a member of that union.

* The Info xrefs and indentation have been removed from the doc string,
   and it's been reformatted (filled) to account for that.

* Like variables, undocumented frame parameters are described as "not
   documented" and there's no link to the manual.

Enjoy!
-- 
Kevin

[-- Attachment #2: describe-frame-parameter.el --]
[-- Type: application/emacs-lisp, Size: 4265 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
       [not found] <E1EnQVb-00056d-Vz@fencepost.gnu.org>
@ 2005-12-19 19:22 ` Kevin Rodgers
  2005-12-20 19:10   ` Kevin Rodgers
  2005-12-23 17:07   ` Kevin Rodgers
  0 siblings, 2 replies; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-19 19:22 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

"Richard M. Stallman" <rms@gnu.org> wrote:
> It looks like this code extracts the list of frame parameter names
> when it is _loaded_.  That is inconvenient.  Could you 
> do that when the function is called for the first time?
...
> replace-regexp is meant for users; could you please write a simple
> while loop instead?

Sure, this version fixes both concerns.
-- 
Kevin

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 2803423440-describe-frame-parameter.el --]
[-- Type: text/x-emacs-lisp; name="describe-frame-parameter.el", Size: 4608 bytes --]

(defvar frame-parameter-docstring-alist nil
  "List of (PARAMETER . DOC-STRING) associations.")

(defun default-frame-parameter-docstring-alist ()
  "Return the default value of `frame-parameter-docstring-alist'."
  (save-excursion
    (save-window-excursion
      (let ((alist '())
            (pop-up-frames nil))
        (info "(elisp)Window Frame Parameters")
        (goto-char (point-min))
        (while (re-search-forward "^`\\(\\sw\\(?:\\sw\\|\\s_\\)*\\)'$" nil t)
          (let* ((parameter (intern (match-string 1)))
                 (infostring
                  (buffer-substring (1+ (point))
                                    (1- (or (re-search-forward "^`" nil t)
                                            (point-max)))))
                 (case-fold-search t)
                 (xref-regexp
                  "\\(?: (\\|; see \\)?\\*note[ \t\n]*\\(?:[^:]*\\)::[).]")
                 (xref-or-indent-regexp
                  (format "\\(%s\\)\\|\\(\n +\\)" xref-regexp))
                 (docstring
                  ;; delete Info xrefs and indentation, then reformat:
                  (with-temp-buffer
                    (insert infostring)
                    (goto-char (point-min))
                    (while (re-search-forward xref-or-indent-regexp nil t)
                      (cond ((and (match-beginning 1) (match-end 1))
                             (replace-match "" t t))
                            ((and (match-beginning 2) (match-end 2))
                             (replace-match "\n" t t))))
                    (fill-region (point-min) (point-max))
                    (buffer-string))))
            (setq alist
                  (cons (cons parameter docstring)
                        alist))
            ;; move to matched backquote at bol:
            (backward-char 1)))
        (nreverse alist)))))

(defun describe-frame-parameter (parameter &optional frame)
  "Display the full documentation of frame PARAMETER (a symbol) in FRAME.
If FRAME is nil, describe the selected frame's parameter value."
  (interactive
   (let* ((enable-recursive-minibuffers t)
          (default-param (symbol-at-point))
          ;; in Emacs 21.4 there are 41 documented frame parameters; 83
          ;; is the smallest prime that's at least twice that:
          (param-table (let ((table (make-vector 83 0)))
                         (mapc (lambda (assoc)
                                 (intern (symbol-name (car assoc)) table))
                               (or frame-parameter-docstring-alist
                                   (setq frame-parameter-docstring-alist
                                         (default-frame-parameter-docstring-alist))))
                         (mapc (lambda (assoc)
                                 (intern (symbol-name (car assoc)) table))
                               (frame-parameters nil))
                         table))
          (param-name
           (progn
             ;; make sure the default is a frame parameter:
             (setq default-param
                   (intern-soft (symbol-name default-param) param-table))
             ;; complete on both documented frame parameters and
             ;; user-defined parameters that may be set:
             (completing-read (if default-param
                                  (format "Describe parameter (default %s): "
                                          default-param)
                                "Describe parameter: ")
                              param-table
                              nil t nil nil
                              (if default-param (symbol-name default-param))))))
     (list (if (equal param-name "")
               default-param
             (intern param-name)))))
  (if (null frame)
      (setq frame (selected-frame)))
  (if (null parameter)
      (message "You did not specify a frame parameter")
    (let ((value (frame-parameter frame parameter))
          (docstring (cdr (assq parameter frame-parameter-docstring-alist))))
      (with-output-to-temp-buffer "*Help*"
        (prin1 parameter)
        (princ "'s value is ")
        (terpri)
        (with-current-buffer standard-output
          (let ((from (point)))
            (pp value)
            ;; (help-xref-on-pp from (point))
            (if (< (point) (+ from 20))
                (save-excursion
                  (goto-char from)
                  (delete-char -1)))))
        (terpri)
        (terpri)
        (princ "Documentation:")
        (terpri)
        (if docstring
            (princ docstring)
          (princ "not documented as a frame parameter."))))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
       [not found] <E1Eoa6a-0004hk-QI@fencepost.gnu.org>
@ 2005-12-20 16:09 ` Kevin Rodgers
  0 siblings, 0 replies; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-20 16:09 UTC (permalink / raw)


"Richard M. Stallman" <rms@gnu.org> wrote:
> Could you please send the change log entry?

Of course, sorry about that:

2005-12-19  Kevin Rodgers  <ihs_4664@ihs.com>

	* help.el (describe-frame-parameter): New command.
	(frame-parameter-docstring-alist): New variable.
	(default-frame-parameter-docstring-alist): New function.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-19 19:22 ` Kevin Rodgers
@ 2005-12-20 19:10   ` Kevin Rodgers
  2005-12-20 19:59     ` Stefan Monnier
  2005-12-23 17:07   ` Kevin Rodgers
  1 sibling, 1 reply; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-20 19:10 UTC (permalink / raw)


Kevin Rodgers wrote:
 > "Richard M. Stallman" <rms@gnu.org> wrote:
 >
 >>It looks like this code extracts the list of frame parameter names
 >>when it is _loaded_.  That is inconvenient.  Could you
 >>do that when the function is called for the first time?
 >
 > ...
 >
 >>replace-regexp is meant for users; could you please write a simple
 >>while loop instead?
 >
 >
 > Sure, this version fixes both concerns.

According to Stefan, the following can be simplified in Emacs 22:

 >           ;; in Emacs 21.4 there are 41 documented frame parameters; 83
 >           ;; is the smallest prime that's at least twice that:
 >           (param-table (let ((table (make-vector 83 0)))
 >                          (mapc (lambda (assoc)
 >                                  (intern (symbol-name (car assoc)) 
table))
 >                                (or frame-parameter-docstring-alist
 >                                    (setq frame-parameter-docstring-alist
 > 
(default-frame-parameter-docstring-alist))))
 >                          (mapc (lambda (assoc)
 >                                  (intern (symbol-name (car assoc)) 
table))
 >                                (frame-parameters nil))
 >                          table))

To just:

           (param-table
            (mapcar (lambda (assoc) (symbol-name (car assoc)))
                    (nconc (frame-parameters nil)
                           (or frame-parameter-docstring-alist
                               (setq frame-parameter-docstring-alist
 
(default-frame-parameter-docstring-alist))))))

-- 
Kevin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-20 19:10   ` Kevin Rodgers
@ 2005-12-20 19:59     ` Stefan Monnier
  0 siblings, 0 replies; 25+ messages in thread
From: Stefan Monnier @ 2005-12-20 19:59 UTC (permalink / raw)
  Cc: emacs-devel

> According to Stefan, the following can be simplified in Emacs 22:

And if not, I think it deserves a bug report,


        Stefan

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-19 19:22 ` Kevin Rodgers
  2005-12-20 19:10   ` Kevin Rodgers
@ 2005-12-23 17:07   ` Kevin Rodgers
  2005-12-23 17:47     ` Eli Zaretskii
  1 sibling, 1 reply; 25+ messages in thread
From: Kevin Rodgers @ 2005-12-23 17:07 UTC (permalink / raw)


Another small simplification:

 >                  (xref-or-indent-regexp
 >                   (format "\\(%s\\)\\|\\(\n +\\)" xref-regexp))
...
 >                     (while (re-search-forward xref-or-indent-regexp 
nil t)
 >                       (cond ((and (match-beginning 1) (match-end 1))
 >                              (replace-match "" t t))
 >                             ((and (match-beginning 2) (match-end 2))
 >                              (replace-match "\n" t t))))

could be:

                  (xref-or-indent-regexp
                   (concat xref-regexp "\\|^ +"))
...
                     (while (re-search-forward xref-or-indent-regexp nil t)
                       (replace-match "" t t)

-- 
Kevin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect]
  2005-12-23 17:07   ` Kevin Rodgers
@ 2005-12-23 17:47     ` Eli Zaretskii
  0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2005-12-23 17:47 UTC (permalink / raw)
  Cc: emacs-devel

> From: Kevin Rodgers <ihs_4664@yahoo.com>
> Date: Fri, 23 Dec 2005 10:07:02 -0700
> 
> Another small simplification:
> 
>  >                  (xref-or-indent-regexp
>  >                   (format "\\(%s\\)\\|\\(\n +\\)" xref-regexp))
> ...
>  >                     (while (re-search-forward xref-or-indent-regexp 
> nil t)
>  >                       (cond ((and (match-beginning 1) (match-end 1))
>  >                              (replace-match "" t t))
>  >                             ((and (match-beginning 2) (match-end 2))
>  >                              (replace-match "\n" t t))))
> 
> could be:
> 
>                   (xref-or-indent-regexp
>                    (concat xref-regexp "\\|^ +"))
> ...
>                      (while (re-search-forward xref-or-indent-regexp nil t)
>                        (replace-match "" t t)

Could you please send "diff -c" or "diff -u" style patches instead?
It is a PITA to apply such changes by hand, and on top of that, manual
patching runs a greater risk of introducing bugs.

TIA

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2005-12-23 17:47 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-13  3:15 [drew.adams@oracle.com: links in Help buffer aren't always correct] Richard Stallman
2005-12-13 17:17 ` Kevin Rodgers
2005-12-13 19:52   ` [drew.adams@oracle.com: links in Help buffer aren't alwayscorrect] Drew Adams
2005-12-13 23:53     ` Kevin Rodgers
2005-12-14 18:10       ` Kevin Rodgers
2005-12-14 20:02       ` Richard M. Stallman
2005-12-14 22:48         ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Drew Adams
2005-12-15  1:11           ` Kevin Rodgers
2005-12-15  2:01             ` [drew.adams@oracle.com: links in Help bufferaren'talwayscorrect] Drew Adams
2005-12-15  3:16             ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Stefan Monnier
2005-12-15 17:08             ` Richard M. Stallman
2005-12-15  4:39           ` Eli Zaretskii
2005-12-15 15:39             ` bad mailer Subject meddling (was: links in Help buffer aren't always correct) Drew Adams
2005-12-15 18:47               ` Alfred M. Szmidt
2005-12-16  5:08                 ` Richard M. Stallman
2005-12-16  7:55                 ` Eli Zaretskii
2005-12-15 19:43               ` Eli Zaretskii
2005-12-15 17:08           ` [drew.adams@oracle.com: links in Help buffer aren'talwayscorrect] Richard M. Stallman
2005-12-16 18:53             ` Kevin Rodgers
     [not found] <E1EnQVb-00056d-Vz@fencepost.gnu.org>
2005-12-19 19:22 ` Kevin Rodgers
2005-12-20 19:10   ` Kevin Rodgers
2005-12-20 19:59     ` Stefan Monnier
2005-12-23 17:07   ` Kevin Rodgers
2005-12-23 17:47     ` Eli Zaretskii
     [not found] <E1Eoa6a-0004hk-QI@fencepost.gnu.org>
2005-12-20 16:09 ` Kevin Rodgers

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).