unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Bug #29083: Is it OK to add a new function to the emacs-26 branch?
@ 2017-11-01 11:21 Alan Mackenzie
  2017-11-01 13:27 ` Compro Prasad
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Alan Mackenzie @ 2017-11-01 11:21 UTC (permalink / raw)
  To: emacs-devel

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).



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-01 11:21 Bug #29083: Is it OK to add a new function to the emacs-26 branch? Alan Mackenzie
@ 2017-11-01 13:27 ` Compro Prasad
  2017-11-01 17:05 ` John Wiegley
  2017-11-03 15:35 ` Stefan Monnier
  2 siblings, 0 replies; 9+ messages in thread
From: Compro Prasad @ 2017-11-01 13:27 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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.



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-01 11:21 Bug #29083: Is it OK to add a new function to the emacs-26 branch? Alan Mackenzie
  2017-11-01 13:27 ` Compro Prasad
@ 2017-11-01 17:05 ` John Wiegley
  2017-11-01 19:43   ` Eli Zaretskii
  2017-11-03 15:35 ` Stefan Monnier
  2 siblings, 1 reply; 9+ messages in thread
From: John Wiegley @ 2017-11-01 17:05 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

>>>>> "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



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-01 17:05 ` John Wiegley
@ 2017-11-01 19:43   ` Eli Zaretskii
  2017-11-01 19:56     ` John Wiegley
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2017-11-01 19:43 UTC (permalink / raw)
  To: John Wiegley; +Cc: acm, emacs-devel

> 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.



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-01 19:43   ` Eli Zaretskii
@ 2017-11-01 19:56     ` John Wiegley
  2017-11-02 19:24       ` Alan Mackenzie
  0 siblings, 1 reply; 9+ messages in thread
From: John Wiegley @ 2017-11-01 19:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: acm, emacs-devel

>>>>> 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



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-01 19:56     ` John Wiegley
@ 2017-11-02 19:24       ` Alan Mackenzie
  0 siblings, 0 replies; 9+ messages in thread
From: Alan Mackenzie @ 2017-11-02 19:24 UTC (permalink / raw)
  To: Eli Zaretskii, emacs-devel

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).



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-01 11:21 Bug #29083: Is it OK to add a new function to the emacs-26 branch? Alan Mackenzie
  2017-11-01 13:27 ` Compro Prasad
  2017-11-01 17:05 ` John Wiegley
@ 2017-11-03 15:35 ` Stefan Monnier
  2017-11-03 16:22   ` Alan Mackenzie
  2 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2017-11-03 15:35 UTC (permalink / raw)
  To: emacs-devel

> 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




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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-03 15:35 ` Stefan Monnier
@ 2017-11-03 16:22   ` Alan Mackenzie
  2017-11-03 17:04     ` Stefan Monnier
  0 siblings, 1 reply; 9+ messages in thread
From: Alan Mackenzie @ 2017-11-03 16:22 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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).



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

* Re: Bug #29083: Is it OK to add a new function to the emacs-26 branch?
  2017-11-03 16:22   ` Alan Mackenzie
@ 2017-11-03 17:04     ` Stefan Monnier
  0 siblings, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2017-11-03 17:04 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

>> 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



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

end of thread, other threads:[~2017-11-03 17:04 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-01 11:21 Bug #29083: Is it OK to add a new function to the emacs-26 branch? Alan Mackenzie
2017-11-01 13:27 ` Compro Prasad
2017-11-01 17:05 ` John Wiegley
2017-11-01 19:43   ` Eli Zaretskii
2017-11-01 19:56     ` John Wiegley
2017-11-02 19:24       ` Alan Mackenzie
2017-11-03 15:35 ` Stefan Monnier
2017-11-03 16:22   ` Alan Mackenzie
2017-11-03 17:04     ` Stefan Monnier

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).