emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 26.1 release branch created


From: Alan Mackenzie
Subject: Re: Emacs 26.1 release branch created
Date: Sun, 24 Sep 2017 20:18:06 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Paul.

On Sun, Sep 24, 2017 at 11:13:06 -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:

> > Putting a single output
> > operation through two `format'-like operations is bizarre and
> > extravagant.  It's not something we should encourage.

> It's not bizarre; it's routine in Emacs Lisp code.

It occurs once in Emacs Lisp code, in cc-engine.el.  I doubt it's used
more than once, and you are remarkably evasive about this point.

> And it's not extravagant: the loss in efficiency for messages is tiny,
> and is not something users have noticed or complained about.

But it's a loss of efficiency nevertheless, no matter how slight.
You've given no reasons to use it, other than "we've already used it
once", which is a poor reason.

> > By contrast, binding a controlling variable around an operation is the
> > standard Emacs way of doing such things.

> It's standard for other things, but it's definitely not standard here. The 
> Emacs 
> source code never does it this way.

It soon will, once I amend cc-engine.el.

> > How many such instances are there in the code anyway?

[ Trim evasive non-answer ]

Why won't you anwer this question, Paul?  Why do you twist my text by
selective quoting?  What are you trying to hide?  Once again, how many
instances of this double format technique exist in the Lisp code?  Cite
another one which isn't in cc-engine.el.

> > This would need fleshing out with something like "To inhibit
> > or influence this translation of ASCII quotes, see text-quoting-style".

> Sure, that's easy. Revised proposal attached.

Thanks, I'll read it.

> > The "boilerplate" you want to replace is short and to the point,

> It is not short; it's discursive and it gets in the way. In your proposal, 
> it's 
> about ten lines of boilerplate for each affected function, ....

of which I've contributed only around three lines.  "Boilerplate" is
hardly an accurate term for it, since it only occurs three times, and
it's essential information for users of these functions, which would get
lost if moved into a separate page.

> .... boilerplate that is about as long as the main function
> description itself. We should move most of this boilerplate to a
> common section, and briefly allude to it in each affected function.
> This will give us room to expand on the issue in the common section,
> which I've done in my proposal - it has about twenty lines discussing
> the issue, and this is shorter and provides more useful info than
> repeating ten lines in multiple places.

> > A further general point about this bit of doc is its rather strange use
> > of the verb "generate".

> Also easy; the revised proposal (attached) uses "translates to" instead of 
> "generates".

Thanks.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]