emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

files.el: Once again impossible to turn off dir-settings


From: T.V. Raman
Subject: files.el: Once again impossible to turn off dir-settings
Date: Tue, 25 Nov 2008 11:00:28 -0800

Stephane -
The slowness --- at least as I observe at my end, has not been
fixed.
In the caase of vc-backends, I'm able to avoid global crawls
across NFS filesystems by setting
;;; vc speed up:

(setq vc-ignore-dir-regexp
"\\`\\([\\/][\\/]\\|/net/\\|/home/\\|/afs/\\)\\'")
Notice the addition of /home above  -- in my case /home is nfs
mounted.

I strongly urge you to reconsider forcing all users to  take the
hit of searching for project settings.

For now, I've defadviced hack-dir-local-variables like so:
(defadvice hack-dir-local-variables (around fix-slowness pre act comp)
  "Restore democracy, restore speed"
nil)

-- 
Best Regards,
--raman

Title:  Research Scientist
Email:  address@hidden
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  address@hidden, address@hidden
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc



On 11/25/08, Stefan Monnier <address@hidden> wrote:
>> I've been watching the thread about forcing users to always take
>> the performance hit of walking up the directory tree with some
>> dismay. I notice that after the latest round of changes, it has
>> once again become impossible to disable project settings ---
>> other than locally advising hack-dir-local-variables ---
>> something the extreme ened of power users can certainly do -- (I
>> already have).
>
> I thought we had fixed this slowness.  I often access files over the
> network and have not bumped into this slowness, so I'm pretty sure it
> can be avoided without turning off the feature.  Especially since the
> "walk up the dir" is not done only for dir-settings but also for
> VC backends, so it's pretty heavily used (meaning not that it's
> important, but that we should have seen this slowness more often if it
> was "normal").
>
> Can we go back to trying to actually fix the slowness rather than
> workaround it?
>
>
>         Stefan
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]