Bug #29083: Is it OK to add a new function to the emacs-26 branch?

Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Alan Mackenzie]

Hello, Emacs.

This bug said that doing M-x c-defun-name failed to display the current
function name.  This is true; c-defun-name merely returns that name to
the calling lisp program, and should never have been interactive.  It's
not going to be interactive for much longer.

However, the OP has requested that a function which actually displays
this name be put into CC Mode.  Would it still be OK to do this on the
emacs-26 branch, or is this branch now closed for such things?

The function I'm proposing adding to cc-cmds.el is "harmless", having no
interaction with the rest of CC Mode.  It would look like this:

     (defun c-display-defun-name (&optional arg)
       "Display the name of the current CC mode defun and the position in it.
     With a prefix arg, push the name onto the kill ring too."
       (interactive "P")
       (save-restriction
         (widen)
         (c-save-buffer-state ((name (c-defun-name))
                               (limits (c-declaration-limits t))
                               (point-bol (c-point 'bol)))
           (when name
             (message "%s.  Line %s/%s." name
                      (1+ (count-lines (car limits) point-bol))
                      (count-lines (car limits) (cdr limits)))
             (if arg (kill-new name))
             (sit-for 3 t)))))
     (put 'c-display-defun-name 'isearch-scroll t)))

It has been well tested by me personally.

I haven't yet decided whether or not it should get a major mode key
binding, say C-c C-m.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Compro Prasad]

Seems like a good feature to me. I also didn't get anything out of
M-x c-defun-name . If it was supposed to interactive then it should
have shown the function name in the minibuffer.

But C-c C-m is same as C-c RET on my system runs M-x man .
If this was implemented then I would have to choose a new key
binding for M-x man .

Apart from that nothing worries me.

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[John Wiegley]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> However, the OP has requested that a function which actually displays this
AM> name be put into CC Mode. Would it still be OK to do this on the emacs-26
AM> branch, or is this branch now closed for such things?

I think that since we're now prepping for release with pretests out there,
it's become too late. Nothing stops us from getting a 26.2 out the door soon
after, though.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Eli Zaretskii]

> From: "John Wiegley" <johnw@gnu.org>
> Date: Wed, 01 Nov 2017 10:05:49 -0700
> Cc: emacs-devel@gnu.org
> 
> >>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:
> 
> AM> However, the OP has requested that a function which actually displays this
> AM> name be put into CC Mode. Would it still be OK to do this on the emacs-26
> AM> branch, or is this branch now closed for such things?
> 
> I think that since we're now prepping for release with pretests out there,
> it's become too late. Nothing stops us from getting a 26.2 out the door soon
> after, though.

That's true, but OTOH a new function that doesn't affect anything
(because it isn't called from any place) cannot do much harm.  So I
tend to allow this exception.

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

AM> However, the OP has requested that a function which actually displays this
AM> name be put into CC Mode. Would it still be OK to do this on the emacs-26
AM> branch, or is this branch now closed for such things?
>> 
>> I think that since we're now prepping for release with pretests out there,
>> it's become too late. Nothing stops us from getting a 26.2 out the door soon
>> after, though.

> That's true, but OTOH a new function that doesn't affect anything (because
> it isn't called from any place) cannot do much harm. So I tend to allow this
> exception.

If you're good with such an addition, Eli, then I'm OK with it too.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Alan Mackenzie]

Hello to you both.

On Wed, Nov 01, 2017 at 12:56:00 -0700, John Wiegley wrote:
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:

> AM> However, the OP has requested that a function which actually displays this
> AM> name be put into CC Mode. Would it still be OK to do this on the emacs-26
> AM> branch, or is this branch now closed for such things?

> >> I think that since we're now prepping for release with pretests out there,
> >> it's become too late. Nothing stops us from getting a 26.2 out the door soon
> >> after, though.

> > That's true, but OTOH a new function that doesn't affect anything (because
> > it isn't called from any place) cannot do much harm. So I tend to allow this
> > exception.

> If you're good with such an addition, Eli, then I'm OK with it too.

OK, thanks, I'll do this, but not tonight.

> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Stefan Monnier]

> However, the OP has requested that a function which actually displays
> this name be put into CC Mode.  Would it still be OK to do this on the
> emacs-26 branch, or is this branch now closed for such things?

FWIW, it would be even better to add this command to which-function-mode
so it can work in "any" mode.


        Stefan

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Alan Mackenzie]

Hello, Stefan.

On Fri, Nov 03, 2017 at 11:35:54 -0400, Stefan Monnier wrote:
> > However, the OP has requested that a function which actually displays
> > this name be put into CC Mode.  Would it still be OK to do this on the
> > emacs-26 branch, or is this branch now closed for such things?

> FWIW, it would be even better to add this command to which-function-mode
> so it can work in "any" mode.

which-function-mode is something a little different - it displays the
current function name continuously in the mode line.  This new feature
of mine displays the current function name in the minibuffer on typing a
key sequence.  (I am proposing C-c C-z in CC Mode.)

Am I right in thinking the meaning of your "to add this command to w-f-m"
is that
(i) There would be a command to display the current function name in the
  minibuffer, together with a line offset in it, and the other refinements
  currently in c-display-defun-name.
(ii) This command would be available regardless of whether or not w-f-m
  is currently enabled.
?

If so, I agree this is a good idea.  However it would need some key
sequence in the global map (or we could expect each user to set her own
C-c <letter> binding for it).

One disadvantage: this new facility can scarcely be included in Emacs
26, as it would be too big a change at this stage.

I would probably be prepared to work on this.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?

[Stefan Monnier]

>> FWIW, it would be even better to add this command to which-function-mode
>> so it can work in "any" mode.
> which-function-mode is something a little different - it displays the
> current function name continuously in the mode line.

Yes, I understand that.  I meant to add such a command to the same file
as which-function-mode and using the same infrastructure.

> Am I right in thinking the meaning of your "to add this command to w-f-m"
> is that
> (i) There would be a command to display the current function name in the
>   minibuffer, together with a line offset in it, and the other refinements
>   currently in c-display-defun-name.
> (ii) This command would be available regardless of whether or not w-f-m
>   is currently enabled.
> ?

Yes.

> If so, I agree this is a good idea.  However it would need some key
> sequence in the global map (or we could expect each user to set her own
> C-c <letter> binding for it).

It's not indispensable: those users who want such a feature can bind
their own key to it.

> One disadvantage: this new facility can scarcely be included in Emacs
> 26, as it would be too big a change at this stage.

That's right.  But this feature has been missing for so many years, that
delaying it a little bit, in exchange for "doing it right" seems like
a good deal.

> I would probably be prepared to work on this.

That would be wonderful.


        Stefan