Re: Value menu value should be listed on a separate line
Usually with :entry-format and :format. No special formatting should be necessary, just to be able to use a simple tag. I don't believe that was why :*format were introduced. You would have to specify what a simple tag is in the first place. Formatting tags is for handling non-standard cases like, for example, options whose values may be variable-length strings. Such options are not necessarily preceded by a [Value Menu]. Writers of defcustom's shouldn't need to concern themselves with the layout of the Customize buffer, anyway. They should be able to define a :tag string without the preoccupation of its starting position and the number of characters already taken up by the option name and the button widths. I'm convinced that writers of defcustoms should care about the layout. OK, you're convinced. I said that they should not *need* to concern themselves with the layout of stuff, beyond their own creations. This is a flaw in the basic layout, which should not be shoved off onto the definers of individual values, to work around. It should be trivial to fix, no less - why not fix the general case, instead of making writers of each value work around it over and over? Your general case is based on the presence of the term [Value Menu]. Often that term is followed by a fixed-length string or an integer as in the following excerpt from the comment group: ... comment-empty-lines: Hide Value Value Menu Never State: STANDARD. If nil, `comment-region' does not comment out empty lines. More comment-fill-column: Hide Value Value Menu nil State: STANDARD. Column to use for `comment-indent'. If nil, use `fill-column' instead. comment-padding: Hide Value Value Menu Integer: 1 State: SAVED and set. Padding string that `comment-region' puts between comment chars and text. More comment-style: Hide Value Value Menu plain ... Moving the text after [Value Menu] to a new line would render this customization buffer completely unreadable. Hence, I'm against a trivial fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrap failed on Windows XP
From: Zhang Wei [EMAIL PROTECTED] Date: Sat, 23 Dec 2006 15:17:43 +0800 D:\download\emacs-gbk\ntmake bootstrap mkdir oo-spd mkdir oo-spd/i386 echo oo-spd/i386 stamp_BLD ', needed by `addsection'. Stop.`oo-spd/i386/addsection.exe D:\download\emacs-gbk\nt Thanks for reporting. I cannot reproduce this on my machine. Is this the CVS code (and if so, when did you checkout), or the 22.0.92 pretest? Also, what versions of Make and shell (if any) did you use in this build? Finally, please try the command make -d bootstrap 21 | tee build.log and post here the full contents of the file build.log. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrap failed on Windows XP
Eli Zaretskii [EMAIL PROTECTED] writes: I cannot reproduce this on my machine. Is this the CVS code (and if so, when did you checkout), or the 22.0.92 pretest? The CVS code, updated. Also, what versions of Make and shell (if any) did you use in this build? D:\download\emacs-gbk\ntmake -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. shell is cmd. Finally, please try the command make -d bootstrap 21 | tee build.log and post here the full contents of the file build.log. GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Reading makefiles... Reading makefile `makefile'... Creating temporary batch file C:\DOCUME~1\zhangwei\LOCALS~1\Temp\make34042.bat CreateProcess(C:\DOCUME~1\zhangwei\LOCALS~1\Temp\make34042.bat,C:\DOCUME~1\zhangwei\LOCALS~1\Temp\make34042.bat,...) Cleaning up temporary batch file C:\DOCUME~1\zhangwei\LOCALS~1\Temp\make34042.bat Updating makefiles Considering target file `makefile'. Looking for an implicit rule for `makefile'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.o'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.c'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.cc'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.cpp'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.p'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.f'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.r'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.s'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.mod'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.sh'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile,v'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `RCS/makefile,v'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `RCS/makefile'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `s.makefile'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `SCCS/s.makefile'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.o'. Looking for a rule with intermediate file `makefile.o'. Avoiding implicit rule recursion. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.c'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.cc'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.cpp'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.p'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.f'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.r'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.s'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.mod'. Trying pattern rule with stem `makefile.o'. Trying implicit prerequisite `makefile.o,v'. Trying pattern rule with stem `makefile.o'. Trying implicit prerequisite `RCS/makefile.o,v'. Trying pattern rule with stem `makefile.o'. Trying implicit prerequisite `RCS/makefile.o'. Trying pattern rule with stem `makefile.o'. Trying implicit prerequisite `s.makefile.o'. Trying pattern rule with stem `makefile.o'. Trying implicit prerequisite `SCCS/s.makefile.o'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.c'. Looking for a rule with intermediate file `makefile.c'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.y'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.l'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.w'. Trying pattern rule with stem `makefile'. Trying implicit prerequisite `makefile.w'. Trying pattern rule with stem `makefile.c'. Trying implicit prerequisite `makefile.c,v'. Trying pattern rule with stem `makefile.c'. Trying implicit prerequisite `RCS/makefile.c,v'. Trying pattern rule with stem `makefile.c'. Trying implicit prerequisite `RCS/makefile.c'. Trying pattern rule with stem
Re: bootstrap failed on Windows XP
From: Zhang Wei [EMAIL PROTECTED] Date: Sat, 23 Dec 2006 18:24:30 +0800 D:\download\emacs-gbk\ntmake -v GNU Make 3.80 I don't recommend this version for building the Windows port. Can you upgrade to Make 3.81? Note that nt/INSTALL says in its compatibility table: sh exists no sh mingw32 compiled make 3.80: okay unknown[6] Also, where did you get the binary of this version of Make? If you compiled it yourself, then with what compiler, and what W32-specific options in config.h.W32 (near its end) did you turn on before compiling Make? shell is cmd. I don't think Make 3.80 can use CMD reliably (v3.81 does support that). What does Make say, if you type the following command in the nt/ subdirectory: make which-sh Considering target file `oo-spd/i386/addsection.exe '. File `oo-spd/i386/addsection.exe ' does not exist. Here's your problem, right there: there's a newline embedded in the target's name, after the .exe suffix. Make is trying to build addsection.exeNL, which of course cannot succeed. How did this happen? Did you checkout the CVS tree with the -kb option to cvs up or cvs co? If not, some of your files in the nt/ subdirectory might have strange line endings. Can you please take a closer look at nt/makefile.w32-in and the file nt/makefile produced from it, and see what kind of characters are found there at the end of each line, and in particular at the end of this line: addsection: stamp_BLD $(BLD)/addsection.exe TIA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Lennart Borgman wrote: With MSYS I get some very strange problems: MSYS /c dir Pr* MSYS /c dir Pr] The above seems to be trouble because I tested different keyboards in XP. I forgot to turn the keyboard switching characters off in XP. If I try to enter * (see above) I get a ]. Quite strange. It only happens inside Emacs. MSYS /c dir PrTAB In minibuffer: Partially completed MSYS /c dir (the listing does not contain Program Files, but it should as far as I can see) MSYS /c pwd /c I have seen this trouble for the shell command both using MSYS and Cygwin as inferior shells. Seems to be a problem with sync of Emacs view of the directory and the shells dito. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
fortran-fill-paragraph fails
Start a fresh emacs --no-init-file. Load file foo.f (fortran-mode): cat foo.f EOF C This is a fortran comment CALL FOO EOF On line 1 execute fill-paragraph, which will run fortran-fill-paragraph. This gives me C This is a fortran comment ALL FOO In GNU Emacs 22.0.90.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-11-10 on tfkp07 configured using `configure '--prefix=/nfs/tfkp07/winkler/emacs/NEW' '--with-gcc' '--with-pop' '--with-x' '--with-x-toolkit=athena'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: isearch-forward-regexp and isearch-backward-regexp return differing search results
Forward and backward regexp search are not symmetrical. This is explained in the Lisp Manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Broken C-b remapped to ... advice in tutorial.
2. Displaying one line of warning message for each rebound key sequence is really annoying. We should just highlight them in a different face and display the message in a tooltip, and/or when the text is clicked on. After all, there is already a big warning message at the top of the tutorial page saying keys have been rebound; no need to hammer it in. Indeed. It should only give each warning once ... and just have a tool-tip on other occurrences. I implemented this, too. I don't think that is a good idea. But what do you mean by just a tool-tip? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
On that note I was wondering if there was any option to have emacs make more backup files. It seems it only does so when I first save the file after visiting it. But I normally only start a new Emacs when it crashes or I have to reboot my machine which isn't very often. So I end up without many backup files. There are manual ways to make backup files, but there is no automatic feature to do this. We could implement such a feature, given a good idea for a criterion for when to make another backup file. Not till after the release, though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
On the other hand I would perhaps prefer it in a node on its own right after Intro, something like Emacs and the platform GUI. This could list all the subtle differences. If we were to have a node about this, it certainly should not come so early. It is a terrible annoyance for a beginner to read caveats about features he doesn't even know about yet, on the way to starting to learn something actually interesting. However, I would be glad to see a list of the specific points you think would be useful to mention in such a node. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-\ does not work with prefix argument as documented
I put in those documentation fixes. Thanks for reminding me. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
A problem that causes loss of work is a serious problem. How to address this one will take some thought, because each of these changes has a good reason individually. I just got bit by this and I bet others will too. In previous versions of Emacs C-x C-v (find-alternate-file) used to prompt you if you hadn't saved the work in the current buffer and you used to have to press 'y' to discard it. *Now* it prompts you asking if you want to *save* your work. So if you use it to revert the buffer to the last saved version -- something I do quite frequently and have become accustomed to hitting 'y' quite quickly -- the default action is to *overwrite* your work! Does it really happen that way? I just tried that case, and it used yes-or-no-p to ask for confirmation for overwriting. So if you type `y RET', it should ask you again whether to save. Did you respond semiconsciously by typing `y e s RET', thinking Dammit I said yes? This is exacerbated by the documented regression in find-file to no longer allow the shortcut of simply hitting return to reread the current file. The reason for this change is to eliminate an anomaly. The new meaning (visit the directory) is useful, and the fact that it failed to work was the anomaly. It is just one extra character to get the old results: M-n. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
- They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. How can `C-h v' help you to find something you're not aware of? That's not the point. The point is that these should be well documented, and autoloaded so you can get to the documentation. Many Emacs users don't care about customization. So? Bug reports about customization don't concern such users, so ignore them in the present context. If you don't care about customization either, then perhaps someone else should respond to this bug report. I do care about customization, and that's why I reported the bug. I would appreciate a lot if you tried to improve its documentation. I try to improve it by pointing out problems with it. FYI, GNU will not accept my patches, doc or code, because my employer will not sign papers. My contribution is bug reports and general suggestions - if they help, fine; if not, ignore. In this case, one needed improvement is to autoload (or equivalent) the defcustoms. However, C-h v can easily help you find something you are not aware of, by showing you what's available with completion. I do it every day. C-h v with completion is hardly an option for beginners and hardly useful when there are many completions. I disagree. Completion is a real aid for beginners, as well as for non-beginners. Apropos is another aid in this context. It is also rendered impotent if the variables have not been loaded or autoloaded. - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? They would browse customization groups, try options, and use them. OK, that's one way to find them. C-h v or apropos is another. That the former way is available as an alternative is no solution for the problem that the latter way is broken. - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? The nil order is the one chosen by the designer of the option. Emacs maintainers are now responsible. I don't know what the designer's rationale was, and I don't see a good rationale. I was asking if there is one. The designers of an option are the persons who invented the option, assigned a name to it, and wrote the customization definition. Their rationale should be to write options such that an option `bar' depending on an option `foo' appears in the customization buffer after `foo' unless the user deliberately changed that order. I see. I guess you're saying that that is the default order that I was calling random. I don't know if the guideline you just mentioned is documented for designers, but the resulting order is, IMO, not obvious or understandable to users - it might as well be random. In any case, the designer is out of the loop now, for this bug fix, unless a maintainer wants to contact the designer for some reason. I don't understand why we would even have such options - who would ever want a random order? Why do you think it's random? I said apparently. I have no idea what determines the order. It is not an obvious, understandable, or obviously useful order. I don't care if it's actually random. I asked if there was a good reason for it, and you essentially told me to go ask the designer. Indeed. You should tell the designers of the options for a specific group whenever you think they wrote them in an inappropriate way. This is a standard GNU-Emacs library. I don't know (or care) who the designers of these options is. I reported a bug; that's all. If a bug fixer wants to contact the designer to understand the original rationale, feel free. I'm just reporting a bug. As always, it's your prerogative to decide not to fix the bug or to decide that there is in fact no bug. I would think that bug reports would be welcomed, as an aid, instead of resisted, as if they were imposing unnecessary chores. This push-back is not helpful, IMO. I personally won't be discouraged, by your attitude, from reporting other bugs, but I expect that some others might be. Please don't adopt this attitude as a general response to bug reports, or we will lose lots of good input from users. A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag None nil) function)) I personally don't see why anyone would want an order other
RE: Value menu value should be listed on a separate line
Usually with :entry-format and :format. No special formatting should be necessary, just to be able to use a simple tag. I don't believe that was why :*format were introduced. You would have to specify what a simple tag is in the first place. I would? My bug report was clear enough, I think, for someone who really wants to understand. I did give a concrete example, however: a literal string of less than 80 characters. Formatting tags is for handling non-standard cases like, for example, options whose values may be variable-length strings. Such options are not necessarily preceded by a [Value Menu]. Then why do you bring them up? The bug report is about option values that are preceded by [Value Menu], and it doesn't mention formatting tags - you brought that up. The examples I gave were not variable-length strings. Why introduce a distraction unrelated to the reported problem? No formatting should be necessary for the simple cases reported. Writers of defcustom's shouldn't need to concern themselves with the layout of the Customize buffer, anyway. They should be able to define a :tag string without the preoccupation of its starting position and the number of characters already taken up by the option name and the button widths. I'm convinced that writers of defcustoms should care about the layout. OK, you're convinced. I said that they should not *need* to concern themselves with the layout of stuff, beyond their own creations. This is a flaw in the basic layout, which should not be shoved off onto the definers of individual values, to work around. It should be trivial to fix, no less - why not fix the general case, instead of making writers of each value work around it over and over? Your general case is based on the presence of the term [Value Menu]. Often that term is followed by a fixed-length string That's exactly the case I reported: [Value Menu] followed by a (fixed-length) :tag string. or an integer as in the following excerpt from the comment group: [snip] Moving the text after [Value Menu] to a new line would render this customization buffer completely unreadable. I disagree. There is no reason that the value should follow [Value Menu] on the same line. What compelling reason is there? How does that enhance readability? If, however, you are convinced that they must remain together, then consider starting [Value Menu] and the value together on a new line. That is, if you don't like this: ...xxx [Value Menu] the-value then consider this: ...xxx [Value Menu] the-value I see no reason why [Value Menu] needs to be next to the value, nor why either needs to be at the end of a possibly long line of stuff (option name, buttons). It makes sense to always start the value in column 1, especially since 1) values can be of any length and 2) a very common case is the use of a :tag, which provides a string value, in a `choice'. That is the case I reported. Hence, I'm against a trivial fix. I think you are against any fix at all. The ball is in your hands; if you don't want to fix it, then you won't fix it. I've done my reporting job; it's your turn. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
So? Bug reports about customization don't concern such users, so ignore them in the present context. If you don't care about customization either, then perhaps someone else should respond to this bug report. I do care about customization, and that's why I reported the bug. Sorry. I herewith apologize for answering to your bug report. Please disregard my comments on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Broken C-b remapped to ... advice in tutorial.
Richard Stallman [EMAIL PROTECTED] writes: 2. Displaying one line of warning message for each rebound key sequence is really annoying. We should just highlight them in a different face and display the message in a tooltip, and/or when the text is clicked on. After all, there is already a big warning message at the top of the tutorial page saying keys have been rebound; no need to hammer it in. Indeed. It should only give each warning once ... and just have a tool-tip on other occurrences. I implemented this, too. I don't think that is a good idea. But what do you mean by just a tool-tip? Suppose I rebind C-v. Instead of displaying a line ** C-v has been rebound, but you can use next instead [More] ** at every instance of C-v in the tutorial, now that line appears the first time C-v appears in the tutorial; both C-v and the line are highlighted in tutorial-warning-face. For subsequent instances of C-v, the C-v is highlighted in tutorial-warning-face, but the line is omitted (this is to prevent many, many instances of, the line appearing, which makes it difficult to read the tutorial text). When you put the mouse over C-v, the message is displaying in a tooltip. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Kevin Gallagher wrote: I just got finished reading through this thread and, I must say, I'm a bit puzzled by its continued limited focus to the question of To backward slash or not to backward slash? in an Emacs shell window running cmd.exe (or equivalent) on w32. Instead, this discussion would benefit greatly by taking several steps backward and looking at the overall command line behavior in cmd.exe, with the goal of devising an overall strategy for Emacs. There is a need to determine to what extent should Emacs support cmd.exe syntax and behavior in its support for running cmd.exe in a shell window. So, let's take a look at some of the cmd.exe input syntax. Some it is is rather strange, by the way, and some of it is quite unexpected. For example, sometimes delimiters are needed between a command and the first parameter, but other times they are not needed. For example, cd .., with a space delimiter, and cd.., without a space delimiter are both accepted by the parser as valid. Press return and both are move the current directory up one level. However, enter cd. followed by a TAB and the bell rings, even though cd.. is valid. Suppose the current directory contains 5 directory entries called aa, bb, cc, dd one, and eleven ee. Enter cd at prompt and then press TAB, the bell rings. Enter cd, followed by a space, and then press TAB, the first directory, in the current directory, is displayed next to cd like this: cd aa Press TAB again and the line is re-written as cd bb TAB again and we have cd cc again, cd dd one again, cd eleven ee and again, cd aa cycling back through the list. It makes no attempt to continue command completion into a subdirectory. To make this happen, the user must enter a backward slash after the directory name and then press TAB. Yes, you are right. This behaviour is not mirrored at all in Emacs shell. Now, here's a surprise! Suppose aa has a subdirectory xy and xy ... I do not think cases outside of what cd is specified to do in cmd.exe are important. Nevertheless, if, instead, I wrap the parameter input to dir in double quotes like this E:\kg\aadir xy/zz then cmd.exe accepts this and generates a directory listing of E:\kg\aa\xy\zz! This is not specified to work. I found some surprises there too before. This leads me to suggest that, instead of To backward slash or not to backward slash?, perhaps the question should be To double quote or not to double quote? Of course, we have to remember that this applies to dir but not cd, though cd will accept the double quotes. I haven't tested this syntax with other commands, such as copy, xcopy, etc. But, hopefully, you get the point: cmd.exe has a very strange input syntax parser with unexpected and inconsistent behavior in what it is willing to accept as valid input syntax. The behavior of cmd.exe, when TAB is pressed, is quite different from what Emacs attempts to do for the user. Technically, one could argue that, for cmd.exe, Emacs should append nothing to a directory completed by TAB. It would make a very bad impression I think. I think I've made the case that the support Emacs should provide when running cmd.exe in a shell window is complicated and very messy; too messy to deal with now. I vote we let it be until after Emacs 22 is released. Then we will just leave that bug there for a long period. I think that a combination of long periods between releases and leaving bugs is not so very good. And unfortunately it is a bug on w32, that in one sense is a platform where we want to attract people because it makes it easier to switch to GNU/Linux later. BTW, I found the directory sync in shell is not working so good for me. Is there something that prevents that comint sends a pwd and reads the result before trying to TAB file name expansion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
...And unfortunately it is a bug on w32, that in one sense is a platform where we want to attract people because it makes it easier to switch to GNU/Linux later. Is that really the aim of Emacs on Windows? Presumably it could also make GNU/Linux users feel more comfortable on Windows and they could switch the other way. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Nick Roberts wrote: ...And unfortunately it is a bug on w32, that in one sense is a platform where we want to attract people because it makes it easier to switch to GNU/Linux later. Is that really the aim of Emacs on Windows? Presumably it could also make GNU/Linux users feel more comfortable on Windows and they could switch the other way. I do not know if that is the aim, but at least I consider it one of the goals. If we would assume that feeling comfortable on the other system was equal then it woudl be much more people switching from Windows to GNU/Linux just because there are more people using Windows. Now if Emacs does not work well on Windows people on Windows will never be comfortable with Emacs. Unless they switch to GNU/Linux without beeing comfortable with Emacs of course, but then Emacs have not helped them feeling at home on GNU/Linux. (And they may instead look for Windows tools on GNU/Linux.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
In that case, is there anything more to change? Perhaps an xref from the Windows appendix to Symbol Completion? Please do that if you want to. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
- None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. We do not aim to mention all options in the manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? If you want to change things about a certain feature (such as the custom buffer interface), you look at its custom group and see what's available. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? If you want to change things about a certain feature (such as the custom buffer interface), you look at its custom group and see what's available. And how do you know what custom group to look in? These are options that are not autoloaded (so unavailable to C-h v and apropos) and are not mentioned in any manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
- None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. We do not aim to mention all options in the manual. Of course not, and these probably need not be in a manual. My point was that if they are not autoloaded and they are not mentioned in a manual, it's difficult to know they exist. Autoloading was my suggestion. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
Richard Stallman [EMAIL PROTECTED] writes: That man page is written in doc rather than in an. Can we make woman detect use of the doc macros and give a meaningful error message? I checked in the test suggested by James Cloos. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
From: Richard Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Sat, 23 Dec 2006 15:14:50 -0500 On the other hand I would perhaps prefer it in a node on its own right after Intro, something like Emacs and the platform GUI. This could list all the subtle differences. If we were to have a node about this, it certainly should not come so early. It is a terrible annoyance for a beginner to read caveats about features he doesn't even know about yet, on the way to starting to learn something actually interesting. However, I would be glad to see a list of the specific points you think would be useful to mention in such a node. Jan, could you perhaps post a list of keys that are frequently in conflict with various window managers? M-TAB is only one of them, IIRC; there are others. That list could be a beginning of a node Richard talks about, perhaps in some appendix to the manual. TIA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrap failed on Windows XP
Eli Zaretskii [EMAIL PROTECTED] writes: How did this happen? Did you checkout the CVS tree with the -kb option to cvs up or cvs co? If not, some of your files in the nt/ subdirectory might have strange line endings. Can you please take a closer look at nt/makefile.w32-in and the file nt/makefile produced from it, and see what kind of characters are found there at the end of each line, and in particular at the end of this line: addsection: stamp_BLD $(BLD)/addsection.exe The cvs code could bootstrap without any problem with my system configuration untill the day before yesterday, so I don't think there's any problem with the version of make or developing environment. I removed all the makefile.w32-in files and run cvs up -kb to obtain them again, this time bootstrap failed at here: --8---cut here---start-8--- [...] Generating cus-load.el... Saving file d:/download/emacs-gbk/lisp/cus-load.el... Loading vc-cvs... Wrote d:/download/emacs-gbk/lisp/cus-load.el Generating cus-load.el...done rm ./../bin/emacs.exe make[1]: Leaving directory `D:/download/emacs-gbk/lisp' make -C ../lib-src DOC make[1]: Entering directory `D:/download/emacs-gbk/lib-src' mkdir oo-spd mkdir oo-spd/i386 echo oo-spd/i386 stamp_BLD echo config.nt has changed. Re-run configure.bat. config.nt has changed. Re-run configure.bat. exit -1 make[1]: *** [../src/config.h] Error -1 make[1]: Leaving directory `D:/download/emacs-gbk/lib-src' make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
I just got bit by this and I bet others will too. In previous versions
of Emacs C-x C-v (find-alternate-file) used to prompt you if you hadn't
saved the work in the current buffer and you used to have to press 'y'
to discard it. *Now* it prompts you asking if you want to *save* your
work. So if you use it to revert the buffer to the last saved version --
something I do quite frequently and have become accustomed to hitting
'y' quite quickly -- the default action is to *overwrite* your work!
Does it really happen that way? I just tried that case, and it used
yes-or-no-p to ask for confirmation for overwriting. So if you type
`y RET', it should ask you again whether to save.
Did you respond semiconsciously by typing `y e s RET', thinking
Dammit I said yes?
y alone doesn't seem to work and it does seem to need `y e s RET'. This is
a bit silly anyway if we have to make find-alternate-file foolproof when
^
the user wants to revert the buffer to an older version of the same file just
because it used to work a certain way.
I can see that you can lose data if your backup is older than your last saved
state because you lose all the undo information but, hey, if I hit myself
over the head with a hammer it hurts. Perhaps Emacs should carry a health
warning, just as everything else does these days.
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
