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: 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: 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
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: 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: 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
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
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
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
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: 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
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
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: 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
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: 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: 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
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: 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: 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: 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
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
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
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
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
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
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
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: 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
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: 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: 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: 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: 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: 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
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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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)
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: 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: 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: 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: 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. ___ 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
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: 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: 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: 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: 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: 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
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: 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: 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: 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
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: 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: 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: 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: mail-abbrev-end-of-buffer apparently does nothing
It works when Emacs is run under X. But when I run Emacs under screen running in gnome-terminal, it does not, and I do not know why. In fact, while view-lossage shows ESC , (event-modifiers last-command-char) returns nil. In that case, last-command-char is ?\, and it has no modifiers. So I need to make another change for that case. Does this patch make it work in both cases? *** mailabbrev.el 21 Jan 2007 01:36:15 -0500 1.82 --- mailabbrev.el 04 May 2007 22:59:43 -0400 *** *** 494,499 --- 494,502 ;; the usual syntax table. (or (and (integerp last-command-char) + ;; Do let Ctl and Meta chars expand if they try. + (not (event-modifiers last-command-char)) + (equal this-command 'self-insert) (or (eq (char-syntax last-command-char) ?_) ;; Don't expand on @. (memq last-command-char '(?@ ?. ?% ?! ?_ ?- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Not easily in detail. Anything I actually contributed I consider OK, obviously. We need to verify that this is ok. When you wrote that code, did you have an employer who could possibly claim copyright on it? If so, do we have a disclaimer from that employer? This is why I ask the period of years during which you worked for that problematical employer, and the period of years during which you worked on the code in python.el. Please answer. We are waiting for you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Unicode2] Crash
Now you can look at the data in the X error packet and see what caused the error. By comparing this with the arguments to these calls, you can find out what is invalid in the arguments. When you report that, someone should be able to fix the bug. I don't understand. Can someone tell me specifically what to do with this? Sorry, I confused this with an X error issue. Now I realize it isn't one. Nonetheless, it is still necessary to examine the arguments to the innermost frames and see if they are somehow invalid. You need to learn how to use GDB to debug a C program. Or else someone who knows how has to work with you, with you being his hands and eyes, so he can debug it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
In that case, why not remove Python support in Emacs 22.1? We can put it back for 22.2, if and when the legal issues get sorted out. Removing it is drastic. Before doing something drastic, I want to check whether it is really necessary. If I can't get the necessary information, then I will remove it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regexp not stateless?
This matches at the start of this text with `looking-at': script type=text/javascript ![CDATA[ However sometimes it matches just to the end of the first line and sometimes to the end of the second line (as it should). I am using this little function to test: If you try a space instead of the newline in that initial text, do you still get variation? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Unicode2] Crash
Could you try doing (x-synchronize t) and then making it crash? That way, the crash will happen WITHIN the X primitive that causes the error. No problem. --=-=-= Content-Disposition: attachment; filename=backtrace_0105.txt Content-Description: backtrace_0105.txt #0 0x4d5967ca in XtWidgetToApplicationContext () from /usr/lib/libXt.so.6 #1 0x4d59eb5f in XtGetValues () from /usr/lib/libXt.so.6 #2 0x080d1630 in x_wm_set_size_hint (f=0xb245f48, flags=0, user_position=0) at xterm.c:9749 Now you can look at the data in the X error packet and see what caused the error. By comparing this with the arguments to these calls, you can find out what is invalid in the arguments. When you report that, someone should be able to fix the bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Not easily in detail. Anything I actually contributed I consider OK, obviously. We need to verify that this is ok. When you wrote that code, did you have an employer who could possibly claim copyright on it? If so, do we have a disclaimer from that employer? This is why I ask the period of years during which you worked for that problematical employer, and the period of years during which you worked on the code in python.el. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: filling long html href
Your code seems good. If people find the 1100 character regexp works well in practice, we could install your code after the release. Please bring it up again in a few months. ___ 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
Does this fix it? *** mailabbrev.el 21 Jan 2007 01:36:15 -0500 1.82 --- mailabbrev.el 28 Apr 2007 21:05:27 -0400 *** *** 494,499 --- 494,501 ;; the usual syntax table. (or (and (integerp last-command-char) + ;; Do let Ctl and Meta chars expand if they try. + (not (event-modifiers last-command-char)) (or (eq (char-syntax last-command-char) ?_) ;; Don't expand on @. (memq last-command-char '(?@ ?. ?% ?! ?_ ?- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: spurious eof to M-x shell child stdin
This is a problem which I believe has no solution. It is due to the limited size of the tty buffer. The buffer gets full, because the program won't read anything until it gets a newline, so Emacs can't send the rest of the characters. Emacs sends an EOF, hoping that will make the program read the text and open up space in the buffer. This is in send_process. It could drop those characters. It could hang. But I don't know of any alternative that is clearly better than what it does now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [sh-mode] .profile is not bash flavoured
I fixed that. Thanks. ___ 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
In my local Emacs hacks, I've fixed the inconsistency the other way: revert doesn't throw away undo info any more. That seems bizarre, but I guess we should consider it. ___ 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
Apparently mail-abbrev-end-of-buffer does nothing special: it jumps to the end of buffer but does not expand the abbreviation. The code tries to expand: (defun mail-abbrev-end-of-buffer (optional arg) Expand any mail abbrev, then move point to end of buffer. Leave mark at previous position. With arg N, put point N/10 of the way from the true end. Don't use this command in Lisp programs! \(goto-char (point-max)) is faster and avoids clobbering the mark. (interactive P) (if (looking-at [ \t]*\n) (expand-abbrev)) Why doesn't it work for you? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Actually I think I found a safe fix. If there is no negative feedback, I'll add it to HEAD. I'm not sure who decides if it should go to the 22.1 branch. I think it should go in 22.1 as well as in the trunk. ___ 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
It used to work in dired buffers. That seems incredible. Deleting the whole text of a directory listing and reading it again is an operation that cannot preserve undo data. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dabbrev--eliminate-newlines
Consider a buffer containing the text 1 2 3 (that is 1 SPC SPC 2 SPC SPC SPC 3 SPC) Then at the end of the buffer, type 1 SPC SPC M-/ SPC M-/. This isn't a case it is really intended to handle. So I won't worry about it now. ___ 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
C-x d /tmp RET M-! touch 00a RET g -- Now yu should see a file named 00a C-x C-q undo -- Now you don't see the file 00a any more The operation undone was the deletion of the old buffer contents and insertion of the new contents. No wonder I turned off undo for that. The comparable operation for files discards undo data also. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Help buffer links on a console
On a linux console and using t-mouse, clicking on a link in a help buffer only works if the cursor is already over the link. Otherwise Emacs reports No cross-reference here which indicates that help-follow-mouse has been activated, rather than push-button. Can you debug it? I don't know how to try to repeat this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: define-globalized-minor-mode has no custom link
I think it would be easier for users if there where such a link too. How else should they understand that they can make the global minor mode be turned on automatically? From the manual, perhaps. Doc strings do not need to list everything that might be relevant. I would rather not change that now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
Thanks for working on this. Now is not the time to install it, but in a few months will be a good time. When you see that Emacs 22 has settled down, would you please get back in touch? (Some others may want to work with you on this now. That would be good.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
