Re: Info pages opened with an incorrect coding system
I agree that it should be the default. Very well, I'll change that. but still produce the Local Variables section, because without 8-bit characters the result is a plain ASCII file. As you know, if the input uses 8-bit characters, the output will also use 8-bit characters, regardless of --enable-encoding. source was written well, I can't agree that it is bad to use literal characters instead of Texinfo commands. It makes for a far more readable source, among other things. IOW, I think the fact that the document specifies @documentencoding should be enough for makeinfo to obey; relying on an additional command-line switch is unreliable. I don't see that it's unreliable, although I could agree with "inconvenient". I don't recall all the details of why we created --enable-encoding all those years ago. At this point, it does seem more useful to make it the default, so that any document with @documentencoding gets the output in that encoding, as best we can manage. Wouldn't linking against libiconv solve all these with minimal fuss? Sure, hopefully libiconv would be helpful, but I highly doubt the "minimal fuss". I suspect it will mean essentially rewriting the entire program (not that that would be a bad thing, but ...), because it is changing the fundamental way in which characters are both read and written. If you want to delve into it, you're welcome to try. I rather doubt you have an excess of spare hacking time available either, though ... Karl ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no set button in Custom buffer
Katsumi Yamaoka <[EMAIL PROTECTED]> writes: > When I run `customize-option', I don't see the Set button in > the Custom buffer. Maybe this is caused by the recent changes > in cus-edit.el. It's been moved to the toolbar. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
feature? dired-do-background-shell-command
I've looked around on the net and see some at least partial support for a function `dired-do-background-shell-command', but I am suprised that this feature isn't currently part of Emacs. (If there is a way to run commands in the background from within dired, it isn't documented in the info file section "Shell Commands in Dired".) In GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-06-08 on deepblack Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr' '--with-x' '--with-x-toolkit=gtk'' 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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Help Minor modes in effect: shell-dirtrack-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: 1 view-mode: t Recent input: C-w C-x C-s M-< C-x C-x C-g M-< M-< ; ; SPC D o c u m e n t a t i o n ; : C-a ; C-e ; ; ; SPC C o d e : C-e ; ; SPC I SPC a m SPC o c c o n s i d e r i n g SPC a d d i n g SPC d i r e d - x w a s SPC C-y C-e SPC s o SPC I SPC c o u l d SPC d o SPC ; ; SPC d i r e d - b M-/ M-/ d o - b a / M-/ c M-/ ' ` C-e , SPC b u t SPC i t SPC d o e s n ' t ; ; SPC s e e m SPC t o SPC p r o v i d e SPC t h a t SPC c o m m a n d . C-h f C-g M-x a p r o p o s b a c k g r o u n d C-x 1 C-n C-n C-n M-< C-x b * a A p C-x C-x C-g C-x C-f C-h C-g C-h k ! C-x o C-SPC C-e M-w M-x b u g - g n e m a b u r e p o r Recent messages: Expansion found in '*grep*' Auto-saving...done Quit Mark set Quit Directory has changed on disk; type g to update Dired Type C-x 1 to remove help window. Mark activated Making completion list... [2 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
That is not a 100% solution for 100% of the problem, but it's a good compromise that works well in practice. You often advise others to shy away of purism and instead embrace practical compromises on the Right side of the 80-20 divide. Why not go with this advice in this case? Because the 20% that fails will tend to include all the general-purpose software that is used around the world. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RFE sql-mode sql-product variable
I have the following handy settings in my .emacs; they might usefully be included in Emacs. (put 'sql-product 'safe-local-variable 'symbolp) (eval-after-load "sql" '(define-key sql-mode-map (kbd "C-c C-z") (lambda () (interactive) (let ((f (intern-soft (concat "sql-" (symbol-name sql-product) (if (and f (commandp f)) (call-interactively f) (error (format "Can't connect to %s databases." sql-product))) Briefly, they allow you to put -*- sql-product: postgres -*- (for arbitrary values of "postgres") at the top of your foo.sql file, and sql-mode will use the appropriate dialect, and also allow you to type C-c C-z to start the appropriate listener. -- Trent Buck ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ido insists on trying to save ido.last
When I invoke Emacs with
sudo emacs
instead of
sudo -H emacs
Emacs runs with root priviledges, but $HOME is still set to /home/twb.
/home is an NFS partition with root_squash on, so emacs does not have
write permission to ~/.emacs.d/. When using ido, this results in an
emacs that cannot be closed with C-x C-c or kill-emacs:
Save file /home/twb/.emacs.d/ido.last? (y, n, !, ., q, C-r, d or C-h) n
Modified buffers exist; exit anyway? (yes or no) yes
File ido.last is write-protected; try to save anyway? (yes or no) no
Debugger entered--Lisp error: (error "Attempt to save to a file which you
aren't allowed to write")
signal(error ("Attempt to save to a file which you aren't allowed to
write"))
error("Attempt to save to a file which you aren't allowed to write")
basic-save-buffer-2()
basic-save-buffer-1()
basic-save-buffer()
save-buffer()
write-file("~/.emacs.d/ido.last" nil)
ido-save-history()
ido-kill-emacs-hook()
run-hooks(kill-emacs-hook)
kill-emacs()
save-buffers-kill-emacs(nil)
call-interactively(save-buffers-kill-emacs)
AFAICT there is no way to kill such an Emacs process short of kill -9
or terminating it's parent tty. Even doing M-x ido mode RET to turn
it off didn't seem to help.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
> Date: Sun, 8 Jul 2007 17:56:12 -0500 > From: [EMAIL PROTECTED] (Karl Berry) > Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] > > I could easily change things so that the Local Variables section was > always output if a @documentencoding was present. I don't see any > particular harm in that. I agree that it should be the default. > Whether we should start to output 8-bit files > by default for any input with a @documentencoding, I'm less sure. IMO, it's pretty much pointless to _not_ output non-ASCII characters, but still produce the Local Variables section, because without 8-bit characters the result is a plain ASCII file. That is, if the Texinfo source was written well, and used @-commands such as @'e instead of verbatim 8-bit characters. IOW, I think the fact that the document specifies @documentencoding should be enough for makeinfo to obey; relying on an additional command-line switch is unreliable. We could have --disable-encoding switch to turn off the default. > but it might be better to generate all the Info files in UTF-8. > > Maybe, but it would be a lot of work. On the input side, makeinfo has > no special understanding of what it's reading. If there are eight-bit > bytes in the input file, it just outputs them as-is, which works well > enough now; we couldn't get away with that any more. On the output > side, this would mean converting from some arbitrary encoding system to > UTF-8. Of course changing either of these is possible, but neither is > easy. Wouldn't linking against libiconv solve all these with minimal fuss? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
> From: Richard Stallman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > emacs-pretest-bug@gnu.org > Date: Sun, 08 Jul 2007 18:23:28 -0400 > > It is pure luck if an Info file was generated for the same character > set that your terminal supports. That's not what I see when I travel, especially not in the Far East. > Personally, I think preferring locale-specific encoding is TRT, since > most of the installed manuals that use non-ASCII characters are more > likely to use that than anything else. > > No, they will use a whole range of coding systems, on your machine, > on my machine, and on anybody's machine. > > That is not a solution. That is not a 100% solution for 100% of the problem, but it's a good compromise that works well in practice. You often advise others to shy away of purism and instead embrace practical compromises on the Right side of the 80-20 divide. Why not go with this advice in this case? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
