Re: Emacs 23.0.0.1 fails parsing gdb output
On 7/14/07, Eli Zaretskii [EMAIL PROTECTED] wrote: ??? Emacs is a program; how can one be ``nice'' or ``not nice'' to a program? Are you saying it is hard to check the value of a single variable and invoke one of two functions depending on that? What am I missing here? Animism? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: memory leak in xpm_load
On 6/6/07, YAMAMOTO Mitsuharu [EMAIL PROTECTED] wrote: In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache is called twice without an intervening xpm_free_color_cache call, and that causes a memory leak ~4KB per XPM image creation. Try removing the second one; I think it's a leftover from a patch by Chong. Juanma Index: src/image.c === RCS file: /cvsroot/emacs/emacs/src/image.c,v retrieving revision 1.70 diff -u -2 -r1.70 image.c --- src/image.c 3 Jun 2007 00:23:33 - 1.70 +++ src/image.c 6 Jun 2007 09:38:34 - @@ -3968,4 +3968,5 @@ attrs.free_colors = xpm_free_colors; attrs.valuemask |= XpmAllocColor | XpmFreeColors | XpmColorClosure; + xpm_init_color_cache (f, attrs); #else /* not ALLOC_XPM_COLORS */ /* Let the XPM lib allocate colors. */ @@ -3979,7 +3980,4 @@ #endif /* not XpmAllocCloseColors */ #endif /* ALLOC_XPM_COLORS */ -#ifdef ALLOC_XPM_COLORS - xpm_init_color_cache (f, attrs); -#endif /* If image specification contains symbolic color definitions, add @@ -4021,8 +4019,4 @@ /* Create a pixmap for the image, either from a file, or from a string buffer containing data in the same format as an XPM file. */ -#ifdef ALLOC_XPM_COLORS - xpm_init_color_cache (f, attrs); -#endif - specified_file = image_spec_value (img-spec, QCfile, NULL); ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: memory leak in xpm_load
On 6/6/07, YAMAMOTO Mitsuharu [EMAIL PROTECTED] wrote: I don't think I fully understand the code I don't, either. I said it seemed like a leftover because the second call was already in place when Chong installed his patch. but attr-numsymbols in xpm_init_color_cache becomes always 0 if the second call is removed. Is that right? I don't think so. Time to ask Chong :) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Would it not be easier if you get a normal backtrace if debug-on-error is t? Perhaps. OTOH, it is an error in an emacsclient-sent string to evaluate an Error *in* Emacs? Something like this can be used in server.el, server-process-filter: Can you please send it as a patch? Otherwise it's kind of difficult to see what's changing. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Why would emacsclient --eval BIG-MISTAKE cause a traceback on Emacs, even if debug-on-error is t? It already shows an error on the output of emacsclient. It is not much, just two or three new lines actually. Aha. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: - It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it could equally well be somewhere in the elisp libraries. Fair enough, though if you set debug-on-error to debug the problem, it will happen also if you evaluate the code from inside Emacs (as opposed to from emacsclient). - If you use -n you will see nothing as it is now. That's no reason, I think. If you're worried about errors, don't use -n. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Some errors are very hard to track down. I think it can help very much to be able to directly debug what happens when the call is from emacsclient. Perhaps you're right, but I'd like to see some examples of things that are much easier to debug from --eval than directly. It might not be the right thing to do in all cases. No. But if it is normal operation for your emacsclient invocation to fail sometimes, it'd be sensible to *not* use -n and read emacsclient's stderr output and exit code; and if it is not normal, the moment you detect a problem you can remove the -n and try again. This is not to say that I oppose the feature; I just don't feel it compelling right now (but I can be easily convinced :) BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? Not currently, no. It returns an error for any trouble communicating with Emacs, not because of what happens to the info exchanged between them. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? I'm not sure. On one hand, if there's no trouble, there's no need to complicate things. On the other, yeah, the context is slightly different, but do you really expect to have to debug much Emacs library code which fails in the context of emacsclient --eval? (I say Emacs library code because if the trouble is in the evaled string, the stderr message is already a good clue.) I am glad to read that ;-) Eh, so long as you're also ready to be easily convinced... Then could it not easily happen that the source of the problem is not detected? That depends of what you're doing with emacsclient -n --eval. I'd expect the user (or client program) to detect that nothing is happening :) Is not that an argument for beeing able to get a traceback the way I suggested? Perhaps. All this is in the purely hypothetical realm right now. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: The complication seems very minor as I see it. Sure. That's why real examples will easily win the day. Maybe the hardest thing is to convince me I am not easy to convince ... ;-) Hummm... I've thought past threads were a convincing example ;-) I looked at the problem just because Klaus Z was doing something in the background from emacsclient. I know. I was following the other thread too. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
On 4/27/07, Stefan Monnier [EMAIL PROTECTED] wrote: While I can imagine myself doing it, I don't remember taking anything from the version of your website. Did anybody else do that? Excluding lines by you, and removing trivial changes to comments and version numbers, the current python.el in HEAD contains the following changes: - 1.13 (2004-05-08), lektu (python-describe-symbol): Pass INTERACTIVE-P argument to `help-setup-xref'. - 1.17 (2004-07-02), RMS (python-beginning-of-statement): Exit the loop if backward-up-list gets error. - 1.21 (2004-11-25), RMS (python-font-lock-syntactic-keywords): Check for escapes in the regexp. (python-quote-syntax): Don't do it here. - 1.23 (2004-12-31), RMS (python-mode): Use mode-require-final-newline. - 1.28 (2005-4-26), RMS (python-mode): Use new name eldoc-documentation-function. - 1.34 (2005-10-18), Masatake YAMATO (python-complete-symbol): Pass the common prefix substring of completion to `display-completion-list'. - 1.49 (2006-9-16), RMS (python-preoutput-filter): Fix arg order to string-match. - 1.50 (2006-10-22), John Wiegley (python-use-skeletons): python-mode was auto-inserting templates (for those with abbrev-mode on), not only by default -- *but without a configuration variable to disable it*. This rendered python-mode completely useless for me, so I have added `python-use-skeletons', which is now off by default. - 1.52 (2006-10-04), RMS (python-indent): Add safe-local-variable prop. - 1.58 (2007-04-16), Chong Yidong (python-end-of-block): Avoid looping forever if python-next-statement fails. All of them are in the tiny category (ten lines or less, excluding whitespace changes), and none seem to be lifted from anywhere (though it is up to the individual authors to confirm, of course). However, 1.40 (2006-08-20) by you is extensive and the changelog says Update to Dave Love's latest version. Was this directly from him? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Then what arguments are actually convincing to you? At this point in time, just days short of the intented release? Either the bug crashes Emacs, or it does cause trouble for some really major package, or it is very common and/or confusing for many users. If you just want to say that you do not want that change to be made now that is also ok. Is not that I don't want, and what I want is largely irrelevant. Is that IMO you have not justified it enough in the urgency scale, release-wise. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: We are getting closer to a serious discussion, thanks. Because you're the arbiter of when a discussion is serious enough? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I do have an opinion about that. Disrespect is not one of the things I respect. Disrespect is often in the eye of the beholder. I certainly have no trouble detecting disrespect in some of your messages, but I'm sure you'll disagree. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I try to have respect for that more economic reasoning that you are using, but I often fail there. Economic reasoning is a good way to see it. Your defense of fixing the bug doesn't seem very convincing, on an (informal, I'm no economist) cost-benefit analysis :) And I often prefer to keep my own opinion even under strong pressure. It is unusual, but it is not out of disrespect. I was not offended, but saying to your opponent I suggested reading my arguments is not keep[ing your] own opinion, for example. I point it out merely to show that it is easy to cross the line without being aware. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: At least that is often a way forward in face-to-face communication. Though one have to say it with an querying voice. Couldn't help but remember this quote from the Subversion developers' list. Several guys were talking about the right way to pronounce Subversion, and one said: The difference in pronunciation is extremely subtle, and I applaud your effort in attempting this via email. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: If you read my messages carefully you will see why I do not think this is dangerous to fix the way I have suggested. That you don't think it is dangerous doesn't make it harmless or safe. Redisplay code is complex. People who knows that code inside and out routinely makes mistakes when changing it (as the bug you've found proves). Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I really did not say so of course. I suggested reading my arguments. I did. I've read this thread in full. I know nothing about the redisplay code (I've taken a few looks at it and that's all), but AFAIK you're not very knowledgeable about it either. OTOH, it seems that people who really knows it inside and out is unconvinced that changing it now is safe. Excuse me if I trust their opinion. Is not that a better level of discussion? I'd suggest as a better level of discussion if you presupposed that people who disagrees with your arguments *perhaps* does so for reasons other than not having read them... Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash with slime on WIN32
On 4/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Slime can be found at http://common-lisp.net/project/slime Which CL implementation are you using? Juanma ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
On 4/11/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote: Should Emacs users always turn off use of ClearType? No. ClearType improves readability, and the problems depend on the font used and perhaps other factors. In my setup, for example, ClearType is quite usable. If so, can Emacs do it automatically? ClearType cannot be deactivated for specific apps, but it can be for specific fonts, so we could fix it in w32_load_system_font. That'd be overkill IMO. If not, is this documented in PROBLEMS or somewhere suitable? The problem and workaround are documented in PROBLEMS. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
On 4/12/07, Jason Rumney [EMAIL PROTECTED] wrote: Yes it can. Cool. How? (I searched Microsoft's docs, but they are less than clear sometimes and I didn't find anything which seemed to imply app-specific settings of ClearType...) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
On 3/28/07, Stefan Monnier [EMAIL PROTECTED] wrote: To clear the misunderstanding, let me put it differently: font-lock-defaults-alist is still *obeyed* by the current code (which is why it's obsolete and not removed), but it is not *used* by the current code. Perhaps the trouble is that font-lock-mode's docstring doesn't stress its obsolete status: See the variable `font-lock-defaults-alist' for the Font Lock mode default settings. You can set your own default settings for some mode, by setting a buffer local value for `font-lock-defaults', via its mode hook. and neither does font-lock-set-defaults': Sets various variables using `font-lock-defaults' (or, if nil, using `font-lock-defaults-alist') and `font-lock-maximum-decoration'. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman [EMAIL PROTECTED] wrote: See the attached image. Completion is after o. (Which looks like c.) Do you have ClearType on? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Ehum, no. I thought there was no use in trying that Oh, of course, I asked about ClearType because it obviously had no relation whatsoever... :) So now I have some reasons having ClearType on and at least one having it off ;-| There are issues with ClearType; see for example this item from admin/FOR-RELEASE: ** Drew Adams 12 Aug bug rpt: overlay display artifact: trace left behind Windows only bug. Bug appears only when Cleartype enabled, probably related to the hack introduced on 2005-07-01 to fix some other Cleartype problem. In fact, your problem could be related to the original problem fixed by Jason's original patch of 2005-07-01. BTW, what font are you using in your tests? Or does it happen with any font? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I have seen some traces of background coloring remaining on the screen, but I wonder whether that is an overlay only thing. What do you mean with an overlay only thing? That only happens with overlays? The default. What is the default font? I have never tried changing font, actually. If you have any suggestions for testing then please point me to some quick recipe for changing fonts to. Try the dejavu fonts. They're quite nice. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I just read citation of the bug report you made: Yes, sorry. -outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1 I can see the problem with Courier New. It doesn't happen for me with DejaVu. Ok, I have downloaded and installed the Dejavu LGC TT fonts. But what do I do now? In Emacs on w32? What I do is to define a fontset in the registry (HKLM\Software\GNU\Emacs), i.e., an Emacs.Fontset-0 string value with -*-DejaVu Sans Mono-normal-r-normal-*-13-*-*-*-c-*-fontset-dejavu and Emacs.Font = fontset-dejavu Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
On 3/21/07, David Kastrup [EMAIL PROTECTED] wrote: Do you have an example for a Postscript file on your system that is neither identified by the magic string %!PS nor an appropriate extension? No. But I don't understand your question. I was agreeing with you (yeah, it happens sometimes). Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in documentation for buffer-display-table
On 3/18/07, Nikolaj Schumacher [EMAIL PROTECTED] wrote: However this is not true, as it needs to be something like: (aset buffer-display-table ?X (vector ?Y)) Fixed, thanks. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Changes to emacs/src/buffer.c,v
On 3/18/07, Kim F. Storm [EMAIL PROTECTED] wrote: Why (vector ?Y) instead of [?Y] ? It was suggested by a pretester and seemed clearer (or at least more explicit) but feel free to change it. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/14/07, Richard Stallman [EMAIL PROTECTED] wrote: Those facts do not present an argument for that conclusion. Well, my conclusion is that most people expects emacsclient to interrupt, and the fact is that everyone who has expressed an opinion in this thread seems (if I'm reading correctly) to support that idea. You excepted, of course. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/13/07, Richard Stallman [EMAIL PROTECTED] wrote: I don't think that an action from outside Emacs is comparable to one done by typing Emacs commands. It could be argued (and I would) that typing emacsclient myfile or clicking in a file associated to emacsclient is comparable to typing Emacs commands. The immediate response I expect from both of them is getting the Emacs frame on top (server-raise-frame defaults to t for a good reason) and ready to accept my input. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/13/07, Richard Stallman [EMAIL PROTECTED] wrote: I don't think that an action from outside Emacs is comparable to one done by typing Emacs commands. Also: the change to abort recursive edits is in CVS since 2006-11-27, so there's been four pretests in between, and not a single complain about emacsclient interrupting. On the contrary, this thread shows that some people *expects* it doing so. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/12/07, Stefan Monnier [EMAIL PROTECTED] wrote: Yes, we can add some ad-hoc isearch hack in server.el for it. It's kind of ugly, tho. No doubt. Having server.el forcefully exit from recursive edits and abort isearches is inellegant. The alternative is for someone who knows isearch, recursive edits and event handling in deep to investigate the issue and propose a better fix :) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/12/07, Stefan Monnier [EMAIL PROTECTED] wrote: So I think the forceful exit from recursive minibuffers is OK (it's generic) Elegant would be for packages and modes to have a way to tell server.el what to do. Forced exit is never going to be elegant IMO. YMMV. whereas the isearch part is a complete hack. From a cursory read of isearch.el, isearch itself is a hack (though very useful). The better fix is easy: implement concurrency in Emacs (at least the cooperating form of it). Yeah, well. The thing is, what do we do now wrt the isearch problem? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/11/07, Richard Stallman [EMAIL PROTECTED] wrote: Use of Emacsclient should not interfere with an isearch! Why not? Emacsclient usually interrupts what Emacs is doing (try doing sleep 5; emacsclient myfile.txt from a shell while you work on Emacs). Certainly, emacsclient terminating the isearch is the behavior I would expect (and so does the user who reported the bug...) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/11/07, Juanma Barranquero [EMAIL PROTECTED] wrote: The patch below seems to work This is a slightly better variant of the previous patch. Comments? Juanma Index: lisp/server.el === RCS file: /cvsroot/emacs/emacs/lisp/server.el,v retrieving revision 1.126 diff -u -2 -r1.126 server.el --- lisp/server.el 27 Jan 2007 19:03:43 - 1.126 +++ lisp/server.el 11 Mar 2007 23:28:07 - @@ -415,4 +415,14 @@ (lambda () (server-process-filter proc (top-level)) + (condition-case nil + ;; If we're running isearch, we must abort it to allow Emacs to + ;; display the buffer and switch to it. + (mapc #'(lambda (buffer) + (with-current-buffer buffer + (when (bound-and-true-p isearch-mode) + (isearch-cancel + (buffer-list)) +;; Signaled by isearch-cancel +(quit (message nil))) ;; If the input is multiple lines, ;; process each line individually. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/11/07, Stefan Monnier [EMAIL PROTECTED] wrote: I don't think we will be able to find a patch that can break out of isearch for Emacs-22 (it's probably going to be too big a change). But the fact that not only it doesn't break out of isearch, but additionally the buffer isn't displayed at all looks more serious. The patch below seems to work, but you know server.el better than I do, so perhaps you can see some downside to it. Juanma Index: lisp/server.el === RCS file: /cvsroot/emacs/emacs/lisp/server.el,v retrieving revision 1.126 diff -u -2 -r1.126 server.el --- lisp/server.el 27 Jan 2007 19:03:43 - 1.126 +++ lisp/server.el 11 Mar 2007 03:12:26 - @@ -405,4 +405,10 @@ (setq string (concat prev string)) (process-put proc :previous-string nil))) + (mapc #'(lambda (buffer) + (when (local-variable-p 'isearch-mode buffer) + (with-current-buffer buffer + (isearch-done) + (message nil + (buffer-list)) (when ( (recursion-depth) 0) ;; We're inside a minibuffer already, so if the emacs-client is trying ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
On 3/10/07, Kim F. Storm [EMAIL PROTECTED] wrote: Also, IMO for 22.1, we should only fix bugs which are regressions since 21.4. Any bug which was also present in 21.4 should wait for 22.2 or 23.1 I'd like to think you're talking about trivial bugs or bugs that cannot lead to data loss. A bug that crashes Emacs, or corrupts a buffer contents, or silently fails to write changes to disk, or some such, should be fixed right now even if it's been with us forever. (Not that I know of any such bug, of course.) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
On 2/19/07, Kim F. Storm [EMAIL PROTECTED] wrote: Can you -- and other W32 users -- please try out the latest CVS and tell me ASAP if there are still _severe_ problems with it. Hard to say what is a severe problem. With the sample file (scroll.txt): - Make the frame's height 30 lines. - Visit scroll.txt - Move point to eob. - Scroll up to bob. - Release the mouse button. - Scroll down. I can't get past line 46. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Richard Stallman [EMAIL PROTECTED] wrote: Who cares? This sort of argument is no reason not to install a simple change that will avoid problems. Nor was I implying that. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
On 2/19/07, Kim F. Storm [EMAIL PROTECTED] wrote: That's right, but still it is not worse than before. Aha. I didn't know, I always work without scroll bars. I don't see an easy fix for this, so let's leave it for after the release. Agreed. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Drew Adams [EMAIL PROTECTED] wrote: Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) In 1), the code is straightforward (a fact obscured in the e-mail because em dash got changed to hyphen-minus), and the comment clearly says what's happening, and even identifies *both* characters involved. In 2), \u2014 does not mean anything per se, so the user hasn't the foggiest idea why some random unicode char would be used instead of -. You'll need the same comment as before to clarify that (and, in fact, Stefan didn't remove the comment when changing the code). You can convince me that 2) will get less trouble than 1) for people with broken tools; but not that 2) is more legible. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/18/07, Drew Adams [EMAIL PROTECTED] wrote: [...] so I did not change my browser encoding - after all, this is code, which displays as plain text. That assumption is just wrong, and more and more with each passing day. elisp is not the only language where you can have source that contains non-ASCII chars (it is perfectly legal in Ada, for example, and Perl). Yes, I know you're arguing that buff-menu.el contains just one non-ASCII char and it would be friendlier to use an escape (It's me who added the comment line just above the one which is causing you so much grief.) Perhaps you're right. But you said yourself your fix wouldn't work for packages with lots of Unicode chars. Where do you intend to put the line? At ten chars? A thousand? And how do you propose to inform the user, used to code which displays as plain text, that suddenly this other code isn't downloadable with broken tools anymore? I don't care about buff-menu.el, and won't argue for or against changing one character; but the fix for the problem you're struggling with is educating the users, and pointing them to non-broken tools. Obviously, we can't (nor should) force anyone to change their ways; but I don't see why should we make extraordinary efforts to suit them, either. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Drew Adams [EMAIL PROTECTED] wrote: I don't intend to establish a line. Judgement is needed, perhaps case by case. That still doesn't help the user who doesn't know what your decision was. What I said, in an earlier mail, was this: I know. I've said that I know what you were arguing for. Good question, and one that I raised in response to Eli's mail. Excuse me for not reading the threads in the order that would be more convenient to you ;-) Maybe we should say explicitly that all code should be downloaded using a Unicode encoding - I don't know. I'm not sure *we* should do it, in the sense that people who downloads code from their browser is bound to learn sooner or later that it is a bad idea to ignore encodings. We will have to live with it, until the world (including Emacs ;-)) is Unicode through and through. Not doing anything is a way to live wit it. Making it easier for the user to continue to ignore the issue is not helpful, long term. Our best recourse, at least in this transitional period, is to be aware of the potential gotchas and use our best judgement to help users avoid problems. That's all; I don't have a better suggestion than that. Maybe someone else does. I agree. I just don't think the problem of people downloading a wrong copy of buff-menu.el is really pressing. I'd say most people gets Emacs in full, either from a source tarball, a binary package or CVS. No, the fix for the problem that I reported is to use an escape sequence in buff-menu.el. I was referring, obviously, to the general problem, not the specific buff-menu.el issue. You say that you weren't talking about the general problem, so let's leave it at that. This sideline discussion (this problem that you are apparently struggling with, and that you think I am struggling with) Oh, I assure you that I'm not struggling with any Emacs problem right now, other than restlessly waiting for Emacs 22 to be released. We can at least do what we can to prevent that problem from arising in no-brainer cases such as buff-menu.el. No comment, as I already said I don't mind this specific case. It's just common sense. And replacing two em-dash characters with \u2014 is hardly making extraordinary efforts. No. Taking the time to discuss a change that should, in an ideal world, be unnecessary and even ill-advised, and also the time do think where to draw the line, is an extraordinary (beyond what is ordinary or usual, not highly unusual or exceptional or remarkable) effort. It does, however, sometimes seem to take extraordinary efforts to get the slightest suggestion across to change something, even something trivial, in the Emacs code. Your (everybody's) trivial is other people's bad idea, sometimes. As with all bug reports, it's up to you whether you want to consider this a bug and, if so, whether you want to fix it, and how. I bow to others in that collective you. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
On 2/9/07, Stefan Monnier [EMAIL PROTECTED] wrote: foo:bar is a special thingy under WinNT (or maybe under NTFS), kind of like a fork in MacOS speech. It seems it's called stream. NTFS. http://msdn2.microsoft.com/en-us/library/aa364404.aspx /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: write-region is mishandling an error
On 2/9/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, please. We have been discussing this before. Yes, and I think we decided that doing nothing was the best course of action. I still agree. There's nothing wrong with streams. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
On 1/26/07, Richard Stallman [EMAIL PROTECTED] wrote: Let's not go around in circles. We've already seen why this can't be fixed in a natural way. Yes, sorry. I missed the start of the thread. BTW, I think the comments in jka-compr.el and some doctrings (notoriously those of `jka-compr-shell' and `ja-compr-compression-info-list') do lie about the use of a shell and the following patch should be applied. /L/e/k/t/u Index: lisp/jka-cmpr-hook.el === RCS file: /cvsroot/emacs/emacs/lisp/jka-cmpr-hook.el,v retrieving revision 1.14 diff -c -r1.14 jka-cmpr-hook.el *** lisp/jka-cmpr-hook.el 21 Jan 2007 03:53:11 - 1.14 --- lisp/jka-cmpr-hook.el 26 Jan 2007 12:13:47 - *** *** 248,257 file-magic-chars is a string of characters that you would find at the beginning of a file compressed in this way. - Because of the way `call-process' is defined, discarding the stderr output of - a program adds the overhead of starting a shell each time the program is - invoked. - If you set this outside Custom while Auto Compression mode is already enabled \(as it is by default), you have to call `jka-compr-update' after setting it to properly update other --- 248,253 Index: lisp/jka-compr.el === RCS file: /cvsroot/emacs/emacs/lisp/jka-compr.el,v retrieving revision 1.92 diff -c -r1.92 jka-compr.el *** lisp/jka-compr.el 21 Jan 2007 03:53:11 - 1.92 --- lisp/jka-compr.el 26 Jan 2007 12:15:06 - *** *** 47,64 ;; The default value of this variable allows jka-compr to work with ;; Unix compress and gzip. ;; - ;; If you are concerned about the stderr output of gzip and other - ;; compression/decompression programs showing up in your buffers, you - ;; should set the discard-error flag in the compression-info-list. - ;; This will cause the stderr of all programs to be discarded. - ;; However, it also causes emacs to call compression/uncompression - ;; programs through a shell (which is specified by jka-compr-shell). - ;; This may be a drag if, on your system, starting up a shell is - ;; slow. - ;; ;; If you don't want messages about compressing and decompressing ! ;; to show up in the echo area, you can set the compress-name and ! ;; decompress-name fields of the jka-compr-compression-info-list to ;; nil. --- 47,55 ;; The default value of this variable allows jka-compr to work with ;; Unix compress and gzip. ;; ;; If you don't want messages about compressing and decompressing ! ;; to show up in the echo area, you can set the compress-msg and ! ;; decompress-msg fields of the jka-compr-compression-info-list to ;; nil. *** *** 105,113 (defcustom jka-compr-shell sh *Shell to be used for calling compression programs. ! The value of this variable only matters if you want to discard the ! stderr of a compression/decompression program (see the documentation ! for `jka-compr-compression-info-list'). :type 'string :group 'jka-compr) --- 96,102 (defcustom jka-compr-shell sh *Shell to be used for calling compression programs. ! NOTE: Not used in MS-DOS and Windows systems. :type 'string :group 'jka-compr) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
On 1/25/07, Richard Stallman [EMAIL PROTECTED] wrote: To see jka-compr failing, evaluate this: (let ((default-directory /a/b/c)) (insert-file-contents /usr/share/man/man1/ls.1.gz)) Can someone please fix jka-compr? It's at a lower level than jka-compr: (let ((default-directory a/b/c)) (call-process gzip c:/emacs/otros/quack.el.gz t nil -d)) = *** Eval error *** Setting current directory: no such file or directory, a/b/c /L/e/k/t/u ___ 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?
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Looks like I am waisting time by not beeing clear enough, but since I am rather sure that you understand what I mean I do not express things that explicit. I was originally answering to this: 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. which is a yes/no question, and wondering why, and then you started talking about relative time consumption. So it seems like the problem (for me) is that you mean different things at different point of the conversation. Is hard to track. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: typo in hexl.el
On 1/22/07, Chris Moore [EMAIL PROTECTED] wrote: I sent this 11 days ago, but it appears not to have reached the list. Committed, thanks. /L/e/k/t/u ___ 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?
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: 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. (progn (defvar my-sym t) (put 'my-sym 'my-prop t) (let (my-sym) (message symbol: %S -- property: %S my-sym (get 'my-sym 'my-prop = symbol: nil -- property: t If `let' interned a new symbol in another obarray, the above would answer: symbol: nil -- property: nil. That would be very surprising. A function call at arbitrary deep doesn't usually care whether a symbol it's using was let-bound or not, only its value and other properties. `let' is not advertised as binding anything other than a symbol's value... /L/e/k/t/u ___ 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?
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Thanks, but I did not mean on this level. On this level I would expect it to be transparent to the user/programmer. Please, explain that. /L/e/k/t/u ___ 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?
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Then perhaps it would make sense to have a small obarray for let variables. You've said that you would expect my example to be transparent to the user/programmer. For that to be true, anything that uses a symbol should have to search first in your special let-obarray and then in the general one. Hard to see an advantage there. /L/e/k/t/u ___ 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?
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, but it depends on the relative time consumption for insert and search in obarrays. More like on the relative number of symbol searches vs. symbol creations. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: emacsclient -a runemacs Tablet Buttons.txt emacsclient: connect: No error I don't see that. runemacs.exe is run normally. Are you using a CVS Emacs, or Lennart's prebuilt binary? (I ask because Lennart's contains quite a few changes in emacsclient.exe.) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: This did not happen with emacsclient 22.0.91 (with the patch to handle quoting of filenames in MS Windows). The only recent patch to emacsclient affecting the running of the alternate editor is the one you mention (quoting arguments with embedded spaces in Windows). The few patches after that are related to passing focus to Emacs after connecting with it, which never happens if the alternate editor is called. If you're using the stock Emacs from CVS, could you please try to determine exactly what change to emacsclient started the behavior you're seeing? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: replace.el documentation typo
On 1/7/07, Chris Moore [EMAIL PROTECTED] wrote: -whole match, `\\N' a partial matches, `\\#' and `\\#N' the +whole match, `\\N' a partial match, `\\#' and `\\#N' the Committed, thanks. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I think Juanma wanted to ask whether you used an unpatched or a patched version. Yes, sorry. (But as you said yourself, most people that downloads from your site gets the patched version, so I think the mistake is understandable :) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: That appears to be the latest pretest release, although it was dated about 20th December, as I recall. So maybe this problem is fixed in the latest version. I'll see if the CVS version works better. Thanks. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: Just for the record, the patch I was referring to was the one you sent me before Christmas in response to my previous emacsclient bug report. Aha. Sorry about that! I'll have to investigate further. OK, thanks for taking the time to determine what's wrong. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: inconsistent childish MS bashing
On 1/5/07, Miles Bader [EMAIL PROTECTED] wrote:
Or on the other hand, we could just relax and think about something
important, like the latest cricket scores in Botswana.
True.
But FWIW, I also dislike the childish MS-DOG moniker every time I
stumble upon it in Emacs.
/L/e/k/t/u
P.S.: Don't you agree this reflects badly upon us?
C:\bin\emacs\HEAD\man\emacs-xtra.texi
* MS-DOS:: Using Emacs on MS-DOS (otherwise known as @dfn{MS-DOG}).
C:\bin\emacs\HEAD\man\emacs.texi
MS-DOS (also called MS-DOG), Microsoft Windows, and Macintosh systems.
C:\bin\emacs\HEAD\man\msdog-xtra.texi
@cindex MS-DOG
the MS-DOS ``operating system'' (also known as ``MS-DOG'').
C:\bin\emacs\HEAD\man\msdog.texi
older MS-DOS ``operating system'' (also known as ``MS-DOG'').
* MS-DOS:: Using Emacs on MS-DOS (otherwise known as @dfn{MS-DOG}).
C:\bin\emacs\HEAD\etc\NEWS.19
** Emacs 19.23 can run on MS-DOG. See the file MSDOS in the same
C:\bin\emacs\HEAD\etc\PROBLEMS
*** MS-DOS+DJGPP: Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs.
C:\bin\emacs\HEAD\src\buffer.c
This variable is meaningful on MS-DOG and Windows NT.
C:\bin\emacs\HEAD\lisp\arc-mode.el
;; not tested this under Ms-Dog myself.
C:\bin\emacs\HEAD\lisp\finder.el
;; MS-DOG-type filenames.
C:\bin\emacs\HEAD\lisp\frame.el
;; MS-DOG frames support selections when Emacs runs inside
C:\bin\emacs\HEAD\lisp\subr.el
This variable is meaningful on MS-DOG and Windows NT.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tutorial: typo
On 1/3/07, Chris Moore [EMAIL PROTECTED] wrote: - (insert \n\nWith you current key bindings + (insert \n\nWith your current key bindings Thanks, fixed. BTW, I added a ChangeLog entry with a different e-mail address (the one used in other entries). I suppose you're the same Chris Moore...? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
On 12/31/06, Lennart Borgman [EMAIL PROTECTED] wrote: Would it perhaps be better to have default t on systems where file name case does not matter? You should've read the docstring... (defcustom auto-mode-case-fold nil Non-nil means to try second pass through `auto-mode-alist'. This means that if the first case-sensitive search through the alist fails to find a matching major mode, a second case-insensitive search is made. On systems with case-insensitive file names, this variable is ignored, since only a single case-insensitive search through the alist is made. :group 'files :version 22.1 :type 'boolean) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
On 12/29/06, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: It would be very good if we continued this discussion. And if no agreement can be reached, will you add another patch to your binary Emacs distribution and make it still more divergent, or will you accept that perhaps it is better to leave it as it stands now? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
On 12/29/06, Lennart Borgman [EMAIL PROTECTED] wrote: I have already said I agreed. Yes. My mind was wandering around, lost in the concept of awfulness, and I got carried away. Sorry. I have no intention of making my Emacs binary distribution be different from Emacs default if I can avoid it. Of course. But your threshold for deciding that it cannot be avoided doesn't seem hard to reach. The purpose of my binary distribution was (as I several times has said) to make it more easy to get Emacs up and running on w32. I was surprised that it was so difficult and time consuming. Compiling Emacs on Windows can be time-consuming. Setting it up is not IMHO. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
On 12/29/06, Richard Stallman [EMAIL PROTECTED] wrote: This change is ok. OK, I've installed it. Kim, you talked about auto-detecting only JPEG image files. If you think it is better to do that right now (I really don't have an opinion), just set the values of the other image types to nil in `image-type-auto-detectable'. Better names or docstrings for `image-type-auto-detectable' and `image-type-auto-detected-p' very welcome. And BTW, I still think Stefan's patch should be committed. No good arguments for preferring fundamental-mode for .PY, .SH, etc. have been exposed. Yeah, yeah, I know, that discussion is settled, etc. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
On 12/28/06, Kim F. Storm [EMAIL PROTECTED] wrote: Sure, but if we had just added Stefan patch now, the rest of the patches would not have been needed before the release. Yes, of course. (BTW, I'm not particularly interested in this stuff, or in getting it in, just trying to be helpful.) Correct, but we have not had reports of bad effects of the simpler regexp. Right. Ok. So we could detect _just_ JPEG via magic-mode-alist, supposing that format is sufficiently different from anything else. Well, I don't really know whether it is common to find other image files with no descriptive file extension. Agree ... for a _very limited set_ of image types, which cannot always be detected by their file suffixes... I don't necessarily disagree... but I'm not sure either than doing such a specific fix is better than going the generic route (which is dead easy, as shown in the patch I just sent). I'm ready to be convinced otherwise, though. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
On 12/28/06, Kim F. Storm [EMAIL PROTECTED] wrote: Sure, but if we had just added Stefan patch now, the rest of the patches would not have been needed before the release. BTW, wasn't the approach in Stefan's patch more-or-less vetoed by Richard (even if most of us find this fix good and non-intrusive)? Or am I mixing things? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
On 12/27/06, Kim F. Storm [EMAIL PROTECTED] wrote: In contrast, the recognize images by file contents approach has already required three rounds of bug-fixing ... and there's no guarantee that there are not more surprises... Well, I think that's not entirely fair. Patches for that approach have conflated several different things: - The possibility of adding matcher functions to `magic-mode-alist'. That's good IMO. - Fixes to regexps in `image-type-header-regexps'. These are good too. ^P[1-6] matching PBM files would be over-eager even if `image-type-from-buffer' were not added to `magic-mode-alist'. - Adding `image-type-from-buffer' to `magic-mode-alist'. That's not good because there is one type of file (postscript) whose interpretation is ambiguous under that function. The right approach would be to add to `magic-mode-alist' a function specifically designed to detect images; it should also take into account `image-type-available-p' (it never makes sense to identify a .ps file as an image on Windows, for example, as the Windows port does not support postscript images). - Modifying `image-type-header-regexps' to support NOT-ALWAYS. Not good IMO because it adds interface complexity just to fix one case. I strongly support installing this, _and_ reverting the recent image-mode related patches which would no longer be needed with this patch. Not entirely true. Someone noted that he wanted Emacs to autodetect JPEG thumb files that had no recognizable extension, for example. That's not fixed by Stefan's patch (which I think is good, BTW). I think a good approach would be to add Stefan patch, remove the NOT-ALWAYS stuff and fix `magic-mode-alist' to use a function specifically designed to detect image types. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
On 12/22/06, Eli Zaretskii [EMAIL PROTECTED] wrote: What are the manifestations of your use of English on this pc? If, as you say, ``keyboard, numbers, currencies, times, time zone and dates are Swedish'', then what aspects of the UI are English? Perhaps the UI, I mean: system messages, menus, etc. I know I've used quite a few times US releases of Windows so my whole interface was English, but the regional settings (keyboard, numbers, times, etc.) were set to Spain / Castillian Spanish. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
First program: SYS: 0xc0a, USR: 0xc0a Second program: LangID = SYS: 0xc0a, USR: 0xc0a LCID = SYS: 0xc0a, USR: 0xc0a GetUserDefaultUILanguage() = 0C0A GetSystemDefaultUILanguage = 0C0A Setup: Regional Options: Standard and formats: Spanish (Spain) Location: Spain Languages: Details: Settings: Default input language: Spanish (international sort) - Spanish Advaced tab: Second checkbox checked. Advanced: Language for non-Unicode programs: Spanish - Spain /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adieu *scratch*
On 12/20/06, Dieter Wilhelm [EMAIL PROTECTED] wrote: It seems that *scratch* is not necessary any longer (in 22) but I wish there were a command for re-creating it I use a variant of the following in my .emacs: (defun switch-to-scratch () (interactive) (let ((exists (get-buffer *scratch*))) (switch-to-buffer *scratch*) (unless exists (unless (eq major-mode initial-major-mode) (funcall (or initial-major-mode 'lisp-interaction-mode))) (setq buffer-offer-save t or at least a mechanism not to kill it incidentally. I use Noah Friedman's protbuf.el (http://www.emacswiki.org/cgi-bin/wiki/ProtectingBuffers), and I even have an advice around bs-delete so if I delete .emacs.el from inside bs-show it is automatically recreated. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adieu *scratch*
On 12/20/06, Romain Francoise [EMAIL PROTECTED] wrote: Is there any reason why you don't use the built-in package? Because they don't do the same thing. - emacs-lock.el prevents you from exiting Emacs if a buffer is locked - protbuf.el protect buffers from accidental killing The killing I'm protecting buffers against is not exiting Emacs, but being C-x k trigger happy (or d happy in bs-show). /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adieu *scratch*
On 12/20/06, Romain Francoise [EMAIL PROTECTED] wrote: Try it, emacs-lock.el does that... I'll certainly try it, I prefer to use standard packages. But the documentation is misleading. Not even the docstring of `emacs-lock-check-buffer-lock' discusses protecting against killing the buffer. And, shouldn't it use `kill-buffer-query-functions' and `message' instead of `kill-buffer-hook' and `error'? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
On 12/20/06, Lennart Borgman [EMAIL PROTECTED] wrote: Yes, and I was not here then. Now instead I am arguing for correcting the bugs. No. You're arguing for correcting the bugs (don't we all?) and you're *also* distributing an alternate version of Emacs. They're separate actions with no causal relation. Distributing your own build has certain dangers; tiny at this point, I concede, but dangers nonetheless. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
On 12/20/06, Lennart Borgman [EMAIL PROTECTED] wrote: I guess you mean logical relation? Causal. Arguing for bug fixes does not cause you having to do an alternate distribution. So the fact that you argue for bugs has no bearing on whether you do an alternate distribution or not. I do argue for bug fixes. I don't have my own distribution. At the moment I think the benefits outweighs the problem, but if some of the more nagging bugs/missing features were corrected I think I would change my mind. Your distribution gets notoriety as a better way to use Emacs on Windows, i.e., it's better for an Emacs user on Windows to use yours than the standard one. If you someday change your mind, there's nothing stopping someone from deciding that he will continue maintaining the improved for Windows version. I'm not saying it is going to happen. I'm not ever saying it is likely to happen. But it is not difficult to happen. Some projects never fork; others... well, look at GNU Arch / Baz / Bazaar / ArX. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
On 12/20/06, Lennart Borgman [EMAIL PROTECTED] wrote: Maybe. I actually started my distribution because it was so damned difficult to get Emacs into a working condition on w32. I'm sure my usage pattern is very different from yours (I never print from inside Emacs, for example), but I don't have any trouble getting Emacs into a working condition on w32. There are some rough edges. Which Is Not The Same Thing :) My thoughts at the beginning was that no one has time to set this up any more. What a pitty, that makes it much harder for those developers/web developers wanting to go from w32 to GNU/Linux later. There are not many Windows developers for Emacs, so resources are scarce. That does not mean they don't care. You have a point there of course. I do not wish this. However it would be much easier if my patches were a bit more seriously considered. I've always tried to take your patches seriously; I'm sure I'm not the only one. As I have tried to explain many times I hardly ever consider them as final patches. I want comments on them but not dismissing. If they're not final, and we are in pretest (or we were approaching pretest) its harder to give them the attention they need. It will be easier to reconsider them after 22.1, IMHO. I always have a problem I want to solve with them (and it is hardly only for myself). I have not heard many people complaining that they cannot remap Win + R, for example. I looked once to your low-level code, and it seemed complicate for the small benefit it offers (IMHO again, of course). (I guess everyone agree, but it does not really feel that way always.) I think yes, many agree. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adieu *scratch*
On 12/20/06, Romain Francoise [EMAIL PROTECTED] wrote: emacs-lock.el seems like a poor man's protbuf.el. Some shortcomings (most, but not all, fixed in protbuf.el): - Locking a buffer should be a minor mode. - There's no emacs-lock entry in minor-mode-alist, so there's no visual clue in the modeline that a buffer is locked. - You cannot make it be silent; trying the locked action always triggers an error. - It uses heuristics for shell and telnet buffers, instead of having a specific mode for process buffers. - It uses kill-emacs-hook when kill-emacs-query-functions would be more logical (and presumably more efficient). - It has two conceptual flags: don't kill buffer, and don't exit Emacs, but conflated in a single interface. - It's documentation is so-so. /L/e/k/t/u ___ 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
On 12/19/06, Kim F. Storm [EMAIL PROTECTED] wrote: Installed. Great. BTW, as `magic-mode-alist' takes precedence over `auto-mode-alist', perhaps we should make some of the regexps in `image-type-header-regexp' somewhat less trigger-happy. I'm thinking mostly of the one for pbm, which matches any file that starts with P[1-6]. I propose the following patch (which also modifies the regexp for PNG to use the full PNG header, according to spec). /L/e/k/t/u Index: lisp/image.el === RCS file: /cvsroot/emacs/emacs/lisp/image.el,v retrieving revision 1.63 diff -u -2 -r1.63 image.el --- lisp/image.el 21 Apr 2006 20:56:06 - 1.63 +++ lisp/image.el 19 Dec 2006 10:40:53 - @@ -36,9 +36,9 @@ (defconst image-type-header-regexps '((\\`/[\t\n\r ]*\\*.*XPM.\\*/ . xpm) -(\\`P[1-6] . pbm) +(\\`P[1-6][[:space:]]+\\(?:#.*[[:space:]]+\\)*[0-9]+[[:space:]]+[0-9]+ . pbm) (\\`GIF8 . gif) -(\\`\211PNG\r\n . png) +(\\`\x89PNG\r\n\x1a\n . png) (\\`[\t\n\r ]*#define . xbm) -(\\`\\(MM\0\\*\\|II\\*\0\\) . tiff) +(\\`\\(?:MM\0\\*\\|II\\*\0\\) . tiff) (\\`[\t\n\r ]*%!PS . postscript) (\\`\xff\xd8 . (image-jpeg-p . jpeg))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CVS Emacs fails to remove server.el socket on exit
On 12/18/06, Trent Buck [EMAIL PROTECTED] wrote: I believe CVS Emacs is not correctly removing the socket file created by server-start (from server.el). It is on purpose. Note the following fragment from server.el: ;; Delete the associated connection file, if applicable. ;; This is actually problematic: the file may have been overwritten by ;; another Emacs server in the mean time, so it's not ours any more. ;; (and (process-contact proc :server) ;; (eq (process-status proc) 'closed) ;; (ignore-errors (delete-file (process-get proc :server-file /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Build problem with temacs
On 12/18/06, Eli Zaretskii [EMAIL PROTECTED] wrote: Same here, but I never saw such a problem. Strange... Neither did I, on XP Home nor XP Pro, both with administrator permissions. /L/e/k/t/u ___ 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
On 12/18/06, Richard Stallman [EMAIL PROTECTED] wrote: Remember that I transfer mail in batches. I know. That's why I didn't install anything ;) I think his method is fine too. Cool. /L/e/k/t/u ___ 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
On 12/17/06, Richard Stallman [EMAIL PROTECTED] wrote: That is smart. Please install it. I can install it, if you don't want to install Kim's change instead right now. But I think his is the way to go. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: try-completion crashes on non-obarray vector
On 12/16/06, Johan Bockgård [EMAIL PROTECTED] wrote: This still crashes: (try-completion [1]) You're right. I've fixed it by checking that buckets are symbols. However, it's still possible that a bad-formed pseudo-obarray like the one above could crash Emacs. /L/e/k/t/u ___ 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
On 12/17/06, Kim F. Storm [EMAIL PROTECTED] wrote: Another way is the following one which does exactly the same as your patch, but in a more generic way: That is what I proposed on http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00395.html so obviously I agree it's a good answer ;-) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacsclient/server filename quoting error
On 12/10/06, Francis Wright [EMAIL PROTECTED] wrote:
I execute all the following commands from a cmd command
prompt (outside of Emacs).
emacsclient -n -a runemacs TO DO.txt
works correctly if Emacs IS already running, but if it is not
already running then Emacs does not see the filename correctly;
the quotes do not appear to be passed on to runemacs.
The following patch addresses the issue by allocating quoted copies of
any argument containing spaces before calling execvp.
Any objections to install this fix? As it stands, it affects also
non-Windows builds. Is requoting args the right behavior in these
environments?
/L/e/k/t/u
Index: lib-src/emacsclient.c
===
RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.98
diff -u -2 -r1.98 emacsclient.c
--- lib-src/emacsclient.c 30 Nov 2006 22:49:38 - 1.98
+++ lib-src/emacsclient.c 15 Dec 2006 10:19:44 -
@@ -310,8 +310,20 @@
if (alternate_editor)
{
- int i = optind - 1;
+ int j, i = optind - 1;
+
#ifdef WINDOWSNT
- argv[i] = (char *)alternate_editor;
+ argv[i] = (char *) alternate_editor;
#endif
+
+ /* Arguments with spaces have been dequoted, so we
+have to requote them before calling execvp. */
+ for (j = i; argv[j]; j++)
+ if (strchr (argv[j], ' '))
+ {
+ char *quoted = alloca (strlen (argv[j]) + 3);
+ sprintf (quoted, \%s\, argv[j]);
+ argv[j] = quoted;
+ }
+
execvp (alternate_editor, argv + i);
message (TRUE, %s: error executing alternate editor \%s\\n,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacsclient/server filename quoting error
On 12/15/06, Eli Zaretskii [EMAIL PROTECTED] wrote:
Actually, a cleaner way of fixing this would be to have a
WINDOWSNT-only wrapper for execvp, called, say w32_execvp, that does
TRT with quoting the arguments.
You like this one better, then?
/L/e/k/t/u
Index: lib-src/emacsclient.c
===
RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.98
diff -u -2 -r1.98 emacsclient.c
--- lib-src/emacsclient.c 30 Nov 2006 22:49:38 - 1.98
+++ lib-src/emacsclient.c 15 Dec 2006 11:49:57 -
@@ -299,4 +299,35 @@
+#ifdef WINDOWSNT
+
+/*
+ execvp() wrapper for Windows.
+ Quotes arguments with embedded spaces.
+*/
+int
+w32_execvp (path, argv)
+ char *path;
+ char **argv;
+{
+ int i;
+
+ argv[0] = (char *) alternate_editor;
+
+ for (i = 0; argv[i]; i++)
+if (strchr (argv[i], ' '))
+ {
+ char *quoted = alloca (strlen (argv[i]) + 3);
+ sprintf (quoted, \%s\, argv[i]);
+ argv[i] = quoted;
+ }
+
+ return execvp (path, argv);
+}
+
+#undef execvp
+#define execvp w32_execvp
+
+#endif /* WINDOWSNT */
+
/*
Try to run a different command, or --if no alternate editor is
@@ -311,7 +342,5 @@
{
int i = optind - 1;
-#ifdef WINDOWSNT
- argv[i] = (char *)alternate_editor;
-#endif
+
execvp (alternate_editor, argv + i);
message (TRUE, %s: error executing alternate editor \%s\\n,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacsclient/server filename quoting error
On 12/15/06, Werner LEMBERG [EMAIL PROTECTED] wrote: Since those issues are full of subtleties I suggest that you have a look at the gnulib CVS (at savannah.gnu.org), inspecting the files `execute.c' and `pipe.c': Thanks, but I think I'll wait for people to test the current implementation. I don't think Windows users will have very sophisticate or uncommon alternate editor setups and if they do, they must be prepared for the possibility of it not working ;) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacsclient/server filename quoting error
On 12/15/06, Eli Zaretskii [EMAIL PROTECTED] wrote: However, please mention the Windows bug with execvp in the comment to w32_execvp I've shamelessly stolen your comment from a previous message. Thanks, /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: try-completion crashes on non-obarray vector
On 12/8/06, Johan Bockgård [EMAIL PROTECTED] wrote: (try-completion []) = Program received signal SIGSEGV, Segmentation fault. 0x004d7e67 in Ftry_completion (string=10456851, alist=9781604, predicate=9337233) at minibuf.c:1315 1315 if (XSYMBOL (bucket)-next) Fixed. Thanks, /L/e/k/t/u ___ 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
On 12/14/06, Richard Stallman [EMAIL PROTECTED] wrote: That seems like a valid reason. Would someone please install that change? It would be useful to recognize PNG and GIF as well this way. image.el already defines `image-type-header-regexps' and `image-type-from-buffer', so it seems wasteful to recreate that. It would be better IMHO to simply use `image-type-from-buffer' from `set-auto-mode'. Other than changes to docstrings and info files, the path is as simple as this, and works quite well. /L/e/k/t/u Index: lisp/files.el === RCS file: /cvsroot/emacs/emacs/lisp/files.el,v retrieving revision 1.868 diff -c -r1.868 files.el *** lisp/files.el 11 Dec 2006 04:40:41 - 1.868 --- lisp/files.el 16 Dec 2006 02:51:21 - *** *** ,2230 (narrow-to-region (point-min) (min (point-max) (+ (point-min) magic-mode-regexp-match-limit))) !(assoc-default nil magic-mode-alist ! (lambda (re dummy) ! (looking-at re)) (set-auto-mode-0 done keep-mode-if-same) ;; Compare the filename against the entries in auto-mode-alist. (if buffer-file-name --- ,2232 (narrow-to-region (point-min) (min (point-max) (+ (point-min) magic-mode-regexp-match-limit))) !(if (image-type-from-buffer) !'image-mode ! (assoc-default nil magic-mode-alist ! (lambda (re dummy) ! (looking-at re))) (set-auto-mode-0 done keep-mode-if-same) ;; Compare the filename against the entries in auto-mode-alist. (if buffer-file-name ___ 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
On 12/16/06, Juanma Barranquero [EMAIL PROTECTED] wrote: path is as simple as this, and works quite well. s/path/patch/ sleep /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: -fs hides part of Emacs window behind task bar on w32
On 12/12/06, Juanma Barranquero [EMAIL PROTECTED] wrote: Any objection then to this patch? It fixes the bug that, on Windows, emacs -Q -fs creates an initial frame partially hidden behind the taskbar. The patch does not take into account multiple monitors, because neither does the original code: it sets *top_pos = 0 and *left_pos = 0, and Windows virtual coordinate (0, 0) is always contained in the primary monitor. /L/e/k/t/u Index: src/frame.c === RCS file: /cvsroot/emacs/emacs/src/frame.c,v retrieving revision 1.335 diff -u -2 -r1.335 frame.c --- src/frame.c 10 Nov 2006 07:54:22 - 1.335 +++ src/frame.c 12 Dec 2006 17:32:17 - @@ -2614,4 +2614,9 @@ int newwidth = FRAME_COLS (f); int newheight = FRAME_LINES (f); +#ifdef HAVE_NTGUI + RECT work_area; + + SystemParametersInfo (SPI_GETWORKAREA, 0, work_area, 0); +#endif *top_pos = f-top_pos; @@ -2623,4 +2628,7 @@ ph = FRAME_X_DISPLAY_INFO (f)-height; +#ifdef HAVE_NTGUI + ph = min (ph, work_area.bottom - work_area.top); +#endif newheight = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, ph); ph = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, newheight) - f-y_pixels_diff; @@ -2634,4 +2642,7 @@ pw = FRAME_X_DISPLAY_INFO (f)-width; +#ifdef HAVE_NTGUI + pw = min (pw, work_area.right - work_area.left); +#endif newwidth = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, pw); pw = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, newwidth) - f-x_pixels_diff; ___ 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
On 12/13/06, Jason Rumney [EMAIL PROTECTED] wrote: The only problem with this method is that the actual regexp you need is more complex Yes, I downloaded the spec; I was just being sloppy in discussing it. I'm not sure I like adding that to `magic-mode-alist'; why not PNG, GIF, TIFF and other easily recognizable formats? image-jpeg-p has a much more relaxed check, basically ^\xFF\xD8\xFF[\xE0-\xEF]..+(JFIF|Exif), but with the search for JFIF|Exif limited based on the first two bytes of the ..+ portion - which indicate the length of the file header. Post-22.1, perhaps `magic-mode-alist' could be extended to also allow (MATCHER . FUNCTION) pairs (MATCHER being a predicate on the text of the current buffer, starting from the point) in addition to the current (REGEXP . FUNCTION). That would allow reusing `image-jpeg-p' (once suitable adapted). /L/e/k/t/u ___ 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
On 12/13/06, Chris Moore [EMAIL PROTECTED] wrote: Is there any kind of file where the case of the extension matters? .Z files are compressed with compress, while .z files are from pack or early versions of gzip. Years ago it wasn't uncommon to find .C and .H for C++ source files. /L/e/k/t/u ___ 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
On 12/13/06, Chris Moore [EMAIL PROTECTED] wrote: Juanma Barranquero [EMAIL PROTECTED] writes: That's a shame. It would have been an easy fix, rather than having to make all these special cases. Though I agree with you, that's a fix I wouldn't dare propose (note that I talked about `image-file-name-regexp', not `auto-mode-alist'). 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. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacsclient/server filename quoting error
On 12/10/06, Francis Wright [EMAIL PROTECTED] wrote: I execute all the following commands from a cmd command prompt (outside of Emacs). emacsclient -n -a runemacs TO DO.txt works correctly if Emacs IS already running, but if it is not already running then Emacs does not see the filename correctly; the quotes do not appear to be passed on to runemacs. Yeah. With an instrumented emacsclient: C:\emacs emacsclient -a c:\emacs\bin\runemacs.exe TO DO.txt 2: [c:\emacs\bin\runemacs.exe] 3: [TO DO.txt] So it would be necessary to re-quote args containing whitespaces before calling execvp(). Question is: is that the right behavior in non-Windows environments? (Quoting filenames with embedded spaces, I mean). /L/e/k/t/u ___ 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
On 12/12/06, Chris Moore [EMAIL PROTECTED] wrote: Opening these files with Emacs opens them in fundamental mode, not image mode, since Emacs only associates image-mode with .jpg and .jpeg files. `image-type-from-file-name' uses `string-match', which depends on the setting of `case-fold-search'. 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. /L/e/k/t/u Index: lisp/image.el === RCS file: /cvsroot/emacs/emacs/lisp/image.el,v retrieving revision 1.63 diff -u -2 -r1.63 image.el --- lisp/image.el 21 Apr 2006 20:56:06 - 1.63 +++ lisp/image.el 12 Dec 2006 10:59:47 - @@ -271,4 +271,5 @@ be determined. (let ((types image-type-file-name-regexps) + (case-fold-search t) type) (while types ___ 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
On 12/12/06, Miles Bader [EMAIL PROTECTED] wrote: 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... Ah. I wasn't aware, because on Windows machines, emacs TEST.JPEG opens it in image mode. If .JPG/.JPEG is frequent, perhaps we should add it to `auto-mode-alist', then. Or do this: (push '(^\xFF\xD8\xFF\xE0\x00\x10JFIF . image-mode) magic-mode-alist) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: -fs hides part of Emacs window behind task bar on w32
On 12/11/06, Lennart Borgman [EMAIL PROTECTED] wrote: When starting with emacs -Q -fs the lower part of Emacs may get hidden behind the MS Windows task bar. The following patch should fix that. /L/e/k/t/u Index: src/frame.c === RCS file: /cvsroot/emacs/emacs/src/frame.c,v retrieving revision 1.335 diff -u -2 -r1.335 frame.c --- src/frame.c 10 Nov 2006 07:54:22 - 1.335 +++ src/frame.c 12 Dec 2006 17:32:17 - @@ -2614,4 +2614,9 @@ int newwidth = FRAME_COLS (f); int newheight = FRAME_LINES (f); +#ifdef HAVE_NTGUI + RECT work_area; + + SystemParametersInfo (SPI_GETWORKAREA, 0, work_area, 0); +#endif *top_pos = f-top_pos; @@ -2623,4 +2628,7 @@ ph = FRAME_X_DISPLAY_INFO (f)-height; +#ifdef HAVE_NTGUI + ph = min (ph, work_area.bottom - work_area.top); +#endif newheight = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, ph); ph = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, newheight) - f-y_pixels_diff; @@ -2634,4 +2642,7 @@ pw = FRAME_X_DISPLAY_INFO (f)-width; +#ifdef HAVE_NTGUI + pw = min (pw, work_area.right - work_area.left); +#endif newwidth = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, pw); pw = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, newwidth) - f-x_pixels_diff; ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
On 12/11/06, Leo [EMAIL PROTECTED] wrote: ido-max-directory-size default to 3 and the number of files in /usr/bin/ on my system is 2067. Documentation: *Maximum size (in bytes) for directories to use ido completion. If you enter a directory with a size larger than this size, ido will not provide the normal completion. To show the completions, use C-a. Note the size (in bytes). /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
