headers
Prof. Dr. Doeringer (FB Informatik | 1 Feb 2004 13:38
Picon
Favicon

utf-8 encoding problem

To: bug-gnu-emacs <at> gnu.org
Subject: utf8
--text follows this line--
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (powerpc-apple-darwin6.0)
 of 2002-09-04 on gump
configured using `configure  --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --without-x'
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: de_DE
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Hi,
I have encountered a problem with the utf-8 encoding in emacs

In essence (please consult the single-line files that come enclosed):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Jacobson | 2 Feb 2004 00:48
Favicon
Gravatar

Re: compile kills background jobs undocumentedly

K> ...calls delete-process, which calls Fkill_process, which sends a QUIT
K> signal.  So I don't see why ignoring HUP would have any effect on that
K> sequence of actions.

All I know is it works here on Debian.

BTW, every once in a while, in the standard compile situation, a
running job isn't noticed, and not asked about or killed, so we get a
concurrent 2nd job. Can't reproduce it.
Permalink | Reply | 0 comments |
headers
Dan Jacobson | 2 Feb 2004 02:43
Favicon
Gravatar

kill-compilation without having to switch buffers first

;So no longer have to switch to compilation buffer before killing!:
(add-hook 'makefile-mode-hook
	  (function
	   (lambda ()
	     (define-key makefile-mode-map "\C-c\C-k" 'kill-compilation))))
Maybe make this a default binding.
No need to first load compile-mode, as the user will only hit the key
after his first compilation.
Permalink | Reply | 0 comments |
headers
Roland Winkler | 2 Feb 2004 11:04
Picon
Picon

Re: pin the right edge of the text to the right edge of the monitor

Barry Margolin <barmar <at> alum.mit.edu> writes:

> In article <mailman.1622.1075480427.928.bug-gnu-emacs <at> gnu.org>,
>  Dan Jacobson <jidanni <at> jidanni.org> wrote:
> 
> > A C-a gets the left edge of the text nicely fixed to the left edge of
> > the monitor, but no consideration is given to us right-wingers.
> 
> Since you know the column that you want to be at the right edge, give a 
> numeric argument to C-x <.

I use the following piece of code in order to let emacs calculate
the numeric argument of scroll-left and scroll-right

(setq auto-show-shift-amount 4)
(defun my-recenter ()
  "Center point in window horizontally and vertically."
  (interactive)
  (recenter)
  (if truncate-lines
      (let ((eol (save-excursion (end-of-line) (current-column)))
            (col (current-column))
            (ww  (window-width)))
        (when (> eol ww)
          (scroll-right eol)
          (cond ((< (- eol col (/ ww 2)) 0)
                 (scroll-left (- (+ eol auto-show-shift-amount 1) ww)))
                ((> col (/ ww 2))
                 (scroll-left (- col (/ ww 2) -1)))
                )))))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 2 Feb 2004 21:55
Picon
Favicon

Re: Info-mode's mode-hook isn't visible

mace wrote:

> On "GNU Emacs 21.2.1 (alpha-debian-linux-gnu, X toolkit, Xaw3d scroll
> bars) of 2002-03-27 on escher, modified by Debian" from a standard
> Debian package, i'm getting this minor bug:
> 
> I noticed that the Info mode doesn't make it's "Info-mode-hook" visible
> with C-h v Info-mode-hook or such. It is evaluated however, on Info
> startup, so it works just fine if defined.

*** emacs-21.3/lisp/info.el.orig	Fri Dec 21 12:08:17 2001
--- emacs-21.3/lisp//info.el	Mon Feb  2 13:53:32 2004
***************
*** 963,968 ****
--- 963,973 ----
  (defvar Info-header-line nil
    "If the info node header is hidden, the text of the header.")

+ (defcustom Info-selection-hook nil
+   "Normal hook run by `Info-select-node'."
+   :type 'hook
+   :group 'info)
+ 
  (defun Info-select-node ()
  "Select the info node that point is in.
  Bind this in case the user sets it to nil."
***************
*** 2232,2237 ****
--- 2237,2247 ----
  ;; Info mode is suitable only for specially formatted data.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 2 Feb 2004 22:50
Picon
Favicon

Fwd: utf-8 encoding problem

When I visit the emacs-bug-with-utf8.tar.gz file that Prof. Dr. Doeringer
attached with emacs-21.3.1 -q --no-site-file, then visit utf8.in or utf8.in.2
with `C-x RET c utf-8 RET f' I get this error:

Debugger entered--Lisp error: (wrong-type-argument integerp [emacs-mule-unix 
emacs-mule-dos emacs-mule-mac])
   coding-system-change-eol-conversion(utf-8 [emacs-mule-unix emacs-mule-dos 
emacs-mule-mac])
   tar-extract()
   call-interactively(tar-extract)
   universal-coding-system-argument()
* call-interactively(universal-coding-system-argument)

That's because tar-extract doesn't handle the case where coding-system-eol-type
returns a vector for the detected coding system.  Here's a patch:

*** emacs-21.3/lisp/tar-mode.el.orig	Sat May 18 13:48:23 2002
--- emacs-21.3/lisp/tar-mode.el	Mon Feb  2 14:47:08 2004
***************
*** 726,734 ****
   		 
	 1 (min 16384 (point-max)) t)))
   		  (if coding
   		      (or (numberp (coding-system-eol-type coding))
! 	 
	  (setq coding (coding-system-change-eol-conversion
! 	 
			coding
! 	 
			(coding-system-eol-type detected))))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 3 Feb 2004 02:25
Picon
Favicon

Re: info-look.el bug

Stephen Eglen wrote:

> Hi, 
> 
> I think I've found a little bug in info-look.el.  If anyone out there
> regularly uses info-look.el, could they please check the following and
> get back to me?
> 
> % emacs -q
> 
> In the *scratch* buffer, type "C-h S defun RET". The frame should divide
> into two: the top window shows *scratch* and the bottom window shows
> the definition of "defun" from the elisp *info*.
> 
> Still in the scratch buffer, type "C-h S setq RET".  This time the
> *scratch* buffer disappears and is replaced by another window showing
> *info* for setq; so now, both windows are showing an info node, but
> the scratch buffer has gone.
> 
> I think this behaviour is wrong, and that if the *info* buffer is
> already visible, it should not be viewed again in another window.  I
> think have tracked down the problem to the call in info-lookup where
> it calls Info-goto-node.  
> 
> I think this problem can be solved by using save-window-excursion, but
> then on the second call to C-h S, the highlighting is not shown.
> Anyone have a better idea of how to solve this?

I think it is caused by the default value of same-window-buffer-names,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Jacobson | 2 Feb 2004 23:49
Favicon
Gravatar

Re: ignored files during TAB expansion

Dan>     I'll try the other example. Oops,
Dan>     Symbol's function definition is void: delete-from-list

RMS> delete-from-list is not a standard Emacs function.

Yes, I was scolding the poster for posting non standard solutions. I
guess I should have been more explicit.

RMS> Is this really a bug in Emacs?
Permalink | Reply | 0 comments |
headers
Jari Aalto+mail.linux | 3 Feb 2004 17:38

Re: [patch] 21.3 executable.el - New func executable-command-find-unix-p

* Wed 2004-01-28 jari.aalto <AT> poboxes.com (Jari Aalto+mail.linux) gnu.emacs.bug
* <http://groups.google.com/groups?oi=djq&as_umsgid=%3Cmailman.1524.1075323038.928.bug-gnu-emacs <at> gnu.org>
| 
| Right. The message is a good indication of Unix find(1) as well. Here
| fix for the previous code. Also added couple of options more like -print.
| 
| 
| 2004-01-28  Jari Aalto  <jaalto <at> w2kpicasso>
| 
| 	* progmodes/executable.el (executable-command-find-unix-p): 
| 	Check basic find which does not support -maxdepth.
| 	Return find(1) type: 'gnu, t or nil. 

And a little more error checking added. This patch should be aplied
after the previous on {See Message ID-reference above).

2004-02-03 Tue  Jari Aalto  <jari.aalto <AT> poboxes.com>

        * progmodes/executable.el (executable-command-find-test-data): New.
        (executable-command-find-unix-p): Improved error checking. Moved
        logic to `executable-command-find-test-data'.

Index: executable.el
===================================================================
RCS file: /cygdrive/h/data/version-control/cvsroot/emacs/gnu-emacs/lisp213/progmodes/executable.el,v
retrieving revision 1.3
retrieving revision 1.5
diff -u -IId: -b -w -u -r1.3 -r1.5
--- executable.el	28 Jan 2004 20:56:16 -0000	1.3
+++ executable.el	3 Feb 2004 16:34:18 -0000	1.5
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 3 Feb 2004 18:04
Picon
Favicon

Re: info-look.el bug

Kevin Rodgers wrote:

> I think it is caused by the default value of same-window-buffer-names,
> which includes "*info*".

BTW, I also tried replacing (switch-to-buffer-other-window "*info*") with
(pop-to-buffer "*info*" t), but both functions let same-window-buffer-names
take precedence over the other-window intent of the programmer.  Is that
correct behavior, or is it a bug?  If it's a bug, I think it could be fixed
simply by let-binding same-window-buffer-names and same-window-regexps to
nil around the call to display-buffer within switch-to-buffer-other-window
and pop-to-buffer (when pop-to-buffer's OTHER-WINDOW arg is non-nil).  What
do you think?

--

-- 
Kevin Rodgers
Permalink | Reply | 4 comments |

Gmane