Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Stefan Monnier]

>     Allow newlines inside cl function arglists
    
>     * lisp/help.el (help-add-fundoc-usage): Allow newlines inside
>     ARGLIST (bug#21839).

Why?  This is problematic since it might be difficult to adjust
help-split-fundoc correspondingly.


        Stefan

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/10/2016 04:34 AM, Stefan Monnier wrote:

> Why?

Because nobody has proposed a better patch until now.

> This is problematic since it might be difficult to adjust
> help-split-fundoc correspondingly.

We already have this problem with e.g.

   (cl-defgeneric asdasd (&optional (separator "\n")))

because when that is evaluated, ARGLIST passed to help-add-fundoc-usage 
is a form, not a string. I think it's better than not being able to 
define the function at all.

We could escape the newlines in the returned string. What's the best 
place to do that? Do we have a handier function that turns "\n" into 
"\\n", and does the same for \r, \t, and maybe unprintable characters?

This seems to work:

diff --git a/lisp/help.el b/lisp/help.el
index 7289375..4bd9cc1 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -1394,11 +1394,14 @@ help-add-fundoc-usage
  	    (if (string-match "\n?\n\\'" docstring)
  		(if (< (- (match-end 0) (match-beginning 0)) 2) "\n" "")
  	      "\n\n")
-	    (if (stringp arglist)
-                (if (string-match "\\`[^ ]+\\(\\(?:.\\|\n\\)*\\))\\'" 
arglist)
-                    (concat "(fn" (match-string 1 arglist) ")")
-                  (error "Unrecognized usage format"))
-	      (help--make-usage-docstring 'fn arglist)))))
+            (replace-regexp-in-string
+             "\n" "\\n"
+             (if (stringp arglist)
+                 (if (string-match "\\`[^ ]+\\(\\(?:.\\|\n\\)*\\))\\'" 
arglist)
+                     (concat "(fn" (match-string 1 arglist) ")")
+                   (error "Unrecognized usage format"))
+               (help--make-usage-docstring 'fn arglist))
+             t t))))

  (defun help-function-arglist (def &optional preserve-names)
    "Return a formal argument list for the function DEF.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> We could escape the newlines in the returned string. What's the best place
> to do that? Do we have a handier function that turns "\n" into "\\n",

print-escape-newlines

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/10/2016 01:21 PM, Andreas Schwab wrote:

> print-escape-newlines

Close, but I don't think we want to see the quotes around the fundoc 
usage, or see the quotes inside escaped, like:

"(fn &optional (SEPARATOR \"\n\"))"

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05/10/2016 01:21 PM, Andreas Schwab wrote:
>
>> print-escape-newlines
>
> Close, but I don't think we want to see the quotes around the fundoc
> usage, or see the quotes inside escaped, like:
>
> "(fn &optional (SEPARATOR \"\n\"))"

I don't understand.  How does print-escape-newlines have any effect on
quoting quotes?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/10/2016 02:27 PM, Andreas Schwab wrote:

> I don't understand.  How does print-escape-newlines have any effect on
> quoting quotes?

It only affects prin1, right? That function affects quotes.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05/10/2016 02:27 PM, Andreas Schwab wrote:
>
>> I don't understand.  How does print-escape-newlines have any effect on
>> quoting quotes?
>
> It only affects prin1, right? That function affects quotes.

I still don't understand.  print-escape-newlines doesn't change that.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/10/2016 02:57 PM, Andreas Schwab wrote:

> I still don't understand.  print-escape-newlines doesn't change that.

help-add-fundoc-usage does not currently use prin1. To use the variable 
you suggested, it'll have to.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> help-add-fundoc-usage does not currently use prin1.

Yes, it does, via format.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/10/2016 03:36 PM, Andreas Schwab wrote:
>> help-add-fundoc-usage does not currently use prin1.
>
> Yes, it does, via format.

OK, it does, in the "else" branch. But what will we do in the (stringp 
arglist) case? format with %s does not use prin1, and we're back to the 
same problem: %S would add the unwanted quotes and escapes.

Maybe if that case were to be eliminated in the callers... but that's 
not a change for emacs-25.

To be clear, this is what doesn't work:

diff --git a/lisp/help.el b/lisp/help.el
index 7289375..5e66042 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -1394,11 +1394,12 @@ help-add-fundoc-usage
  	    (if (string-match "\n?\n\\'" docstring)
  		(if (< (- (match-end 0) (match-beginning 0)) 2) "\n" "")
  	      "\n\n")
-	    (if (stringp arglist)
-                (if (string-match "\\`[^ ]+\\(\\(?:.\\|\n\\)*\\))\\'" 
arglist)
-                    (concat "(fn" (match-string 1 arglist) ")")
-                  (error "Unrecognized usage format"))
-	      (help--make-usage-docstring 'fn arglist)))))
+            (let ((print-escape-newlines t))
+              (if (stringp arglist)
+                  (if (string-match "\\`[^ ]+\\(\\(?:.\\|\n\\)*\\))\\'" 
arglist)
+                      (format "(fn%s)" (match-string 1 arglist))
+                    (error "Unrecognized usage format"))
+                (help--make-usage-docstring 'fn arglist))))))

  (defun help-function-arglist (def &optional preserve-names)
    "Return a formal argument list for the function DEF.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Stefan Monnier]

> OK, it does, in the "else" branch. But what will we do in the (stringp
> arglist) case?

We could document that if arglist is a string, it is not allowed to
contain a newline.


        Stefan

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/11/2016 12:14 AM, Stefan Monnier wrote:
>> OK, it does, in the "else" branch. But what will we do in the (stringp
>> arglist) case?
>
> We could document that if arglist is a string, it is not allowed to
> contain a newline.

OK. That's not a 100% solution, though. Is there some place up the call 
stack we could make sure the newlines are escaped when the arglist 
string is constructed?

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/11/2016 12:26 AM, Dmitry Gutov wrote:

> Is there some place up the call
> stack we could make sure the newlines are escaped when the arglist
> string is constructed?

...and this was rather easy. Seems to work fine. Comments?

diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index ae52e8b..68abe67 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -299,7 +299,8 @@ cl--transform-lambda
                                 ;; Be careful with make-symbol and 
(back)quote,
                                 ;; see bug#12884.
                                 (help--docstring-quote
-                                (let ((print-gensym nil) (print-quoted t))
+                                (let ((print-gensym nil) (print-quoted t)
+                                      (print-escape-newlines t))
                                    (format "%S" (cons 'fn 
(cl--make-usage-args
                                                            orig-args))))))
                                header)))
diff --git a/lisp/help.el b/lisp/help.el
index 7289375..57f358b 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -1395,7 +1395,7 @@ help-add-fundoc-usage
  		(if (< (- (match-end 0) (match-beginning 0)) 2) "\n" "")
  	      "\n\n")
  	    (if (stringp arglist)
-                (if (string-match "\\`[^ ]+\\(\\(?:.\\|\n\\)*\\))\\'" 
arglist)
+                (if (string-match "\\`[^ ]+\\(.*\\))\\'" arglist)
                      (concat "(fn" (match-string 1 arglist) ")")
                    (error "Unrecognized usage format"))
  	      (help--make-usage-docstring 'fn arglist)))))
@@ -1468,7 +1468,8 @@ help--make-usage
  (define-obsolete-function-alias 'help-make-usage 'help--make-usage "25.1")

  (defun help--make-usage-docstring (fn arglist)
-  (help--docstring-quote (format "%S" (help--make-usage fn arglist))))
+  (let ((print-escape-newlines t))
+    (help--docstring-quote (format "%S" (help--make-usage fn arglist)))))

  \f
  (provide 'help)

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[John Wiegley]

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

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

>     * lisp/help.el (help-add-fundoc-usage): Allow newlines inside
>     ARGLIST (bug#21839).

Hi Dmitry!

Indeed this bug is in our blocking list, according to debbugs. So thank you
very much for the fix! What I can't imagine is this being a release blocker
for 25.1

I'm wondering if you and some of other core devs would be willing to spend a
few days scanning through the blocking bugs list[1], to see which ones really
need to be fixed in the next month, and which can be deferred until later?
This one was very nearly wishlist, in my opinion, though I haven't run into
the problem enough for it to have bothered me personally.

Footnotes: 
[1]  https://debbugs.gnu.org/db/19/19759.html

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Dmitry Gutov]

On 05/11/2016 03:39 AM, Dmitry Gutov wrote:

> ...and this was rather easy. Seems to work fine. Comments?

Pushed. Andreas, thanks for the idea.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Tue, 10 May 2016 18:47:08 -0700
> Cc: Andrew Hyatt <ahyatt@gmail.com>, Artur Malabarba <arturmalabarba@gmail.com>,
> 	Dmitry Gutov <dgutov@yandex.ru>, Alan Mackenzie <acm@muc.de>,
> 	Eli Zaretskii <eliz@gnu.org>, Lars Ingebrigtsen <larsi@gnus.org>
> 
> I'm wondering if you and some of other core devs would be willing to spend a
> few days scanning through the blocking bugs list[1], to see which ones really
> need to be fixed in the next month, and which can be deferred until later?

We'd need clear criteria for nominating blocking bug reports.  Could
you publish what you think should be those criteria?

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[John Wiegley]

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

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

>> From: John Wiegley <johnw@gnu.org>
>> 
>> I'm wondering if you and some of other core devs would be willing to spend a
>> few days scanning through the blocking bugs list[1], to see which ones really
>> need to be fixed in the next month, and which can be deferred until later?

> We'd need clear criteria for nominating blocking bug reports. Could you
> publish what you think should be those criteria?

Sure, that's a great question. These would be my criteria at this point:

A bug should be considered release blocking for 25.1 if:

  1. It causes loss of user data.

  2. It renders core functionality unusable without any acceptable workaround.
     This includes: crashing, hanging, runaway memory consumption, exhaustion
     of limited resources such as file handles, etc.

     The extent of "core" is open to debate, but basically I mean features
     used by a great many users.

  3. The presence of the bug makes basic functionality annoying or cumbersome.

  4. The presence of the bug would cause widespread breakage in community
     packages, unless there is an acceptable upgrade path.

  5. It impairs the goals of the Free Software Foundation.

In other words, as long as the presence of bug X doesn't make Emacs unsuitable
for use, I'm willing to live with bug X until the next point release.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Removing bugs from the blockers

[Dmitry Gutov]

On 05/11/2016 04:47 AM, John Wiegley wrote:

> Indeed this bug is in our blocking list, according to debbugs. So thank you
> very much for the fix! What I can't imagine is this being a release blocker
> for 25.1

It seems minor, but it made a certain kind of functions impossible to 
define. Which makes it a regression, at least in theory.

And since someone noticed it, Elisp code that triggers it likely exists 
in the wild.

> I'm wondering if you and some of other core devs would be willing to spend a
> few days scanning through the blocking bugs list[1], to see which ones really
> need to be fixed in the next month, and which can be deferred until later?

I'm fuzzy on what "really need" means, but:

20420 is not very important, and likely wontfix.
22107 - same.
22527 is not very important.
19479 is a crapfest, and is unlikely to be fixed soon (we haven't even 
fixed the basic signature verification functionality yet, see the other 
bugs, and that's shameful).

> This one was very nearly wishlist, in my opinion, though I haven't run into
> the problem enough for it to have bothered me personally.

I've fixed a lot of bugs that haven't bothered me personally. The fix 
wasn't too hard anyway.

Re: Removing bugs from the blockers

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 13 May 2016 00:35:37 +0300
> 
> 20420 is not very important, and likely wontfix.
> 22107 - same.
> 22527 is not very important.
> 19479 is a crapfest, and is unlikely to be fixed soon (we haven't even 
> fixed the basic signature verification functionality yet, see the other 
> bugs, and that's shameful).

Agreed.  Additional triage:

22434 -- caused by fixing another bug, affects a minor feature, and
      	 won't be fixed unless someone motivated works on it
23144 -- we don't know how to fix it; maybe talking to GTK maintainers
      	 could help
22884 -- IMO we did everything possible, so the bug could be closed
22338 -- shows up only in rare situations, and reasons are not well
      	 understood; suggest to close
17976 -- actually, a feature request, so should not be blocking
20352 -- I thought this was recently resolved, no?
21489 -- is most probably the result of refactoring of keystroke
      	 echoing, and probably won't be fixed
17693 -- not reproducible on my machine, and no one responded to my
      	 request for reproduction
23360 -- does anyone have a better idea than introducing a variable to
      	 control the affected code (which is mostly unneeded, but
      	 sometimes is)?
22440 -- someone who knows about package.el should look at this
21650 -- MH-E bug, handled there
23513 -- includes a patch; someone who knows about package.el should
      	 look at this
22795 -- not reproducible, should probably be closed, as I've not
      	 heard from the OP for a long time
22465 -- includes a patch that should be applied, and the bug closed
20247 -- appears in very rare situations, so shouldn't block the
      	 release
21182 -- the blamed commit seems unrelated, so should probably be
      	 tagged not reproducible
19548 -- is worded too generally, and is therefore hard to work on;
      	 perhaps Glenn could make post specific complaints, which then
      	 could be handled one by one
23050 -- is a manifestation of an old bug 18125, and also includes 2
      	 ideas for solution; also, is specific to a certain workflow,
      	 so there's a workaround
21871 -- discussion ends with an unanswered question to Stefan
22527 -- sounds like it should be closed?
21422 -- my opinion on that is in the discussion; 'nuff said
19717 -- a patch was suggested not long ago; can someone review it?
21874 -- sounds like it should be closed?
22295 -- undo-related, I hope Phillip will be able to look into it
22147 -- should be closed, I think (why is it on the blocking list?)

My conclusion from reviewing these bugs is: I don't really understand
how come some of the bugs were designated as "blocking".

A more general conclusion (from both these and other bug reports) is
that we tend to break valid use cases when we refactor some core parts
of Emacs, and the people who worked on refactoring are not always
willing to work on cleaning up the breakage it caused.  For example,
the above list includes a few bugs for which the offending commit was
identified, but the guilty parties don't seem to be eager to work on
that.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: emacs-devel@gnu.org,  dgutov@yandex.ru,  larsi@gnus.org,  ahyatt@gmail.com,  arturmalabarba@gmail.com,  acm@muc.de
> Date: Thu, 12 May 2016 14:23:05 -0700
> 
> A bug should be considered release blocking for 25.1 if:
> 
>   1. It causes loss of user data.
> 
>   2. It renders core functionality unusable without any acceptable workaround.
>      This includes: crashing, hanging, runaway memory consumption, exhaustion
>      of limited resources such as file handles, etc.
> 
>      The extent of "core" is open to debate, but basically I mean features
>      used by a great many users.
> 
>   3. The presence of the bug makes basic functionality annoying or cumbersome.
> 
>   4. The presence of the bug would cause widespread breakage in community
>      packages, unless there is an acceptable upgrade path.
> 
>   5. It impairs the goals of the Free Software Foundation.

Thanks.  However, items 3 and 4 are IMO too vague, and can fit almost
any issue, as the criteria are open to subjective interpretation.

Also, we used to have criteria related to the age of the bug, on the
assumption that old bugs are less likely to be critical.  I'm not
saying that we must keep such a criterion, but I think it should at
least be considered for inclusion.

> In other words, as long as the presence of bug X doesn't make Emacs unsuitable
> for use, I'm willing to live with bug X until the next point release.

This sounds like much more stringent criterion than the others.

Re: Removing bugs from the blockers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> My conclusion from reviewing these bugs is: I don't really understand
> how come some of the bugs were designated as "blocking".

Did you remove the "block" from the bugs you didn't feel were
block-worthy?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Removing bugs from the blockers

[Kaushal Modi]

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

On Thu, May 12, 2016, 5:35 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> 20420 is not very important, and likely wontfix.
> 22107 - same.
>

About 22107, at this point it is a documentation bug. this-command-keys and
this-single-command-keys are equivalent (more info towards the end of that
bug thread). But the documentaion still says that this-single-command-keys
does not return prefix argument unlike this-command-keys. In fact, none of
them return the prefix arg. So the docstring needs to be fixed.

> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 960 bytes --]

Re: Removing bugs from the blockers

[Dmitry Gutov]

On 05/13/2016 02:30 PM, Kaushal Modi wrote:

> About 22107, at this point it is a documentation bug. this-command-keys
> and this-single-command-keys are equivalent (more info towards the end
> of that bug thread). But the documentaion still says that
> this-single-command-keys does not return prefix argument unlike
> this-command-keys. In fact, none of them return the prefix arg. So the
> docstring needs to be fixed.

Makes sense. But could we please contain the in-depth discussions to the 
respective bug threads?

Re: Removing bugs from the blockers

[Dmitry Gutov]

On 05/13/2016 11:36 AM, Eli Zaretskii wrote:

> 22884 -- IMO we did everything possible, so the bug could be closed

Not closed, but not blocker either. See my last comment in there.

> 22338 -- shows up only in rare situations, and reasons are not well
>       	 understood; suggest to close

I think there's something left to investigate there, but also not a blocker.

> 17976 -- actually, a feature request, so should not be blocking

It's a bug, but an old one. It had appeared in a few reports already. 
Also not a blocker.

> 20352 -- I thought this was recently resolved, no?

Not sure. But the bug is discussing master, so it's probably not a 
blocker for 25.1. (If you think it should be closed, please post there).

> 17693 -- not reproducible on my machine, and no one responded to my
>       	 request for reproduction

Until someone reconfirms, it should be made a non-blocker. Probably 
close it if it's silent for a couple of months after today.

> 22440 -- someone who knows about package.el should look at this

> 23513 -- includes a patch; someone who knows about package.el should
>       	 look at this

I will if nobody else does.

> 19548 -- is worded too generally, and is therefore hard to work on;
>       	 perhaps Glenn could make post specific complaints, which then
>       	 could be handled one by one

Yes, aside from improving the situation with vc-cvs-stay-local and 
checking that NEWS includes the major changes, I'm not sure what else to 
do. Look through the manual for outdated information?

> 23050 -- is a manifestation of an old bug 18125, and also includes 2
>       	 ideas for solution; also, is specific to a certain workflow,
>       	 so there's a workaround

If Glenn's proposal would work, we could have it in emacs-25. Otherwise, 
not a blocker.

> 21871 -- discussion ends with an unanswered question to Stefan

The question seems rhetorical (unless we want Stefan to fix the bug 
himself).

> 22527 -- sounds like it should be closed?

It describes a problem, so probably not.

> 21422 -- my opinion on that is in the discussion; 'nuff said

Actually, I've fixed the biggest pain point there, so it can be made 
non-blocker.

> 19717 -- a patch was suggested not long ago; can someone review it?

The patch looks trivial (one should notice right away if it doesn't 
work). Someone who's used printing.el at least once in their life should 
try and install it.

> 22147 -- should be closed, I think

Probably.

> (why is it on the blocking list?)

Maybe because the description made is sound like it's a regression.

> My conclusion from reviewing these bugs is: I don't really understand
> how come some of the bugs were designated as "blocking".

The blocking list is largely maintained by one person who cannot 
understand everything.

> A more general conclusion (from both these and other bug reports) is
> that we tend to break valid use cases when we refactor some core parts
> of Emacs, and the people who worked on refactoring are not always
> willing to work on cleaning up the breakage it caused.  For example,
> the above list includes a few bugs for which the offending commit was
> identified, but the guilty parties don't seem to be eager to work on
> that.

Not sure what do do about that. Revoke commit access? Drop to GNU ELPA 
or obsolete older and/or niche packages like Viper?

Re: Removing bugs from the blockers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  emacs-devel@gnu.org
> Date: Fri, 13 May 2016 12:30:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My conclusion from reviewing these bugs is: I don't really understand
> > how come some of the bugs were designated as "blocking".
> 
> Did you remove the "block" from the bugs you didn't feel were
> block-worthy?

I didn't set the indication, so I don't feel myself authorized to
remove it unilaterally.

Re: [Emacs-diffs] emacs-25 d0d9f55: Allow newlines inside cl function arglists

[John Wiegley]

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

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

>> 3. The presence of the bug makes basic functionality annoying or cumbersome.
>> 
>> 4. The presence of the bug would cause widespread breakage in community
>> packages, unless there is an acceptable upgrade path.

> Thanks. However, items 3 and 4 are IMO too vague, and can fit almost any
> issue, as the criteria are open to subjective interpretation.

Yes, if a person lobbies for a bug to be included in the blocking list under
these criteria, they'd need to do some convincing on these points.

> Also, we used to have criteria related to the age of the bug, on the
> assumption that old bugs are less likely to be critical. I'm not saying that
> we must keep such a criterion, but I think it should at least be considered
> for inclusion.

Sure, I'd be willing to add this.  A bug that's been in the past 5 versions of
Emacs can likely be in a 6th.

>> In other words, as long as the presence of bug X doesn't make Emacs
>> unsuitable for use, I'm willing to live with bug X until the next point
>> release.

> This sounds like much more stringent criterion than the others.

I meant it to summarize what a bug should "feel" like to be considered
blocking, but I didn't add it to the list. "Unsuitable" is even vaguer still.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Removing bugs from the blockers

[John Wiegley]

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

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

>> Did you remove the "block" from the bugs you didn't feel were
>> block-worthy?

> I didn't set the indication, so I don't feel myself authorized to remove it
> unilaterally.

Eli, please manage the blocking list as you see fit.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Removing bugs from the blockers

[John Wiegley]

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

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

> My conclusion from reviewing these bugs is: I don't really understand how
> come some of the bugs were designated as "blocking".

From my experience working on other projects: there comes a time when people
start noticing that "blocking" bugs get fixed sooner than other bugs, so they
start adding things they "think should be fixed", without asking whether it's
truly a blocking bug.

At Borland we called it "Priority 0"; and guess what happened: nearly every
new bug started getting assigned priority 0, because for a while they were the
only bugs we were paying attention to.

Periodically the blocking list needs recalibration, to return it to its
original purpose. I'd say please unblock every bug you mentioned.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Removing bugs from the blockers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't set the indication, so I don't feel myself authorized to
> remove it unilaterally.

Everybody involved in Emacs can set the blockiness, so everybody
involved in Emacs should feel enabled to remove blockiness, I think.
It's all (mostly) just a matter of taste and opinion, after all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Removing bugs from the blockers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Fri, 13 May 2016 22:20:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I didn't set the indication, so I don't feel myself authorized to
> > remove it unilaterally.
> 
> Everybody involved in Emacs can set the blockiness, so everybody
> involved in Emacs should feel enabled to remove blockiness, I think.
> It's all (mostly) just a matter of taste and opinion, after all.

Yes, and the above is _my_ opinion (and the way I like to do business
in community projects in general).

Re: Removing bugs from the blockers

[Nix]

On 13 May 2016, Eli Zaretskii uttered the following:

> 21182 -- the blamed commit seems unrelated, so should probably be
>       	 tagged not reproducible

FWIW, I'm getting back into Emacs development now (a little late --
anything I discover will be much too late for 25.1!) and will endeavour
to replicate this bugger on a sacrificial mailbox. (I suspect it is a
bug of some sort related to work's rather bizarre Beehive mail system,
so the only person on this list who would be likely to have been able to
reproduce it is Drew, and he doesn't use Gnus... so the onus is on me to
look at this rather than simply locally reverting the commit as I have
up till now.)

It is definitely not a release blocker, given the huge number of person
it affects :)

-- 
NULL && (void)

bug#21182 (was Removing bugs from the blockers)

[Mike Kupfer]

Nix wrote:

> > 21182 -- the blamed commit seems unrelated, so should probably be
> >       	 tagged not reproducible
> 
> [...] (I suspect it is a
> bug of some sort related to work's rather bizarre Beehive mail system,

I use Beehive at $DAYJOB, and I sometimes use Gnus (both Emacs 24.5 and
Emacs 25) for it.  I haven't seen the symptoms reported in the bug,
though I have seen other issues (bug 22590 in particular).

Do you use the Gnus agent or registry?  (I use neither one.)

Can you look at the messages using some other application, e.g.,
Thunderbird or Zimbra?  Does the other application show the messages as
read?

When Gnus shows the message as read, what mark does it use ("O", "M",
etc)?

regards,
mike

Re: bug#21182 (was Removing bugs from the blockers)

[Nix]

On 9 Jun 2016, Mike Kupfer told this:

> Nix wrote:
>
>> > 21182 -- the blamed commit seems unrelated, so should probably be
>> >       	 tagged not reproducible
>> 
>> [...] (I suspect it is a
>> bug of some sort related to work's rather bizarre Beehive mail system,
>
> I use Beehive at $DAYJOB, and I sometimes use Gnus (both Emacs 24.5 and
> Emacs 25) for it.  I haven't seen the symptoms reported in the bug,
> though I have seen other issues (bug 22590 in particular).
>
> Do you use the Gnus agent or registry?  (I use neither one.)

I use the registry, but not the agent.

> Can you look at the messages using some other application, e.g.,
> Thunderbird or Zimbra?  Does the other application show the messages as
> read?

Yes -- indeed, I will rely on this in testing, since otherwise I'd have
no real way to mark the contents of my "sacrificial mailbox" as unread
again to retest :) thank goodness it only does it on entry to the group,
not on every refresh, or I'd be unable to test this without wrecking all
the read marks on all my work email!

> When Gnus shows the message as read, what mark does it use ("O", "M",
> etc)?

I honestly can't remember, but I think it was O (M is rare enough that I
remember it when it appears). I'll check when I replicate this, probably
this weekend.

-- 
NULL && (void)