Re: make `occur' use word at point as default
Hi Drew, "Drew Adams" writes: > I should have added that I doubt that such up and down cursor > motions are very useful in the minibuffer. I regularly edit multi-line text in the minibuffer when I use replace-string and eval-expression. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
Hi Alan, Alan Mackenzie writes: > What is a "paragraph" in Emacs? The info node that you quoted is (info "(emacs)Paragraphs") I think? It has this text (this is a rather old CVS version, so it may be different by now): [...] Blank lines and text-formatter command lines separate paragraphs and are not considered part of any paragraph. [...] [...] In major modes for programs, paragraphs begin and end only at blank lines. This makes the paragraph commands continue to be useful even though there are no paragraphs per se. [...] Technically the term "paragraph" is defined not by some global definition but by the individual modes via the variables that you have cited. So every mode can have it's own idea of what a paragraph is. E.g. the buffer that I'm currently writing in to compose this message, is in GNUS' "Message" mode. It tries to accomodate the marker that separates the headers from the message body and also attribution lines like the above "Alan Mackenzie writes:". benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Emacs and proxy on w32
Hi Lennart, Lennart Borgman writes: > But how do you get the name of the proxy server to use for a specif > URL then? You don't. That is unless you write your own script in ELisp. > Don't you have to find the ECMAscript and execute it? Javascript/ECMAscript is a feature of some browsers. It is *not* a feature of all those other programs that can otherwise do HTTP fine, and even a fair number of browsers don't have it. If you want to seriously support more than IE and Mozilla, Javascript proxy scripts are useless. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Carbon port: setting the creator code (patch)
Hi David, David Reitter writes: > I don't know if we need to check for UFS drives (works fine for me > on SMB mounts; [...] UFS works the same as SMB. > I don't know how to check for that - maybe you can add that. You can use "Disk Utility" to create a disk image, repartition the image to change the filesystem to UFS and test on that image. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Editing exportet registry files
Hi Gaëtan, > Benjamin Riefenstahl wrote on 07 Jul 2005 20:56:42 +0200: >>(prefer-coding-system 'utf-16le-with-signature) >>(prefer-coding-system 'latin-9) Gaëtan LEURENT writes: > That would try latin-9 first, and if the file is valid as latin-9 > (which is quite likely), it will fail. [...] I thought it would not detect a UTF-16 file as Latin-9 because of all the NUL characters you get when you try to interpret UTF-16 as an 8-bit encoding. I just did a test and sadly, detection of Latin-9 seems to like those NUL characters fine, even though nobody would ever write such a file. Pity. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Editing exportet registry files
Hi Juanma, Juanma Barranquero writes: > Basically I want to use latin-9 for everything, but I want to be > able to do C-x C-f my-utf-16-file and get it decoded right. Have you tried to do something like this: (prefer-coding-system 'utf-16le-with-signature) (prefer-coding-system 'latin-9) I.e. first put UTF-16 on the "priority list for automatic detection" and than override it again with Latin-9 for the defaults. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Problem with library images on Windows (again)
Hi Jason, Jason Rumney writes: > The version of TIFF headers I have uses extern "C" if compiling > under C++, so I doubt the library is using Pascal calling > conventions. Maybe Juanma's library is different than mine. 'extern "C"' doesn't mean what you think it means, at least not in most compilers. In theory 'extern ""' is the C++ equivalent of the propriatory '__cdecl', '__stdcall' and '__pascal' keywords known from the C compilers. But the exact behaviour of that C++ feature is implementation defined, especially for languages other than "C". In practice with MSC++ and GCC, '__stdcall' and 'extern "C"' are *both* needed (or at least it's highly recommended to use both) in C++ mode to actually get '__stdcall' calling conventions and name mangling. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: What about a seperate "HOME" environment variable under w32?
Hi Sun Yijiang, Sun Yijiang writes: > The %HOME% environment variable is used by many programs under w32, > so it's really a mess sometime. The HOME environment variable is used by almost every program with a Unix heritage. But it seems pretty clear to me what HOME is. It's the place where user-level configuration files are stored and on Unix it's also the place where the user can store his/her other personal files. Windows has other places for the latter purpose, but that is not relevant here, I think. > I suggest Emacs use a different HOME variable underw32, something > like %EMACS_HOME% or %EHOME%. You can achieve that effect with other means, like starting Emacs from a batch that sets HOME. Or let the ~/.emacs in your standard HOME jkust be a short stub that points to another file in some other directory like e.g. (setenv "HOME" "x:/some/other/directory") (load "~/.emacs) That way all subsequent references to HOME are redirected. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: copying to clipboard silently discards lines
Hi Kenichi Handa, Kenichi Handa writes: > I've just installed these fixes. Thanks. > but we must set 4 for XXX-with-signature. Really? I thought XXX-with-signature just adds 2 additional bytes, regardless how long the string is. That should be covered by "+ CONVERSION_BUFFER_EXTRA_ROOM" (== 256) in encoding_buffer_size() and similar extra space in other places. I may be missing something, of course. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: copying to clipboard silently discards lines
Hi Chong Yidong, "Chong Yidong" writes: > The bug is in the Lisp_Object QUNICODE, which specifies the > "utf-16le-dos" coding system used by `selection-coding-system'. QUINCODE is just a symbol, a unique string. It is used for looking up the actual coding-system. setup_coding_system() in src/coding.c does that lookup by filling in the struct coding_system. > When a coding_system is extracted from QUNICODE, the parameter > coding->spec.ccl.encoder.buf_magnification is 1. This causes a call to > encoding_buffer_size (in convert_to_handle_as_coded, w32select.c:247) to > return a buffer size that is too small for the encoded string. > > I'm guessing the magnification has to be set to 2, because `abc...' > gets encoded to `a\0b\0c\0...' (encoding_buffer_size multiplies this > again by 2, because of the CRLF issue.) That would indicate that the coding-system "utf-16le-dos" itself has a bug. The source code description comment for encoding_buffer_size() says Return maximum size (bytes) of a buffer enough for encoding SRC_BYTES of text to CODING. which matches its usage in w32select.c, I think. > Trouble is, I can't find where the `spec.ccl...', or indeed any of > the other parameters of QUNICODE are initialized. Grep is our friend ;-). The coding-system (and its CCL programs) is created in lisp/international/ccl.el using (define-ccl-program ...). The parameter BUFFER_MAGNIFICATION for that function is set as 1 there for the encoders (ccl-encode-mule-utf-16le, ccl-encode-mule-utf-16be, ccl-encode-mule-utf-16le-with-signature, ccl-encode-mule-utf-16be-with-signature), so that might well be the problem. Can you try and replace that 1 with 2 and see if your problem goes away? benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Unicode support for the MS Windows clipboard [new patch]
Hi Tak, Tak Ota writes: > I suppose Benjamin is too busy lately. Sorry about the delay. I got distracted by that thing they call "life". ;-( > I suspect there maybe some relationship between clipboard operation > and the memory leak but I don't have conclusive evidence. I did a systematic code review and couldn't find any problems. Than I tried to develop a test. My machine does freeze (more or less) during a loop of putting data onto the clipboard and retrieving it with a simple external tool, but only after some hours. I could not see relevant memory consumption when I let the loop just run for 100 or 1000 times. It's possible that some non-memory resource in the NT kernel is consumed. It's also possible that it's just hardware problems with my machine. Jason Rumney writes: > OK, I've checked it in. Thanks. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
