From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.bugs Subject: bug#13583: 24.3.50; Error when activating auto-revert-mode Date: Wed, 30 Jan 2013 23:42:02 +0000 Message-ID: <821ud2p7at.fsf@gmail.com> References: <83ehh4i6rs.fsf@gnu.org> <83d2woi43u.fsf@gnu.org> <83boc8i2u5.fsf@gnu.org> <85ip6gow8p.fsf@iznogoud.viz> <82r4l3k7gm.fsf@gmail.com> <7110B850AC6142F787053C16D069232C@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1359589413 31002 80.91.229.3 (30 Jan 2013 23:43:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jan 2013 23:43:33 +0000 (UTC) To: 13583@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 31 00:43:53 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U0hJm-0001UV-6C for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jan 2013 00:43:50 +0100 Original-Received: from localhost ([::1]:36855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0hJU-0003qJ-62 for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Jan 2013 18:43:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0hJP-0003qC-7T for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:43:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0hJL-0007H8-NC for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:43:26 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0hJL-0007H4-Jt for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:43:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U0hJy-00027q-9g for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:44:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Andy Moreton Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jan 2013 23:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13583 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13595894038087 (code B ref -1); Wed, 30 Jan 2013 23:44:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 30 Jan 2013 23:43:23 +0000 Original-Received: from localhost ([127.0.0.1]:56429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0hJK-00026N-C3 for submit@debbugs.gnu.org; Wed, 30 Jan 2013 18:43:23 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58176) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0hJF-00025s-BP for submit@debbugs.gnu.org; Wed, 30 Jan 2013 18:43:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0hIa-0006v8-MN for submit@debbugs.gnu.org; Wed, 30 Jan 2013 18:42:38 -0500 Original-Received: from lists.gnu.org ([208.118.235.17]:46420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0hIa-0006v2-Hp for submit@debbugs.gnu.org; Wed, 30 Jan 2013 18:42:36 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0hIS-0003fL-7H for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:42:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0hIQ-0006s0-0G for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:42:28 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:34281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0hIP-0006rb-NG for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2013 18:42:25 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U0hId-00011U-Or for bug-gnu-emacs@gnu.org; Thu, 31 Jan 2013 00:42:39 +0100 Original-Received: from 82-69-64-228.dsl.in-addr.zen.co.uk ([82.69.64.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Jan 2013 00:42:39 +0100 Original-Received: from andrewjmoreton by 82-69-64-228.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Jan 2013 00:42:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 177 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82-69-64-228.dsl.in-addr.zen.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) Cancel-Lock: sha1:SOU3U8YIGjnsyT8YSybW3djwpJA= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:70506 Archived-At: On Tue 29 Jan 2013, Drew Adams wrote: >> and avoid Customize altogether. > > Not at all. There is nothing that "forces all users" who do more than tinker to > "avoid Customize altogether". That's an extreme (because of "force") version of > precisely the fallacy that I'm trying to point out. > > Just because a user knows some Elisp is no reason that s?he should (let alone is > forced to) "avoid Customize altogether". > > You are perfectly illustrating the very problem I pointed to: users can > mistakenly think that having recourse to Elisp instead of Customize is somehow > more advanced or somehow necessary to do anything non-trivial. Nothing could be > further from the truth. I don't use customize at all. It's hard to find options in the UI and its harder to configure things via the UI than to do it directly via elisp. > I would add, however, that there are too many users of defcustom who either do > not understand its possibilities or are too lazy to DTRT when it comes to > defining the :type and the possible user inputs/interactions. > > Based on core code I've seen, this applies also to Emacs Dev, to some extent. > It is all too easy to just throw together a simple but awful definition - one > that is not as helpful to users as it should be. This is an essential problem of the customize package. By making it to hard to write and debug something robust, package authors are more likely to do the minimum neccesary to "tick the box" and move on. The very prescence of customize is a strong disicentive for a developer to come up with something better, due to all fo the comatibiility and migration headaches that must be overcome for a replacement or evolution to be acceptable. >> The type checking may useful, but it shouldn't be buried in a library >> that brings in so much extra cruft with it. > > I agree 100%. It's an important point. All the more important because this > feature is available to Emacs Lisp programmers ONLY for option customization. > So they do not and cannot take advantage of it otherwise. And in many cases > they are, I think, not even very aware of it. Type checking and accessor methods are fundamental primitives that belong in the interpreter/compiler or an object system library. The extra stuff for deciding how to present a variavble of a particular type in UI is a separate set of concerns. > This is so important, IMO, that I've suggested that such type-checking (i.e., > defcustom :type's) could be useful for non-option variables (defvars) as well. > There is no reason not to be able to take advantage of this feature for other > variables. Unfortunately, there was little interest: "YAGNI", was about the > only response. The Cygwin folk use SHTDI (somebody has to do it) and PTC (patches thoughtfully considered), both which are applicable here. > Today, if you want to take advantage of type-checking then you need to make the > variable that benefits from it into a user option. Emacs Dev should separate > these two orthogonal things: type checking and user customizability. Agreed (but see above). >> Far better to make those facilities available and useful whether >> the customize UI is used or not, > > +1! I could not agree more. > >> and to document this style of usage in the emacs manual (even >> if this is only links to the elisp manual). > > +1 again. > >> Customize is also strongly anti modular, lumping settings for >> eveything together, and giving the user no control over per >> platform or per machine settings. >> >> It also neatly ensures that the user cannot add any >> comments to the customised settings when they are saved. > > Yes, those are among the things that should be improved. There is in fact a lot > of room for improvement in the Customize UI and wrt Emacs customizing more > generally. > > As I mentioned, one problem is that the custom* (more generally, the widget*) > code is difficult to fathom and poorly documented. The result is that few Elisp > programmers can or want to hack it. Agreed. These code quality issues are good reasons for delaying integration of a new feature until the basics are in place. > And that probably goes for Emacs Dev programmers as well. The author, Per A., > was not wont to spend much effort communicating with Emacs Dev about the code. > It lacks, above all, easy ways to follow it and discover info about its parts. > Following it in the debugger is, well, "interesting". > > Another problem, another reason that few people hack the Customize code, I > think, is the phenomenon I pointed to earlier: they don't bother to use the > Customize UI themselves, so they are not that familiar with it and its problems, > and they too easily tend to think that it is beneath them, somehow lower than > using Lisp. No, I think the problem is that most emacs devs don't use it because they do not experince the problems that it clains to be a solution for. Those who have used it have discovered that it causes pain, and resolved not to repeat the experience. > I _want_ Customize to automatically manage most of my option and face > customizations. > > But in a separate `custom-file'. I specifically keep my init file away from > Customize, and I think Emacs Dev should advise most users to do the same thing. > There is little reason to let a program mix automatically generated code in with > your manually edited code. And vice versa, there is little reason for you to be > editing the same file that contains automatically generated code. That is the only thing I configure about it: to prevent it damaging my init file :-) >> > The best thing that could happen - for users, IMO, is for >> > Emacs developers to stop, themselves, using "Custom only for >> > face settings" etc., and thus confront the deficiencies of the >> > UI directly. Turn your frustration with it into >> > something constructive - for all users. >> >> No, the best thing would be to remove Customize altogether :-) > > Though I disagree, I won't argue with you about that. I will say that that > attitude is a primary obstacle to our improving customization for Emacs users. > I don't mean your attitude personally, but the fact that the same attitude is so > prevalent. > > The reaction of most Emacs developers is just to ignore Customize, which is no > more helpful than removing it would be. > > FWIW, I used to feel exactly as you just expressed it: Customize is not worth > it. Little by little I came to learn more about it, and now I feel strongly > that it is a good thing. > > Had I not tried to make my code useful for other users besides myself, I would > never have bothered to learn more about defcustom :type's etc. I would have > just continued to keep the same attitude toward what Customize is good for: > nothing. > > Not that the _UI_ is wonderful - far from it. It is especially all of the > behind-the-scenes initialization, :set triggering, backing up, and type-checking > that is helpful, if not indispensable for robust preference management. That machinery is what puts me off in the first place. Customize wraps everything up in an embedded language to describe how to transform settings into lisp. I'd rather avoid the obfuscation and write the lisp myself to start with. > Trying to take advantage of those features using only Lisp is the problem that > was at the starting point of this thread. You can do it, but you must be on > your toes and learn a fair amount about the custom* code. See earlier in the > thread, about different "ugly little hacks" to get custom* to do what you want. > > I do some of that myself, and I put some of it into an extension of the > Customize UI code, so that others can benefit without needing to dive into the > custom* code themselves each time. Please consider contributing these improvements to emacs. > IMO, that's the kind of thing we need, to start with: fix the UI so it lets you > do the kinds of things that started this thread: e.g., tell Customize to ignore > certain changes and consider them irrelevant to saving. > > There is no reason that users should need to use Lisp to do this kind of thing. > It is simple to give them an action in the UI that accomplishes the same thing. Agreed, but this should not be at the expense of doing things directly from code and avoiding the UI. AndyM