Re: suspend/fg excitement in *shell*
Also exiting an emacs that contains such shells still alive (merely sitting at their prompts), sends the signal to them to get wacko. That sounds like a shell bug to me. Does it happen with Emacs 21.4 too? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacsen 22.1.50 and 23.0.0 can't stop compilation
The fix will be installed soon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Well, at least I now can see it too. Focus is definitly shifted away, but where and why? I'll have to come back to this. Could you please put a note in FOR-RELEASE so we will know this is still pending? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: HowTo: Avoid packages like TPU
2) Worse, tpu-extras is evil -- it redefines things like newline That is ugly, the same way advice is ugly, but the change to the behavior of `newline' is harmless enough. 3) And even worse, tpu-current-line (used by the redefined newline) raises errors at times when called from display-warning. How does it happen that tpu-current-line is not loaded? tpu-extras starts with (require 'tpu-edt). It looks like the redefinition of `newline' is done as part of a scheme to implement scroll margins. Emacs nowadays has scroll margins as a built-in feature. So I think all that code could be replaced by a few variable aliases. Would someone like to do that, and ack? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: HowTo: Avoid packages like TPU
With loaddefs.el in Emacs 22, rarely used packages like tpu end up showing up in the default obarray operated upon by mapatoms. Is there a way to avoid this? The only easy way is to delete the autoloads. But why do that? There are not very many of them. 0) mapatoms finds commands like "set cursor free" from tpu-extras 1) In using reflection, it ends up loading tpu-extras.el (even though I have no intention of using tpu) What is "reflection"? Perhaps we should put the tpu-extras.el autoloads into tpu-edt.el instead of into loaddefs.el. I think that only tpu users would want to call those entry points. Stefan, you know how to do that. Would you please do that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs trunk needs to increase PURESIZE (was Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space)
The following change solves it, however it seems to become insufficient sooner or later. Please add 1 to the value. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: commandp
Thanks for fixing it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Two Tramp .el files executable
Yes, likely they have inherited the permissions from my local copy when I have created these files. I have no idea how to change this in CVS. Does anybody know? If nobody here knows how, please ask [EMAIL PROTECTED] to fix it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current "M-x gdb" and will not be pleased to see the GUI version instead. I agree. How about if we modify "M-x gdb" to invoke gdb-ui if a certain option is set? That would be ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
That is not a 100% solution for 100% of the problem, but it's a good compromise that works well in practice. You often advise others to shy away of purism and instead embrace practical compromises on the Right side of the 80-20 divide. Why not go with this advice in this case? Because the 20% that fails will tend to include all the general-purpose software that is used around the world. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
If I'm understanding correctly, it can already be done. If you use the @documentencoding command in the Texinfo source, and then specify --enable-encoding to makeinfo, the resulting Info file(s) will contain a Local Variables section setting the `coding' variable. What happens if you do not specify --enable-encoding? For instance, Local Variables: coding: iso-8859-2 End: This means different Info files will use different coding systems. That works fine in Emacs, which can read them all, but it might be better to generate all the Info files in UTF-8. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
> On the other hand, we might also want to fix a coding system > for Info files, so that their handling will not depend on the locale. How? Do you mean to encode Info files in UTF-8 or some such? I mean, for some specific coding system. UTF-8 might be a good choice, but not necessarily the best. That would not work well with the stand-alone Info reader, which is a text-mode program and thus limited to the character set supported by the underlying text terminal. It is pure luck if an Info file was generated for the same character set that your terminal supports. Thus, we can't expect good results from the stand-alone Info reader unless it understands coding systems to some extent. But if we use the same coding system for all Info files, at least the stand-alone Info reader only needs to understand that one coding system. Personally, I think preferring locale-specific encoding is TRT, since most of the installed manuals that use non-ASCII characters are more likely to use that than anything else. No, they will use a whole range of coding systems, on your machine, on my machine, and on anybody's machine. That is not a solution. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
The default coding system is determined by Locale settings, that is `LC_ALL', `LC_CTYPE', or `LANG'. Thanks. I rechecked the first message and saw that the problem only affects a few Info files that use non-ASCII characters. Maybe changing those manuals to use @documentencoding is the right fix. On the other hand, we might also want to fix a coding system for Info files, so that their handling will not depend on the locale. Handa and Karl, what do you think? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Richard, is it okay to assume Texinfo 4.6 for the CVS trunk? To support @documentencoding, when it appears in a .texi file, would not require anyone to move to Texinfo 4.6. There is no harm in supporting it, so let's do so. The problem is that that may not solve the whole problem. Even people who use Texinfo 4.6, many years from now, won't generally write @documentencoding in all their files. That is why I asked what it is that makes chinese-iso-8bit the default on his system. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
This problem happens with "emacs -Q", I don't think my .emacs cause this. That is surely correct. The comments in emacs-mime.texi specify which coding system should be used to edit it: --8<---cut here---start->8--- @c Local Variables: @c mode: texinfo @c coding: iso-8859-1 @c End: --8<---cut here---end--->8--- but the generated emacs-mime info file doesn't specify which coding should be used to view it. I think that's why emacs open it with the default coding system chinese-iso-8bit. Is this a bug, or is this correct behavior? What is it on your system that makes the default coding system chinese-iso-8bit? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfmt crashes Emacs
Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
> Does the problem happen with "emacs -Q"? If it doesn't, then > something in your .emacs init file causes this. Yes, it does. Could you show us the code in your .emacs file which caused this? It is possible that your .emacs file was incorrect. But it is also possible that your code is correct, and Emacs ought to be fixed to handle it better. When we see what your code says, we can figure that out. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfmt crashes Emacs
If you revert the recent byte-opt.el patch, does this crash stop? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
When I enter Info, the info doc is allways opened with chinese-iso-8bit coding system which is the default of my installation. If there are non-ascii characters in the doc, it will be displayed incorrectly, such as the emacs-mime page, there's a word `Naïve' in the page, and it should be opened with iso-8859-1. Since this depends on something unusual about your system, most of us cannot easily investigate it. Can you please investigate how this happens? I have cc'd Handa-san, whose area this is in. Please report back about whatever progress you can make. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: clipboard integration hangs pasting text from emacs
Its not just Debian. Fedora, Apple and Ubuntu do too. It has the advantage that if you make a bugfix or security release, as with Emacs 21.4, it doesn't throw all of us who have been calling it the next big release. We do that with minor version numbers. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Saving markup formats (was: warnings before opening very big directories)
What are the most preferable formats to save markup? One variant is Enriched text. It was designed for using in e-mail, but actually nobody uses it nowadays. Most people prefer HTML in e-mail as a replacement of plain text. HTML would be useful. RTF would be useful. XML would be useful. The old Word format would be useful, at least to be able to read it. If you implement any of these, it will be a nice contribution. If you implement more than one, even better. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: clipboard integration hangs pasting text from emacs
I think names for releases is completely confusing. Debian does this, and I never remember which one is which. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings before opening very big directories
We don't need to add help to all questions at once. We could progress adding them one by one only for non-trivial cases We will not have any plan to add them -- neither all at once nor one by one. Please tell what things are more important. Implementing horizontal position computation using variabled-width fonts is an important feature. Saving with markup in additional formats is an important feature. If you would like to work on one of those, it could lead to a real advance in what Emacs can do. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings before opening very big directories
Then what about using a Help key to display the additional information? It sounds like more trouble than it is worth. Many questions Emacs asks can be disabled or made less frequent by setting options. I do not want to start making all of them display info about those options. That would be a lot of work, and not worth the trouble. (And we have more important things to do.) I don't mind adding a feature that tells y-or-n-p and yes-or-no-p a help string to can display for C-h. (Tho it's a bit harder to do this in yes-or-no-p, since it is a normal minibuffer.) But if it is added, we must not let the presence of this feature be used as ammunition for lots of arguments that we must _use_ it to mention all those options. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings before opening very big directories
I just verified that this option is easy to find using customize-browse. BTW, every time I need to increase the default value of the variable controlling the maximum size of file above which a confirmation is requested, I can't remember its name. The name is `large-file-warning-threshold'. Perhaps the name `file-size-warning-threshold' would be more coherent with usual Emacs conventions, thus easier to remember or guess. Do you think so? This is not user-friendly. This warning misses a link to the user option where the user can change its value. Maybe, the y-or-n prompt should contain a line pointing to this user option? I do not want to start putting option names into messages. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: document custom-variable-p
Customize is good for interactive editing and saving of options etc. But its UI is fixed and somewhat limited. I expect that users (e.g. third-party libraries) may well want to provide commands or other UI thingies that let you interface with the functionalities provided by custom: editing that respects specified types, and possibly saving changes. To create such UI extensions, it would be useful to be able to recognize variables that are editable and savable in custom from other user variables (those that just have "*..." as doc string). I see no need to borrow trouble. If and when people undertake such projects, I am sure that finding out about `custom-variable-p' will be the least of their difficulties. If and when such packages become common, there may be a good reason to document `custom-variable-p'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: document custom-variable-p
"Lisp programs should use `custom-variable-p', not `user-variable-p', whenever they want to test whether a variable is something that a user can customize and save." By the latter, I meant user Lisp programs, not just internal Lisp programs - Why do you think this is something user Lisp programs are likely to want to do? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: document custom-variable-p
`user-variable-p' is documented in the Elisp manual, but `custom-variable-p' is not. In general, the internals of Custom are documented only in regard to how to write definitions. Why is it important to document `custom-variable-p'? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-guess-type-alist doesn't exist, but is mentioned in doc string
I will fix this. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: memory leak in xpm_load
Can you fix this, in Emacs 22 and the trunk? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
But, in emacs-unicode-2, x_encode_text uses encode_coding_object, and that function does call Lisp for pre-write-conversion. Would you please install in emacs-unicode-2 whatever GCPROs are needed in the callers of x_encode_text? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Such GCPROs are not necessary because x_encode_text is called with the third arg SELECTIONP == 0. Actually, there's no SELECTIONP != 0 case in the current Emacs code. Ok. How about deleting the arg SELECTIONP in the trunk, to avoid confusion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Ah, now I understand what you are saying. But even if your change had been left in place, wouldn't these GCPRO would have been needed anyway (for the case where HAVE_GTK is false)? I don't think there is any variable that needed protecting in the non-HAVE_GTK case in my version of the code. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
> If my change broke something, then please undo it; but in that case, > please put in whatever GCPROs are needed for x_encode_text. The GCPRO you added in x_encode_text was not deleted. I know that, but we are miscommunicating. There needs to be a GCPRO in x_set_name_internal around the calls to x_encode_text, at least to protect the variable encoded_name. Or else the code needs to be rearranged so encoded_name is not used after the calls to x_encode_text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
So I propose undoing the latest change for x_set_name_internal for now. If my change broke something, then please undo it; but in that case, please put in whatever GCPROs are needed for x_encode_text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Setting the frame title works fine on both GTK and non-GTK builds. That is good. Please make the release tomorrow if no reason comes up why not. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Do we want to give a recommendation at all? I suggest simply keeping silent. Setting font-lock-keywords in file-local variables is a hack---it's not documented in the Emacs manual, and it's not something we want to encourage users to do, due to security concerns. Advanced users can search the web to find the workarounds discussed in this thread, or they can simply use hi-lock mode (which *is* documented in the Emacs manual). ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Thanks for guessing this. After your change, there was another similar bug: x_encode_text can call Lisp code, which would have needed a GCPRO. After looking at it, I realized there was no need to call x_encode_text in the GTK case. So I separated the two cases completely, which should improve things. Would people please test setting the name, in both GTK and non-GTK builds? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> Font-lock-keywords can not be set any more in the local variables > section of a file. Use font-lock-defaults instead. I find the change in behavior sufficiently mysterious that I'm not even sure this characterization is correct. We want to give users a simple and clear recommendation. What should it be? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
What version are you running? If it is from CVS, is it the trunk or which branch? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
I suggest not patching Emacs 22.1 at this time. Ok, I won't. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual doc of `fontified' property
I think it should instead say something like: `fontified' This property says whether the text is ready for display. If nil, Emacs's redisplay routine will call the `fontification-function' (which see) to prepare this part of the buffer before it is displayed. This is used internally by jit-lock. The manual also needs updating w.r.t fontification-function since it says that this var is used for font-lock, whereas it's used for jit-lock. Can you please fix it in Emacs 22? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Should this fix be installed in Emacs 22.1? Or is it safer for us to leave that bug unfixed? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual needs xrefs for text properties and point after cmds
Node Adjusting Point of the Elisp manual is in the Command Loop section - far from help about text properties. It should cross reference node Special Properties, and vice versa, so users can understand the relation between properties such as intangible and point adjustment. I added a reference. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-bury should use one-window-p, not window-dedicated-p
(window-dedicated-p (frame-selected-window)) to this: (and pop-up-frames (one-window-p)) I think it is correct to test the first one. It may be desirable to test the second as well. Let's try it out for a while. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual doc on `intangible' is incomplete
I think it would help to add an explicit statement that you can place point between groups (which are defined as consecutive characters with the same `intangible' value). That is, clarify that you can place point between groups, but not within a group. I clarified that. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: rx doc string
Thanks for checking. Would someone please install that change ASAP? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
I think this way of merging a face and a character code in a single number is a kludge, a relic of an old era when Emacs didn't have any other way to put faces on the text, and we intended to remove this at some point. Maybe Emacs 23 is that point. We now have text properties and overlays, so we shouldn't be needing this. I don't think so. If the goal is to change the display of a particular char code, doing that with overlays or text properties is pretty painful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error' on, I no longer see a `forward-list' error with original bug recipe; I never observed the "other operations are blocked" part of the bug report on this platform.) Let's get this into the branch. Yes, that is good. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
The face codes are ugly kludge. It would be nice to replace that feature some day with a cleaner feature which allows specification of a face name directly, if that can be done without a painful slowdown. Until we do that, we may as well leave the feature as it is. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
The most simple patch I can come up with is specbinding it within `display_mode_line' since that's causing the present problems. Please test it (no other patches needed). If there are more occurrences left I'll have move it to `display_mode_element'. That may be a good compromise for right now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: rx doc string
The documentation for `rx' currently claims `word-start' matches the end of a word. Have you verified it does not? (I don't use rx myself.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Infinite loop in log-edit-changelog-entries
I installed your fix. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
From: YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> Maybe you need to use specbind for the `current_column' call in redisplay_internal instead. *** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007 --- src/xdisp.c Sun May 27 22:48:48 2007 *** redisplay_internal (preserve_echo_area) *** 10888,10893 --- 10888,10894 Fcons (make_number (redisplaying_p), selected_frame)); ++redisplaying_p; specbind (Qinhibit_free_realized_faces, Qnil); + specbind (Qinhibit_point_motion_hooks, Qt); { Lisp_Object tail, frame; This binds the variable across nearly all of redisplay. That is a bit drastic as a solution; it might be right, but it is hard to be sure. Where is the actual call to `current_column' for which you specifically want to bind this? Could you bind Qinhibit_point_motion_hooks for just that? Or what about binding it in `current_column_1'? Maybe that is the right thing to do. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
(2) A bug in redisplay. Somewhere Qinhibit_point_motion_hooks doesn't get bound to Qt but so far I was not able to find out where. There's evidence that the bug shows up when `column-number-mode' is enabled, `current-column' is called and triggers sgml's point-entered hook. If you can arrange to enter GDB (perhaps with a breakpoint at Fsignal) and send the backtrace, we should be able to figure out straightaway where that is. Thanks for getting a handle on this problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc string of make-directory
I will fix it. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: canonically-space-region and fill-delete-newlines leave bounds
Would someone please install this in Emacs 22 also? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem in xterm-mouse-event in longrunning emacs process
Would someone please install this fix in Emacs 22? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word-before-point errs in terminal
There is no easy way to make this work, so I made it give a cleaner error message. After the release I hope someone will implement this case. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: rcirc: feature request: window-width in rcirc-fill-column
Nevertheless I'd still feel rather uneasy if this would be applied without further review/testing. Maybe Ryan's development version would be a better place for the change for now? Ok, please do that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
Thank you for the reply. But I don't have a write access to the Emacs CVS, so I ask someone to install it. Please email the patch and change log to emacs-devel and ask someone to install it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: rcirc: feature request: window-width in rcirc-fill-column
I wonder if the fix shouldn't be more elaborate -- the selected window isn't necessarily the one new messages are inserted in. This leads to rather random filling if your windows aren't all of the same width. Can you write a patch that would use the width of the proper window? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: rcirc: feature request: window-width in rcirc-fill-column
Thanks. I added that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
Yes, there is a second (require 'cl) on line 4157. It is inside an if statement whose condition will never be true in a modern Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
Please install your patch in the trunk. If it proves correct, we can install it in 22.2. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word-before-point errs in terminal
The error message when invoking flyspell-correct-word-before-point in an emacs running in terminal is not clear. What Emacs version is this? Can you please send a precise test case? I don't want to have to learn how to use that command and flail around looking for a case that fails! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
It looks like mh-e tries to avoid loading cl at run time. Would someone like to verify that this works? It seems that the only other real problems are viper and tramp. I've asked the maintainers to fix them in the trunk, and I want to put those fixes into 22.2. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
It seems to me that idlwave.el loads cl only at compile time. Why do you think otherwise? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
However there is one thing I do not understand and that other people have asked: If one want to use functions from cl.el (not only macros), how does one do then? Is (eval-when-compile (require 'cl)) sufficient then? Installed Lisp packages must not use those functions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
This is a change with respect to Emacs 21, and I don't think anyone feels that it is necessary in practice, while some are against it. I think it should be reverted. I think it is just plain wrong to undo a revert. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: docstring of push-mark
Thanks. I fixed it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ispell-word breaks when buffer contents change automatically
Thanks. I will install a simplified variant of this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
Some libraries (iswitchb.el for example) does (require 'cl) without (eval-when-compile ...). Is not that incorrect? It is incorrect, in general. However, in the case of iswitchb, it is a no-op: ;; CL needed for cadr and last (if (not (and (fboundp 'cadr) (fboundp 'last))) (require 'cl)) The current Emacs has `cadr' and `last' as primitives, so cl will never be loaded. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
The way I posted, to make the syntax of all non-ASCII characters `word', has a weakness. It is not effective to charsets that are created after loading mail-extr.el. Regards, So, what about the first proposed fix? The one that patched this particular function? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
If people have doubts that changing that syntax table is generally correct, what about the previous patch that alters just the particular function? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
> Please install your patch. > Installed in the trunk. Please install it in EMACS_22_BASE too! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: Option-as-Meta Sometimes Inputs Accented Characters
Here's a revised one, in Mac-only code. If you have tested it, please install it in the Emacs 22 branch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
Please install your patch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: using rlogin from a shell window
well, if I use the same rlogin in a non-emacs terminal window it works. That doesn't mean rlogin is correct. It means rlogin's bug only happens in the case where it fails for you. If it depends on getting a CR at the end of the password, that seems like a bug to me. But I am rather surprised that it does get a CR in any other situation. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: show-paren-mode and browse customizations
If show-paren-mode is turned on I see a strange visual distortion in *Customize Browser*, see attached image. I looked at it, but I don't see the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
I remember fixing such a bug. What version are you using? Or when did you get the sources from CVS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: Option-as-Meta Sometimes Inputs Accented Characters
OK, fine. I presume that patch isn't going to make it into the 22 branch? Could you show me the patch? Is it in Mac-only code? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: elisp manual indent-line-function default
I will update the documentation for this. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: using rlogin from a shell window
More info. If, when it prompts for the password, I type the password and then add a carriage return (using ^Q^M) at the end of the password, then hit enter, all works as expected. This suggests it is a bug in rlogin. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: elisp manual indent-line-function default
Perhaps a change in the code (emacs 21 was indent-to-left-margin), which didn't make it to the manual. That seems to be a change made by Stephan. Stephan, what was the reason for that change? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: compilation-finish-functions is not run as a hook
Should not run-hook-with-args be used there? Yes, thanks. BTW the doc string for run-hook-with-args does not mention the special handling of t. That is an internal part of the hook mechanism. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: "denet" format save error message
Does this patch make it give the right error message? *** iso-cvt.el 21 Jan 2007 01:36:12 -0500 1.31 --- iso-cvt.el 10 May 2007 06:29:40 -0400 *** *** 823,829 (iso-translate-conventions from to iso-sgml2iso-trans-tab)) ;;;###autoload ! (defun iso-cvt-read-only () "Warn that format is read-only." (interactive) (error "This format is read-only; specify another format for writing")) --- 823,829 (iso-translate-conventions from to iso-sgml2iso-trans-tab)) ;;;###autoload ! (defun iso-cvt-read-only (&rest ignore) "Warn that format is read-only." (interactive) (error "This format is read-only; specify another format for writing")) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: where-is-internal doc
but in reality the return value seems to always be a vector, in this case ([8 102] [f1 102] [help 102] [menu-bar help-menu describe describe-function]) I will get that fixed. Thanks. (And the `C-h d' binding has been changed.) I do not see the signficance of that point. Aside from updating the value returned by this call to where-is-internal, is there something else that needs to be changed in the manual? If so, could you say where? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: can't nowadays type M-e to edit the search string
It works for me. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: elisp manual format-alist encode call description
If TO-FN is a function, it is called with two arguments, BEGIN and END, which specify the part of the buffer it should convert. There are two ways it can do the conversion: But if I'm not mistaken it's three args, the third being a buffer, as per the format-alist docstring, or per the enriched-encode function. Thanks. I fixed this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Recent change to Faccept_process_output
- please mention this as an incompatible change in the NEWS file. I did that. Thanks. - please consider making it an error to supply a third argument that is larger than 999. That is an interesting idea, but I wonder if it might break something else. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Euro sign bound, Pound sign not bound. (Bug?)
Oh, it rings a bell: IIRC key-sequences specified as strings are presumed to be "sequences of bytes" (because the use of a string was introduced when those key-sequences could only come from a tty). So they do not behave correctly in the presence of non-ASCII chars. The patch below seems to fix the problem. That would be good to install in the unicode-2 branch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Euro sign bound, Pound sign not bound. (Bug?)
(key-binding [2211] t) -> self-insert-command (key-binding [342604] t) -> self-insert-command or generically: (key-binding (vector (string-to-char "£")) t) -> self-insert-command (key-binding "£" t) -> nil So, it seems to be a problem with the string specification of the key. Oh, now I see it. key-binding operates byte by byte, and does not understand non-ASCII characters if they come from strings. This is because codes above 0200 are treated as meta-characters in these strings. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-abbrev-end-of-buffer apparently does nothing
It works in both cases even if I delete the first condition, leaving only the second one. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs deadlock: malloc inside signal handler inside malloc ...
Sorry, I lost the running image (X Windows locked up and I had to reboot), and have no core dump file. I'll make sure to get a core dump if I see it again. Please don't just make a core dump. Please investigate using the live process; try to figure out whether the BLOCK_INPUT was executed, and if not, why not, and if so, then why it didn't take effect. I'm very happy to hear that there are precautions to prevent this from happening. (Too bad they didn't work ;-{.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-abbrev-end-of-buffer apparently does nothing
> + ;; Do let Ctl and Meta chars expand if they try. > + (not (event-modifiers last-command-char)) > + (equal this-command 'self-insert) Why check (not (event-modifiers last-command-char)), then? Maybe it isn't necessary given the other condition. But the main question is, does this code fully work right? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs deadlock: malloc inside signal handler inside malloc ...
Notice that malloc is being called inside a signal handler, which has interrupted malloc! That ought to be impossible due to the BLOCK_INPUT near the top of the body of allocate_string_data. What is the value of interrupt_input_blocked? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: turn-on-eldoc-mode docstring clarity
I fixed this. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Recent change to Faccept_process_output
Is it on the branch? If so, that would be extremely annoying. This kind of change obviously shouldn't be made without discussion. The reason I have mostly stopped discussing changes with people is that I expect them to respond mechanically with "Don't make this change because I want a release NOW". Since I don't agree with that basis for the conclusion, these responses are not useful. What's more, people often say things that seem to be meant only to vent their resentment. That doesn't incline me to talk with them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.98 not starting on Solaris 10/I386
I finally found out about this one! The bug arises from setting the LANG variable in your environement. I used LANG="en_US.UTF-8" If LANG is not set emacs will start on the terminal and as a GTK application. Given this help, can anyone reproduce it, and fix it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug