Re: woman doesn't work if current buffer's directory doesn't exist
Eli Zaretskii [EMAIL PROTECTED] writes: At this late stage in the pretest, won't it be safer to bind default-directory only if the original value doesn't exist? I don't think so, because it's possible for the original value to exist and yet not be accessible to us. For example, if the original value exists but we don't have execute permission on it, then call-process still fails like this: Debugger entered--Lisp error: (file-error Setting current directory permission denied /tmp/444/) On the other hand, if we can't cd to (file-name-directory infile) then we won't be able to read infile anyway. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org From: Chris Moore [EMAIL PROTECTED] Date: Sat, 27 Jan 2007 10:53:24 +0100 Eli Zaretskii [EMAIL PROTECTED] writes: At this late stage in the pretest, won't it be safer to bind default-directory only if the original value doesn't exist? I don't think so, because it's possible for the original value to exist and yet not be accessible to us. Okay, then test for accessibility instead of a mere existence. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Richard Stallman [EMAIL PROTECTED] writes: We need to fix all the file handlers that use call-process, I agree. Fortunately there are not too many. I agree it would be easier if we could fix this in call-process. That was the first direction I looked in. However, someone pointed out why changing the home directory magically in call-process just isn't acceptable: because it would change the meaning of relative file name arguments. Fixing the callers is our only option. Therefore, I ask people to start actually doing this. Michael, could you fix Tramp and ange-ftp? For Tramp and ange-ftp, it is start-process who needs a proper setting of default-directory. I've fixed this for Tramp. ange-ftp was already clean with respect to this. Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Unused variable in mouse.el: make-cursor-line-fully-visible
mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? If so, perhaps add a comment indicating the reason. (_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: (when (and (functionp fun) (= start-hscroll (window-hscroll start-window)) (or end-point ... From: Drew Adams Sent: Saturday, January 27, 2007 9:01 AM mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
Also, there are multiple functions defined in mouse.el that have no doc strings. Some even have no comments that could substitute for doc strings. I think the mouse.el code could use a bit of cleaning up, generally. From: Drew Adams Sent: Saturday, January 27, 2007 9:15 AM Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? If so, perhaps add a comment indicating the reason. (_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: (when (and (functionp fun) (= start-hscroll (window-hscroll start-window)) (or end-point ... From: Drew Adams Sent: Saturday, January 27, 2007 9:01 AM mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unused variable in mouse.el: make-cursor-line-fully-visible
From: Drew Adams [EMAIL PROTECTED] Date: Sat, 27 Jan 2007 09:01:11 -0800 mouse.el has this binding in `mouse-drag-track': (make-cursor-line-fully-visible nil) That variable is not used anywhere in the Lisp source code. It is used in xdisp.c. For primitives written in C, having a Lisp binding for a variable that controls the behavior of the primitive is the way to go. I think the doc string of the variable goes a long way towards hinting that this variable _is_, in fact, used in the C code. So I'm curious why you thought it was unused. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unused variable in mouse.el: make-cursor-line-fully-visible
From: Drew Adams [EMAIL PROTECTED] Date: Sat, 27 Jan 2007 09:15:28 -0800 Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? Looks like a witty way of calling a function inside a let* binding. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: Thanks, I fixed the whitespace. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
It is used in xdisp.c. For primitives written in C, having a Lisp binding for a variable that controls the behavior of the primitive is the way to go. I think the doc string of the variable goes a long way towards hinting that this variable _is_, in fact, used in the C code. So I'm curious why you thought it was unused. My bad. No coffee yet. I grepped for the variable without first trying `C-h v'! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
Here's another unused binding, also in `mouse-drag-track'. It seems that this code is called only for its side effect. Is there a reason to bind the result? Looks like a witty way of calling a function inside a let* binding. I don't see why. I thought maybe point needed to be set at that point so that subsequent bindings would have the right value, but I don't see that being done - no subsequent binding examines (point), AFAICT. I suspect that at one time a subsequent binding tested point, and that value depended on point having been previously set by the `_' binding code. I don't see that this is the case now. Perhaps I'm missing something, however. Witty ways should generally be documented by comments. One person's clever! is another, later maintainer's huh?. Even naming the variable `ignored' instead of `_' improves readability (but still doesn't address the question raised). The bound variable is unused. Even if the function did in fact need to be called before subsequent bindings were made (which I don't see), the clean way to do that is with a nested `let'. If a single `let' is better for some reason for performance (or some other reason), then a comment is in order, explaining why such a witty binding is employed. Also, the code for `mouse-drag-track' is not indented correctly. Please use `M-q' on it. See, e.g., this code starting at line 1043: Thanks, I fixed the whitespace. Thx. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc for try-completion etc. conflicts with doc for completing-read
The doc for `completing-read-multiple' refers you to the doc of `completing-read' for explanation of arg TABLE. Click the `completing-read' link. The doc for `completing-read' refers you to the doc for `try-completion' etc. for explanation of arg TABLE. Click the `try-completion' link. The doc for `try-completion' does not mention TABLE; it mentions ALIST. In sum, we send users to the doc of `try-completion' etc. for info about TABLE, but they cannot find its explanation there. Please change the doc of `try-completion' etc. to use TABLE, not ALIST, for consistency. Thanks. I didn't want to rename the argument so close to the release, so I added a few more words to the doc string of completing-read, and mentioned the fact that TABLE is called ALIST in try-completion and all-completions. Thanks. `test-completion' is in the same boat, BTW. Please make a note somewhere (e.g. TODO) that the right fix, after the release, is to rename the parameter to TABLE, in each of `try-completion', `test-completion', and `all-completions'. Today, `completing-read-multiple' refers to `completing-read' for an explanation of TABLE, so you need only tweak the doc of `completing-read'. But tomorrow someone might refer `completing-read-multiple' directly to `try-completion' or `test-completion' or `all-completions'. If that happens, the problem will resurface. IOW, if the fix is made where we send people elsewhere for the explanation, then it needs to be made everywhere we might do that. If the fix (renaming) is made at the target, not the source, then there is no such problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for try-completion etc. conflicts with doc for completing-read
From: Drew Adams [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sat, 27 Jan 2007 10:16:04 -0800 I didn't want to rename the argument so close to the release, so I added a few more words to the doc string of completing-read, and mentioned the fact that TABLE is called ALIST in try-completion and all-completions. Thanks. `test-completion' is in the same boat, BTW. Not AFAICS: it calls that argument ALIST, not TABLE. IOW, if the fix is made where we send people elsewhere for the explanation, then it needs to be made everywhere we might do that. If the fix (renaming) is made at the target, not the source, then there is no such problem. I generally don't like sending people to read doc strings of other symbols at all, so if it were up to me, I'd just spill everything about TABLE and PREDICATE into each function that calls the low-level primitives. But the explanations are very long, so I will let Richard decide. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
emacs -Q Help Emacs Tutorial You see this, in red, at the top: NOTICE: The main purpose of the Emacs tutorial is to teach you the most important standard Emacs commands (key bindings). However, your Emacs has been customized by changing some of these basic editing commands, so it doesn't correspond to the tutorial. We have inserted colored notices where the altered commands have been introduced. [More] This is wrong - nothing has been customized in emacs -Q. The wording is also bad: standard Emacs commands are not the same thing as key bindings. So already we're teaching the vocabulary incorrectly. has been customized by changing some of these basic editing commands. Customizing a key binding doesn't change a command. The wording is not good. We have inserted colored notices sounds horrible too. Who's we? The user is just following a tutorial; it is only the tutorial that should be speaking to the user - there is no need of 1) the user, 2) the tutorial, and 3) some we who comments about modifications they made to the tutorial by inserting colored notices. If this doesn't appear to users to be an UGLY hack, then I don't know what would. If the idea is to adapt the tutorial so that it reflects the user's customized key bindings, then that is done poorly (or not at all). Similarly, if the idea is to mark all of the places in the tutorial that mention standard bindings that are not currently in effect because of customization. I really think this hack does more harm than good, at least the way it's done now. Just say that the tutorial reflects the standard Emacs bindings. That's all. We are trying to be too clever, and it hurts the user. Anyway... Clicking [More] then shows this: The following key bindings used in the tutorial had been changed from the Emacs default in the TUTORIAL (English) buffer: Key Standard BindingIs Now On Remark M-backspace backward-kill-word C-backspace more info backspace delete-backward-char DEL more info It is OK to change key bindings, but changed bindings do not correspond to what the tutorial says. This is also wrong: had been changed is incorrect grammatically here. Perhaps have was meant. What is the point of from the Emacs default in the TUTORIAL (English) buffer? Buffer? English? Why is TUTORIAL uppercase? I don't understand this sentence AT ALL. What are we trying to say here? And why are we telling the user that s?he can change bindings? (during the tutorial? in the future? in the past?) The help shown from clicking [More] is also not aligned well, as can be seen above. It is also unclear: What does Is Now On mean? What is now on what? Does it mean that the Standard Binding (command), which is the second column, is now on that key? The order seems backward (German? ;-)). The order should be: Command Current KeyStandard Key (emacs -Q) --- ------ backward-kill-word C-backspace M-backspace Or, better perhaps (depending on what the intention is - I'm lost): Key mentioned in tutorial Key in your Emacs Command - - --- M-backspace C-backspace backward-kill-word In any case, however this is done, it is bound to confuse. Another bug, unrelated to the tutorial: Clicking `delete-backward-char' does not show its binding (DEL). The doc string needs to mention this. Clicking either of the more info links leads to further incorrect information... Most importantly: Do we really need this? What is the point of scaring users with a huge red NOTICE, and inviting them to click for more information that details ALL of the bindings that are different from the default bindings. (Not to mention that it does so erroneously.) This is crazy. This is the FIRST thing that a newbie will see, when trying to learn about Emacs. It sends only one message: You will never understand Emacs. It is far too difficult for you to learn. You can't even figure out what we're trying to say about customized bindings. What a dummy you are - move along. Please, let's drop this or redo it completely. If we keep it, it needs to be 1) simple, 2) unalarming, 3) obviously of secondary importance. A tutorial should hold you by the hand in the beginning, not scare and confuse you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc for try-completion etc. conflicts with doc for completing-read
Thanks. `test-completion' is in the same boat, BTW. Not AFAICS: it calls that argument ALIST, not TABLE. That's what I meant. It is in the same category as `try-completion' and `all-completions' - they all call it ALIST, not TABLE. IOW, if the fix is made where we send people elsewhere for the explanation, then it needs to be made everywhere we might do that. If the fix (renaming) is made at the target, not the source, then there is no such problem. I generally don't like sending people to read doc strings of other symbols at all, so if it were up to me, I'd just spill everything about TABLE and PREDICATE into each function that calls the low-level primitives. But the explanations are very long, so I will let Richard decide. I know that you're trying to make a quick and unrisky fix for this release. That is fine. I was only mentioning the rest for the future. Thanks for the fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unused variable in mouse.el: make-cursor-line-fully-visible
(_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. It's probably my code, influenced by my SML hacking. In Prolog, Haskell, SML, (and probably all other ML dialects and many logic programming languages) _ is a special variable used as here, to ignore arguments or return values. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Unused variable in mouse.el: make-cursor-line-fully-visible
(_ (mouse-set-point start-event)) ; variable `_' is unused, AFAICT. It's probably my code, influenced by my SML hacking. In Prolog, Haskell, SML, (and probably all other ML dialects and many logic programming languages) _ is a special variable used as here, to ignore arguments or return values. Yes, I'm used to it in Prolog and Haskell. I don't see why any variable should be bound here, however, anonymous or not. It is no doubt compiled away, but I think the code is a bit less clear. It's not a big deal, though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
Drew Adams wrote: emacs -Q Help Emacs Tutorial You see this, in red, at the top: NOTICE: The main purpose of the Emacs tutorial is to teach you the most important standard Emacs commands (key bindings). However, your Emacs has been customized by changing some of these basic editing commands, so it doesn't correspond to the tutorial. We have inserted colored notices where the altered commands have been introduced. [More] This is wrong - nothing has been customized in emacs -Q. It is a bug. I have noticed it and have a fix for it, but I have not had time to send it to the list yet. The wording is also bad: standard Emacs commands are not the same thing as key bindings. So already we're teaching the vocabulary incorrectly. Could you please propose a better text? Anyway... Clicking [More] then shows this: The following key bindings used in the tutorial had been changed from the Emacs default in the TUTORIAL (English) buffer: Key Standard BindingIs Now On Remark M-backspace backward-kill-word C-backspace more info backspace delete-backward-char DEL more info It is OK to change key bindings, but changed bindings do not correspond to what the tutorial says. This is also wrong: had been changed is incorrect grammatically here. Perhaps have was meant. I am not quite sure had is incorrect here. The state of the TUTORIAL buffer may have changed since the link was created. Is not had the correct word then? Or how would you say it? What is the point of from the Emacs default in the TUTORIAL (English) buffer? Buffer? English? Why is TUTORIAL uppercase? I don't understand this sentence AT ALL. Would it be more understandable like this from the Emacs default in the buffer TUTORIAL (English): TUTORIAL (English) is simply the name of the tutorial buffer. Or maybe it is better just to say from the Emacs default: Even if this is more inexact it is actually not incorrect. What are we trying to say here? And why are we telling the user that s?he can change bindings? (during the tutorial? in the future? in the past?) These text should only be showed if some of the key bindings used in the tutorial have been changed. In other words they are only showed when the tutorial does not work. We discussed what to do in this case earlier. We decided then that the best way to handle it was to tell the user about the problem. Other alternatives was to refuse to run the tutorial or to change the key bindings in the tutorial buffer so that they matched the tutorial. The help shown from clicking [More] is also not aligned well, as can be seen above. Some more work can be done on this. It fails with very long names if I remember correctly now. But I felt this was good enough. It is also unclear: What does Is Now On mean? What is now on what? Does it mean that the Standard Binding (command), which is the second column, is now on that key? The order seems backward (German? ;-)). The order should be: Command Current KeyStandard Key (emacs -Q) --- ------ backward-kill-word C-backspace M-backspace Or, better perhaps (depending on what the intention is - I'm lost): Key mentioned in tutorial Key in your Emacs Command - - --- M-backspace C-backspace backward-kill-word In any case, however this is done, it is bound to confuse. I am not sure what is best. Of your proposals I like the first one best. What do others think? Another bug, unrelated to the tutorial: Clicking `delete-backward-char' does not show its binding (DEL). The doc string needs to mention this. This is disturbing but maybe a bit hard to fix right now. I would rather put that in TO-DO for after the release. Clicking either of the more info links leads to further incorrect information... Please tell what the incorrect information is. Most importantly: Do we really need this? What is the point of scaring users with a huge red NOTICE, and inviting them to click for more information that details ALL of the bindings that are different from the default bindings. (Not to mention that it does so erroneously.) This was my idea so I guess I have to say something about it. Yes, I believe we need it. The idea is simply to tell the user let the user run the tutorial even though some things have changed, but inform the user what has changed. I think without this the user may get very confused when the tutorial does not work. Whether this is the best way to handle the problem with changed key bindings that affects the tutorial is another question (see above). This is crazy. This is the FIRST thing that a newbie will see, when trying to learn about Emacs. If no key bindings have been changed the user will not see this. (When the bug has been fixed.) Please, let's drop this or redo it
RE: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
Could you please propose a better text? As I said, I prefer that we not use this. I think it has a negative effect. I am not quite sure had is incorrect here. The state of the TUTORIAL buffer may have changed since the link was created. Is not had the correct word then? Or how would you say it? I wouldn't say it. I would just say something generic, without trying to determine whether the user had actually customized Emacs. Something short and simple, such as this: Keys mentioned in this tutorial are those defined by default. If Emacs has been customized, then some keys might differ from those mentioned here. If you want to use the tutorial with the standard Emacs keys, then start Emacs again using `emacs -Q'. IOW, YMMV. This need not be in red, and it need not be the very first thing the user reads. It should not be. Put it after the first place where the tutorial asks you to use a key, as a footnote. YMMV belongs in the fine print (more or less). These text should only be showed if some of the key bindings used in the tutorial have been changed. In other words they are only showed when the tutorial does not work. I don't agree that that is worthwhile. Just let users know that the tutorial is written for standard (i.e. default) Emacs bindings. That's all. The tutorial should not (IMO) be mostly about teaching keys, anyway. If it is, then that's a mistake. Keys are only a means to Emacs functionalities; we shouldn't concentrate too much on them. Users can learn Emacs using emacs -Q, and they can then learn different bindings afterward, if need be, for their customized version. We discussed what to do in this case earlier. We decided then that the best way to handle it was to tell the user about the problem. Other alternatives was to refuse to run the tutorial or to change the key bindings in the tutorial buffer so that they matched the tutorial. I think the cure is worse than the disease. There is no reason to refuse to run the tutorial or to try to adapt it. Just let users know that it assumes standard (default) bindings. Keep it simple. Users should get the same behavior each time they use the tutorial, whether with customized or vanilla Emacs - any other behavior is confusing. Referential transparency and all... Some more work can be done on this. It fails with very long names if I remember correctly now. But I felt this was good enough. It's not needed. I don't think users who have customized versions of Emacs really need to be told just which bindings have changed. It's true that some of the tutorial won't work or even make sense to them without knowing which keys to use, but it should be clear that they can always use the tutorial with emacs -Q. We don't need to make the tutorial work for customized bindings. I am not sure what is best. Of your proposals I like the first one best. What do others think? None of them are needed. I shouldn't even have mentioned them. My point was that what is there now is harmful, because confusing (and scary). Another bug, unrelated to the tutorial: Clicking `delete-backward-char' does not show its binding (DEL). The doc string needs to mention this. This is disturbing but maybe a bit hard to fix right now. I would rather put that in TO-DO for after the release. `delete-backward-char' is a built-in function. It should be possible to fix this detail. (Again, it has nothing to do with the tutorial.) Most importantly: Do we really need this? Yes, I believe we need it. The idea is simply to tell the user let the user run the tutorial even though some things have changed, but inform the user what has changed. I think without this the user may get very confused when the tutorial does not work. The confusion is 100x now. I see no need for the user to run the tutorial using customized bindings. If you could automatically adapt the entire tutorial to reflect the user's bindings perfectly, then I guess it could be OK (but see above, about same, repeated behavior). However, that is too difficult, and any half measure is worse than none at all. Whether this is the best way to handle the problem with changed key bindings that affects the tutorial is another question (see above). That's the question. My answer is No. This is crazy. This is the FIRST thing that a newbie will see, when trying to learn about Emacs. If no key bindings have been changed the user will not see this. (When the bug has been fixed.) That bug really needs to be fixed, at a minimum. Right now, we're scaring 100% of the people who try the tutorial 100% of the time. Messing their minds, to no good end. Please, let's drop this or redo it completely. If we keep it, it needs to be 1) simple, 2) unalarming, 3) obviously of secondary importance. A tutorial should hold you by the hand in the beginning, not scare and confuse you. IMO this is the wrong level to discuss it on. We should rather discuss the GUI instead and how that can be
can I customize source-directory please?
In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-21 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' I've recently been using Lennart's Windows build of Emacs. When I want to look at the C source definition of a function, it prompts me for Emacs C source dir. This is the same every time, and I'm getting tired of typing the path. I would like to customize this variable, but it doesn't have a you may customize this variable link in the help, and also the description of the variable says: Directory in which Emacs sources were found when Emacs was built. which makes me think that maybe I shouldn't change it. So: 1) is it safe to change the value? It's currently set to c:/eclean/bld/emacs/, which doesn't exist on this machine, and 2) if so, could the variable be made customizable, and have the doc string changed to make changing it less intimidating? Thanks. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
keybindings change for recursive minibuffers
In GNU Emacs 22.0.93.9 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-27 on trpaslik configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' $ emacs -Q M-x set SPC variable RET enable-recursive-minibuffers RET t RET C-x C-f M-x set SPC variable RET== [No match] ie. notice that initially typing M-x set SPC variable will correctly insert a hyphen between set and variable, and that trying the same in a recursive minibuffer (inside a find-file prompt) doesn't work. In a top-level minibuffer: SPC runs the command minibuffer-complete-word In a recursive minibuffer (while find-file's prompt is pending): SPC runs the command self-insert-command Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Drew Adams wrote: Clicking either of the more info links leads to further incorrect information... Please tell what the incorrect information is. I'm guessing it's this: The default Emacs binding for the key M-backspace is the command `backward-kill-word'. However, your customizations have rebound it to the command `nil'. the command `nil'? `nil' isn't a command! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for try-completion etc. conflicts with doc for completing-read
From: Drew Adams [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sat, 27 Jan 2007 12:25:49 -0800 Thanks. `test-completion' is in the same boat, BTW. Not AFAICS: it calls that argument ALIST, not TABLE. That's what I meant. It is in the same category as `try-completion' and `all-completions' - they all call it ALIST, not TABLE. But `test-completion' is only a problem if some other function which uses TABLE refers to it in the doc string. Are there any functions like that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for try-completion etc. conflicts with doc for completing-read
Please stop working on this. I have already taken care of this, but I have not installed it yet. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.
emacs -Q Help Emacs Tutorial You see this, in red, at the top: NOTICE: The main purpose of the Emacs tutorial is to teach you the most important standard Emacs commands (key bindings). However, your Emacs has been customized by changing some of I fixed that. I will try to install the change soon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
