Re: [NonGNU ELPA] 11 new packages!

[Philip Kaludercic <philipk@posteo.net>]

Akib Azmain Turja <akib@disroot.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Akib Azmain Turja <akib@disroot.org> writes:
>>
>>>>  ;;;###autoload
>>>>  (defun gnu-indent-region (beg end)
>>>> @@ -88,14 +87,15 @@ When called non-interactively, indent text between BEG and END."
>>>>              (send-region process beg end)
>>>>              (process-send-eof process)
>>>>              (redisplay)
>>>> -            (while (process-live-p process)
>>>> -              (sleep-for 0.01))
>>>> +            (while (accept-process-output process nil 10))
>>>
>>> MILLISEC argument is obsolete, I used SECONDS instead.
>>
>> Actually, this change might have been pointless.  I misremembed the
>> warning from (elisp) Accepting Output, that said you shouldn't combine
>> `accept-process-output' and `process-live-p', but what you were doing
>> was probably harmless.
>>
>> I guess the real question is why you don't use a synchronous process?
>> indent usually isn't that slow.
>>
>
> I don't like synchronous processes, they block Emacs completely.

What confuses me is that you manually re-create the behaviour of
blocking, which in the end probably won't even matter because indent
might even be done before you reach the first `process-live-p'.

>>>> @@ -364,6 +370,7 @@ TIME-FORMAT is used to format data."
>>>>                     'solaire-region-face
>>>>                   'region))
>>>>                ('line
>>>> +               ;; Looks like a `cond' to me
>>>>                 (if (bound-and-true-p hl-line-mode)
>>>>                     (if (bound-and-true-p solaire-mode)
>>>>                         'solaire-hl-line-face
>>>
>>> Yes, but I think its more efficient.  (IIUC cond would test hl-line-mode
>>> before returning why-this-face.)
>>
>> I don't think there would be a big difference.  The transformation I had
>> in mind was something along these lines:
>>
>> (if foo (if bar (if baz 0 1) 2) 3)
>> ⇝
>> (cond ((not foo) 3)
>>       ((not bar) 2)
>>       ((not baz) 1)
>>       (t 0))
>
> At the first glance, I though your code is simply wrong.  But after
> reading more attentively, it tells me you're actually a genius.

Humbled, but that might actually be a good argument against this change,
if it is not that intuitive.