From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13490: toolkit, toolkit, who's got the toolkit? Date: Sat, 19 Jan 2013 07:39:50 -0800 Message-ID: References: <83obgm5l83.fsf@gnu.org> <83a9s5qx09.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1358610077 26320 80.91.229.3 (19 Jan 2013 15:41:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2013 15:41:17 +0000 (UTC) Cc: 13490@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 19 16:41:36 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 1TwaY3-0006mG-Gk for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Jan 2013 16:41:35 +0100 Original-Received: from localhost ([::1]:57272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwaXm-00020Z-La for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Jan 2013 10:41:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwaXg-00020S-QD for bug-gnu-emacs@gnu.org; Sat, 19 Jan 2013 10:41:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TwaXe-0008VP-58 for bug-gnu-emacs@gnu.org; Sat, 19 Jan 2013 10:41:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwaXe-0008VI-1m for bug-gnu-emacs@gnu.org; Sat, 19 Jan 2013 10:41:10 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TwaYU-0000eG-3b for bug-gnu-emacs@gnu.org; Sat, 19 Jan 2013 10:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jan 2013 15:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13490 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13490-submit@debbugs.gnu.org id=B13490.13586100632418 (code B ref 13490); Sat, 19 Jan 2013 15:42:01 +0000 Original-Received: (at 13490) by debbugs.gnu.org; 19 Jan 2013 15:41:03 +0000 Original-Received: from localhost ([127.0.0.1]:40448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TwaXU-0000cc-IG for submit@debbugs.gnu.org; Sat, 19 Jan 2013 10:41:02 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:19474) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TwaXM-0000cQ-DV for 13490@debbugs.gnu.org; Sat, 19 Jan 2013 10:40:54 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0JFdwQp023864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Jan 2013 15:39:58 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0JFdvds021863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2013 15:39:58 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0JFdvNu022189; Sat, 19 Jan 2013 09:39:57 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 19 Jan 2013 07:39:57 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83a9s5qx09.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac32MQWEnKn4RRlKQwG2WnqWfVSGwgAJVWhQ X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:70037 Archived-At: > > > > I'm using MS Windows. Dunno whether that means that no > > > > toolkit is used. Where do I find that information? > > > > How does an Emacs user even know what Emacs means by a > > > > "toolkit"? > > > > > > Why do you need to know? That's a serious question. > > > What practical importance for you is in these issues? > > > > Did I not make it clear that the doc refers to specific > > behaviors, features, etc. that affect users and that it says > > are available only in particular contexts, i.e., with or > > without particular toolkits. > > But do you have specific cases where this prevented you from > understanding the intended behavior? Can you at least give one or 2 > examples of such places in the documentation? Nearly every occurrence of it, IIRC. It is not at all clear whether the given behavior applies to the current user's context (platform etc.). And it is not at all clear how the user can find out whether it does. > > That doc, since it has brought up the qualification, needs > > to make clear what it means, what those contexts are, how to tell > > whether you are in one or not. > > Differences between the various toolkits is a vast subject, and gets > more and more so as time passes and new toolkits and new versions are > developed. It might take a large document to describe the differences > in any level of detail. In the Emacs manuals, I think we should only > describe the absolute minimum without which it would be unclear what > the manual says. That's why I ask about practical implications of > this. I agree: describe only what you need to describe, to enable users to understand what you are trying to tell them. It is the Emacs doc that throws "toolkit" in here, telling users IF you have a toolkit (or if you have X, Y, or Z toolkit) THEN the behavior is THIS, not THAT. The user cannot understand whether s?he has behavior THIS or THAT, without Emacs providing info about whether and which toolkit the user has. Or if it can, then it should, and should just remove any mention of the toolkit. It's one or the other - it's not fair to conditionalize things on something that is unknown, not understood, and for which we give no info about how to find the answer. Naive question: Couldn't Emacs provide a way (at runtime, dynamically) for the user to answer the question of whether and which toolkit s?he has? That would seem to be the best solution: 1. Ensure that the doc mentions toolkit only when it needs to (i.e., when that is useful) - the principle you espoused above. 2. Add a brief description blurb somewhere saying what a toolkit is, and preferably adding a link outside the manual to more information about that topic. IOW, do not go into details about toolkits, but give a brief explanation/definition, just as you would do for "frobglith" or "plunop". 3. Give users an easy way (e.g. a command or variable) to tell what toolkit they have (e.g., nil means no toolkit). > > > A toolkit is a collection of system APIs that allow to create and > > > display menus, tool bars, scroll bars, and some other frame > > > decorations. When Emacs "does not use a toolkit", it draws all of > > > these itself, using its own code and graphics. > > > > Thanks, but please don't just tell this bug thread. If that's what > > users need to understand about toolkits, please put it in the > > manual, so that the existing references there to "toolkits" are > > elucidated. > > Please tell how did that help you understand something in the manual > you couldn't figure out before, and you will have gained one more > person to agree with you on this. It is #2 above. It might not be the final text you choose for that, but it is at least a start in that direction. IOW, (1) IF we tell users that a given behavior depends on the toolkit THEN we point to the doc section where we present, (3) what a toolkit is, and (2) how to find out whether you have a toolkit and if so which toolkit you have. > You referred to the Emacs build process, so I responded with > toolkit-related information available for those who build Emacs. If > the build process is not relevant to your report, let's forget about > this argument of yours. I know next to nothing about toolkits. You referred to the build process as a way to know what toolkit you have. IF that is the only way to know that THEN we are leaving out letting non-builders know what toolkit they have. Clearly, all users should have a quick, easy way to determine whether they have a toolkit, and which. That is, unless there is no need to mention toolkits at all in the doc. Currently knowledge of this is necessary to know about the availability of multiple features and behaviors in Emacs. > > The target of the Elisp manual is not just users who build > > their own Emacs on Unix. > > In fact, describing the build process is not a goal of the ELisp > manual at all, it only mentions that in an appendix in the context of > describing the internal details of how certain things done during the > build work. We agree. > > And the features that the manual describes, telling users that > > their availability depends on whether they have this or that > > toolkit, are features for general Emacs _users_. They are not just > > features for Emacs installers/builders. > > When the manuals mention toolkits, they say something like "with some > toolkits, this will work so-and-so" or "depending on the toolkit, this > function might return this-and-that value". This basically means > "don't rely on that behavior or that value, because they might vary". > How would knowing what a "toolkit" is help clearing this intentionally > vague description? Sometimes that is what they say. In that case, there is not a problem, especially if you follow up with just what you said: THEREFORE, do not rely on... But in other cases we say that such and such a behavior is not available if you have a toolkit, or if you do not have one, or if your toolkit is X, Y, or Z, or not X, Y, or Z. We should distinguish clearly between the two cases. And for the former we should explicitly give the point, not just the background reason: the point is that you should not rely on this... And for the latter we should point users to the (new) manual section that tells them how to quickly, easily determine whether they have a toolkit, and which. > It was your argument to mention the build process. No. It is the _manual_ that sends users off scratching their heads about the build process. That's the point. The closest the manual comes to helping users understand anything at all about toolkits is to send them investingating how Emacs gets built. That's a big mistake, IMHO. This is what I really said, "to mention the build process": >>> How to know about any of that? Why on earth would we refer >>> Emacs _users_ to the Emacs build process to find out whether >>> and which toolkits might be used and therefore whether some >>> feature being presented is in fact supported? > > Not about the build process, no. About the features that > > are being described as depending on toolkit availability. > > But the manuals do not tell which toolkit will do what in these cases. > If they were, then the Windows behavior should have been described > there, as well as exactly what each toolkit and what the non-toolkit > version does in each of these circumstances. If this is what you are > asking for, then why not say that explicitly, instead of asking "what > is a toolkit", a question whose answer, which I just gave, evidently > didn't help you understand whatever you didn't before? See (1), (2), (3), above. And yes, we do tell users that certain behaviors are available or not available only with a toolkit etc. And yes, this is the main problem I've raised: they cannot know what behavior to expect without (apparently) knowing whether they have a toolkit (and in some cases what toolkit they have). > > Users should not be left scratching their > > heads wondering "What's this toolkit stuff, and how do I > > know whether it applies to me or not, and what do I do about it?" > > The manuals clearly say that it could or could not be applicable, > depending on how Emacs was built. Yes, and you interpret that in every occurrence as meaning that the reader should not care and should not rely on...? If that is indeed the message in each case then we should say that: you do not need to know this, and you should not rely on it. Another interpretation is possible: the manual is telling me this because I need to know whether I have a toolkit, so that I can determine whether behavior XYZ applies to me. That's a very different message. > > IOW, I'm not sure whether we need more doc or less doc wrt > > toolkits. I am sure that what mention there is of toolkits is not > > adequate. > > That cannot be judged, IMO, without hearing specific instances where > that information would help in understanding what the manuals say. I hope that someone with knowledge about whether toolkit knowledge is pertinent to this or that occurrence of "toolkit" in the manual will review all of the occurrences and then judge and fix accordingly.