Per Cederqvist | 4 May 2007 10:56
Favicon

accept-process-output incompatible change in CVS Emacs: patch included

This change in the upcoming Emacs 22 breaks some code:

> 2006-03-22  Kim F. Storm  <storm <at> cua.dk>
> 
> 	* process.c (Faccept_process_output): Fix to comply with lisp
> 	reference.  Change arg "timeout" to "seconds" and allow both
> 	integer and float value.  Change arg "timeout-msec" to "millisec"
> 	and interpret" as milliseconds rather than microseconds.  Fix doc
> 	string accordingly.

I enclose a patch that makes accept-process-output
backwards-compatible with Emacs 21.

One application I'm running now runs very slowly, since its carefully
tuned timeoutes are multiplied by 1000.

The third argument of the accept-process-output function used to be a
number of microseconds.  Apparently whoever wrote the GNU Emacs Lisp
Reference Manual mistook "msec" to mean milliseconds.  But the
built-in documentation in Emacs 21.3 clearly states that the argument
is in milliseconds:

> accept-process-output is a built-in function.
> (accept-process-output &optional PROCESS TIMEOUT TIMEOUT-MSECS)
> 
> Allow any pending output from subprocesses to be read by Emacs.
> It is read into the process' buffers or given to their filter functions.
> Non-nil arg PROCESS means do not return until some output has been received
> from PROCESS.
> Non-nil second arg TIMEOUT and third arg TIMEOUT-MSECS are number of
(Continue reading)

Kim F. Storm | 5 May 2007 00:33
Picon

Re: accept-process-output incompatible change in CVS Emacs: patch included

Per Cederqvist <ceder <at> ingate.com> writes:

> This change in the upcoming Emacs 22 breaks some code:
>
>> 2006-03-22  Kim F. Storm  <storm <at> cua.dk>
>> 
>> 	* process.c (Faccept_process_output): Fix to comply with lisp
>> 	reference.  Change arg "timeout" to "seconds" and allow both
>> 	integer and float value.  Change arg "timeout-msec" to "millisec"
>> 	and interpret" as milliseconds rather than microseconds.  Fix doc
>> 	string accordingly.

Please see:

http://lists.gnu.org/archive/html/emacs-devel/2006-03/msg00937.html

>
> I enclose a patch that makes accept-process-output
> backwards-compatible with Emacs 21.
>
> One application I'm running now runs very slowly, since its carefully
> tuned timeoutes are multiplied by 1000.

Well, other code believing the lisp ref, and was broken by the old
behaviour.

So just reverting the change is no good at this time.

What application is that?  

(Continue reading)

Per Cederqvist | 5 May 2007 10:42
Favicon

Re: accept-process-output incompatible change in CVS Emacs: patch included

On 5/5/07, Kim F. Storm <no-spam <at> cua.dk> wrote:
> Per Cederqvist <ceder <at> ingate.com> writes:
>
> > This change in the upcoming Emacs 22 breaks some code:
> >
> >> 2006-03-22  Kim F. Storm  <storm <at> cua.dk>
> >>
> >>      * process.c (Faccept_process_output): Fix to comply with lisp
> >>      reference.  Change arg "timeout" to "seconds" and allow both
> >>      integer and float value.  Change arg "timeout-msec" to "millisec"
> >>      and interpret" as milliseconds rather than microseconds.  Fix doc
> >>      string accordingly.
>
> Please see:
>
> http://lists.gnu.org/archive/html/emacs-devel/2006-03/msg00937.html

rms has already installed my patch, so I guess Gnus will have to be
fixed.  I was not aware that XEmacs used milliseconds.  Maybe the
documentation should be updated to tell everybody to use floating
point instead, as the interpretation of the msec argument varies.

> > I enclose a patch that makes accept-process-output
> > backwards-compatible with Emacs 21.
> >
> > One application I'm running now runs very slowly, since its carefully
> > tuned timeoutes are multiplied by 1000.
>
> Well, other code believing the lisp ref, and was broken by the old
> behaviour.
(Continue reading)

Eli Zaretskii | 5 May 2007 10:57
Picon

Re: accept-process-output incompatible change in CVS Emacs: patch included

> Date: Sat, 5 May 2007 10:42:43 +0200
> From: "Per Cederqvist" <ceder <at> ingate.com>
> 
> > What application is that?
> 
> A client to the LysKOM system, called lyskom-elisp-client.  Info about
> the entire system is available from
> http://www.lysator.liu.se/lyskom/index-en.html, and the client itself
> can be found in ftp://ftp.lysator.liu.se/pub/lyskom/elisp-client/.

So we've broken Gnus for the benefit of an obscure unbundled package.
Hardly a good decision, I'd say.
Wilmar Igl | 4 May 2007 21:10
Picon
Picon

Re: Emacs - "Save As" Dialog Window under MS Windows

Dear David,

after checking your suggestions I found out that the menu bar "save as" 
dialog does _save_ the file. It did not work in my case as my file name 
included asterisks "*", however, did not show any error message.

Therefore, the only thing that should be changed is the description of 
the button from "Open" to "Save" in the menu-driven "Save as..." dialog 
window.

Best regards,

Will

PS: Do you know whether sort of a package management system is under 
development for Emacs (e.g. based on EmacsWiki).
That would be marvellous!!!

David Vanderschel skrev:
> Hi Wilmar,
> 
> I administer help-emacs-windows.  Your message is
> subject to moderation since you do not subscribe to
> the list.  This would appear to be a bug report.  The
> appropriate list to which to send that is
> bug-gnu-emacs which you can join here:
> http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
> 
> It is not appropriate to address your message to RMS
> himself.  There is a staff of folks who support GNU
(Continue reading)

Loic Dachary | 5 May 2007 13:24
Gravatar

vc-svn.el does not implement vc-update-change-log


       Hi,

       I did not go into details but I could if someone is interested.
The svn2cl script implements the conversion from the svn log to the
ChangeLog format. Something like:

svn2cl --group-by-day --authors=$(echo $HOME)/.svn2cl --stdout | head -2000 | sed -n '0,/^2007-04-27/p'

       Does the work. It would be nice to have it under emacs the
same way it works for CVS.

       Cheers,

--

-- 
+33 1 76 60 72 81  Loic Dachary mailto:loic <at> dachary.org
http://dachary.org/loic/gpg.txt sip:loic <at> dachary.org
Latitude: 48.86962325498033 Longitude: 2.3623046278953552
Richard Stallman | 6 May 2007 01:19
Picon
Picon

Re: accept-process-output incompatible change in CVS Emacs: patch included

    > http://lists.gnu.org/archive/html/emacs-devel/2006-03/msg00937.html

    rms has already installed my patch, so I guess Gnus will have to be
    fixed.  I was not aware that XEmacs used milliseconds.

I didn't know that Gnus depended on the newer behavior
(or about XEmacs).

Both options are quite undesirable.  Damn.  But I think it is less bad
to go with the milliseconds.  So I will take out your patch.
Richard Stallman | 6 May 2007 01:19
Picon
Picon

Re: accept-process-output incompatible change in CVS Emacs: patch included

    So we've broken Gnus for the benefit of an obscure unbundled package.
    Hardly a good decision, I'd say.

Give me a break!  I didn't know Gnus depended on it.
Reindert-Jan Ekker | 7 May 2007 17:30
Picon
Favicon

highlight-changes-rotate-faces sets buffer modified flag

L.S.

Running the function highlight-changes-rotate-faces sets the buffer's 
modified flag. It seems to me that this should not happen, since only some 
faces are changed. As a workaround, I use the following advice:

;; advice for highlight-changes-rotate-faces
;; so that it does not change the modified flag for the buffer
(defadvice highlight-changes-rotate-faces (around around-rotate-faces)
   (let ((was-modified (buffer-modified-p)))
 	ad-do-it
 	(unless was-modified
 	  (set-buffer-modified-p nil))))
(ad-activate 'highlight-changes-rotate-faces)

The version string of my emacs:
"GNU Emacs 21.3.1 (i386-mingw-nt5.1.2600) of 2004-03-10 on NYAUMO"

With kind regards,

Reindert-Jan Ekker
martin rudalics | 8 May 2007 08:10
Picon
Picon

Re: highlight-changes-rotate-faces sets buffer modified flag

 > Running the function highlight-changes-rotate-faces sets the buffer's
 > modified flag. It seems to me that this should not happen, since only
 > some faces are changed.

Thank you for sending a report on this.  In principle a "face change"
may change the buffer-modified state and can be undone as well.  In the
present case I agree with you that the buffer-modified state should not
change.  I believe that most of theses face changes were obscured by
changes in the buffer text, hence probably people didn't notice.

 > As a workaround, I use the following advice:
 >
 >
 > ;; advice for highlight-changes-rotate-faces
 > ;; so that it does not change the modified flag for the buffer
 > (defadvice highlight-changes-rotate-faces (around around-rotate-faces)
 >   (let ((was-modified (buffer-modified-p)))
 >         ad-do-it
 >         (unless was-modified
 >           (set-buffer-modified-p nil))))
 > (ad-activate 'highlight-changes-rotate-faces)

You proably do not want adding an entry to `buffer-undo-list' either.

 >
 >
 > The version string of my emacs:
 > "GNU Emacs 21.3.1 (i386-mingw-nt5.1.2600) of 2004-03-10 on NYAUMO"

AFAICT this problem is still present in Emacs 22.  In addition, it seems
(Continue reading)


Gmane