headers
Dr Francis J. Wright | 2 Jan 2005 17:34
Picon
Favicon

Re: wrong dired format

From: "Radomir Hejl" <rh62121 <at> yahoo.com>
To: <help-emacs-windows <at> gnu.org>
Sent: Monday, December 27, 2004 12:30 PM
Subject: [h-e-w] Re: Re: wrong dired format

> I've got ls-lisp.el as of Dec 2002 included in emacs
> 21.3.1. Nevertheless the problem persists. How do you
> change from "Feb" to "II"? In Windows I have
> DD.MM.YYYY date format, but dired clings to
> I,II,III,IV... for months.

All versions of ls-lisp that I have seen so far use the Lisp function
format-time-string with a hard-coded format string containing %b to format
months within dates, and %b gives the locale's abbreviated month name.  So I
guess Emacs is working in a locale that represents abbreviated month names
as Roman numerals and the locale is probably being set by an environment
variable.  If so, then it's probably ignored by Windows, which is why you
see different date formats in Emacs and Windows.

One way to see all the environment variables that Emacs is seeing is to open
an Emacs shell buffer (M-x shell) and then run the shell command "set"
(without the quotes).  That should work with most shells, including Windows
XP cmd and bash.

Francis
Permalink | Reply | 0 comments |
headers
Radomir Hejl | 5 Jan 2005 14:52
Picon
Favicon

Re: wrong dired format


> > I've got ls-lisp.el as of Dec 2002 included in
> emacs
> > 21.3.1. Nevertheless the problem persists. How do
> you
> > change from "Feb" to "II"? In Windows I have
> > DD.MM.YYYY date format, but dired clings to
> > I,II,III,IV... for months.
> 
> All versions of ls-lisp that I have seen so far use
> the Lisp function
> format-time-string with a hard-coded format string
> containing %b to format
> months within dates, and %b gives the locale's
> abbreviated month name.  So I
> guess Emacs is working in a locale that represents
> abbreviated month names
> as Roman numerals and the locale is probably being
> set by an environment
> variable.  If so, then it's probably ignored by
> Windows, which is why you
> see different date formats in Emacs and Windows.
> 
> One way to see all the environment variables that
> Emacs is seeing is to open
> an Emacs shell buffer (M-x shell) and then run the
> shell command "set"
> (without the quotes).  That should work with most
> shells, including Windows
> XP cmd and bash.
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Abrahams | 10 Jan 2005 15:50
Picon
Picon
Favicon
Gravatar

NT build of CVS failing


...
Loading cus-start (compiled; note, source file is newer)...
Note, built-in variable `x-use-underline-position-properties' not bound
Loading international/mule (compiled; note, source file is newer)...
Loading international/mule-conf.el (source)...
Loading format (compiled; note, source file is newer)...
Loading bindings (compiled; note, source file is newer)...
Loading files (compiled; note, source file is newer)...
Loading cus-face (compiled; note, source file is newer)...
Loading faces (compiled; note, source file is newer)...
Symbol's function definition is void: tty-supports-face-attributes-p
NMAKE : fatal error U1077: '"c:\src\emacs\src/obj-spd/i386/temacs.exe"'
: return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
.NET 2003\VC7\BIN\nmake.exe"' : return code '0x2'
Stop

Does anyone know when the last time it built successfully was?
I'm not subscribed to this list so a direct reply would be appreciated.

--

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Permalink | Reply | 2 comments |
headers
Lennart Borgman | 11 Jan 2005 08:37
Picon
Picon
Favicon

Re: NT build of CVS failing

I built Emacs using a fresh CVS download 01/09/05. (Using MinGW for
compiling.)

----- Original Message ----- 
From: "David Abrahams" <dave <at> boost-consulting.com>

> Loading faces (compiled; note, source file is newer)...
> Symbol's function definition is void: tty-supports-face-attributes-p
> NMAKE : fatal error U1077: '"c:\src\emacs\src/obj-spd/i386/temacs.exe"'
> : return code '0xffffffff'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> .NET 2003\VC7\BIN\nmake.exe"' : return code '0x2'
> Stop
>
> Does anyone know when the last time it built successfully was?
> I'm not subscribed to this list so a direct reply would be appreciated.
Permalink | Reply | 0 comments |
headers
Jason Rumney | 11 Jan 2005 10:56
Picon

Re: NT build of CVS failing

David Abrahams wrote:

>...
>Loading cus-start (compiled; note, source file is newer)...
>Note, built-in variable `x-use-underline-position-properties' not bound
>Loading international/mule (compiled; note, source file is newer)...
>Loading international/mule-conf.el (source)...
>Loading format (compiled; note, source file is newer)...
>Loading bindings (compiled; note, source file is newer)...
>Loading files (compiled; note, source file is newer)...
>Loading cus-face (compiled; note, source file is newer)...
>Loading faces (compiled; note, source file is newer)...
>Symbol's function definition is void: tty-supports-face-attributes-p
>
>  
>
You need to "make recompile" or if that fails, "make bootstrap" to 
recompile the lisp files that have changed above.

I successfully built Emacs from CVS at around 17:00 GMT yesterday.
Permalink | Reply | 0 comments |
headers
Francis Litterio | 11 Jan 2005 21:30
Picon
Picon
Favicon

Patch to fix frame positioning bug on Windows with (make-frame '((left . -1)))

Using Emacs built from CVS source code on Windows XP, the frame created
using the following Emacs-Lisp code is positioned such that the
rightmost 7 pixels of the frame are off the right edge of the screen:

  (make-frame '((width . 80) (height . 20) (top . 0) (left . -1)))

Those 7 pixels encompass the border of the Windows frame and some of the
right fringe.  This may have been caused by revision 1.220 of w32term.c
in which function x_calc_absolute_position() was changed:

  revision 1.220
  date: 2004/12/11 21:12:45;  author: jhd;  state: Exp;  lines: +0 -30
  * w32term.c (x_calc_absolute_position): Remove calculation of
  difference between inner and outer window.  Don't subtract difference
  for left and top calculations.

The below patch solves the problem but it may not be optimal because it
simply subtracts 7 from the computed value of f->left_pos.

One risk I see in this solution is that the user can change the Active
Window Border size to have any pixel width (right click on the desktop,
choose Properties, choose Appeareance, click Advanced, choose Active
Window Border from the Item listbox).  This code (both with and without
my patch) does not take the user-configurable size of the Active Window
Border into account.

I hope this helps.
--
Francis Litterio
franl <at> world . std . com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan D. | 12 Jan 2005 21:04
Picon

Re: Patch to fix frame positioning bug on Windows with (make-frame '((left . -1)))

> Using Emacs built from CVS source code on Windows XP, the frame created
> using the following Emacs-Lisp code is positioned such that the
> rightmost 7 pixels of the frame are off the right edge of the screen:
>
>   (make-frame '((width . 80) (height . 20) (top . 0) (left . -1)))
>
> Those 7 pixels encompass the border of the Windows frame and some of  
> the
> right fringe.  This may have been caused by revision 1.220 of w32term.c
> in which function x_calc_absolute_position() was changed:
>
>   revision 1.220
>   date: 2004/12/11 21:12:45;  author: jhd;  state: Exp;  lines: +0 -30
>   * w32term.c (x_calc_absolute_position): Remove calculation of
>   difference between inner and outer window.  Don't subtract difference
>   for left and top calculations.
>
> The below patch solves the problem but it may not be optimal because it
> simply subtracts 7 from the computed value of f->left_pos.

Can you verify if your change has any impact on this bug:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/ 
msg00519.html

This was the reason a change was made.  It may be impossible to get  
Emacs to work correctly on W32.  Just adding 7 is no good, as you self  
pointed out, a more general solution must be found.

	Jan D.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Litterio | 12 Jan 2005 21:45
Picon
Picon
Favicon

Re: Patch to fix frame positioning bug on Windows with (make-frame '((left . -1)))

Jan D. wrote:

>> Using Emacs built from CVS source code on Windows XP, the frame created
>> using the following Emacs-Lisp code is positioned such that the
>> rightmost 7 pixels of the frame are off the right edge of the screen:
>>
>>   (make-frame '((width . 80) (height . 20) (top . 0) (left . -1)))
...
>> The below patch solves the problem but it may not be optimal because it
>> simply subtracts 7 from the computed value of f->left_pos.
>
> Can you verify if your change has any impact on this bug:
>
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg00519.html
>
> This was the reason a change was made.  It may be impossible to get
> Emacs to work correctly on W32.  Just [subtracting] 7 is no good, as
> you self pointed out, a more general solution must be found.

My change breaks the fix for that bug, so I'm going to investigate
further.

In my testing, I noticed that (make-frame '((top . -1))) on Windows
suffers an even worse positioning error -- about 30 pixels at the bottom
of the frame fall off the bottom of the screen!

I would think that when a frame is positioned so that it is completely
visible, we have the following variables and relations:

  OUTER-LEFT: The number of pixels between the left screen edge
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Litterio | 13 Jan 2005 03:59
Picon
Picon
Favicon

Re: Patch to fix frame positioning bug on Windows with (make-frame '((left . -1)))

Francis Litterio wrote:

> Jan D. wrote:

>> Can you verify if your change has any impact on this bug:
>>
>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg00519.html
>>
>> This was the reason a change was made.  It may be impossible to get
>> Emacs to work correctly on W32.  Just [subtracting] 7 is no good, as
>> you self pointed out, a more general solution must be found.
>
> My change breaks the fix for that bug, so I'm going to investigate
> further.

OK, I think I've gotten to the bottom of the issue.  The above bug
report by Drew Adams contains an incorrect assumption in step #2 of the
steps to reproduce:

> 1. Position a new frame at the left border (the position isn't important,
> but keep track of the position you use - using 0 makes it easier). Evaluate
> (assq 'left (frame-parameters nil)), getting, for example, (left . 0).
> 
> 2. Measure the frame width in pixels: (frame-pixel-width nil), getting, for
> example, 600.

600 is not the width of the frame in pixels.  It is the width of the
frame's client area in pixels.  The window manager (i.e., Windows) draws
left and right borders on either side of the client area, but
frame-pixel-width does not include those borders in the value it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Litterio | 13 Jan 2005 04:37
Picon
Picon
Favicon

Re: Patch to fix frame positioning bug on Windows with (make-frame '((left . -1)))

I wrote:

> To demonstrate that the window borders must be taken into account when
> computing the negative 'left frame parameter, evaluate the below form in
> a frame that is completely visible (no parts of the frame are
> off-screen).  Evaluating this form should not move the frame at all,
> assuming your window manager draws left and right borders that are 4
> pixels each (change the two 4's if your borders are different):
>
> (let ((negative-left (- (+ 1 (- (display-pixel-width)
>                                 (+ 4 4
>                                    (frame-pixel-width nil)
>                                    (frame-parameter nil 'left)))))))
>   (modify-frame-parameters nil `((left . ,negative-left))))

Sorry.  You will only see no frame movement when evaluating the above
form if you have already patched x_calc_absolute_position() as described
in the parent of this article.
--
Francis Litterio
franl <at> world . std . com
Permalink | Reply | 0 comments |

Gmane