headers
Luc Teirlinck | 1 Jun 2004 01:05
Picon

Re: Auto-revert on remote files: disabling timers temporarily?

Kim Storm wrote:

   Luc Teirlinck <teirllm <at> dms.auburn.edu> writes:

   > Now I all of a sudden _always_ get a hang out of which I can _not_
   > quit.

   I don't know if it is relevant in your case, but try to undo the
   last change in process.c (use rev 1.429) and see if that helps.

That seems to solve the problems.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 01:08
Picon

Re: Auto-revert on remote files: disabling timers temporarily?

My previous reply was premature.  Justv ignore it for the time being.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 01:24
Picon

Re: Auto-revert on remote files: disabling timers temporarily?

Kim Storm wrote:

   Luc Teirlinck <teirllm <at> dms.auburn.edu> writes:

   > Now I all of a sudden _always_ get a hang out of which I can _not_
   > quit.

   I don't know if it is relevant in your case, but try to undo the
   last change in process.c (use rev 1.429) and see if that helps.

I still get the quittable hangs and the "Invalid base64 data" errors,
just after loading more (than one) remote files.  The fact that I can
load more remote files and do, for the moment get no non-quittable
hangs might be due to coincidence ot to a temporarily better
connection, however.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 01:58
Picon

Re: Auto-revert on remote files: disabling timers temporarily?

>From my previous message:

   I still get the quittable hangs and the "Invalid base64 data" errors,
   just after loading more (than one) remote files.  The fact that I can
   load more remote files and do, for the moment get no non-quittable
   hangs might be due to coincidence ot to a temporarily better
   connection, however.

I might accidentally have done something strange in that one session.
In all other tries, the problem starts again immediately with the
second remote file.  I have not seen the unquittable hangs again, just
quittable hangs and errors, but that probably is a coincidence too.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 02:18
Picon

Re: Auto-revert on remote files: disabling timers temporarily?

Michael Albinus wrote:

   I guess you have the recent Emacs CVS, including Tramp 2.0.41 and
   Kai's post-release fix? The auto-revert stuff shouldn't appear during
   Tramp actions ...

I have the version of Tramp from the latest _Emacs_ CVS, including
Andreas' fix to the bug I reported (the last change to Tramp in Emacs
CVS).  However, to avoid confusion, I did not apply the patch you
proposed.  (Disabling all timers during execution of Tramp).

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Jun 2004 02:34
Picon
Favicon

automatic frame-resizing


 > I regularly (tho not often) do C-x 5  f <somefile> where <somefile> is
 > already in an open frame.  This basically has the effect of raising that
 > frame and it should not resize it

Stefan, your point on not resizing existing frames when raising them by
function is a valid one - I agree 100%.

If automatic frame resizing is added to Emacs, then simply raising an
existing frame (whether iconified, invisible, or already raised) should not
by itself trigger resizing. Resizing should only happen when the buffer in
the frame changes (different buffer or different contents for the same
buffer).

It is not necessary to adopt the sort of implementation of automatic frame
resizing I used, but *if* an implementation is done along those lines (that
is, if the resizing is done in display-buffer and switch-to-buffer), then it
is necessary to modify the C code for display-buffer and switch-to-buffer:
If an existing frame is simply being raised, then do not resize it.

(Pop-to-buffer, switch-to-buffer-other-frame, and
switch-to-buffer-other-window are taken care of by display-buffer;
switch-to-buffer does not use display-buffer, so it needs to be modified
separately.)

I did not try to change any C code: my implementation is a simple Lisp
hack/workaround. I just called the built-in functions from Lisp, doing a
resize-frame afterward (if one-window-p).  I don't know of any way in Lisp
to determine whether an existing frame was in fact reused by display-buffer
or switch-to-buffer. I do at least inhibit resizing in switch-to-buffer
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 04:15
Picon

locate.el

This is the first in a series of three patches to locate.el,
find-dired.el and dired-aux.el.

They correct a variety of malfunctionings, bugs and misfeatures
regarding inserted subdirectories in *Locate* and *Find* buffers as
well as in ordinary Dired buffers.  The patches to locate.el and
find-dired.el are just updated versions of patches I submitted
earlier.  But to function well, they need the changes in dired-aux,
which I will post separately.

The patches to locate.el and find.el do not fix every single problem
in  *Locate* and *Find* buffers.  That is impossible, because both are
in a form that Dired is not 100 percent prepared to cope with.

I will install all three patches within a few days if there are no
objections.

===File ~/locate-diff=======================================
*** locate.el	20 May 2004 17:14:36 -0500	1.22
--- locate.el	28 May 2004 11:35:25 -0500	
***************
*** 223,241 ****
      (save-window-excursion
        (set-buffer (get-buffer-create locate-buffer-name))
        (locate-mode)
!       (erase-buffer)

!       (setq locate-current-filter filter)

!       (if run-locate-command
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 04:43
Picon

find-dired.el

Below is the latest version of my patch to find-dired.el.  It needs
the patch to dired-aux.el, that I will send somewhat later, to
function properly.

One remaining problem with *Locate* and *Find* buffers is that if one
does `l' _on the very first line_, the directory will update in a
way that makes sense for Dired, but not for *Locate* or *Find*
buffers.  The effect can easily be undone using dired-undo, usually
bound to C-_ and C-x u.  Everything continues to work after that.
Doing `l' on the main directory is not a very usual thing to do.
After my patch to dired-aux, `l' and `C-u l' seem to work perfectly
on subdirectories.  The "l in the first line problem" already occurred
prior to my patch for *Locate* buffers.  It did not occur for *Find*
buffers, but the only reason for that is that neither `i' nor `l'
worked at all for *Find* buffers due to a bug I fixed.

The only solution around the "l on the first line problem" seems to be
to define separate `locate-do-redisplay' and `find-dired-do-redisplay'
functions, whose only difference with `dired-do-redisplay' would be
that they throw an error on the first line.  I do not believe that is
worth the trouble, since an inadvertent `l' on the first line, can
easily be undone with dired-undo.

===File ~/find-dired-diff===================================
diff -c /home/teirllm/stored/find-dired.old.el /home/teirllm/emacscvsdir/emacs/lisp/find-dired.el
*** /home/teirllm/stored/find-dired.old.el	Sat May 29 15:55:43 2004
--- /home/teirllm/emacscvsdir/emacs/lisp/find-dired.el	Fri May 28 11:38:32 2004
***************
*** 54,59 ****
--- 54,67 ----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Jun 2004 05:21
Picon

dired-aux.el

Below is a patch to dired-aux.  It corrects various problems with
reverting or auto-reverting Dired buffers, as well as various problems
in *Locate* and *Find* buffers with inserted subdirectories.

Basically, all three types of changes made by the patch are necessary
to be able to properly auto-revert dired buffers with subdirectories
(currently Dired buffers with inserted subdirectories can not be
auto-reverted).  One is necessary for several other reasons.

Currently, reverting a dired buffer overrides user specified (using
`C-u i' or `C-u l") alternate switches for subdirectories, replacing
them with the general default for the buffer.  I do not believe that
makes sense.  My patch below makes dired remember and respect those
switches.  In my opinion it corrects a misfeature in Dired itself.
The change is necessary to make updating of subdirectories work
properly in *Locate* and *Find* buffers and it is one of the three
changes necessary to make autoreverting Dired buffers work
properly even with inserted subdirectories.

One problem with auto-reverting is that auto-revert should not
auto-revert modified Dired buffers.  Otherwise dired-undo and various
other Dired functionality ceases to work.  But Dired for various
reasons inappropriately (for auto-revert) marks a Dired buffer as
"modified".  This includes inserting subdirectories.  Buffers with
inserted subdirectories stay marked modified, even after `g'.  As a
consequence, they never auto-revert.  The patch below ensures that
inserting, deleting, hiding or unhiding subdirectories will no longer
mark a Dired buffer as modified.  As a result, such dired buffers will
auto-revert.  The two other types of changes in the patch assure that
this will not cause problems.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Monnier | 1 Jun 2004 06:03
Picon

Re: dired-aux.el

> ! 	  (let ((cons (assoc-string (dired-get-subdir) dired-switches-alist))
> ! 		(modflag (buffer-modified-p)))
> ! 	    (when cons
> ! 	      (setq dired-switches-alist (delete cons dired-switches-alist)))
> ! 	    (dired-kill-subdir)
> ! 	    (set-buffer-modified-p modflag))

You should probably use restore-buffer-modified-p here.

        Stefan
Permalink | Reply | 0 comments |

Gmane