Re: Info warnings

Hrvoje> OK, for quite a few betas Info has been pretty insistent in throwing Hrvoje> warnings in my face. I was kind of hoping this would be resolved, so Hrvoje> I stayed silent. However, it is not getting solved, so I have to Hrvoje> speak up. The subject has been discussed for a while some time ago. I made some changes according to the state that discussion was left and since nobody complained, I assumed that everybody accepted the current behaviour. Hrvoje> The warning is this: Hrvoje> (1) (info/notice) Outdated info dir file: /usr/local/info/dir This is not strictly a warning but a notice. Hrvoje> Of course, I don't even have permission to modify the Hrvoje> /usr/local/info/dir file, and neither has any of the users on the Hrvoje> machine I run XEmacs on. So, the warning will be seen by all of them, Hrvoje> and likely many more of our users in the world. Hrvoje> What is the *purpose* of this warning, anyway? Warnings should inform Hrvoje> the user of a condition he/she should remedy. Your not having the right to overwrite that file at the moment you run Info does not mean you can not acquire that right. So you may be able to remedy the problem with that file. This notice tells you also you should be aware that the Info directory you're seeing is not the one that's on your disk but one that was automatically generated on the fly. I suppose that by default a user wants this kind of information. As usual, if this is not the case and you don't want that information you're not helpless, you can either: - set `Info-rebuild-outdated-dir' to `never' or `always' - set `display-warning-minimum-level' to 'warning - set `display-warning-suppressed-classes' to '(info) Hrvoje> I don't see how I could remedy this -- even if I bug my sysadmin into Hrvoje> updating `dir', it will get outdated the first time he installs Hrvoje> another package. The first time he installs another package he should update the dir file consequently with `install-info' or `xemacs -batch -f Info-batch-rebuild-dir DIR' Hrvoje> I don't even see why I *should* remedy this situation, because XEmacs Hrvoje> appears perfectly able to deal with the situation. This is not an error but an informative message so XEmacs has no problem dealing with the situation. IMO, the current default is good (provided I document better how to change that behaviour, which I will do ASAP) and it seemed to me from the previous discussion there was a majority in favour. I may be wrong however (and then will agree to change that default once again), so I would like more feedback on the issue before making any further change. Oscar