find-file-hook as illustration of Custom problems

find-file-hook as illustration of Custom problems

[Luc Teirlinck]

Programs adding entries to hooks or other lists or alists that are
defined by defcustoms can yield _all kinds_ of problems.

If you do `emacs -q' and then `M-x customize-rogue' you will see well
over twenty variables that are defined with defcustoms and are then
changed by code.  Just experimenting a little bit with these variables
in Custom buffers (_not_ in `emacs -q', because you want a regular
customized Emacs for this) will reveal a wide variety of buggish behavior.

I _only_ took a look at find-file-hook, because I wanted a really easy
example.  (Plenty of other variables, look like they might be a much
bigger mess.)

If you customize find-file-hook, then regret your customizations and
select "Erase Customization" VC will not work any more, for newly
visited files.  If you use auto-revert-tail-mode, it will malfunction
from that moment on, for newly visited files.  Both will work again if
you start a new session, but the fact that they cease to work without
warning in the current session is bad enough.

The problem is that vc-hooks.el contains:

(add-hook 'find-file-hook 'vc-find-file-hook)

and autorevert.el contains:

(add-hook 'find-file-hook
	    (lambda ()
	        (set (make-local-variable 'auto-revert-tail-pos)
		      (save-restriction (widen) (1- (point-max))))))

Since vc-hooks.el is apparently preloaded, one could either call
vc-find-file-hook directly from after-find-file or one could add it to
the defcustom of find-file-hook.  Since it seems to be a function that
needs to run _unconditionally_, I personally would lean toward calling
it from after-find-file directly.

What should be done with the auto-revert-tail-mode problem is not that
straightforward.  I would say just ignore it for the moment.  I just
noticed auto-revert-tail, because I use auto-revert-mode, but looking
through the code, I noticed that several other packages add stuff to
find-file-hook in the same way and hence will also be disabled by
"Erase Customization ".

I guess that after "21.4" is released, we could split some of the most
often used and most problematic hooks (like find-file-hook) into a
user and a program hook, thereby solving this kind of problem.  (Doing
this for all defcustomed hooks would probably be unrealistic, because
there are too many of them.)

After that more than twenty complete different and much more complex
problems with changing stuff outside Custom remain, if we just look at
problems present at startup.

But problems occurring _after_ startup are much more dangerous, as I
pointed out and they are also apparently even way more numerous.

I would say, let us tackle this seriously after 21.4 is released and
let us leave Custom alone until 21.4 is released.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> I guess that after "21.4" is released, we could split some of the most
> often used and most problematic hooks (like find-file-hook) into a
> user and a program hook, thereby solving this kind of problem.  (Doing
> this for all defcustomed hooks would probably be unrealistic, because
> there are too many of them.)

Thanks for the clear example.

What we can (and I think we should) do before release is some small changes
to Customize to try to help the user avoid the problems. I would suggest the
following:

1) Do not at all allow "Erase Customization" for rouge options. Or at least
ask and explain the problems at any such attempts.

1) Do not at all allow "Save" for rouge options. Or at least ask and explain
explain at any such attempts.

2) Ask and explain before "Set" of any such option.

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    The problem is that vc-hooks.el contains:

    (add-hook 'find-file-hook 'vc-find-file-hook)

    and autorevert.el contains:

    (add-hook 'find-file-hook
		(lambda ()
		    (set (make-local-variable 'auto-revert-tail-pos)
			  (save-restriction (widen) (1- (point-max))))))

Such code is legitimate, and it would be absurd to call it broken.
The hook in vc-hooks.el could be replaced with  explicit code
inside after-find-file, and that might be an improvement.
But we can't do that for other uses of the hook.  This is what
the hook is meant for.

For the case of hooks, we could imagine changing cus-edit.el so that
edits made using Custom only affect elements that were installed using
Custom.  Any other elements could be invisible and untouchable; or
they might be displayed in a separate way as "program-added hooks" and
untouchable through the usual Custom features.  In effect, this means
treating a single list as if it were the combination of too list
values, one to be edited through Custom and one to be updated
by programs.

I don't know how hard this would be.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

Richard Stallman wrote:

   For the case of hooks, we could imagine changing cus-edit.el so that
   edits made using Custom only affect elements that were installed using
   Custom.  Any other elements could be invisible and untouchable; or
   they might be displayed in a separate way as "program-added hooks" and
   untouchable through the usual Custom features.

I believe the latter.  The user should know that there are other,
untouchable things in the list.

  In effect, this means treating a single list as if it were the
  combination of too list values, one to be edited through Custom and
  one to be updated by programs.

I guess that Custom could use an internal custom-list-var for every
list-var.  Everything specified in the definition of the defcustom
should be in custom-list-var and hence, removable.

   I don't know how hard this would be.

That is the problem, of course.

The problem occurs not only for hooks, but for every non-atom, to
which elements can be added both by code and by the user.  So the
solution should apply to all such non-atoms.  But not to lists that
have a fixed length, like values that are a supposed to be a single
cons.  How do we tell such things apart?  Probably from the type.  So
something in the type of a list to which elements can be added both
through code and through Custom should say that Custom needs to use a
custom-list-var.  Currently, types are not designed with this in mind.
How do we determine whether a defcustom of type 'sexp' with standard
value nil is intended to be a variable length list or not?

I believe that we eventually should go in a direction like this.
If we want it for 21.4 somebody should essentially start to try to
implement it right now.  Per already has said that he has no time.
I do currently not have the time to start implementing something like
this either.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

       For the case of hooks, we could imagine changing cus-edit.el so that
       edits made using Custom only affect elements that were installed using
       Custom.  Any other elements could be invisible and untouchable; or
       they might be displayed in a separate way as "program-added hooks" and
       untouchable through the usual Custom features.

    I believe the latter.  The user should know that there are other,
    untouchable things in the list.

      In effect, this means treating a single list as if it were the
      combination of too list values, one to be edited through Custom and
      one to be updated by programs.

    I guess that Custom could use an internal custom-list-var for every
    list-var.  Everything specified in the definition of the defcustom
    should be in custom-list-var and hence, removable.

The symbol property that records the value according to Custom
can serve this purpose.  Instead of saying "Changed outside Custom",
it can diff the two values to determine which elements were added
outside Custom and which were added within it.

After Custom is used to change the latter set, it can merge the two
sets.

custom-set-variable has to handle this too.

      So
    something in the type of a list to which elements can be added both
    through code and through Custom should say that Custom needs to use a
    custom-list-var.

Yes, we could try handling other kinds of lists in the same way
if it works for hooks.

    How do we determine whether a defcustom of type 'sexp' with standard
    value nil is intended to be a variable length list or not?

Don't worry about it yet.  One thing at a time.

Re: find-file-hook as illustration of Custom problems

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

>     I guess that Custom could use an internal custom-list-var for every
>     list-var.  Everything specified in the definition of the defcustom
>     should be in custom-list-var and hence, removable.
>
> The symbol property that records the value according to Custom
> can serve this purpose.  Instead of saying "Changed outside Custom",
> it can diff the two values to determine which elements were added
> outside Custom and which were added within it.
>
> After Custom is used to change the latter set, it can merge the two
> sets.

Maybe we should not forget that this symbol property according to Per A is a
valuable tool to find errors in the handling of defcustom symbols. Perhaps
that possibility can be retained by adding a new property corresponding to
the users added part?

Re: find-file-hook as illustration of Custom problems

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> For the case of hooks, we could imagine changing cus-edit.el so that
> edits made using Custom only affect elements that were installed using
> Custom.  Any other elements could be invisible and untouchable; or
> they might be displayed in a separate way as "program-added hooks" and
> untouchable through the usual Custom features.  In effect, this means
> treating a single list as if it were the combination of too list
> values, one to be edited through Custom and one to be updated
> by programs.
>
> I don't know how hard this would be.

Would not this require changes to the run hook functions too? In that case
it might be more simple to add a macro (or function) used for creating
hooks, maybe "define-hook" that added the normal hook and a second hook used
by Custom. (This would of course also require changes to the run hook
functions.)

This is somewhat in the spirit of define-minor-mode. It would make it rather
easy to change all the 400 hooks now defined by defcustom. I assume there
would not be big changes necessary to the run hooks functions. It is just to
run the hooks in the second list too. (However maybe the marriage between
Custom and the C code should feel uncomfortable.)

Popup when buffer file is changed on disk

[moheb missaghi]

Hi:

As great as emacs is, sometimes I'd like to use an IDE simultaneously with
emacs which has features not currently available in emacs.  To give an 
example,
Microsoft's Visual Studio which has something called Intelisense which has a
knowledge of object hierarchy and allows object name completion. Most IDE's
prompt the user when the file is changed outside them (for example by an 
editor
such as emacs) by poping up a dialog box asking the user if he/she wants to
reload the file. emacs gives this warning a bit too late in my opinion, 
i.e.,
when the buffer is about to be modified rather than when its frame gets the
focus.

In the following I am presenting changes for NT emacs which allow poping up 
of
a dialog box to notify the user that the file is changed on disk and the 
buffer
is going to be refreshed. This is my first attempt and I can already think 
of
some improvements (for example if the user doesn't want the file to be 
reloaded
but the warning should popup only once). Just wanted to get some feed back 
from
this group before going further.

Here are the changes in cvs diff format delimited by a user flag named
USING_WITH_IDE. Please note that this feature is not specific to any IDE and
the code on Windows is simply an example.

Regards

Moheb

Index: nt/nmake.defs
===================================================================
RCS file: /cvsroot/emacs/emacs/nt/nmake.defs,v
retrieving revision 1.20
diff -r1.20 nmake.defs
132a133,135
>
> USER_CFLAGS = -DUSING_WITH_IDE
>
cvs diff: Diffing nt/icons
cvs diff: Diffing nt/inc
cvs diff: Diffing nt/inc/arpa
cvs diff: Diffing nt/inc/netinet
cvs diff: Diffing nt/inc/sys
cvs diff: Diffing oldXMenu
cvs diff: Diffing site-lisp
cvs diff: Diffing src
Index: src/buffer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.473
diff -r1.473 buffer.c
55a56,59
> #if USING_WITH_IDE
> #include "w32term.h"
> #endif
>
1662a1667,1671
> #if USING_WITH_IDE
>   Lisp_Object buf;
>   HWND hwnd = FRAME_W32_WINDOW (SELECTED_FRAME ());
> #endif
>
1670a1680,1703
> #if USING_WITH_IDE
>   buf = switch_to_buffer_1 (buffer, norecord);
>
>   // see if file is changed
>   if (!NILP (current_buffer->filename)
>       && SAVE_MODIFF >= MODIFF
>       && NILP (Fverify_visited_file_modtime (Fcurrent_buffer ()))
>       && !NILP (Ffile_exists_p (current_buffer->filename)))
>     {
>       int fileChangedDialogAnswer = MessageBox (NULL, "Buffer file changed 
> on disk. Buffer will be reloaded from disk.", "Emacs", 
> MB_OK|MB_ICONWARNING|MB_APPLMODAL|MB_SETFOREGROUND);
>       char msg[80];
>
>       if (fileChangedDialogAnswer == IDOK)
>         {
>           call3 (intern ("revert-buffer"), Qt, Qt, Qt);
>           strcpy(msg, "File reverted: ");
>           strcat(msg, XSTRING(current_buffer->filename)->data);
>           message (msg);
>           SetFocus(hwnd);
>         }
>     }
>
>   return buf;
> #else
1671a1705
> #endif
Index: src/w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.246
diff -r1.246 w32fns.c
3558a3559,3578
> #if USING_WITH_IDE
>       // see if file is changed
>       if (!NILP (current_buffer->filename)
>           && SAVE_MODIFF >= MODIFF
>           && NILP (Fverify_visited_file_modtime (Fcurrent_buffer ()))
>           && !NILP (Ffile_exists_p (current_buffer->filename)))
>           {
>       int fileChangedDialogAnswer = MessageBox (NULL, "Buffer file changed 
> on disk. Buffer will be reloaded from disk.", "Emacs", 
> MB_OK|MB_ICONWARNING|MB_APPLMODAL|MB_SETFOREGROUND);
>             char msg[80];
>
>             if (fileChangedDialogAnswer == IDOK)
>               {
>                 call3 (intern ("revert-buffer"), Qt, Qt, Qt);
>                 strcpy(msg, "File reverted: ");
>                 strcat(msg, XSTRING(current_buffer->filename)->data);
>                 message (msg);
>         SetFocus(hwnd);
>               }
>           }
> #endif

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> From: "moheb missaghi" <moheb1333@comcast.net>
> Date: Sat, 5 Feb 2005 13:56:19 -0700
> 
> Microsoft's Visual Studio which has something called Intelisense which has a
> knowledge of object hierarchy and allows object name completion.

Doesn't ECB provide that feature?

> Most IDE's prompt the user when the file is changed outside them
> (for example by an editor such as emacs) by poping up a dialog box
> asking the user if he/she wants to reload the file. emacs gives this
> warning a bit too late in my opinion, i.e., when the buffer is about
> to be modified rather than when its frame gets the focus.

Would switching on auto-revert-mode solve your problem here?

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>

> > Most IDE's prompt the user when the file is changed outside them
> > (for example by an editor such as emacs) by poping up a dialog box
> > asking the user if he/she wants to reload the file. emacs gives this
> > warning a bit too late in my opinion, i.e., when the buffer is about
> > to be modified rather than when its frame gets the focus.
>
> Would switching on auto-revert-mode solve your problem here?

I have been missing this feature too. Emacs behaviour is quite confusing if
you are used to the behavior Moheb mentions.

I do not believe that auto-revert-mode can do what Moheb (and I myself)
wants. What we want to happen is that Emacs should warn at the moment when
it gets focus that the file has changed.

So the message that the operating system sends to Emacs to tell it that it
has got focus must be catched by Emacs message queue and given to elisp. I
do not know exactly how to do that but it should be done by letting the
detection of the message start a timer that then runs the wanted code. (I
mean I don't remember the message name and I do not know how Emacs handles
messages.)

This description is from my knowledge of w32 but I guess something similar
should apply to for example GNU/Linux?

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> Cc: <emacs-devel@gnu.org>
> Date: Sun, 6 Feb 2005 01:51:43 +0100
> 
> > Would switching on auto-revert-mode solve your problem here?
> 
> I have been missing this feature too. Emacs behaviour is quite confusing if
> you are used to the behavior Moheb mentions.
> 
> I do not believe that auto-revert-mode can do what Moheb (and I myself)
> wants. What we want to happen is that Emacs should warn at the moment when
> it gets focus that the file has changed.

When Emacs warns you that the file was changed, what would you do in
response?  I thought that you would revert the buffer, so auto-revert
seemed like a good solution.

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>
To: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
Cc: <moheb1333@comcast.net>; <emacs-devel@gnu.org>
Sent: Sunday, February 06, 2005 8:20 AM
Subject: Re: Popup when buffer file is changed on disk


> > From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> > Cc: <emacs-devel@gnu.org>
> > Date: Sun, 6 Feb 2005 01:51:43 +0100
> >
> > > Would switching on auto-revert-mode solve your problem here?
> >
> > I have been missing this feature too. Emacs behaviour is quite confusing
if
> > you are used to the behavior Moheb mentions.
> >
> > I do not believe that auto-revert-mode can do what Moheb (and I myself)
> > wants. What we want to happen is that Emacs should warn at the moment
when
> > it gets focus that the file has changed.
>
> When Emacs warns you that the file was changed, what would you do in
> response?  I thought that you would revert the buffer, so auto-revert
> seemed like a good solution.

auto-revert-mode does what it does later, not at the moment Emacs gets
focus. I believe that at the moment when Emacs gets focus it should for all
files that are visited in buffers and changed outside of Emacs should ask:

     "File AA.C has changed on disk. Do you want to reload it?"

I think a popup should be used for this since it is more visible. Emacs
should also keep track of when this question was asked last time (to avoid
asking to many times).

After this the usual Emacs handling of the situation should persist.

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> Cc: <moheb1333@comcast.net>, <emacs-devel@gnu.org>
> Date: Sun, 6 Feb 2005 10:02:20 +0100
> 
> > When Emacs warns you that the file was changed, what would you do in
> > response?  I thought that you would revert the buffer, so auto-revert
> > seemed like a good solution.
> 
> auto-revert-mode does what it does later, not at the moment Emacs gets
> focus.

??? auto-revert-mode periodically checks all buffers that are visiting
a file.  The frequency of these checks is determined by the variable
auto-revert-interval, by default every 5 seconds.

Perhaps you need to set auto-revert-stop-on-user-input to nil and
maybe also play with auto-revert-interval's value, to get almost
instanteneous automatic reverts whenever a file changes.

> I believe that at the moment when Emacs gets focus it should for all
> files that are visited in buffers and changed outside of Emacs should ask:
> 
>      "File AA.C has changed on disk. Do you want to reload it?"

Perhaps a feature can be added to autorevert.el, whereby it checks the
buffers when a focus event arrives.  All the rest is already there, I
believe.

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>

> > auto-revert-mode does what it does later, not at the moment Emacs gets
> > focus.
>
> ??? auto-revert-mode periodically checks all buffers that are visiting
> a file.  The frequency of these checks is determined by the variable
> auto-revert-interval, by default every 5 seconds.

Hm. Thanks. Looks like I tested too fast. Sorry.

> Perhaps you need to set auto-revert-stop-on-user-input to nil and
> maybe also play with auto-revert-interval's value, to get almost
> instanteneous automatic reverts whenever a file changes.

Setting auto-revert-stop-on-user-input to nil does not work for me. Using
CVS, any ideas of what could be wrong.

> Perhaps a feature can be added to autorevert.el, whereby it checks the
> buffers when a focus event arrives.  All the rest is already there, I
> believe.

The timer is surely good, but checking at the focus event is still
desireable IMO since it is more instantaneous when switching to Emacs.

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

Lennart Borgman wrote:

   Setting auto-revert-stop-on-user-input to nil does not work for me. Using
   CVS, any ideas of what could be wrong.

I believe that what is wrong is that you misunderstand what it is
supposed to do.  Basically, setting this to nil is only going to make a
noticeable difference when a bunch og huge files are changing on disk
while you are trying to type.  My best guess is that you are not going
to enjoy it being nil in such a situation.

Do you still believe that it "does not work" after reading the
following expanded docstring?

===File ~/autorevert-diff===================================
*** autorevert.el	29 Dec 2004 21:08:55 -0600	1.42
--- autorevert.el	06 Feb 2005 10:14:45 -0600	
***************
*** 150,156 ****
  	      (auto-revert-set-timer))))
  
  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input."
    :group 'auto-revert
    :type 'boolean)
  
--- 150,160 ----
  	      (auto-revert-set-timer))))
  
  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input.
! This prevents Auto Revert from interrupting you while you are typing.
! This option controls when files are auto-reverted, not which files
! are auto-reverted.  Modified files are never auto-reverted,
! regardless of the value of this option."
    :group 'auto-revert
    :type 'boolean)
  
============================================================

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> Do you still believe that it "does not work" after reading the
> following expanded docstring?

No. Thanks.

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

I believe that the following is better than my original patch.  Only
the second line of the docstring has changed.  The thing that can go
wrong if the option is nil is less often that you get "interrupted".
than that Emacs fails to respond (whether to typing or to other commands).

===File ~/autorevert-diff-b=================================
*** autorevert.el	29 Dec 2004 21:08:55 -0600	1.42
--- autorevert.el	06 Feb 2005 10:48:08 -0600	
***************
*** 150,156 ****
  	      (auto-revert-set-timer))))
  
  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input."
    :group 'auto-revert
    :type 'boolean)
  
--- 150,160 ----
  	      (auto-revert-set-timer))))
  
  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input.
! This prevents Auto Revert from interfering with your normal Emacs usage.
! This option controls when files are auto-reverted, not which files
! are auto-reverted.  Modified files are never auto-reverted,
! regardless of the value of this option."
    :group 'auto-revert
    :type 'boolean)
  
============================================================

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

I will install the following doc patch to autorevert.el if there are
no objections.  The patch would be silly if the first line of the
docstring were clear enough without it.  But I believe that it is not.

===File ~/autorevert-diff-b=================================
*** autorevert.el	29 Dec 2004 21:08:55 -0600	1.42
--- autorevert.el	06 Feb 2005 10:48:08 -0600	
***************
*** 150,156 ****
		 (auto-revert-set-timer))))

  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input."
    :group 'auto-revert
    :type 'boolean)

--- 150,160 ----
		 (auto-revert-set-timer))))

  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input.
! This prevents Auto Revert from interfering with your normal Emacs usage.
! This option controls when files are auto-reverted, not which files
! are auto-reverted.  Modified files are never auto-reverted,
! regardless of the value of this option."
    :group 'auto-revert
    :type 'boolean)

============================================================

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> Date: Thu, 10 Feb 2005 18:33:13 -0600 (CST)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> Cc: lennart.borgman.073@student.lu.se, eliz@gnu.org, emacs-devel@gnu.org
> 
>   (defcustom auto-revert-stop-on-user-input t
> !   "When non-nil Auto-Revert Mode stops checking files on user input.
> ! This prevents Auto Revert from interfering with your normal Emacs usage.
> ! This option controls when files are auto-reverted, not which files
> ! are auto-reverted.  Modified files are never auto-reverted,
> ! regardless of the value of this option."

I don't see why the doc string should mention modified files.
Modified files have nothing to do with this option.

Re: Popup when buffer file is changed on disk

[David Kastrup]

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

>> Date: Thu, 10 Feb 2005 18:33:13 -0600 (CST)
>> From: Luc Teirlinck <teirllm@dms.auburn.edu>
>> Cc: lennart.borgman.073@student.lu.se, eliz@gnu.org, emacs-devel@gnu.org
>> 
>>   (defcustom auto-revert-stop-on-user-input t
>> !   "When non-nil Auto-Revert Mode stops checking files on user input.
>> ! This prevents Auto Revert from interfering with your normal Emacs usage.
>> ! This option controls when files are auto-reverted, not which files
>> ! are auto-reverted.  Modified files are never auto-reverted,
>> ! regardless of the value of this option."
>
> I don't see why the doc string should mention modified files.
> Modified files have nothing to do with this option.

Actually, modified files have _everything_ to do with autorevert-mode.

But I think that in this case "modified buffers" was much more likely
the intended meaning, and this should be changed accordingly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

Sorry, I mistakenly used the word "file" where "buffer" was meant.
Of course, the option has nothing to do with modified buffers either,
but it is exactly the purpose of the patch to point this out.

"on user input" could be misinterpreted as meaning "after you modify
the buffer" and "checking files" could be misunderstood as implicitly
meaning to revert them, so the user could get the impression that if
he sets the option to nil, autorevert will even autorevert modified
buffers.  For instance, I had the impression that this was how Lennart
understood it, when he said that the option "did not work".

===File ~/autorevert-diff-b=================================
*** autorevert.el	29 Dec 2004 21:08:55 -0600	1.42
--- autorevert.el	06 Feb 2005 10:48:08 -0600	
***************
*** 150,156 ****
		 (auto-revert-set-timer))))

  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input."
    :group 'auto-revert
    :type 'boolean)

--- 150,160 ----
		 (auto-revert-set-timer))))

  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input.
! This prevents Auto Revert from interfering with your normal Emacs usage.
! This option controls when buffers are auto-reverted, not which buffers
! are auto-reverted.  Modified buffers are never auto-reverted,
! regardless of the value of this option."
    :group 'auto-revert
    :type 'boolean)

============================================================

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> Date: Fri, 11 Feb 2005 13:38:23 -0600 (CST)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: eliz@gnu.org, lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> 
> Sorry, I mistakenly used the word "file" where "buffer" was meant.

I understood that, and this is why I objected to mentioning modified
files in the doc string.

> Of course, the option has nothing to do with modified buffers either,
> but it is exactly the purpose of the patch to point this out.

I'm certain that you didn't mean to mention something that is
unrelated to the option, as the above sentence seems to imply.

> "on user input" could be misinterpreted as meaning "after you modify
> the buffer"

If ``user input'' is ambiguous, it would be okay to explain in more
clear manner what user input means.

> and "checking files" could be misunderstood as implicitly
> meaning to revert them

It would be okay to explain that as well, so that the confusing text
is replaced with a more clear one.

But mentioning modified buffers is not the way to make these
explanations more clear, IMHO.  On the contrary, it might make things
more confusing, since it makes the doc string less self-contained.

Re: Popup when buffer file is changed on disk

[Richard Stallman]

    !   "When non-nil Auto-Revert Mode stops checking files on user input.

I don't understand that sentence.  Does it mean,

  "When nil, Auto-Revert Mode checks files on user input--otherwise, it doesn't?

If so, what does it mean to "check files on user input"?

    ! This prevents Auto Revert from interfering with your normal Emacs usage.

That is so general that it doesn't mean much.  What kind of
"interference" does it refer to?

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

What about the following docstring?

===File ~/autorevert-diff===================================
diff -c /home/teirllm/emacscvsdir/emacs/lisp/autorevert.el.\~1.42.\~ /home/teirllm/emacscvsdir/emacs/lisp/autorevert.el
*** /home/teirllm/emacscvsdir/emacs/lisp/autorevert.el.~1.42.~	Wed Dec 29 21:08:55 2004
--- /home/teirllm/emacscvsdir/emacs/lisp/autorevert.el	Sat Feb 12 19:22:19 2005
***************
*** 150,156 ****
  	      (auto-revert-set-timer))))
  
  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil Auto-Revert Mode stops checking files on user input."
    :group 'auto-revert
    :type 'boolean)
  
--- 150,161 ----
  	      (auto-revert-set-timer))))
  
  (defcustom auto-revert-stop-on-user-input t
!   "When non-nil, user input temporarily interrupts Auto-Revert Mode.
! When nil, Auto-Revert Mode checks files and reverts buffers, with
! quitting disabled, without paying attention to user input.  Thus,
! Emacs could appear to be hung for a while.  When non-nil,
! Auto-Revert Mode checks for user input after handling each buffer
! and does not process any further buffers (until the next run of
! the timer) if user input is available."
    :group 'auto-revert
    :type 'boolean)

Diff finished.  Sat Feb 12 19:24:50 2005
============================================================

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> Date: Sat, 12 Feb 2005 19:41:53 -0600 (CST)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: lennart.borgman.073@student.lu.se, eliz@gnu.org, emacs-devel@gnu.org
> 
>   (defcustom auto-revert-stop-on-user-input t
> !   "When non-nil, user input temporarily interrupts Auto-Revert Mode.
> ! When nil, Auto-Revert Mode checks files and reverts buffers, with
> ! quitting disabled, without paying attention to user input.  Thus,
> ! Emacs could appear to be hung for a while.  When non-nil,
> ! Auto-Revert Mode checks for user input after handling each buffer
> ! and does not process any further buffers (until the next run of
> ! the timer) if user input is available."

I think you should describe the effects of each possible value (nil
and non-nil) without intermixing them.  The way this doc string goes,
it's confusing: first you say what happens under a non-nil value, then
under nil value, then again under non-nil.

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

Eli Zaretskii wrote:
   
   I think you should describe the effects of each possible value (nil
   and non-nil) without intermixing them.  The way this doc string goes,
   it's confusing: first you say what happens under a non-nil value, then
   under nil value, then again under non-nil.

What about the following?

(defcustom auto-revert-stop-on-user-input t
  "When non-nil, user input temporarily interrupts Auto-Revert Mode.
More precisely, Auto-Revert Mode checks for user input after
handling each buffer and does not process any further
buffers (until the next run of the timer) if user input is
available.  When nil, Auto-Revert Mode checks files and reverts
buffers, with quitting disabled, without paying attention to user
input.  Thus, Emacs could appear to be hung for a while."
  :group 'auto-revert
  :type 'boolean)

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> Date: Mon, 14 Feb 2005 21:05:01 -0600 (CST)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: lennart.borgman.073@student.lu.se, rms@gnu.org, emacs-devel@gnu.org
> 
> What about the following?
> 
> (defcustom auto-revert-stop-on-user-input t
>   "When non-nil, user input temporarily interrupts Auto-Revert Mode.
> More precisely, Auto-Revert Mode checks for user input after
> handling each buffer and does not process any further
> buffers (until the next run of the timer) if user input is
> available.  When nil, Auto-Revert Mode checks files and reverts
> buffers, with quitting disabled, without paying attention to user
> input.  Thus, Emacs could appear to be hung for a while."
>   :group 'auto-revert
>   :type 'boolean)

I think this is okay, except that I'd remove "More precisely", and
replace the last sentence with something like

   Thus, Emacs could appear sluggish in reacting to user input.

(I don't like telling users that Emacs appears to be hung.)

Re: Popup when buffer file is changed on disk

[moheb missaghi]

Hi,

I posted the following yesterday but I am not sure if it made it to the 
list.
Sorry if it did post but noone chose to comment.

Thanks for all the responses to my proposed patch. Autorevert doesn't quite 
do
what Lennart and I want because it is not deterministic, i.e., depends on 
some
frequency value to be set. Also it has to be turned on/off for each buffer
unless you set it globally. Problem with global setting is that you might
forget that buffers are automatically reverted unless some message or symbol
appears on the modeline.

Following Lennart's idea, I added a flag to the buffer struct
(leaveBufferAlone) which persists the state of whether the user chose to 
ignore
that the buffer file was changed on disk or not. When working with an IDE, 
the
popup provides a symmetric editing experience in that emacs and the IDE 
notify
the user whenever the file is changed on disk (by the other) and give 
him/her
the chance to ignore or revert. In the case of emacs, this works fine with
ask-user-about-supersession-threat, if user chooses not to revert. When 
he/she
finally saves the buffer, the leaveBufferAlone flag is reset. It is also a 
bit
more efficient than the current emacs functionality in that it involves one
less key stroke. Currently, if the file is changed on disk you have to do an
edit action in order to get to choose to revert or not via
ask-user-about-supersession-threat (which is a bit annoying to my taste!)
whereas with the popup, you'll get the message as soon as you switch to the
buffer or as soon as the emacs frame gets the focus if the buffer is 
currently
visited. The new code follows.

Regards,

Moheb

cvs diff: Diffing nt
Index: nt/nmake.defs
===================================================================
RCS file: /cvsroot/emacs/emacs/nt/nmake.defs,v
retrieving revision 1.20
diff -w -r1.20 nmake.defs
132a133,136
>
>
> USER_CFLAGS = -DUSING_WITH_IDE
>

cvs diff: Diffing src
Index: src/buffer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.473
diff -w -r1.473 buffer.c
55a56,59
> #if USING_WITH_IDE
> #include "w32term.h"
> #endif
>
684a689,693
>
> #if USING_WITH_IDE
>  b->leaveBufferAlone = 0;
> #endif
>
1662a1672,1676
> #if USING_WITH_IDE
>   Lisp_Object buf;
>   HWND hwnd = FRAME_W32_WINDOW (SELECTED_FRAME ());
> #endif
>
1670a1685,1720
> #if USING_WITH_IDE
>   buf = switch_to_buffer_1 (buffer, norecord);
>
>   // see if file is changed
>   if ((!NILP (current_buffer->filename)
>       && SAVE_MODIFF >= MODIFF
>       && NILP (Fverify_visited_file_modtime (Fcurrent_buffer ()))
>       && !NILP (Ffile_exists_p (current_buffer->filename))) &&
>    current_buffer->leaveBufferAlone == 0)
>     {
>       int fileChangedDialogAnswer = MessageBox (NULL, "Buffer file changed 
> on disk, revert?", "Emacs", 
> MB_YESNO|MB_ICONQUESTION|MB_APPLMODAL|MB_SETFOREGROUND);
>    char msg[80];
>
>       if (fileChangedDialogAnswer == IDYES)
>         {
>      /* reset the don't change flag */
>      current_buffer->leaveBufferAlone = 0;
>           call3 (intern ("revert-buffer"), Qt, Qt, Qt);
>           strcpy(msg, "File reverted: ");
>           strcat(msg, XSTRING(current_buffer->filename)->data);
>           message (msg);
>           SetFocus(hwnd);
>         }
>    else
>     {
>      /* persist that the question was asked and the answer was no */
>      current_buffer->leaveBufferAlone = 1;
>      strcpy(msg, "File changed on disk: ");
>      strcat(msg, XSTRING(current_buffer->filename)->data);
>      message (msg);
>      SetFocus(hwnd);
>     }
>     }
>
>   return buf;
> #else
1671a1722
> #endif
Index: src/buffer.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.h,v
retrieving revision 1.100
diff -w -r1.100 buffer.h
510a511,515
> #if USING_WITH_IDE
>  /* for persistance when buffer file changes on disk */
>  int leaveBufferAlone;
> #endif
>
Index: src/fileio.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/fileio.c,v
retrieving revision 1.526
diff -w -r1.526 fileio.c
5276a5277,5281
> #if USING_WITH_IDE
>  /* reset leaveBufferAlone flag */
>  current_buffer->leaveBufferAlone = 0;
> #endif
>
Index: src/w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.246
diff -w -r1.246 w32fns.c
3558a3559,3590
> #if USING_WITH_IDE
>       // see if file is changed
>       if ((!NILP (current_buffer->filename)
>           && SAVE_MODIFF >= MODIFF
>           && NILP (Fverify_visited_file_modtime (Fcurrent_buffer ()))
>           && !NILP (Ffile_exists_p (current_buffer->filename))) &&
>      current_buffer->leaveBufferAlone == 0)
>           {
>       int fileChangedDialogAnswer = MessageBox (NULL, "Buffer file changed 
> on disk, revert?", "Emacs", 
> MB_YESNO|MB_ICONQUESTION|MB_APPLMODAL|MB_SETFOREGROUND);
>             char msg[80];
>
>             if (fileChangedDialogAnswer == IDYES)
>               {
>         /* reset the flag */
>         current_buffer->leaveBufferAlone = 0;
>                 call3 (intern ("revert-buffer"), Qt, Qt, Qt);
>                 strcpy(msg, "File reverted: ");
>                 strcat(msg, XSTRING(current_buffer->filename)->data);
>                 message (msg);
>         SetFocus(hwnd);
>               }
>       else
>        {
>         /* don't let the dialog to be annoying */
>         current_buffer->leaveBufferAlone = 1;
>         strcpy(msg, "File changed on disk: ");
>         strcat(msg, XSTRING(current_buffer->filename)->data);
>         message (msg);
>         SetFocus(hwnd);
>        }
>           }
> #endif

Re: Popup when buffer file is changed on disk

[Richard Stallman]

    What about the following?

    (defcustom auto-revert-stop-on-user-input t
      "When non-nil, user input temporarily interrupts Auto-Revert Mode.
    More precisely, Auto-Revert Mode checks for user input after
    handling each buffer and does not process any further
    buffers (until the next run of the timer) if user input is
    available.  When nil, Auto-Revert Mode checks files and reverts
    buffers, with quitting disabled, without paying attention to user
    input.  Thus, Emacs could appear to be hung for a while."

It seems clear to me.

Thanks for working on this.

Re: Popup when buffer file is changed on disk

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     What about the following?
>
>     (defcustom auto-revert-stop-on-user-input t
>       "When non-nil, user input temporarily interrupts Auto-Revert Mode.
>     More precisely, Auto-Revert Mode checks for user input after
>     handling each buffer and does not process any further
>     buffers (until the next run of the timer) if user input is
>     available.  When nil, Auto-Revert Mode checks files and reverts
>     buffers, with quitting disabled, without paying attention to user
>     input.  Thus, Emacs could appear to be hung for a while."
>
> It seems clear to me.

Well, Eli suggested "sluggish" instead of the negatively connotated
"hung" (which usually is used for a terminal error condition), but I
think that is misleading.  I'd suggest using something like "Thus,
Emacs might be non-responsive at times."  Something like that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

David Kastrup wrote:

   Well, Eli suggested "sluggish" instead of the negatively connotated
   "hung" (which usually is used for a terminal error condition), but I
   think that is misleading.  I'd suggest using something like "Thus,
   Emacs might be non-responsive at times."  Something like that.

I used:

Thus, it might take a while before Emacs responds to your input.

On the other hand. I kept the "More precisely" (in the second
sentence) which Eli suggested removing, because without it things did
just not seem to flow right.  Because the first sentence of a
docstring stands out on its own, it seemed no longer clear that we
were talking about the case where the option was nil, and the sentence
_is_ repeating what was already said in the first sentence, just in
more (I believe necessary) detail.

Maybe I installed somewhat too early, but, of course, changes can
still be made if there are objections.

  "When non-nil, user input temporarily interrupts Auto-Revert Mode.
More precisely, Auto-Revert Mode checks for user input after
handling each buffer and does not process any further buffers
\(until the next run of the timer) if user input is available.
When nil, Auto-Revert Mode checks files and reverts buffers,
with quitting disabled, without paying attention to user input.
Thus, it might take a while before Emacs responds to your input."

Sincerely,

Luc.

Re: Popup when buffer file is changed on disk

[David Kastrup]

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

> David Kastrup wrote:
>
>    Well, Eli suggested "sluggish" instead of the negatively
>    connotated "hung" (which usually is used for a terminal error
>    condition), but I think that is misleading.  I'd suggest using
>    something like "Thus, Emacs might be non-responsive at times."
>    Something like that.
>
> I used:
>
> Thus, it might take a while before Emacs responds to your input.

Well, I don't like that better, but that's a matter of taste, and the
one doing the work should certainly enjoy the benefits of it.

> On the other hand. I kept the "More precisely" (in the second
> sentence) which Eli suggested removing, because without it things
> did just not seem to flow right.  Because the first sentence of a
> docstring stands out on its own, it seemed no longer clear that we
> were talking about the case where the option was nil, and the
> sentence _is_ repeating what was already said in the first sentence,
> just in more (I believe necessary) detail.

But "more precisely" would imply that the first sentence was imprecise
in some manner.  I'd rather recommend "In this case, Auto-Revert
Mode..."  or "With this setting, Auto-Revert Mode...".

> Maybe I installed somewhat too early,

Oh nonsense.  If everybody waited for unanimous applause before
installing a reworded, obviously mostly improved doc string, we'd not
get Emacs 21.4 out in 2004 anymore.  Uh, I mean, uhm...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

I have now installed the following:

(defcustom auto-revert-stop-on-user-input t
  "When non-nil, user input temporarily interrupts Auto-Revert Mode.
With this setting, Auto-Revert Mode checks for user input after
handling each buffer and does not process any further buffers
\(until the next run of the timer) if user input is available.
When nil, Auto-Revert Mode checks files and reverts buffers,
with quitting disabled, without paying attention to user input.
Thus, Emacs might be non-responsive at times."
  :group 'auto-revert
  :type 'boolean)

Sincerely,

Luc.

Re: Popup when buffer file is changed on disk

[Richard Stallman]

    focus. I believe that at the moment when Emacs gets focus it should for all
    files that are visited in buffers and changed outside of Emacs should ask:

	 "File AA.C has changed on disk. Do you want to reload it?"

I don't want to install this; I think it would be annoying.  However,
you could write it and post a patch, and people could try it and
report whether they like it.  If people generally agree it is a good
thing, I will install it.

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> "File AA.C has changed on disk. Do you want to reload it?"
>
> I don't want to install this; I think it would be annoying.  However,
> you could write it and post a patch, and people could try it and
> report whether they like it.  If people generally agree it is a good
> thing, I will install it.

I tried to implement it to see how it could work. I took a little bit
different road. I let the app activate event call a lisp function (which I
named "handle-app-activation"). This should handle both app activation and
app deactivation.

Any ideas around this?

I am only able to implement this on w32. I guess it should be
straightforward to do the same for other OS:es if there are events for app
activation/deactivation (which I suppose there are). The only part that
differs is the "real message loop".

Re: Popup when buffer file is changed on disk

[Jan D.]

>
> I am only able to implement this on w32. I guess it should be
> straightforward to do the same for other OS:es if there are events for 
> app
> activation/deactivation (which I suppose there are). The only part that
> differs is the "real message loop".

I haven't seen other OS:es (i.e. Unix) use the terms 
activate/deactivate for applications.  What does it mean?  That some 
GUI window for the application gets focus?  In that case a better 
implementation is to generate a lisp event for FOCUS_IN.  That should 
work on all platforms directly.

	Jan D.

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Jan D." <jan.h.d@swipnet.se>

> I haven't seen other OS:es (i.e. Unix) use the terms
> activate/deactivate for applications.  What does it mean?  That some
> GUI window for the application gets focus?  In that case a better
> implementation is to generate a lisp event for FOCUS_IN.  That should
> work on all platforms directly.

Thanks. I will see what I will do. It gets more complicated in that case
(because of the structure of the code) and I do not want to break anything
now.

Re: Popup when buffer file is changed on disk

[Jan D.]

> ----- Original Message -----
> From: "Jan D." <jan.h.d@swipnet.se>
>
>> I haven't seen other OS:es (i.e. Unix) use the terms
>> activate/deactivate for applications.  What does it mean?  That some
>> GUI window for the application gets focus?  In that case a better
>> implementation is to generate a lisp event for FOCUS_IN.  That should
>> work on all platforms directly.
>
> Thanks. I will see what I will do. It gets more complicated in that 
> case
> (because of the structure of the code) and I do not want to break 
> anything
> now.

I spoke too soon, w32 and msdos doesn't seem to generate FOCUS_IN, so 
perhaps a new event is called for.

	Jan D.

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 6 Feb 2005 21:40:29 +0100
> Cc: emacs-devel@gnu.org
> 
> I spoke too soon, w32 and msdos doesn't seem to generate FOCUS_IN, so 
> perhaps a new event is called for.

The MSDOS case is irrelevant: it's not a multi-frame configuration, so
focus-in events are meaningless there.

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

If you are going to do this, at least make it an option that is by
default off.

The rationale behind checking for and warning about files that have
changed on disk _after a focus change_ is apparently the assumption
that most files change on disk because you edited them with another
editor.  Many people only use one editor, Emacs.  For them that
assumption is completely wrong.

Files can change on disk for several reasons, including:

1.  Because you edited them with another editor.

2.  Because some process is writing to them.

3.  Because another person is editing them.

4.  Because you changed them from within Emacs in some way that
    bypassed the buffer.  (To be avoided, but can inadvertently happen.)

(2), (3) and (4) are unrelated to focus changes.  They can happen any
time.  For people that only edit files using Emacs, (1) never happens.

If processes are writing to files visited in buffers, files are going
to change on disk all the time.  I would be reminded about that on
just about every focus change, even though I know that autorevert is
going to revert them within 5 seconds or less.  This is senseless.

Clearly, the best way to deal with all ways that a file can change on
disk is a combination of mode line and Buffer Menu.  (And still this
would only be needed if for some reason you do not want to use
autorevert or if you are editing files that could change on disk.)
The mode line and Buffer Menu features would not be very difficult to
implement.  But we are in a feature freeze, so I believe it can wait
till Emacs 22.

Sincerely,

Luc.

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

Richard Stallman wrote:

   I don't want to install this; I think it would be annoying.

I believe that it would be very annoying.  It is apparently something
people who use MS Windows applications are used to, but I guess that
is because they have systematically adapted their customizations and
work habits to it.

I believe that autorevert mostly covers the functionality.  The only
problem is that autorevert quits either reverting or warning if the
buffer is modified.  (Emacs _does_ warn when you try to save your
changes to disk.)

I believe that it would not be too difficult to adapt the code in
autorevert to put a flag in the modeline that says whether the visited
file has changed on disk or not, regardless of whether the buffer is
modified or not.  This would be a mode (more of a mode line feature)
that could be enabled independently from Auto Revert.  If you do not
use Auto Revert, it would just tell you that the file had changed on
disk, leaving the decision of whether to revert or not up to the user.
It would be analogous to the flag telling you that you have new mail.
It would also not be very difficult to add a global flag indicating
that at least one file visited in some buffer has changed on disk, but
I believe that would be less useful than the "local" variant.

While I do not believe that would be terribly difficult to implement,
I personally do not have the time right now and we are in a feature freeze.

Sincerely,

Luc.

Re: Popup when buffer file is changed on disk

[Luc Teirlinck]

>From my previous message:

   I believe that it would not be too difficult to adapt the code in
   autorevert to put a flag in the modeline that says whether the visited
   file has changed on disk or not,

In addition the Buffer Menu could display the flag.  You can enable
Auto Revert in the Buffer Menu, thereby updating the flag every
auto-revert-interval seconds.

In as far as I am concerned, all stuff for Emacs 22, not 21.4.

Sincerely,

Luc.

Re: Popup when buffer file is changed on disk

[Jason Rumney]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> I think a popup should be used for this since it is more visible.

The dialog code has been waiting for someone to implement it on w32
for years. It would be better to put effort into implementing general
dialog support than to create a dialog especially for this purpose.

> Emacs should also keep track of when this question was asked last
> time (to avoid asking to many times).

I don't understand the rationale for this. If Emacs decides it has
asked too many times, what should it do?

Re: Popup when buffer file is changed on disk

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

> > Emacs should also keep track of when this question was asked last
> > time (to avoid asking to many times).
>
> I don't understand the rationale for this. If Emacs decides it has
> asked too many times, what should it do?

Sorry, "too many times" was not really what I meant. When Emacs asks about a
file change it should keep track of the modification (or write time) of the
changed file. If that time has not changed then do not ask again.

Re: Popup when buffer file is changed on disk

[Eli Zaretskii]

> Date: Sun, 06 Feb 2005 00:57:59 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: "moheb missaghi" <moheb1333@comcast.net>
> > Date: Sat, 5 Feb 2005 13:56:19 -0700
> > 
> > Microsoft's Visual Studio which has something called Intelisense which has a
> > knowledge of object hierarchy and allows object name completion.
> 
> Doesn't ECB provide that feature?

It is perhaps noteworthy that Ebrowse and maybe even Speedbar, both
bundled with Emacs 21.x, offer similar, if less elaborate,
functionality.

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    > For the case of hooks, we could imagine changing cus-edit.el so that
    > edits made using Custom only affect elements that were installed using
    > Custom.  Any other elements could be invisible and untouchable; or
    > they might be displayed in a separate way as "program-added hooks" and
    > untouchable through the usual Custom features.  In effect, this means
    > treating a single list as if it were the combination of too list
    > values, one to be edited through Custom and one to be updated
    > by programs.
    >
    > I don't know how hard this would be.

    Would not this require changes to the run hook functions too?

My proposal does not involve any changes to run-hooks.
I am talking about a change entirely within cus-edit.el.

    In that case
    it might be more simple to add a macro (or function) used for creating
    hooks, maybe "define-hook" that added the normal hook and a second hook used
    by Custom. (This would of course also require changes to the run hook
    functions.)

It should not be necessary to change all the definitions of hooks.
It would be much better to avoid that.  So let's look only at solutions
that do not require changing all the definitions of hooks.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous reply:

      Any other elements could be invisible and untouchable; or they
      might be displayed in a separate way as "program-added hooks"
      and untouchable through the usual Custom features.

   I believe the latter.  The user should know that there are other,
   untouchable things in the list.

Actually, the situation is more complex, certainly for non-hook atoms
(and I would guess probably also for many hooks).  Code puts things in
variables like completion-ignored-extensions, debug-ignored-errors,
file-coding-system-alist, help-event-list,
minibuffer-prompt-properties, mode-line-format,
same-window-buffer-names, same-window-regexps, and many others, that
the user definitely might want to override.  The same could be true
for many hooks.  So it looks like we should also give the user veto
power over code and implement `remove-hook' and `delete' functionality
through Custom, adding to the complexity.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous message:

   So it looks like we should also give the user veto
   power over code and implement `remove-hook' and `delete' functionality
   through Custom, adding to the complexity.

Maybe we could avoid that additional complexity if non-preloaded code
strictly adhered to the conventions proposed in another message and if
preloaded code put, for all involved list-vars, all elements of the
involved hook, list or alist, that should be user-overridable in
custom-list-var (instead of just in list-var).  That way, these
elements would _not_ appear in the Custom buffer as "untouchable".

We are talking about approximately ten preloaded variables of this
type, so it should be not too much of a hassle to treat them
separately.

This way, not too much complexity is added to the original proposal.
I am afraid that implementing the original proposal might nevertheless
be more than complex enough.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous message:

   Maybe we could avoid that additional complexity if non-preloaded code
   strictly adhered to the conventions proposed in another message and if
   preloaded code put, for all involved list-vars, all elements of the
   involved hook, list or alist, that should be user-overridable in
   custom-list-var (instead of just in list-var).  That way, these
   elements would _not_ appear in the Custom buffer as "untouchable".

The situation is somewhat more complex.  _Newly added_ (by code)
elements could be unwittingly overridden by .emacs if they were just
put into custom-list-var.  (That is one of the reasons why the
distinction between list-var and custom-list-var is needed.  I forgot
about that for a moment.)  But _maybe_ it is OK anyway.  _Essential_
elements get put in list-var, so Emacs will never malfunction as a
result of essential new code being overridden in .emacs.
Non-essential ones go in custom-list-var.  When upgrading to a new
Emacs version, the user could then do `M-x customize-changed-options'
to see what new non-essential elements were added and see whether he
likes them.

Maybe we may need special `remove-hook' and `delete' functionality,
maybe we can avoid it.  Probably the person volunteering to implement
this (if anybody) might have to decide.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    Actually, the situation is more complex, certainly for non-hook atoms
    (and I would guess probably also for many hooks).  Code puts things in
    variables like completion-ignored-extensions, debug-ignored-errors,
    file-coding-system-alist, help-event-list,
    minibuffer-prompt-properties, mode-line-format,
    same-window-buffer-names, same-window-regexps, and many others, that
    the user definitely might want to override.

The right thing to do may not be the same for all these variables.  We
would need to look at them one by one in order to come to conclusions
about what to do with them.

For same-window-buffer-names, we could arrange for all the values
added by Lisp packages to be part of the "standard value".
That would be a start at solving the problem.

I don't think that minibuffer-prompt-properties is a problem.  It is
simply a customizable variable whose value is set up with a setq.
Likewise for help-event-list.  If there is a problem with these, it is
only that they are built-in and handled by cus-start.el rather than
a defcustom.  We just need to give them the right standard value.

Do you want to try to do that?

It would be useful to look for other variables that are in the same
situation, and handle them.  These being localized bug fixes,
we could safely install them now.

    Maybe we could avoid that additional complexity if non-preloaded code
    strictly adhered to the conventions proposed in another message and if
    preloaded code put, for all involved list-vars, all elements of the
    involved hook, list or alist, that should be user-overridable in
    custom-list-var (instead of just in list-var).

We could say that any adding of values to these variables by Lisp code
has to be done by an autoload, so that the whole value is constructed
by loadup.el.  Then we can arrange to record it as the standard value,
and that will be a good start at solving the problems.

We could have a function custom-add-to-list which adds an element to a
list and makes it part of the standard value.

    Just _loading_ a non-preloaded file should not change any defcustomed
    variable unless "harmless" (like a hook function only used to gather
    info and without user visible consequences).

This is already the convention.  Do you know of any cases where
this case is violated?

    When changing a defcustomed variable from a function, that function
    should be interactively called by the user and either the _only_
    effect should be to implement the documented behavior of the function
    (for instance by adding a function to a hook that implements that
    behavior and does not interfere with anything else), or the fact that
    elements are going to be added to the defcustom should be clearly
    documented in the docstring and in any manual where the function is
    described.


This seems plausible.  Do you know of any specific exceptions?

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

Richard Stallman wrote:

   I don't think that minibuffer-prompt-properties is a problem.  It is
   simply a customizable variable whose value is set up with a setq.
   Likewise for help-event-list.  If there is a problem with these, it is
   only that they are built-in and handled by cus-start.el rather than
   a defcustom.  We just need to give them the right standard value.

   Do you want to try to do that?

If you mean removing the "Changed outside Custom" warning from those
rogue-at-startup (with emacs -q) variables that are really harmless,
then I could definitely do that way in time for Emacs 22 (old 21.4).

The way in which I would do that could be a temporary solution until a
more fundamental solution is implemented.  I could mention that in a
comment.

I might need to keep the "Changed outside Custom" warning for the two
hooks in the list.   I will need to take a closer look at that.

At a given moment we will have to implement the splitting of hooks and
probably other list vars into two parts which we discussed.  Until we
do that bugs in Custom will remain, but they are not new bugs.  These
bugs are serious, but the probability of users encountering them is
limited by the fact that the involved variables are not often used by
beginning users and are inconvenient to set through Custom anyway.  As
we get more hooks like `before-save-hook', by which the user can
enable two relatively popular features by a simple mouse click or
RETURN, the probability of users actually being inconvenienced by
those bugs will increase.  So we can not wait forever to fix them but
I believe we can (actually have to) wait until after the 22 release.

Getting rid of the bugs I described will require fundamental changes
in the Custom user interface.  Until we look at these problems
carefully and implement solutions, I would make as few changes to the
current Custom interface as possible.  I believe it would be bad to
have an oddball 22 Custom interface that would be very different from
both the 21 and the 23 interface.  People are used to the old
interface.  They should not have to adapt to non-trivial changes for
one single release (or *maybe* two releases, should 23 be released
very soon after 22).

We very definitely need to keep "Set outside Custom" until the bugs
are fixed.  Whether we still need it afterward depends on the
particular interface we wound up with.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    If you mean removing the "Changed outside Custom" warning from those
    rogue-at-startup (with emacs -q) variables that are really harmless,
    then I could definitely do that way in time for Emacs 22 (old 21.4).

    The way in which I would do that could be a temporary solution until a
    more fundamental solution is implemented.  I could mention that in a
    comment.

This is the wrong solution.  The right solution for variables such as
minibuffer-prompt-properties is to set up a valid expression for its
standard value.  It may be necessary to store the current default
value in a new variable so that the standard value can use that
variable.  This is easy and simple, it's just that each variable needs
to be looked at separately.  Would you like to do this for some
of the variables?

Re: find-file-hook as illustration of Custom problems

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     If you mean removing the "Changed outside Custom" warning from those
>     rogue-at-startup (with emacs -q) variables that are really harmless,
>     then I could definitely do that way in time for Emacs 22 (old 21.4).
>
>     The way in which I would do that could be a temporary solution until a
>     more fundamental solution is implemented.  I could mention that in a
>     comment.
>
> This is the wrong solution.  The right solution for variables such as
> minibuffer-prompt-properties is to set up a valid expression for its
> standard value.  It may be necessary to store the current default
> value in a new variable 

or use a `valid-expression' property on the variable 

>                         so that the standard value can use that
> variable.  This is easy and simple, it's just that each variable needs
> to be looked at separately.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    > This is the wrong solution.  The right solution for variables such as
    > minibuffer-prompt-properties is to set up a valid expression for its
    > standard value.  It may be necessary to store the current default
    > value in a new variable 

    or use a `valid-expression' property on the variable 

I do not understand that suggestion.
The symbol `valid-expression' does not occur in cus-edit.el.
If you are proposing it as the way to represent some new feature,
I don't know what the new feature would do.

Re: find-file-hook as illustration of Custom problems

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > This is the wrong solution.  The right solution for variables such as
>     > minibuffer-prompt-properties is to set up a valid expression for its
>     > standard value.  It may be necessary to store the current default
>     > value in a new variable 
>
>     or use a `valid-expression' property on the variable 
>
> I do not understand that suggestion.
> The symbol `valid-expression' does not occur in cus-edit.el.
> If you are proposing it as the way to represent some new feature,
> I don't know what the new feature would do.

Sorry, I misread what you read.

The essence of my idea is to use _some_ property on the original
variable to "store the current default value", rather than using
a "new variable" for that.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    The essence of my idea is to use _some_ property on the original
    variable to "store the current default value", rather than using
    a "new variable" for that.

That is ok.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

Richard Stallman wrote:

   This is the wrong solution.  The right solution for variables such as
   minibuffer-prompt-properties is to set up a valid expression for its
   standard value.  It may be necessary to store the current default
   value in a new variable so that the standard value can use that
   variable.  This is easy and simple, it's just that each variable needs
   to be looked at separately.  Would you like to do this for some
   of the variables?

Yes, for some.  Here is a try at one.

Actually, I started out with my least favorite Emacs feature,
`blink-cursor'.  Reason for that is that this one had a very
intriguing bug.  This extra bug is unrelated to the stuff we have been
discussing here, but we should fix it anyway.  It is confusing and
annoying.

Description of bug:

Do `emacs -q --eval "(blink-cursor-mode 0)" &'.  Then:

M-x customize-rogue (actually, `C-h v blink-cursor' works too).

We now see that blink-cursor is t, even though the cursor does not blink.

If we do `M-x load-library RET frame", the cursor _does_ start blinking.
(Courtesy of custom-initialize-reset.  I looked away as fast as I
could and typed `C-x C-c'.)

The problem is that the function `blink-cursor-mode' sets the value of
the variable blink-cursor-mode, but not of blink-cursor.  The patch
below does get rid of blink-cursor altogether and uses
blink-cursor-mode instead.  I know there must have been some reason
why that was not done all along, but I guess it must have been related
to the fake defcustom stuff, which the patch also gets rid of (that
was the original purpose).

One problem is that this will mess things up for the (I suppose many)
people who have set blink-cursor to nil_in their custom-set-variables
form.  The patch keeps blink-cursor as an alias for blink-cursor-mode,
but Custom does apparently not recognize aliases.  (That is probably
something we could and should fix still for Emacs 22.)

I do not know whether the combination phony-defvar, then
defvar-mimicking setq, then makunbound, then non-top-level defcustom
in startup.el is acceptable.  It seems to do the job.  The problem
with a temporary variable, as you suggested, seems to be that code
should use the same variable during startup and after that, so it did
not seem like it would work very well.

As a minor detail:

`blink-cursor-timer' now seems to call `blink-cursor-timer-function'
instead of `blink-cursor'.  The patch addresses this too.

===File ~/frame.el-diff=====================================
*** frame.el	09 Feb 2005 15:59:13 -0600	1.215
--- frame.el	09 Feb 2005 22:50:04 -0600	
***************
*** 1253,1262 ****
  
  (defvar blink-cursor-timer nil
    "Timer started from `blink-cursor-start'.
! This timer calls `blink-cursor' every `blink-cursor-interval' seconds.")
  
! (defvar blink-cursor-mode nil
!   "Non-nil means blinking cursor is active.")
  
  (defun blink-cursor-mode (arg)
    "Toggle blinking cursor mode.
--- 1253,1267 ----
  
  (defvar blink-cursor-timer nil
    "Timer started from `blink-cursor-start'.
! This timer calls `blink-cursor-timer-function' every
! `blink-cursor-interval' seconds.")
  
! ;; This will be unbound and defcustomed in startup.el.  We can not
! ;; defcustom it  here because the default depends on the operating system.
! (defvar blink-cursor-mode)
! (defvaralias 'blink-cursor 'blink-cursor-mode)
! (make-obsolete-variable 'blink-cursor 'blink-cursor-mode "22.1")
! (unless (boundp 'blink-cursor-mode) (setq blink-cursor-mode nil))
  
  (defun blink-cursor-mode (arg)
    "Toggle blinking cursor mode.
***************
*** 1289,1306 ****
  	  (setq blink-cursor-mode t))
        (internal-show-cursor nil t))))
  
- ;; Note that this is really initialized from startup.el before
- ;; the init-file is read.
- 
- (defcustom blink-cursor nil
-   "*Non-nil means blinking cursor mode is active."
-   :group 'cursor
-   :tag "Blinking cursor"
-   :type 'boolean
-   :set #'(lambda (symbol value)
- 	   (set-default symbol value)
- 	   (blink-cursor-mode (or value 0))))
- 
  (defun blink-cursor-start ()
    "Timer function called from the timer `blink-cursor-idle-timer'.
  This starts the timer `blink-cursor-timer', which makes the cursor blink
--- 1294,1299 ----
============================================================

===File ~/startup.el-diff===================================
*** startup.el	28 Dec 2004 09:50:38 -0600	1.337
--- startup.el	09 Feb 2005 19:46:22 -0600	
***************
*** 735,747 ****
                (<= (frame-parameter nil 'tool-bar-lines) 0))
      (tool-bar-mode 1))
  
!   ;; Can't do this init in defcustom because window-system isn't set.
!   (unless (or noninteractive
! 	      emacs-quick-startup
!               (eq system-type 'ms-dos)
!               (not (memq window-system '(x w32))))
!     (setq-default blink-cursor t)
!     (blink-cursor-mode 1))
  
    (unless noninteractive
      ;; DOS/Windows systems have a PC-type keyboard which has both
--- 735,753 ----
                (<= (frame-parameter nil 'tool-bar-lines) 0))
      (tool-bar-mode 1))
  
!   (makunbound 'blink-cursor-mode)
!   (defcustom blink-cursor-mode
!     (not (or noninteractive
! 	     emacs-quick-startup
! 	     (eq system-type 'ms-dos)
! 	     (not (memq window-system '(x w32)))))
!     "*Non-nil means Blinking Cursor mode is active."
!     :group 'cursor
!     :tag "Blinking cursor"
!     :type 'boolean
!     :set #'(lambda (symbol value)
! 	     (set-default symbol value)
! 	     (blink-cursor-mode (or value 0))))
  
    (unless noninteractive
      ;; DOS/Windows systems have a PC-type keyboard which has both
============================================================
 LocalWords:  defvar

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

It is rather unclean to have a defcustom inside a function.
Let's try to solve this1 some other way.

The conventional way to handle custom definitions for variables
that are defined too early to use defcustom is thru cus-start.el.
Could you make it work that way?

I see that, for variables set up in cus-start.el, the standard value
is merely whatever value happens to be in effect when cus-edit is
loaded.  This is a lot like a suggestion that someone made
for how to handle settings in the init file.  However, it's not right
for this case.  So I added a feature to make it possible to specify
a standard value expression for each variable.

Does this patch work right?


*** cus-start.el	10 Feb 2005 01:13:19 -0500	1.64
--- cus-start.el	10 Feb 2005 12:12:56 -0500	
***************
*** 287,294 ****
  	     ;; xterm.c
               (mouse-autoselect-window display boolean "21.3")
  	     (x-use-underline-position-properties display boolean "21.3")
! 	     (x-stretch-cursor display boolean "21.1")))
!       this symbol group type native-p version
        ;; This function turns a value
        ;; into an expression which produces that value.
        (quoter (lambda (sexp)
--- 287,302 ----
  	     ;; xterm.c
               (mouse-autoselect-window display boolean "21.3")
  	     (x-use-underline-position-properties display boolean "21.3")
! 	     (x-stretch-cursor display boolean "21.1")
! 	     ;; frame.el
! 	     (blink-cursor-mode cursor boolean 
! 				'(not (or noninteractive
! 					  emacs-quick-startup
! 					  (eq system-type 'ms-dos)
! 					  (not (memq window-system '(x w32))))))
! 
! 	     ))
!       this symbol group type standard version native-p
        ;; This function turns a value
        ;; into an expression which produces that value.
        (quoter (lambda (sexp)
***************
*** 297,304 ****
  			(and (listp sexp)
  			     (memq (car sexp) '(lambda)))
  			(stringp sexp)
- ;; 			(and (fboundp 'characterp)
- ;; 			     (characterp sexp))
  			(numberp sexp))
  		    sexp
  		  (list 'quote sexp)))))
--- 305,310 ----
***************
*** 309,314 ****
--- 315,325 ----
  	  group (nth 1 this)
  	  type (nth 2 this)
  	  version (nth 3 this)
+ 	  ;; If we did not specify any standard value expression above,
+ 	  ;; use the current value as the standard value.
+ 	  standard (if (nthcdr 4 this)
+ 		       (nth 4 this)
+ 		     (funcall quoter (default-value symbol)))
  	  ;; Don't complain about missing variables which are
  	  ;; irrelevant to this platform.
  	  native-p (save-match-data
***************
*** 326,333 ****
  	     (message "Note, built-in variable `%S' not bound" symbol))
        ;; Save the standard value, unless we already did.
        (or (get symbol 'standard-value)
! 	  (put symbol 'standard-value
! 	       (list (funcall quoter (default-value symbol)))))
        ;; If this is NOT while dumping Emacs,
        ;; set up the rest of the customization info.
        (unless purify-flag
--- 337,343 ----
  	     (message "Note, built-in variable `%S' not bound" symbol))
        ;; Save the standard value, unless we already did.
        (or (get symbol 'standard-value)
! 	  (put symbol 'standard-value (list standard)))
        ;; If this is NOT while dumping Emacs,
        ;; set up the rest of the customization info.
        (unless purify-flag

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

My previously posted patch was indeed not very good.  Among other
things `C-h v blinking-cursor-mode' did not find the defcustom.  The
patch you proposed has a similar problem.  Also cus-start.el is meant
for variables defined in the C code.  I believe that we should avoid
using it for Lisp variables, if possible.  I now believe that the
following patch to frame.el would be better.  I believe that Per
designed the standard value to be an unevaluated expression exactly to
allow what the patch below does.  The accompanying patch to startup.el
is now very minor.

===File ~/frame.el-diff=====================================
*** frame.el	09 Feb 2005 15:59:13 -0600	1.215
--- frame.el	10 Feb 2005 17:42:44 -0600	
***************
*** 1253,1262 ****
  
  (defvar blink-cursor-timer nil
    "Timer started from `blink-cursor-start'.
! This timer calls `blink-cursor' every `blink-cursor-interval' seconds.")
  
! (defvar blink-cursor-mode nil
!   "Non-nil means blinking cursor is active.")
  
  (defun blink-cursor-mode (arg)
    "Toggle blinking cursor mode.
--- 1253,1289 ----
  
  (defvar blink-cursor-timer nil
    "Timer started from `blink-cursor-start'.
! This timer calls `blink-cursor-timer-function' every
! `blink-cursor-interval' seconds.")
  
! ;; The strange sequence below is meant to set both the right temporary
! ;; value and the right "standard expression" , according to Custom,
! ;; for blink-cursor-mode.  We do not know the concrete standard
! ;; _evaluated_ value yet, because the standard expression uses values
! ;; that are not yet set.  Evaluating it now would yield an error, but
! ;; we make sure that it is not evaluated, by making sure that
! ;; blink-cursor-mode is set before the defcustom is evaluated and by
! ;; using the right :initialize function.  The correct evaluated
! ;; standard value will be installed in startup.el using exactly the
! ;; same expression as in the defcustom.
! (defvar blink-cursor-mode)
! (unless (boundp 'blink-cursor-mode) (setq blink-cursor-mode nil))
! (defcustom blink-cursor-mode
!   (not (or noninteractive
! 	   emacs-quick-startup
! 	   (eq system-type 'ms-dos)
! 	   (not (memq window-system '(x w32)))))
!   "*Non-nil means Blinking Cursor mode is active."
!   :group 'cursor
!   :tag "Blinking cursor"
!   :type 'boolean
!   :initialize 'custom-initialize-set
!   :set #'(lambda (symbol value)
! 	   (set-default symbol value)
! 	   (blink-cursor-mode (or value 0))))
! 
! (defvaralias 'blink-cursor 'blink-cursor-mode)
! (make-obsolete-variable 'blink-cursor 'blink-cursor-mode "22.1")
  
  (defun blink-cursor-mode (arg)
    "Toggle blinking cursor mode.
***************
*** 1289,1306 ****
  	  (setq blink-cursor-mode t))
        (internal-show-cursor nil t))))
  
- ;; Note that this is really initialized from startup.el before
- ;; the init-file is read.
- 
- (defcustom blink-cursor nil
-   "*Non-nil means blinking cursor mode is active."
-   :group 'cursor
-   :tag "Blinking cursor"
-   :type 'boolean
-   :set #'(lambda (symbol value)
- 	   (set-default symbol value)
- 	   (blink-cursor-mode (or value 0))))
- 
  (defun blink-cursor-start ()
    "Timer function called from the timer `blink-cursor-idle-timer'.
  This starts the timer `blink-cursor-timer', which makes the cursor blink
--- 1316,1321 ----
============================================================

===File ~/startup.el-diff===================================
*** startup.el	28 Dec 2004 09:50:38 -0600	1.337
--- startup.el	10 Feb 2005 17:18:09 -0600	
***************
*** 735,746 ****
                (<= (frame-parameter nil 'tool-bar-lines) 0))
      (tool-bar-mode 1))
  
!   ;; Can't do this init in defcustom because window-system isn't set.
    (unless (or noninteractive
  	      emacs-quick-startup
                (eq system-type 'ms-dos)
                (not (memq window-system '(x w32))))
-     (setq-default blink-cursor t)
      (blink-cursor-mode 1))
  
    (unless noninteractive
--- 735,748 ----
                (<= (frame-parameter nil 'tool-bar-lines) 0))
      (tool-bar-mode 1))
  
!   ;; Can't do this init in defcustom because the relevant variables
!   ;; are not set.  If you make any changes to the `or' form below,
!   ;; you should also change the corresponding expression in the
!   ;; defcustom in frame.el, or Custom will be badly confused.
    (unless (or noninteractive
  	      emacs-quick-startup
                (eq system-type 'ms-dos)
                (not (memq window-system '(x w32))))
      (blink-cursor-mode 1))
  
    (unless noninteractive
============================================================

Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

This patch is clever.  Please install it.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous reply:

  My previously posted patch was indeed not very good.  Among other
  things `C-h v blinking-cursor-mode' did not find the defcustom.  The
  patch you proposed has a similar problem.

The last remark may have been a little bit confusing.  Meant was:
finding the defcustom by clicking on "Defined in ...".  In the case of
your patch, of course it can not do that, because there is no defcustom.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous message:

   Among other things `C-h v blinking-cursor-mode' did not find the
   defcustom.

I meant that `C-h v blink-cursor-mode' did not find the defcustom.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previously posted patch:

  ! ;; This will be unbound and defcustomed in startup.el.  We can not
  ! ;; defcustom it  here because the default depends on the operating system.
  ! (defvar blink-cursor-mode)

I believe that the following is a somewhat better comment:

;; This will be unbound and defcustomed in startup.el.  We can not
;; defcustom it here because `window-system' is not set yet.
(defvar blink-cursor-mode)

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous message:

    So it looks like we should also give the user veto power over code
    and implement `remove-hook' and `delete' functionality through
    Custom, adding to the complexity.

But it is difficult to see how this could work reliably.  The
`remove-hook' or `delete' functionality is only going to work if the
code adds the stuff _before_ the user's custom-set-variables form is
executed.  Code that runs later will override the user's veto and add
the stuff back anyway.  We would have to do something like keep track
of all Lisp files that add code to defcustoms (and what code to which
defcustom) and put the remove-hook or delete in an `eval-after-load'
call.  That does not seem very attractive.

Problems related to Custom tend to grow more and more complex the
longer you keep thinking about them.

Sincerely,

Luc.

Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

>From my previous message:
   
   Code that runs later will override the user's veto and add
   the stuff back anyway.

Note that this is not a problem that would be a consequence of the
discussed changes.  It is a problem that exists right now.  If, in
present code, a non-preloaded Lisp file adds elements to a defcustomed
hook, list or alist, then there is no way that you can presently
override that in your `custom-set-variables' form.  To override it in
your .emacs you have to use `eval-after-load' or similar.

To avoid this, I believe that the following conventions should be
documented and followed.  Is there any objection against any of the
following conventions?

In the following "changing" a defcustomed variable means _changing the
global default value_.  Changing buffer local values or `let' bindings
are OK.

Just _loading_ a non-preloaded file should not change any defcustomed
variable unless "harmless" (like a hook function only used to gather
info and without user visible consequences).  Currently, just loading
autorevert.el adds a function to find-file-hook, but that function is
"harmless" in the above sense.

When changing a defcustomed variable from a function, that function
should be interactively called by the user and either the _only_
effect should be to implement the documented behavior of the function
(for instance by adding a function to a hook that implements that
behavior and does not interfere with anything else), or the fact that
elements are going to be added to the defcustom should be clearly
documented in the docstring and in any manual where the function is
described.

Sincerely,

Luc.