Re: message.el user References control
On 7/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I mean hardwiring any number without a defvar alternative should raise > a red flag anyway. Good point. > Anyway, thanks for your persistence in this matter. Farther than I got > last time just posting to [EMAIL PROTECTED] I'm not sure that anyone actually reads [EMAIL PROTECTED] -- every bug report I send there seems to be entirely ignored... -miles -- Do not taunt Happy Fun Ball. ___ 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
Stefan Monnier <[EMAIL PROTECTED]> writes: > In my opinion we should very much make the gdb-ui code the default. > As for keeping support for --fullname, I believe it's needed as long as the > gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the > current state of affairs, but I've had to switch to --fullname because of > minor problems at least once in the last year. I think another issue is multiple-debugging session support (though I like the new gdb-ui too). Not critical for most people, but may be for some. -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Eli Zaretskii <[EMAIL PROTECTED]> writes: > 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. We have discussed this before; there are still uses for glyph codes which aren't solved by text properties or overlays. The example I know about is display tables. Perhaps another, better mechanism will come along which will supplant glyph codes entirely, but there isn't one yet (AFAIK). -Miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Jason Rumney <[EMAIL PROTECTED]> writes: >> The "19" should be "21" in the unicode branch. > > I'm not sure I understand what this magic number 19/21 is. Is there a > constant for it that could be substituted? Yeah, though it's a grody implementation detail, certainly this ought to have a constant defined by the C code, if only to make the definition of make-glyph-code more clear (though hopefully people will use make-glyph-code instead!). > I'm surprised that that is the only change needed. The code points > between the unicode branch and Emacs 22 should be completely different, > shouldn't they? I assume most people get the codepoints themselves by loading a lisp file or something, which uses an external encoding. -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
"Drew Adams" <[EMAIL PROTECTED]> writes: > (defun make-glyph-code (char &optional face) > "Return a glyph code representing char CHAR with face FACE." > (if face (logior char (lsh (face-id face) 19)) char)) ... > I admit to not understanding a lot about glyphs, character codes, or > Unicode. Perhaps it is silly to expect that `make-glyph-code' would work as > proposed for Emacs 23 also. Please explain. Otherwise, if this is a bug, > HTH. The "19" should be "21" in the unicode branch. [I'll make that change in the CVS tree, as make-glyph-code already exists there.] -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: hl-line-face should be a face, not an option
Stephen Berman <[EMAIL PROTECTED]> writes: > Why not simply have hl-line-face defalias'd to hl-line? Wouldn't that > suffice for backward compatibility (assuming that was the reason for > retaining hl-line-face)? `hl-line' is not a variable, so it makes no sense to use defalias. If backward compatibility is necessary, then I'm not sure there's any alternative to what was done. -Miles -- "Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join." -- Anon. British Officer in WW I ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: git mirror of emacs CVS repository
Jim Meyering <[EMAIL PROTECTED]> writes: > I'm using git for projects I control, and find that I am less and less > tolerant of the abysmal (by comparison) performance of CVS and SVN Git is enticing, but the main issue that's prevented me from adopting it has been the (apparent) clumsiness of maintaining tag information in conjunction with a "remote shared" repository. It's a bit hard to describe, but basically I want a single central git repository (for myself in this case, but something similar might be desirable for a project like Emacs) with multiple "branches" in it, and I want to be able to have different "checkouts" of that (e.g., a checkout of 'tag FOO'). When I make a change locally, I want to then commit the changes to the branch described by 'tag FOO' and _update the central repository's notion of 'tag FOO'_. The latter point seems to be where the problems occur. It's never entirely clear what goes wrong -- it always kinda-sorta works at first, but I always seem to end up inadvertently trashing the remote repository at some point (I think after merging back and forth between branches a bit), in confusing and hard to describe ways; this is not comforting. My vague impression is that working this way is possible, but not entirely trivial, and that other projects trying to use a similar model (x.org?) use big .git-config files specifying the proper tag synchronization to use, which seems kind of fragile. Sorry if that's not described well, my experience with git is somewhat limited. -Miles -- Do not taunt Happy Fun Ball. ___ 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
Glenn Morris <[EMAIL PROTECTED]> writes: > Otherwise, it seems there is something of a trend to disable undo all > over the place, for no real reason, then have to un-disable it when > someone complains. This is true, but using undo in a dired buffer is a pretty dodgy thing to do; it seems almost guaranteed to stop working at some point in the future (if I was adding some feature to dired that made it necessary to disable undo, I wouldn't even think twice about it). -Miles -- My spirit felt washed. With blood. [Eli Shin, on "The Passion of the Christ"] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
I wrote: > _None_ of this is important enough to do before the release. Given that > there's some disagreement about the right change to make, I think it's > better to hold off doing anything to the locate command until after the > release. hmm, I see the patch is already applied; oh well... -Miles -- Next to fried food, the South has suffered most from oratory. -- Walter Hines Page ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > I do not see the urgency to do that before the release. _None_ of this is important enough to do before the release. Given that there's some disagreement about the right change to make, I think it's better to hold off doing anything to the locate command until after the release. -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: >Why are you putting the "prefix inverts sense of locate-prompt-for-command" >logic into the main function body, and not in the (interactive ...) code? > > I believe that was already the case before my patch is it not? The old code didn't have an "arg" argument, so there's no argument compatibility to maintain -- and indeed that argues for introducing reasonable arguments now. The interactive operation is the same either way (the only difference being whether certain operations are done in the function body or the (interactive...) form). The only real difference as far as I can see is how the arguments are "captured" and re-used with `C-x ESC ESC' -- and your patch changes that behavior anyway (by capturing the state of current-prefix-arg instead of using the current value when C-x ESC ESC is used). The differences between your patch and what I'm suggesting only occur when the user does something weird: Invokes "locate" interactively, then _changes_ the value of locate-prompt-for-command, and attempts to re-invoke locate using `C-x ESC ESC'. I don't think either behavior is obviously more correct, so it seems reasonable to pick the cleanest in this case. -Miles -- A zen-buddhist walked into a pizza shop and said, "Make me one with everything." ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > New patch identical to the last one, except for a trivial one-line > docstring change in `locate-with-filter': Why are you putting the "prefix inverts sense of locate-prompt-for-command" logic into the main function body, and not in the (interactive ...) code? Such toggling behavior is convenient for interactive use, but it often doesn't make much sense for the programmatic function interface. It would seem more understandable and useful for non-interactive users if you just added a "prompt-for-command" argument to the locate function and put all the grot involving locate-prompt-for-command into the interactive code. IOW, (1) add a "prompt-for-command" argument to locate, (2) use that arg everywhere in the function body where "locate-prompt-for-command" used to be used, (3) implement the arg toggles global var stuff in the (interactive ...) code (e.g., (not (eq (not arg) (not locate-prompt-for-command. [I think anytime you find yourself using a function argument called "arg" with funny semantics intended solely for convenient keyboard use, it's a hint that maybe you should rethink the function interface.] -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Glenn Morris <[EMAIL PROTECTED]> writes: > OpenAFS at least is still widely used in the particle physics > community. I have never encountered the "superroot" concept in > connection with it though. Everything is accessed through /afs. The filesystem I was thinking of wasn't AFS; I don't know if it's still used or not. -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> I always thought it was a rather clever idea. It certainly messes up >> assumptions some programs make, but I think the "/.." == "/" assumption >> is generally rather rare in practice. [Compare to the microsoftian "//" >> superroot syntax, which messes up the far more common "//" == "/" >> assumption, and just generally feels a lot more arbitrary.] > > The Microsoft // doesn't mess up anything because on Microsoft > filesystems // != /. My point was that lots of (unixoid) _apps_ assume // = /, and it's rather common to "prettify" filenames by doing the equivalent of "sed [EMAIL PROTECTED]//@/@" [*] -- which screws up filenames using the MS superroot. The reason many unixoid apps do such prettification is that filenames inadvertently containing "//" at the beginning are pretty common too, e.g. when you have a Makefile that does "FOO_DIR = $(INSTALL_ROOT)/foo" and INSTALL_ROOT is "/". -Miles -- A zen-buddhist walked into a pizza shop and said, "Make me one with everything." ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Chong Yidong <[EMAIL PROTECTED]> writes: > On the other hand, I just checked, and this behavior seems to have > been around since at least Emacs 20. Glancing through the source > code, this behavior seems to be deliberate---something to do with the > "superroot directory". Maybe someone on this list can elucidate? I don't know anything about the Emacs code, but CMU CS had a networked filesystem (the mach/spice project vaxes) which had the concept of a super-root above /, accessed via "/..". E.g. to access file "/x/y" on machine "blargh", you'd use "/../blargh/x/y" (IIRC, "/.." was a real directory so you could do "cd /..", "ls /.." to see all machines, etc).. I always thought it was a rather clever idea. It certainly messes up assumptions some programs make, but I think the "/.." == "/" assumption is generally rather rare in practice. [Compare to the microsoftian "//" superroot syntax, which messes up the far more common "//" == "/" assumption, and just generally feels a lot more arbitrary.] -Miles -- I'd rather be consing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Nick Roberts <[EMAIL PROTECTED]> writes: > > `eq' compares immediate values in lisp. All integers in emacs lisp are > > immediate values. Floating point numbers in Emacs lisp are "boxed" -- > > allocated on the heap -- just like cons-cells or whatever. > > Well a symbol also seems to be a pointer/allocated on the heap, but > OK, thanks, that gives me some understanding. Symbols are indeed on the heap, and in fact it's quite possible to have two identically named symbols which aren't eq. However in normal usage symbols are interned when they are read, which makes them eq. -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Nick Roberts <[EMAIL PROTECTED]> writes: > > >A "character" in emacs is represented by a normal integer. > > > > > Because emacs does have the concept of characters, separate from > > > integers, it's just that they share a concrete representation in lisp. > > > > I agree. > > What's an abnormal integer? > (A "character" in emacs is represented by an integer. ?) The word "normal" is simply to emphasize the point that they're the same integers which are generally used in lisp (I thought of leaving it out, but I think it sounds beter with it). -Miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Nick Roberts <[EMAIL PROTECTED]> writes: > Yes. I still don't get it. `eq' compares immediate values in lisp. All integers in emacs lisp are immediate values. Floating point numbers in Emacs lisp are "boxed" -- allocated on the heap -- just like cons-cells or whatever. So if you do (let ((v1 5) (v2 5) (v3 5.0) (v4 5.0)) ...), v1's and v2's immediate values are the integer "5", so (eq v1 v2) will return t, but v4's and v5's immediate values are _pointers_ to heap locations containing 5.0. v3 and v4 may point to the same location in the heap or different locations (in this case probably different locations, but I don't know of any guarantee); (eq v3 v4) can return t or nil depending on which is the case. -Miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Nick Roberts <[EMAIL PROTECTED]> writes: > It might still be logically true but generally it's best to say exactly what > things are i.e "is a non-negative integer.", if this change is made. If it's > not made then maybe the manual should be changed to be more precise: > > A "character" in Emacs Lisp is just an integer. I think it would be more clear to say something like: A "character" in emacs is represented by a normal integer. Because emacs does have the concept of characters, separate from integers, it's just that they share a concrete representation in lisp. -Miles -- Suburbia: where they tear out the trees and then name streets after them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
martin rudalics <[EMAIL PROTECTED]> writes: > > I am of the mind that having indent-tabs-mode set to nil should be > > sufficient to disable this behavior. > > This should be handled by > > (defcustom whitespace-check-indent-whitespace indent-tabs-mode >"Flag to check indentation whitespace. This is the global for the system. That fails to do the right thing if the user changes indent-tabs-mode mode after whitespace.el is loaded -- which is certainly not unlikely, especially given that indent-tabs-mode is automatically buffer local, and traditionally set on a per-buffer basis! In general, using another variable as the initial value in a defvar/defcustom is almost never the right thing for exactly this reason. The right thing to do with whitespace.el is probably support a special `auto' value for such settings. For instance, in `whitespace-cleanup-internal', instead of just checking the value of `whitespace-check-buffer-indent' (the "local" version of `whitespace-check-indent-whitespace'), it could do something like: (if (eq whitespace-check-buffer-indent 'auto) indent-tabs-mode whitespace-check-buffer-indent) [Incidentally, whitespace.el seems absurdly overspeced in many ways -- is it really necessary to have separate names for the global and local versions of every config variable, and a toggle function for just about every whitespace option?!?] -Miles -- My books focus on timeless truths. -- Donald Knuth ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q -f calendar wraps ugly
Dan Jacobson <[EMAIL PROTECTED]> writes: > $ emacs -Q -f calendar > wraps ugly these days. It looks great to me. Perhaps you need to give more details... > However, even there, (setq show-trailing-whitespace t) shows trailing > blanks, which when combined with the obligatory leading whitespace, > means that you need a wider window than really needed before wrapping. ??? There's an amazing _one_ trailing space. That makes the line length 76 characters, which should be fine. -Miles -- Would you like fries with that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Leo <[EMAIL PROTECTED]> writes: > But the new icon theme has been chanted in both Gnome 2.16 and 2.18. I > don't think Gnome team would do that if it is just slightly different. Um, you looked at the icons, right (you posted a picture of them after all)? They are slightly different. -Miles -- "Unless there are slaves to do the ugly, horrible, uninteresting work, culture and contemplation become almost impossible. Human slavery is wrong, insecure, and demoralizing. On mechanical slavery, on the slavery of the machine, the future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Leo <[EMAIL PROTECTED]> writes: > My concern is a lot of users who want to learn Emacs will > be driven off by the ugly GUI interface. "Ugly GUI interface"?!? I have no particular objection using the 2.18 icons, but they're not really any prettier than the older icons, just (very slightly) different. -Miles -- "An atheist doesn't have to be someone who thinks he has a proof that there can't be a god. He only has to be someone who believes that the evidence on the God question is at a similar level to the evidence on the werewolf question." [John McCarthy] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Italic font does not have same height as non-italic
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: >> Er, so what? >> >> [It's nice when variants of a mono-spaced font are sized consistently >> with it, but I think it's up to the font creator to do that.] > > Would it not be nice if Emacs by default used a consistently sized font? Sure, but I'm not sure it's very easy for Emacs to do (not that I know anything about w32 font selection :-). Even if it was easy, it may not be desirable -- for instance if a slightly inconsistent font was much more readable than a consistent font, it's probably better to just deal with it and use the more readable font (italics are hardly very common in Emacs anyway). Anyway, I'll shut up now; hopefully some w32 people can say something more concrete... :-) -Miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: >> I get the feeling that the massive extended toolbars really serve >> somewhat the same role in a typical MS app that keybindings do in Emacs: >> both are somewhat cryptic and take a fair bit of time to remember, but >> are probably faster and more convenient than the menus -- once you have >> learned them. > > Toolbars are for mouse, menus for keyboard (or at least they are faster > with the keyboard). That may be the case, but I don't think it changes my point: massive bloated toolbars are still more of an expert interface than a newbie one. -Miles -- "Nah, there's no bigger atheist than me. Well, I take that back. I'm a cancer screening away from going agnostic and a biopsy away from full-fledged Christian." [Adam Carolla] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Italic font does not have same height as non-italic
Lennart Borgman <[EMAIL PROTECTED]> writes: > It looks like the height of an italic font is different from a > non-italic, at least on w32. Er, so what? [It's nice when variants of a mono-spaced font are sized consistently with it, but I think it's up to the font creator to do that.] -miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Stefan Monnier <[EMAIL PROTECTED]> writes: >> On modern graphical displays, this is a non-issue. On my standard >> laptop display, if the frame is appr. 80 columns wide, 20-25 buttons >> can be placed on the toolbar (i.e., all the standard and Info buttons >> would be visible); ... > I definitely do not want to encourage people to use windows larger than > 80 columns. Indeed. It's actually very annoying to see comments like "on modern graphical displays, this is a non-issue." That simply isn't true. There are many different usage styles, and despite the increasing resolution of displays, you can't assume that everybody is using the one-huge-window-occupying-the-whole-screen style of usage that's common with MS apps, nor do I think you can assume that the majority are. [Like many others, I prefer to use my display's resolution to show multiple windows side by side when possible.] I don't think the "big windows vs. many small windows" issue is entirely arbitrary either: Emacs is a _text editor_, and typical text just isn't very readable past a certain width. Emacs can split windows horizontally, but unfortunately Emacs window layout is too dynamic to work very well if you require constraints on the layout like certain horizontal vertical splits. This is in contrast with graphical applications like spreadsheets, or mail readers with a rigid layout, which can use extra horizontal space much more effectively. >> Modern word processors/text editors often have two or three toolbar >> lines with dozens of buttons. ... >> A more extensive toolbar could help newbies learn/explore Emacs faster. > > Could be. Right now, the menus play this role. Yup. Emacs newbies I've observed seem quite happy with the menus (which are actually quite a bit easier to understand than the toolbar; the whole concept of "irritatingly slow to use" doesn't seem to be a problem for some reason... :-) I think in fact a big fancy toolbar is not particularly newbie-friendly at all. Indeed, even as an "expert" user, I'm somewhat daunted by typical toolbars and even after using a MS-style app for a long time, only really seem to end up using a few common toolbar buttons. I get the feeling that the massive extended toolbars really serve somewhat the same role in a typical MS app that keybindings do in Emacs: both are somewhat cryptic and take a fair bit of time to remember, but are probably faster and more convenient than the menus -- once you have learned them. Given Emacs' much larger command set and more sophisticated keybinding mechanisms, the typical expert user seems better served by just learning the keybindings. The exception is perhaps heavily-used commands like file save/open etc -- and those are exactly the things which are already in Emacs' toolbar. -miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `move-beginning-of-line' doesn't move to beginning of line
Chris Moore <[EMAIL PROTECTED]> writes: > C-a runs the command move-beginning-of-line > Move point to beginning of current line as displayed. ... > The documentation should match the behaviour one way or the other. I would suggest adding something like: "This function constrains point to the current field in a similar manner to `beginning-of-line' (see that function for details)." to the docstring. -Miles -- Fast, small, soon; pick any 2. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
David Kastrup <[EMAIL PROTECTED]> writes: > a) accept "%!" as magic PostScript override (previous behavior) > b) accept "%!PS" as magic override (what I proposed and checked in) > c) don't accept any magic postscript override ... > My point of view is that b) nowadays appears like the most > pragmatically useful option, judging from problematic cases I have > seen. I agree. (b) is the conservative change. "%" is a common enough comment character that I can see "%!" as being slightly risky, but "%!PS" is far less so. -Miles -- "1971 pickup truck; will trade for guns" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Quotation marks
"Per Starbäck" <[EMAIL PROTECTED]> writes: > I suggest sometimes using a display table where they are replaced by > U+2018 LEFT SINGLE QUOTATION MARK and > U+2019 RIGHT SINGLE QUOTATION MARK. Those quite often look _worse_ -- it's very common that they get dragged in from some completely unrelated font (in my current setup, they use a double-width font, and the resulting glyphs are odd blobs that don't even look like any kind of quotes at all!). -Miles -- I'd rather be consing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
Ralf Angeli <[EMAIL PROTECTED]> writes: > The build process, however, now is really slow. Probably twice the > time it took before. Is the slowness restricted to the abnormally large files in the leim subdirectory, such as ZIRANMA.el and ja-dic.el, or is it all lisp files? If the former, perhaps we should add a variable to control whether the byte compiler tries to correctly dump circular data structures or not (`byte-compile-circle'?), and bind it to nil when compiling those large files as we know they contain no circular data. -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-face-name PROMPT arg should be self-contained, including ": "
"Drew Adams" <[EMAIL PROTECTED]> writes: > In any case, whenever a prompt is expressed as an explicit question, > for whatever reason, it needs to be followed by a question mark (`?'). No it doesn't. These prompts are perfectly understandable as they are. -Miles -- 80% of success is just showing up. --Woody Allen ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
> So #:my-uninterned-var could be #:dummy? The name given is never used, or?
If you print the code, the name you use is what's printed (that's really
the only thing variable names are ever used for once the reader has read
the code).
-miles
--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: >>(let ((#1=#:my-uninterned-var 5)) >> (+ #1# 3)) > > Thanks. I have never seent that syntax. I guess it is "unofficial"? I'm not really sure what you mean; it's real reader syntax, and it's perfectly fine to use it... It will also be output by the lisp printer if `print-gensym' is non-nil. See `(elisp)Output Variables' and `(elisp)Circular Objects' in the info manual. Basically #:SYMBOL is read like SYMBOL, except that it's not interned. So a further occurance of #:SYMBOL will be a _different_ symbol. > When is my-uninterned-var used in the elisp code? Only in the #:? The #1# is actually #:my-uninterned-var (the same one as before, not a different one with the same name). It uses the "reference" feature of the reader, which allows you to specify multiple references to the same lisp object in a form read by the reader. Here #N=FORM (where N is an integer) is read just like FORM, except that it also associates N with FORM. #N# is then read as the same FORM which was read earlier. This is useful for printing/reading circular data structures (so the variable `print-circle' enables printing of it), but it's also good for reading multiple references to uninterned symbols. -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
Leo <[EMAIL PROTECTED]> writes: >> If you _do_ care about 100MB of disk space (I do, as I have a small >> disk), you could use the "emacs/quick-install-emacs" script to > > But the script is lying in admin/quick-install-emacs. Oops, you're right, that's what I meant to type ... :-) -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> The point is if I have 50 builds then the DOC-* will take up more than >> 100M disk space. > > Whoever cares about 100MB of disk space these days? ;-) If you _do_ care about 100MB of disk space (I do, as I have a small disk), you could use the "emacs/quick-install-emacs" script to install Emacs, instead of "make install". It hard links installed files instead of copying them (which allows much faster re-installs as well as saving space), and will optionally purge old cruft like DOC-*. To do this you should give it the "-p" (--prune) option. -Miles -- Would you like fries with that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: > However the real question was of course if the same obarray is used for > symbols created by let variable declarations (did I get everything right > now?;-) as for symbols created by "defvar" variables. I was surprised by > that and a bit curious. Interning is done by the reader, it has absolutely no connection to the interpretation of what is being read. If you want to use an uninterned variable name in a let statement, you can use the "#:" reader syntax, along with the #n= and #n# syntaxes to allow using the uninterned variable: (intern-soft "my-uninterned-var") => nil (let ((#1=#:my-uninterned-var 5)) (+ #1# 3)) => 8 (intern-soft "my-uninterned-var") => nil -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: inconsistent childish MS bashing
Chris Moore <[EMAIL PROTECTED]> writes: > If we're going to refer to MS-DOS as MS-DOG, shouldn't we demonstrate > that we're consistent in our childishness by also referring to Windows > as "Windoze" or "Winblows"? > > Alternatively we could use the proper "grown up" names "MS-DOS" and > "Windows NT". Or on the other hand, we could just relax and think about something important, like the latest cricket scores in Botswana. -Miles -- "Whatever you do will be insignificant, but it is very important that you do it." Mahatma Gandhi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [bug] Gnus weird behavior
Richard Stallman <[EMAIL PROTECTED]> writes: > No. But it has been installed in the stable (v5-10) branch of Gnus. > It will be synched to Emacs with Miles (Cc-ed) next sync. > > Miles, would you please tell me when this is done, so I can remove > that item from FOR-RELEASE? OK, it's done. -miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ___ 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
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> to use is M-TAB. Is M-TAB the only such problem on MS Windows? > > Yes. And the same happens with other window managers on Posix > systems, so I think this issue should be described as a general > problem with window managers. Yeah, all the window managers I use steal M-TAB too (and the function they use it for is very useful, so I think it's fair to let them have it). -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Stefan Monnier <[EMAIL PROTECTED]> writes: >> I've made my decision about this, and I don't want to argue it >> further. > > Does anybody agree with Richard on this one? Technically I prefer Jason's solution, but I think in practice it's an extremely minor issue. I've only ever had problems with uppercase extensions on image files, so the less general fix of simply adding appropriate entries to auto-mode-alist would suffice for me at least. I also think that as maintainer, it's Richard's right to say "it's good enough, let's drop this issue for now" and that people should respect that unless doing so would cause real problems -- and in this case, it simply doesn't matter very much. -miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Eli Zaretskii <[EMAIL PROTECTED]> writes: > We all have our bad days, and that's when we are in dire need of > support. Not before, not after, but right there and then. True... I apologize for the snide comment, Jason. -Miles -- "Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> You might try decaf. > > Not really my idea of support. I wasn't trying to support him. I don't particularly like Richard's method of handling such issues, but Jason's response was downright petulant. -MIles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Jason Rumney <[EMAIL PROTECTED]> writes: >> The answer is no, and I've chosen a different solution. >> Please drop the subject. > > If a developers mailing list cannot be used for discussing development > ideas, then I think I might as well unsubscribe. You might try decaf. -miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
Alan Mackenzie <[EMAIL PROTECTED]> writes: > Hmmm. One processor for foreground editing, another for doing garbage > collection, yet another four or five for background font-locking and > syntactic cacheing, and so on. Hmmm I wonder, maybe allocate separate processors to analyze separate regions of the file -- of course that assumes a reasonable beginning-of-defun actually gets sorted out by then... :-) -miles -- `The suburb is an obsolete and contradictory form of human settlement' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > I get the distinct impression that some people using non-Windows > environments would get really pissed if Emacs suddenly started to > treat .ext and .EXT (for most values of "ext") as the same thing. I don't think they'd care in general, and might even approve. Like most people, even though I never use windows, I occasionally receive files from windows users, and there's lots of crufty old windows software that still uses DOS-like names. I think it's the special cases that you to be careful about, e.g., .c -> c-mode, .C -> c++-mode. -Miles -- My books focus on timeless truths. -- Donald Knuth ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
"Juanma Barranquero" <[EMAIL PROTECTED]> writes:
>> Adding this line to the default value of image-type-file-name-regexps
>> in lisp/image.el would help:
>>
>> ("\\.JPE?G\\'" . jpeg)
>
> Perhaps the following patch would be more correct. After all, I don't
> think it will be common to have files with extensions .PNG, .TIFF,
> .BMP, etc. which are not images.
...
> --- lisp/image.el 21 Apr 2006 20:56:06 - 1.63
> +++ lisp/image.el 12 Dec 2006 10:59:47 -
> @@ -271,4 +271,5 @@
> (let ((types image-type-file-name-regexps)
> + (case-fold-search t)
Thought that's probably a reasoanble change, but it doesn't suffice in
this case -- image-type-from-file-name is not called except when
specifically dealing with an image, and Emacs never gets that far unless
auto-mode-alist tells it to...
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Jan Djärv <[EMAIL PROTECTED]> writes: > In summary, pkg-config is a very helpful tool, but you have to get use to it. And for better or for worse, it seems to be becoming the standard method of doing the sort of things it does. So if there are problems with it, we should either try to fix package-config (send bug reports), or try to convince people to use something else (this option seems a lot harder!). Simply _ignoring_ package-config doesn't seem practical. -Miles -- Freedom's just another word, for nothing left to lose --Janis Joplin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Yidong Chong <[EMAIL PROTECTED]> writes: > I guess with this change, either third-party programs that inspect the > EMACS envvar will simply have to handle the new Emacs 22 behavior, or > be incompatible. Ugh. Why would they care what it's value is though? I suspect it's just as common to simply check for the variable's existance, not its value. -Miles -- "1971 pickup truck; will trade for guns" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 32bit system on 64bit kernel
Richard Stallman <[EMAIL PROTECTED]> writes: > So I wonder what is going on with the amdx86-64 configuration: > why someone else expected it to have 64-bit longs, while Stefan's > machine uses 32-bit longs. I think because he's using a 64-bit kernel, but 32-bit libraries etc (so programs like Emacs use a 32-bit ABI) -- and "uname" reports information from the kernel. I'd think in general it's possible simply override configure's choice of architecture (so that it doesn't use uname) by explicitly specifying the architecure on the configure command line. [Emacs' configure.in also seems to call uname directly in several places, but not apparently for the x86-64 case.] -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 32bit system on 64bit kernel
Stefan Monnier <[EMAIL PROTECTED]> writes: > This apparently comes from the use of `uname' in `configure' which tells I'm > running an x86-64 machine (aka amd64) and thus includes m/amdx86-64.h which > says that `long' is 64bit. Hmm, shouldn't configure just be using AC_CHECK_SIZEOF(long) instead of defining such things in the m/ files? -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x shell hides output if given CR
Chris Moore <[EMAIL PROTECTED]> writes: >> > $ echo -e 'bla\r ' #hides output! > > I think what's going on here is that when Emacs sees a carriage return > character, it moves the cursor back to the beginning of the line without > moving down a line. > > Lots of programs rely on this behaviour to get 'animated' displays (see > wget, apt-get, etc). Yes. IOW, it's a feature, not a bug. The way comint does it is not strictly the same as the way a real terminal does it, so there are occasionally different results, but it's generally close enough to make such programs display correctly in comint. -Miles -- Run away! Run away! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control
Peter Dyballa <[EMAIL PROTECTED]> writes: > Here is the output: Hmmm, it looks reasonable enough -- if I just do "cat /tmp/output" in an Emacs shell session, it displays correctly (only showing one short line). Is the shell buffer in "mac line-ending mode"? I guess that might confuse things a lot (RET characters are being used for the ascii graphics, but RET is newline in mac mode...). -Miles -- "An atheist doesn't have to be someone who thinks he has a proof that there can't be a god. He only has to be someone who believes that the evidence on the God question is at a similar level to the evidence on the werewolf question." [John McCarthy] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control
Reiner Steib <[EMAIL PROTECTED]> writes: >> ./git_xorg.sh > file 1>&2 > > ./git_xorg.sh > file 2>&1 whoops -miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control
Peter Dyballa <[EMAIL PROTECTED]> writes: > Sorry, I have no idea of a "typescript" session – and neither does > Unicode Emacs 23.0.0: C-h d t y p e s c r i p t returns an > empty buffer ... Follow the example I gave. It's a shell command, called "script", and takes one argument which is the file to put the output in. It will start a subshell, where you can give your command, and afterwards type "exit" to the subshell to finish the typescript session. I don't know whether it's installed on osx (I gather that's what you're using), but it's a "traditional" bsd-unix command, so the odds are decent that it is. -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control
Peter Dyballa <[EMAIL PROTECTED]> writes: > Neither this nor the other method nor (GNU) tee work, neither in bash > nor in tcsh. All log files are empty. Git obviously is sending ANSI > escape sequences directly to the terminal. Try running the git command inside a "typescript" session (which creates a pty and captures all io to/from it): $ script /tmp/output Script started, file is /tmp/output $ echo -e 'hello\rworld' world $ exit exit Script done, file is /tmp/output $ cat -v /tmp/output Script started on Thu Sep 28 19:23:59 2006 $ hello^Mworld $ exit Script done on Thu Sep 28 19:24:03 2006 $ -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control
Miles Bader <[EMAIL PROTECTED]> writes: > E.g., do: > >./git_xorg.sh > file > > and send "file" as a binary attachment. hmmm, probably better do: ./git_xorg.sh > file 1>&2 In case it's writing that stuff to stderr. -miles -- We have met the enemy, and he is us. -- Pogo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *shell* buffer in GNU Emacs 23.0.0 has faulty terminal control
It would help if you could save the exact raw output of git_xorg.sh into a file, and attach that file with a mime type of application/octet-stream or something to avoid anything mucking with it. E.g., do: ./git_xorg.sh > file and send "file" as a binary attachment. -miles -- "Unless there are slaves to do the ugly, horrible, uninteresting work, culture and contemplation become almost impossible. Human slavery is wrong, insecure, and demoralizing. On mechanical slavery, on the slavery of the machine, the future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Peter Dyballa <[EMAIL PROTECTED]> writes: > it needs to be emphasised that C-s C-q uses a Unicode search and does > not take into account the file's proper encoding. Could be there are > just a few that care about these encoding details. That's misleading. There's no "unicode search"; if the variable I added is set to `ucs', it _converts_ a unicode codepoint entered via C-q to Emacs' internal representation; after that, it works exactly like the old C-q. Since I-search (for instance) currently seems to correctly handle, for instance, searching for a latin-1 ä in a latin-2 buffer -- even though the underlying buffer representation is in fact different -- then searching should continue to work correctly even in "unicode C-q mode". [However, I think that character insertion via C-q won't work as the user-expects; for instance, C-q e4 would insert a latin-1 ä even in a unicode-2 buffer -- using the default settings, this situation will get fixed up at file write time, because unify-8859-on-encoding-mode is on by default, but until then, the inconsistent buffer contents might confuse a user.] -Miles -- "Whatever you do will be insignificant, but it is very important that you do it." Mahatma Ghandi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Richard Stallman <[EMAIL PROTECTED]> writes: > Could you give a self-contained explanation of why you propose this to > be added now? I don't really care one way or another, but Peter (Dyballa) suggests that it would be more user-friendly if non-ASCII characters entered/searched-for via C-q used a standard like unicode to interpret , rather than Emacs internal character numbers as it does now. [In Emacs 23, of course, Emacs internal character numbers will _be_ unicode, so the distinction will go away.] -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä i n different ISO Latin encodings
On 9/23/06, Peter Dyballa <[EMAIL PROTECTED]> wrote: The improvement is that I can find via an Unicode value an ISO Latin encoded character – is this an improvement? It's what you asked for -- that input codes use some well-known encoding rather than the unfamiliar emacs codes. The file code is A4 in any ISO Latin case, and the character is U+20AC in Unicode when in ISO Latin-10/ISO Latin-0 or ISO Latin-9. This looks like a Do What I Mean. Really not bad! But the real way should be C-s C-q 2 4 4 RET or C-s C-q A 4 RET or C-s C-q 1 6 4 RET (decimal), because it searches for the codes one expects in the encoded file, and which does not work. I think that sounds awful -- I do not think users want to learn the codepoints in all encodings they use, they simply want to be able to enter _characters_ that they don't know how to enter via the keyboard. UCS codepoints are good because they allow _all_ emacs characters to be entered in a consistent way. Having C-q use the buffer's file encoding on the other hand seems quite annoying, because it requires users to use different numbers depending on what the file they're editing was saved in (and I suspect a large portion of the time, users don't even _know_ what encoding their file uses). Nonetheless, if you feel that is the right method, feel free to implement it and allow us to try it out (I offered the patch above because it is very simple and offers useful functionality, but I do not know offhand how to implement what you want). -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Peter Dyballa <[EMAIL PROTECTED]> writes: > There is also the option to change the 'base' of the character code > notation from 8 to 16 This feature is supported; see the variable `read-quoted-char-radix'. > This might be the correct way in a GNU Emacs way, but not in the way an > Emacs user would use it. Or can I type C-q 4245 RET to input ¥ in some > file? (Well, it actually works ...) Having to use other numbers than > the well-known three digits wide ones is not the usual user > experience. I suppose that a patch such as the following could be used to support at least unicode input in `read-quoted-char' (the function underlying C-q). (set `read-quoted-char-charset' to `ucs' to input unicode-codes) Whether this is a serious enough problem to consider adding a patch this latein the release cycle to consider, I don't know. [I think the default value of read-quoted-char-charset would probably have to remain nil though...] -Miles 2006-09-22 Miles Bader <[EMAIL PROTECTED]> * subr.el (read-quoted-char-charset): New variable. (read-quoted-char): Use it. --- orig/lisp/subr.el +++ mod/lisp/subr.el @@ -1539,6 +1548,17 @@ :type '(choice (const 8) (const 10) (const 16)) :group 'editing-basics) +(defvar read-quoted-char-charset nil + "*The character-set used for numeric codepoints entered with `read-quoted-char'. +If nil, Emacs' internal codepoints are used.") + +(custom-declare-variable-early + 'read-quoted-char-charset nil + "*The character-set used for numeric codepoints entered with `read-quoted-char'. +If nil, Emacs' internal codepoints are used." + :type '(choice (const nil) (const ucs)) + :group 'editing-basics) + (defun read-quoted-char (&optional prompt) "Like `read-char', but do not allow quitting. Also, if the first character read is an octal digit, @@ -1595,7 +1615,13 @@ (t (setq code translated done t))) (setq first nil)) -code)) +(if (null read-quoted-char-charset) + code + (let ((decoded (decode-char read-quoted-char-charset code))) + (when (null decoded) + (error "Invalid %s character: %d, #o%o, #x%x" +read-quoted-char-charset code code code)) + decoded (defun read-passwd (prompt &optional confirm default) "Read a password, prompting with PROMPT, and return it. -- The secret to creativity is knowing how to hide your sources. --Albert Einstein ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
[EMAIL PROTECTED] (Kim F. Storm) writes: >> Er, well Richard said to wait until after the release, but ... >> >> Yes, I did. > > Ouch! Er, so given that the current code is wrong, what shall we do? Revert to Richard's code until the release? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Jason Rumney <[EMAIL PROTECTED]> writes: >>(single-key-description ?字) >>"字" > > What does (single-key-description (read-event)) say if you input that > character using XIM? I dunno, as XIM doesn't seem to work with Emacs anymore ... it used to, but I normally use Emacs' internal input methods, and trying the usual XIM hot-key now does not turn on XIM! -Miles -- "1971 pickup truck; will trade for guns" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Peter Dyballa <[EMAIL PROTECTED]> writes:
> C-s C-q 245 in ISO 8859-16 does not find ``„´´ (U+201E) – mini-
> buffer tells me that ``¥´´ (\245 in ISO 8859-1) cannot be found.
That's because the numeric code following C-q is _not_ a unicode code
point, it's an Emacs character code. In Emacs 22 those two things are
very different (in Emacs 23, I guess they are the same, as Emacs 23 uses
unicode for its internal codes).
You can see the "Emacs character code" of a character by hitting C-x =
on top of that character in a buffer.
E.g., C-x = says that ``„´´ has Emacs code 1234576, and indeed entering
`C-s C-q 1234576 RET' successfully searches for „ ! Similarly, the
Emacs code for ¥ is 4245, and that also works correctly following C-q.
> Which is the formula to map octal 0156772 to a Unicode slot/position?
> Octal 0156772 is DDFA in hex, which is different from 5B57, 字's
> position in Unicode.
(encode-char #o156772 'ucs)
=> 23383 (#o55527, #x5b57)
> Or: how can I find the octal value for a given Unicode slot (U+ABCD)?
(decode-char 'ucs #x5b57)
=> 56826 (#o156772, #xddfa)
[There seems to be no such unicode character #xABCD known to Emacs.]
Note that (decode-char 'ucs CODE) continues to work properly in Emacs
23, even though Emacs internal codes are completely different (in Emacs
23, of course, it basically just returns its 2nd argument), so it seems
a good function to use for code portable between Emacs 22 and 23.
-Miles
--
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Peter Dyballa <[EMAIL PROTECTED]> writes: > Anyway, what also does not work is: C-s C-q 177 octal code>. For those with really small keyboards this is the > (almost?) only chance to find some of the x times 64 K characters in > Unicode ... Eh? It works for me: E.g., the Emacs 22 character code of "字" is octal 0156772. If I enter C-s C-q 0156772 (followed by some other char to terminate the octal code), it correctly adds that character to the search string (and finds in the buffer). -Miles -- P.S. All information contained in the above letter is false, for reasons of military security. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
[EMAIL PROTECTED] (Kim F. Storm) writes: >> A change to `pushnew' is not necessary anyway: for simple cases (a value >> with no side-effects), the change to `member*' is enough to do the job, >> so `pushnew' itself can just be reverted to what it was before Richard's >> change (just calling adjoin). > > IIUC, the rationale for Richard's original change was to allow a > program using pushnew to be evalled in non-compiled form without > loading cl (because it needs the _function_ adjoin defined there). That doesn't make any sense -- pushnew is defined in cl.el, so if non-compiled code is using it, it must have already loaded cl.el anyway (so it doesn't matter what cl-stuff it uses). IIRC, the reason for Richard's change was simply to make pushnew with default arguments (no :test keyword arg) usable in compiled code that only does (eval-when-compile (require 'cl)) -- before that wasn't the case because the default predicate for pushnew/adjoin/member* was `eql', which prevented the cl compile-time optimizations from removing calls to member*. My change to the member* (and adjoin) _compiler-macros_, and the addition of memql, fixes that very common case, allowing the cl compiler macros to do their job and get rid of runtime calls to cl functions in most cases. >> [Non-simple cases can easily be handled as well by making the `adjoin' >> compiler-macro bind the value when it's non-simple.] > > It doesn't help in the non-compiled case. As I mention above, it doesn't matter in the non-compiled case (pushnew is a macro in cl.el, so if non-compiled code is using pushnew, it must have loaded cl.el anyway). -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs conflicts with gnome-settings-daemon
"Zhang Wei" <[EMAIL PROTECTED]> writes: > This bug is quite subtle and hard to trace. The problem is that other > applications collaborate with gnome-settings-daemon quite well except > Emacs, and you can activate XIM in Emacs with no difficulty if > gnome-settings-daemon is not running. If Emacs _did_ cooperate, it would screw up common Emacs bindings. That isn't a problem for many Gnome apps, because they barely use any keybindings, but Emacs obviously uses keybindings very heavily, and this particular keybinding is extremely common indeed. -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs conflicts with gnome-settings-daemon
Richard Stallman <[EMAIL PROTECTED]> writes: > There's a lot of report from chinese Emacs community that Emacs conflicts > with gnome-settings-daemon. > > The developers of the gnome-settings-daemon should not have chosen a > character that is so important for Emacs. Can you tell me their names > and email addresses, so I can talk with them about this? FWIW, the key in Gnome apps on my system to enter alternate input modes is Shift-Space, not Control-Space. I use a Japanese locale though; it would seem silly to have different hot keys for different locales, but maybe there's some sort of history behind it? [I'm not sure where this stuff is configured though...] -Miles -- .Numeric stability is probably not all that important when you're guessing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
"Drew Adams" <[EMAIL PROTECTED]> writes: > Shouldn't the `single-key-description of a Chinese etc. character simply be > that Chinese character in a string? Er, perhaps I misunderstand you, but that's exactly what it appears to be: (single-key-description ?字) "字" Do you see something different? -Miles -- We have met the enemy, and he is us. -- Pogo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
[EMAIL PROTECTED] (Kim F. Storm) writes: > I have added new primitive memql, and modified pushnew and member* to use it. Er, well Richard said to wait until after the release, but ... I think your change to pushnew is wrong -- it evaluates the value twice. A change to `pushnew' is not necessary anyway: for simple cases (a value with no side-effects), the change to `member*' is enough to do the job, so `pushnew' itself can just be reverted to what it was before Richard's change (just calling adjoin). [Non-simple cases can easily be handled as well by making the `adjoin' compiler-macro bind the value when it's non-simple.] -Miles --- orig/lisp/emacs-lisp/cl-macs.el +++ mod/lisp/emacs-lisp/cl-macs.el @@ -2606,9 +2592,18 @@ (t form (define-compiler-macro adjoin (&whole form a list &rest keys) - (if (and (cl-simple-expr-p a) (cl-simple-expr-p list) - (not (memq :key keys))) - (list 'if (list* 'member* a list keys) list (list 'cons a list)) + (if (and (cl-simple-expr-p list) (not (memq :key keys))) + (if (cl-simple-expr-p a) + (list 'if (list* 'member* a list keys) list (list 'cons a list)) + (let ((test (and (= (length keys) 2) (eq (car keys) :test) +(cl-const-expr-val (nth 1 keys) + (if (or (null keys) (memq test '(eql eq equal))) + (let ((a-var (make-symbol "--cl-var--"))) + `(let ((,a-var ,a)) + (if (member* ,a-var ,list ,@keys) + ,list +(cons ,a-var ,list + form))) form)) (define-compiler-macro list* (arg &rest others) --- orig/lisp/emacs-lisp/cl.el +++ mod/lisp/emacs-lisp/cl.el @@ -149,20 +149,13 @@ (if (symbolp place) (list 'setq place (list 'cons x place)) (list 'callf2 'cons x place))) -(defvar pushnew-internal) - (defmacro pushnew (x place &rest keys) "(pushnew X PLACE): insert X at the head of the list if not already there. Like (push X PLACE), except that the list is unmodified if X is `eql' to an element already on the list. \nKeywords supported: :test :test-not :key \n(fn X PLACE [KEYWORD VALUE]...)" - (if (symbolp place) - (if (null keys) - `(let ((pushnew-internal ,place)) -(add-to-list 'pushnew-internal ,x nil 'eql) -(setq ,place pushnew-internal)) - (list 'setq place (list* 'adjoin x place keys))) + (if (symbolp place) (list 'setq place (list* 'adjoin x place keys)) (list* 'callf2 'adjoin x place keys))) (defun cl-set-elt (seq n val) -Miles -- My books focus on timeless truths. -- Donald Knuth ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: describe-prefix-bindings uses let* but could use let
Stefan Monnier <[EMAIL PROTECTED]> writes: > Actually, sometimes using let* instead of let (when defining several vars) > can result in more efficient byte-code. I thought they generally resulted in more or less the same bytecode, the only difference being whether the "varbind" byte-ops were interleaved with the init expressions, or all bunched up at the end... E.g. `let' is: INIT1 INIT2 varbind V2 varbind V1 unbind N and `let*' is: INIT1 varbind V1 INIT2 varbind V2 unbind N -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
[EMAIL PROTECTED] (Johan Bockgård) writes: >> How about adding a new primitive `memql', a variant of memq that >> uses eql -- which should be very efficient in C -- and then make the >> slight tweak to cl's `member*' expander to produce that in the >> default case? > > Yes, please. That should also fix the `(case foo (LIST-OF-KEYS ...) ...)' > problem. Indeed it does. -Miles -- Everywhere is walking distance if you have the time. -- Steven Wright ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
BTW, the previous patch is against my personal branch, which predates Richard's changes to pushnew (so to see the effect you'll have to revert those changes too). -miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
Stefan Monnier <[EMAIL PROTECTED]> writes: > Honestly, I think using `add-to-list' here makes no sense. > Since we have the variable as a symbol and we're macro-expanding, we can > just use `(unless (member ,element ,var) (setq ,var (cons ,element ,var))) > That'll be a lot more efficient than going through a function call to > add-to-list, using an aux-var accessed via symbol-value and set and checking > `append' arg etc... Yup, and it even looks like cl-macs.el has the machinery in place to do that, it's just very hard to follow (lots of levels of compiler-macros). However I think it normally doesn't "take" because the default comparison function for pushnew is `eql', not eq, so there's no non-cl way to express the result; that's why it uses member*. It works now to use: (pushnew a b :test 'eq), which expands at compile time into the desired: (setq b (if (memq a b) b (cons a b))). How about adding a new primitive `memql', a variant of memq that uses eql -- which should be very efficient in C -- and then make the slight tweak to cl's `member*' expander to produce that in the default case? Then (pushnew a b) would expand to: (setq b (if (memql a b) b (cons a b))). I think this is good behavior because most people probably want more-or-less memq but don't want to uglify their code with the :test 'eq grot; memql would be as fast as memq. The following patche seems to implement this: orig = [EMAIL PROTECTED]/emacs--miles--0--patch-27 M lisp/emacs-lisp/cl-macs.el M lisp/subr.el * modified files --- orig/lisp/emacs-lisp/cl-macs.el +++ mod/lisp/emacs-lisp/cl-macs.el @@ -2578,21 +2578,7 @@ (cl-const-expr-val (nth 1 keys) (cond ((eq test 'eq) (list 'memq a list)) ((eq test 'equal) (list 'member a list)) - ((or (null keys) (eq test 'eql)) - (if (eq (cl-const-expr-p a) t) - (list (if (floatp-safe (cl-const-expr-val a)) 'member 'memq) -a list) -(if (eq (cl-const-expr-p list) t) -(let ((p (cl-const-expr-val list)) (mb nil) (mq nil)) - (if (not (cdr p)) - (and p (list 'eql a (list 'quote (car p -(while p - (if (floatp-safe (car p)) (setq mb t) -(or (integerp (car p)) (symbolp (car p)) (setq mq t))) - (setq p (cdr p))) -(if (not mb) (list 'memq a list) - (if (not mq) (list 'member a list) form - form))) + ((or (null keys) (eq test 'eql)) (list 'memql a list)) (t form (define-compiler-macro assoc* (&whole form a list &rest keys) --- orig/lisp/subr.el +++ mod/lisp/subr.el @@ -350,6 +350,15 @@ (setq list (cdr list))) list) +(defun memql (elt list) + "Like `memq', but compares numbers using `=' instead of `eq'." + (if (numberp elt) + (progn + (while (and list (not (eql elt (car list + (setq list (cdr list))) + list) +(memq elt list))) + (defmacro with-lexical-binding (&rest body) "Execute the statements in BODY using lexical binding." `(let ((internal-interpreter-environment internal-interpreter-environment)) -Miles -- 97% of everything is grunge ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-lisp/cl.el (pushnew): void-variable x
[EMAIL PROTECTED] (Kim F. Storm) writes: >> But what's the wisdom behind pushnew-internal [we already know that >> PLACE is a symbol]? >> >> This is in case we someday switch to lexical binding. >> add-to-list won't work properly on lexical varables. > > Ok, but why does it need a defvar ? That tells the compiler that pushnew-internal is a special (non-lexical) variable. -Miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: format-time-string results invalid char with %a of Chinses Monday
Kenichi Handa <[EMAIL PROTECTED]> writes: > Thank you for the bug report. I've just installed the > attached fix in HEAD. That change will be propagated to > emacs-unicode-2 branch when Miles does synchronization next > time. I did. -miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
bar
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/share/emacs/22.0.50/etc/DEBUG for instructions. In GNU Emacs 22.0.50.113 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-08-17 on dhapc248.dev.necel.com X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--with-x-toolkit=gtk' '--without-xim'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ja_JP.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Dired by date Minor modes in effect: rcirc-track-minor-mode: t desktop-save-mode: t display-time-mode: t minibuffer-electric-default-mode: t recentf-mode: t show-paren-mode: t shell-dirtrack-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t temp-buffer-resize-mode: t line-number-mode: t transient-mark-mode: t Recent input: E E P N P P q g p 5 = q C-v n n n n n n n n 5 = SPC q p 1 SPC SPC q p p p 5 = SPC i n i SPC q x r e p o SPC t r t SPC f o o C-c C-c C-h v r e p o SPC ? n o SPC c SPC( s e t q SPC r e p o ' SPC n i l ) x p Recent messages: Expiring articles...done Making completion list... Loading emacsbug...done Sending... Sending via mail... Appended to /home/soft1/miles/mail/out/20060817 Sending...done Making completion list... Loading pp...done Type C-x 4 C-o RET to restore the other window. nil -- .Numeric stability is probably not all that important when you're guessing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
foo
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/share/emacs/22.0.50/etc/DEBUG for instructions. In GNU Emacs 22.0.50.113 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-08-17 on dhapc248.dev.necel.com X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--with-x-toolkit=gtk' '--without-xim'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ja_JP.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t rcirc-track-minor-mode: t desktop-save-mode: t display-time-mode: t minibuffer-electric-default-mode: t recentf-mode: t show-paren-mode: t shell-dirtrack-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t temp-buffer-resize-mode: t line-number-mode: t transient-mark-mode: t Recent input: q > p p p p p p 1 SPC i q n n p p p p p p p q y C-x g g 5 = q 5 = E E P N P P q g p 5 = q C-v n n n n n n n n 5 = SPC q p 1 SPC SPC q p p p 5 = SPC i n i SPC q x r e p o SPC t r t SPC Recent messages: Suppressing duplicates...done Scoring...done Generating summary...done Exiting summary buffer and applying spam rules Marking spam as expired without moving it Expiring articles... Deleting article 91483 in emacs Expiring articles...done Making completion list... Loading emacsbug...done -- Occam's razor split hairs so well, I bought the whole argument! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CONTRIBUTE file
Nick Roberts <[EMAIL PROTECTED]> writes: > > Everything that's useful to the end user is suitable for inclusion. > > By that criterion the CONTRIBUTE file is probably unsuitable. We may as > well leave things as they are and just accept that the CONTRIBUTE file > won't always be available. There are many other ways to find out how to > contribute to Emacs. How is CONTRIBUTE not "useful to the end user"??? It seems very useful indeed... -Miles -- .Numeric stability is probably not all that important when you're guessing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hello in Hungarian
Kenichi Handa <[EMAIL PROTECTED]> writes: > Another way is to change the policy of that file to accept > all proposals without limit. If people think that is > better, I don't object to it. How about moving the most important lines to the beginning (those using unique scripts), and adding a "Hello in other languages" section to the end for other languages. That way the important testing function of the file would remain convenient, and people could also easily learn how to say hello in many languages... :-) I personally like having as many languages as possible; it adds to the warm fuzzy international feel of Emacs (and Emacs indeed has an amazingly wide range of contributors -- I think even among regular posters on this list, there's a fairly even distribution around the globe!). -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fill-paragraph bug
Chong Yidong <[EMAIL PROTECTED]> writes: > M-: (setq foo 1) RET > M-: (let ((foo 2)) (error "foo")) RET > M-: foo ---> 2 > > After an error, the `let' form gets exited too, so the global variable > isn't rebound to its original value. If that's really happening, it's a very serious bug in `let'. _Huge_ amounts of code depends on let dealing with errors correctly... However when I tried to reproduce it using your example above, I couldn't: (setq foo 1) 1 (let ((foo 2)) (error "foo")) [*get error backtrace, quit from backtrace*] foo 1 [I tried using both the *scratch* buffer and M-:] Are you sure your final test evaluation of `foo" above isn't done while the debugger's recursive edit (with backtrace) is still active? While in that recursive edit, you're still actually "inside" the let context. > One way to fix this is to replace every such construct with ... > OK? Er, no... -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hello in Hungarian
"Peter Tury" <[EMAIL PROTECTED]> writes: > I would like to ask you to add "Hello" to the file (expand-file-name > "HELLO" data-directory) in Hungarian as well. It should look like > this: > > Szép jó napot! Just from curiosity, what's a literal translation of that? [E.g., for some languages, HELLO has greetings which translate as "good day" etc.] -Miles -- "Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
[EMAIL PROTECTED] (Kim F. Storm) writes: > It seems to work fine With the following patch (not trivial, but > not extremely complex either): Regardless of what happens, changing all those hardwired "2"s to a IT_STACK_SIZE is a good thing!! -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: binding for RET in python.el
On 4/27/06, Dan Nicolaescu <[EMAIL PROTECTED]> wrote: > Another argument is that python-mode.el does this by default, so the > python users have come to expect it. Since python-mode.el did not seem to have come with emacs, it could do all sort of bizarre things that are undesirable... it's very common that a lot of dodgy behavior gets cleaned up when a package is included in Emacs proper. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line display bug in XFT_JHD_BRANCH
Baishampayan Ghose <[EMAIL PROTECTED]> writes: > I guess now that the XFT & Unicode branches have been merged, this > critical bug will be fixed. I can help with testing the branch by doing > daily builds, if it's being developed actively. Miles, what do you think > about this? Well so far it's not being developed at all -- I've just created the branch. There are people who have expressed interest in working on it but I don't know how actively they can do so... [If nobody jumps on it, I may try to fix up any compilation bugs and the like, but I probably don't have the time to do real development on it.] -miles -- Americans are broad-minded people. They'll accept the fact that a person can be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a man doesn't drive, there is something wrong with him. -- Art Buchwald ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
unicode-xft branch
I've created the branch "unicode-xft" in both CVS and arch (the full arch name is "[EMAIL PROTECTED]/emacs--unicode-xft--0"). I did this by cloning the unicode branch, and applying Jan D's trunk xft patch from 2006-01-12. I've fixed up the merge conflicts, but done no other testing or even tried to compile the result. There are very likely to be more fixes needed before it will work in any sense. Anybody that wants to hack on this branch, give it a go. I will merge unicode/trunk changes into the unicode-xft branch at whatever intervals people think is appropriate. BTW, there are currently no ChangeLog entries for the changes in this branch. If somebody makes them, please put them in separate ChangeLog files called "ChangeLog.xft" (this is the standard technique used to avoid merge conflicts in ChangeLog files, which is otherwise a problem). Thanks, -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: what is the status of the XFT branch?
On 4/17/06, Pedro Kröger <[EMAIL PROTECTED]> wrote: > So I'd like to ask: what is the status of > the xft support in emacs? is there any branch with it been maintained? Not that I know of. I promised earlier to make a merge branch, but never did... I'll try to do so today. [Note that it probably won't work at first because I'm not going to attempt to debug it, merely to make a branch (by applying Jan's latest patch to the unicode tree and fixing up any obvious silliness) so that people can more easily hack on it.] -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File name completion in mini-buffer cannot expand Cé
2006/3/22, Peter Dyballa <[EMAIL PROTECTED]>: > Then there seems to be some need to type these accents more easily. > The COMBINING ACUTE ACCENT is described in GNU Emacs 22.0.50 as > >character: (332481, #o1211301, #x512c1, U+0301) ... > Or is there something better, faster, easier to remember? And where > come these large numbers for a character in GNU Emacs 22.0.50 from ... ? There's a command `ucs-insert' (in both versions of emacs) which accepts the unicode hex code (e.g. 301). It's not bound by default, so you must type `M-x ucs-insert', but of course you can bind it yourself if you use it a lot. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tooltip-mode = nil only displays first line of multi-line text-properties or overlays
2006/3/21, Eli Zaretskii <[EMAIL PROTECTED]>: > I rather think it's a bug. We already change the height of the echo > area when a multi-line string is displayed there, so I don't see any > reason to avoid that for help echo. It could be _quite_ annoying; tooltips tend to pop up more often, and more "randomly" than normal echo-area messages. Even when the user is intentionally invoking tooltips, it could be very aggravating -- consider the case where the user is moving the mouse over the mode-line to see the embedded help messages... and the echo area keeps changing, moving the mode-line! At the least, I think Richard's suggestion to fill the message text (to cram as much text onto each line as possible) would be a good start. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Xft Jhd refresh
2006/3/20, Jan Djärv <[EMAIL PROTECTED]>: > The branch you are using is probably not going to be updated much more. There > is (or will be?) another branch that merges the Xft changes with the unicode-2 > Emacs branch. However, I don't see a tag for it in CVS. I never created the branch because the guy who wanted to hack on it didn't actually have CVS write access, so it didn't seem useful (might as well just apply the diff to his own sources), and he didn't seem to be an arch user. I'm happy to create and maintain a branch if it's useful for something though. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: self-insert-command advice is not called when command is run
Remember that defadvice is not at all guaranteed to work. It is a good debugging tool, and a way for users to add hacks with minimal work in many cases, but it isn't intended as an interface for packages to use. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: copy & paste problem of non standard encoding ctext
On 3/8/06, Zhang Wei <[EMAIL PROTECTED]> wrote: > The arch repository can't keep up with the CVS repository. The arch repository is not synced in real-time. I typically do it 1 or 2 times a day. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No catch for tag: exit, nil
"Drew Adams" <[EMAIL PROTECTED]> writes: > I think that is ok if the user does something so silly and unnatural. > > Novice users, especially, are not unlikely to do things that to us seem > silly and unnatural. They are also apt to not understand what they did or > what it means. Do you have some evidence that users are (1) _really_ doing this, and (2) getting excessively worried about the resulting (harmless) error message? -miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: command remapping problem
2006/2/1, Kim F. Storm <[EMAIL PROTECTED]>:
> + DEFUN ("indirect-function-noerror", Findirect_function_noerror,
> Sindirect_function_noerror, 1, 1, 0,
...
> + If the final symbol is unbound, return OBJECT
Instead of making a new function, how about adding an optional
"default" argument to the existing `indirect-function' function?
[BTW, you could also get rid of the "and" -- if DEFN is nil, then
that's just an funbound symbol.]
-miles
--
Do not taunt Happy Fun Ball.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: auto-image-file-mode fails for image files inside archives handled by archive-mode
2006/1/30, Joe Wells <[EMAIL PROTECTED]>: > There is no file in Emacs CVS (at least on the trunk) that defines > "image-file-mode". There is only "auto-image-file-mode". It's called "image-mode" and is in the file "image-mode.el". It was written by Richard. [It has basically no connection with image-file-mode, other than offering similar functionality.] -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: auto-image-file-mode fails for image files inside archives handled by archive-mode
2006/1/29, Joe Wells <[EMAIL PROTECTED]>: > Then when you visit bar.png, auto-image-file-mode has no effect and > you see the raw image data rather than the image. Ugh. I believe auto-image-file-mode has been more or less replaced by `image-mode', which uses different techniques and I think works better in this sort of circumstance. [I'm not exactly sure why auto-image-file-mode is still in emacs, but I suppose it's for compatibility.] -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Inherited faces has wrong priority
2005/11/23, Henrik Enberg <[EMAIL PROTECTED]>: > I take this to mean that the inherited face should win when both set the > same attribute. Er, no, not if the _face itself_ has a given attribute. Inheritance always loses to attributes directly defined in the actual face. The comment has to do with other faces which get merged at display-time. -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
2005/11/17, Kim F. Storm <[EMAIL PROTECTED]>: > > [Has pure-space been a major contributor to GC bugs? It doesn't ring > > any bells, in particular.] > > How can we know? There are still quite some reported GC-related bugs > that nobody has managed to explain. Sure, but if we don't know, then proceeding based on a random presumption that pure-space is "the cause" doesn't seem like a very sound strategy. -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
2005/11/17, Kim F. Storm <[EMAIL PROTECTED]>: > So I will re-iterate my proposal to ONLY EVER put the following items > into pure space: You forget "after the release". > - defuns [assuming they are not self-modifyiable] > > - byte-code > > Anything else should go into normal GC space, so we can avoid > the potential headaches of keeping track of this pure space in > various primitives. So do you have any reasoning behind the above suggestion? AFAICS, the most important thing to be in pure space is large twisty data structures (like normal lists) which take lots of time to traverse in the garbage collector. I'd be suspicious of any proposal that didn't have hard data (like benchmarking) behind it. > I have wasted too much time on GC related problems already. Nobody's forcing you. [Has pure-space been a major contributor to GC bugs? It doesn't ring any bells, in particular.] -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
