Re: process output has become a bit random...

David Kastrup <dak <at> gnu.org> writes:

> storm <at> cua.dk (Kim F. Storm) writes:
> 
> > storm <at> cua.dk (Kim F. Storm) writes:
> > 
> > > Could you try to set readmax to 1024 ?
> > >
> > > That may break UDP packet receive, but it isn't relevant for this case.
> > 
> > 
> > Could you also try the following patch (with readmax=4096).
> > 
> > I don't expect it to make a lot of difference, but just to rule out
> > the obvious...
> 
> [...]
> 
> Sorry for the delay, had to go climbing.  The patch does not cure the
> problem.  The problem still occurs with comparable severity.

However, the following patch cures everything then:

This might explain why the changes in buffer size that I did
previously triggered problems: that way the buffer could get larger
than this threshold of 1024 bytes.  It would appear that as soon as

Re: copyright.el

    There is an apparent bug in copyright.el.

    variables.texi contains:

Does this give good results?

*** copyright.el	07 Jan 2004 08:15:08 -0500	1.46
--- copyright.el	31 Jul 2004 21:04:36 -0400	
***************
*** 54,59 ****
--- 54,66 ----
    :group 'copyright
    :type 'regexp)

+ (defcustom copyright-years-regexp
+  "\\(\\s *\\)\\([1-9]\\([-0-9, ';/*%#\n\t]\\|\\s<\\|\\s>\\)*[0-9]+\\)"
+   "*Match additional copyright notice years.
+ The second \\( \\) construct must match the years."
+   :group 'copyright
+   :type 'regexp)
+ 

  (defcustom copyright-query 'function
    "*If non-nil, ask user before changing copyright.
***************
*** 77,82 ****
--- 84,106 ----

  (defun copyright-update-year (replace noquery)
    (when (re-search-forward copyright-regexp (+ (point) copyright-limit) t)

Re: Repeating tag searches does no longer work.

[This started with a bug report of me on the bug list]

Richard Stallman <rms <at> gnu.org> writes:

>     M-. RET M-, on some suitable tag word will just barf.  See input and
>     messages below:
> 
> I don't think this is a bug.  M-, is meant to repeat a tags-search or
> tags-query-replace command.  It does not work with M-.

Uh, yes.  It is C-u M-. that repeats M-.  Sorry for the false alarm.
Would there be drawbacks if M-, also did it?  Is an interleaving of
M-. and M-, (in its current meaning) likely, so that it would make
sense to keep the current separation?  I think it is not the first
time that I confused this, and the similarity of the keybindings does
suggest some connection.

I am copying this to emacs-devel in case someone wants to comment on it.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Repeating tag searches does no longer work.

David Kastrup <dak <at> gnu.org> writes:

> Uh, yes.  It is C-u M-. that repeats M-.  Sorry for the false alarm.
> Would there be drawbacks if M-, also did it?

* Changes in version 19.

** M-. (find-tag) no longer has any effect on what M-, will do
subsequently.  You can no longer use M-, to find the next similar tag;
you must use M-. with a prefix argument, instead.

The motive for this change is so that you can more reliably use
M-, to resume a suspended `tags-search' or `tags-query-replace'.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Default history does not work with Lisp regexps

Ok, here is the gist of a bug report.  I have not sent it to the bug
list since I don't need any review for getting this classified as
something we need to do something about.

Basically this boils down to the question: what do we enter in the
history list, the compiled Lisp expression or a string?  If we enter a
string, then we need to go through compilation again in case somebody
just hits RET in order to get the defaults.

Any objections?

Recent input:

C-M-% [ 0 - 9 ] + <return> 
\ , ( 1 + SPC \ # & ) <return> q C-M-% <return> y 
M-x r e p o r t - e <tab> <return>

Recent messages:
Replaced 0 occurrences
Mark set
Entering debugger...
Loading emacsbug...done

Debugger entered--Lisp error: (error "Invalid use of `\\' in replacement text")
  replace-match("\\,(1+ \\#&)" nil nil)
  replace-match-maybe-edit("\\,(1+ \\#&)" nil nil nil (77 81 #<buffer replace.el>))
  perform-replace("[0-9]+" "\\,(1+ \\#&)" t t nil nil nil nil nil)
  query-replace-regexp("[0-9]+" "\\,(1+ \\#&)" nil nil nil)
  call-interactively(query-replace-regexp)

Re: Repeating tag searches does no longer work.

Andreas Schwab <schwab <at> suse.de> writes:

> David Kastrup <dak <at> gnu.org> writes:
> 
> > Uh, yes.  It is C-u M-. that repeats M-.  Sorry for the false alarm.
> > Would there be drawbacks if M-, also did it?
> 
> * Changes in version 19.
> 
> ** M-. (find-tag) no longer has any effect on what M-, will do
> subsequently.  You can no longer use M-, to find the next similar tag;
> you must use M-. with a prefix argument, instead.
> 
> The motive for this change is so that you can more reliably use
> M-, to resume a suspended `tags-search' or `tags-query-replace'.

Considering the relative frequency of those commands, I would have
thought it more convenient to make C-u M-, resume a suspended
`tags-search' or `tags-query-replace', while just M-, resumes whatever
was done last.

So a single C-u M-, would make subsequent M-, switch to tags-search
again, and a single C-u M-. would make subsequent M-, switch to
find-tag again.

In either case, there would be an easy way to switch M-, M-, M-, to go
through the kind of search you prefer at the moment.

C-u M-, does not appear to have any meaning right now.

Re: Default history does not work with Lisp regexps

David Kastrup <dak <at> gnu.org> writes:

> Basically this boils down to the question: what do we enter in the
> history list, the compiled Lisp expression or a string?  If we enter
> a string, then we need to go through compilation again in case
> somebody just hits RET in order to get the defaults.

Applied a fix doing just that.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Repeating tag searches does no longer work.

David Kastrup <dak <at> gnu.org> writes:

> Andreas Schwab <schwab <at> suse.de> writes:
>
>> David Kastrup <dak <at> gnu.org> writes:
>> 
>> > Uh, yes.  It is C-u M-. that repeats M-.  Sorry for the false alarm.
>> > Would there be drawbacks if M-, also did it?
>> 
>> * Changes in version 19.
>> 
>> ** M-. (find-tag) no longer has any effect on what M-, will do
>> subsequently.  You can no longer use M-, to find the next similar tag;
>> you must use M-. with a prefix argument, instead.
>> 
>> The motive for this change is so that you can more reliably use
>> M-, to resume a suspended `tags-search' or `tags-query-replace'.
>
> Considering the relative frequency of those commands, I would have
> thought it more convenient to make C-u M-, resume a suspended
> `tags-search' or `tags-query-replace', while just M-, resumes whatever
> was done last.

Note that this change was established more than 12 years ago.

----------------------------
revision 1.11
date: 1992/07/07 17:57:20;  author: rms;  state: Exp;  lines: +3 -1
*** empty log message ***
----------------------------

Re: [BUG] widget-field-overlay becomes wrong

Lars Hansen <larsh <at> math.ku.dk> writes:

> As you noted yourself, the problem comes when a widget rewrites itself
> "from scratch". Any widget does that if you change it's value with
> widget-value-set from some lisp program.

Yes, from a Lisp program.  But then it is under programmer control.

Only the menu-choice, coding-system and color widgets[1] call
widget-value-set as a result of a user action, so only those are
inherently unsafe.

Footnotes: 
[1]  The radio-button-choice widget also call widget-value-set, but it
doesn't rewrite itself when that happens.

Re: Gnus update

Andreas Schwab <schwab <at> suse.de> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> I.e. I hope that the Gnus repository now has a "gnus-emacs-base" tag of some
>> sort on the 5.10 branch
>
> I have no write access to the Gnus repository.

I feel pretty sure if you write Lars and ask for it, you will get it.
Especially if you state why (to help with the Emacs merge).