Unexpected find-file behavior in Version 22.3 for Windows

Unexpected find-file behavior in Version 22.3 for Windows

[Count Dracula]

Under Linux, if find-file is invoked while the cursor is in a buffer
called
  /opt/foo/bar/textfile.txt
the text offered for completion in the minibuffer area is
  /opt/foo/bar/
but in a newly installed Windows (Vista Home) version 22.3, the
minibuffer area always shows the home directory ~/. This is strange
and annoying. How can I get find-file to behave as in the Linux
version?

Also in cc-mode in the Windows version 22.3, the line indentation
function is bound to
C-c C-q and this works fine, but I would like to bind it to the tab
key. The C-d key is also bound to some function or other, and I need
it to be bound to delete-region.
I thought I could make these changes in the c-mode-hook function, but
what I tried was apparently not the way to do it. Could someone post
the lisp code I need for these changes?

A long-standing problem under Linux has been the shell buffer (or
terminal). If I run man in the shell buffer, I get a message that says
that the terminal is not fully functional. If I run gcc, its messages
contain what look like octal codes.
If I run ls, the filenames I get are surrounded by spurious
characters, mostly square brackets and carets. What does it take to
set up a fully functional terminal?

Thanks,
Levent

Re: Unexpected find-file behavior in Version 22.3 for Windows

[Eli Zaretskii]

> From: Count Dracula <Levent.Kitis@navy.mil>
> Date: Wed, 8 Apr 2009 06:01:22 -0700 (PDT)
> 
> Under Linux, if find-file is invoked while the cursor is in a buffer
> called
>   /opt/foo/bar/textfile.txt
> the text offered for completion in the minibuffer area is
>   /opt/foo/bar/
> but in a newly installed Windows (Vista Home) version 22.3, the
> minibuffer area always shows the home directory ~/.

That's not what I see.  Does this happen for you even in "emacs -Q"?

> Also in cc-mode in the Windows version 22.3, the line indentation
> function is bound to
> C-c C-q and this works fine, but I would like to bind it to the tab
> key. The C-d key is also bound to some function or other, and I need
> it to be bound to delete-region.

You will need to customize your Emacs in the .emacs file.

> I thought I could make these changes in the c-mode-hook function, but
> what I tried was apparently not the way to do it. Could someone post
> the lisp code I need for these changes?

I think you want c-mode-common-hook.  If that does not work, show here
your Lisp, and someone will help you get it right.

Re: Unexpected find-file behavior in Version 22.3 for Windows

[Peter Dyballa]

Am 08.04.2009 um 15:01 schrieb Count Dracula:

> A long-standing problem under Linux has been the shell buffer (or
> terminal). If I run man in the shell buffer, I get a message that says
> that the terminal is not fully functional.

The *shell* buffer is not a terminal emulator. The function terminal- 
emulator is closer.

> If I run gcc, its messages contain what look like octal codes.

You're using an inadequate coding system to display characters like

	[‘]  2018  LEFT SINGLE QUOTATION MARK
	[’]  2019  RIGHT SINGLE QUOTATION MARK
	[‚]  201A  SINGLE LOW-9 QUOTATION MARK
	[‛]  201B  SINGLE HIGH-REVERSED-9 QUOTATION MARK
	[“]  201C  LEFT DOUBLE QUOTATION MARK
	[”]  201D  RIGHT DOUBLE QUOTATION MARK
	[„]  201E  DOUBLE LOW-9 QUOTATION MARK

Set for GNU Emacs environment variables like LANG or LC_ALL to be  
something like *.UTF-8. The use of ISO 10646 (Unicode) encoded fonts  
is also recommended.

> If I run ls, the filenames I get are surrounded by spurious
> characters, mostly square brackets and carets.

You've set up ls to colourise its output. This

     (add-hook 'shell-mode-hook (lambda ()
         (ansi-color-for-comint-mode-on)))

might solve the problem. Otherwise set in ~/.emacs_<login shell> ls  
to produce clear output with those ANSI Esc codes.

--
Greetings

   Pete

Radio heißt: Erst denken dann reden.
TV heißt: Erst schminken dann reden.