headers
Thomas Lord | 1 May 2008 01:46
Picon

Re: Very interesting analysis of "the state of Emacs"

David Hansen wrote:
> There are some small languages that implement this (e.g. Lua or Scheme
> (not in the standard but it's a natural use for continuations)).  The
> main problem I would see is emacs dynamic scope, e.g. what's the value
> of a variable in one thread if another one let binds it.
>   

As usual, Henry Baker wrote some stuff years ago that might be helpful 
there.
Poking around with the obvious web searches should turn it up.

Did anyone ever get any further on the "Emacs lisp on GNU Guile" idea?
I'm not too familiar with the current state of Guile these days but, at 
one time,
while it was never clear we could do it perfectly, there was non-trivial 
effort and
decision making in that direction.

-t
Permalink | Reply | 1 comment |
headers
Jason Rumney | 1 May 2008 01:48
Picon

Re: font-backend branch

Kenichi Handa wrote:
> As for Windows port:
>
> I tried to compile it on Windows in cygwin environment.  By,
> "make bootstrap", it seems that src/oo-spd/i386/emacs.exe is
> created, but the make failed at the target finder-data of
> lisp/makefile.
This is because Cygwin make passes invalid paths to Emacs.

>   And, when I run src/oo-spd/i386/emacs, it
> starts up without an error, but, non-ASCII characters are
> not correctly displayed by garbage glyphs.

The new code seems to be making a poor choice of font for Latin-1 
characters, it is choosing a symbol font which does not contain the 
characters for me. This was triggering a bug that is also present in the 
trunk which caused the crash that Juanma experienced. The choice of font 
for other Latin characters is also not optimal, as the font used for 
ASCII contains most of these characters, but in the font-backend branch 
other fonts are chosen.

In addition to the bug mentioned above, I got another crash while 
displaying etc/HELLO which was caused by using s->face->font in 
w32font_draw. Changing it to use s->font works, but I have no idea what 
the difference is between these two, and why s->face->font would be NULL 
while s->font points to a valid font.
Permalink | Reply | 19 comments |
headers
YAMAMOTO Mitsuharu | 1 May 2008 01:56
Picon

Re: [PATCH] fix for unexec bootstrap fail on darwin

>>>>> On Wed, 30 Apr 2008 10:42:53 -0700, Mike Mattie <codermattie <at> mac.com> said:

> I ran into "not enough room for load commands for new __DATA
> segments" from unexecmacosx.c while bootstrapping yesterday. I
> increased the room for load commands from 30, to 40 and acheived a
> successful bootstrap.

> I did not know exactly how much room was required so increasing the
> padding by 10 commands is a guess. otool -l src/emacs shows 43 load
> commands after bootstrap completed.

Alternatively, you can bootstrap by keeping term/x-win.el from being
preloaded in loadup.el during the bootstrap stage.  I think this will
decrease the optimal size of STATIC_HEAP_SIZE in sheap.c for Cygwin.

I still don't understand why term/*-win.el are changed to be preloaded
at the multi-tty merger.  If it was necessary for multi-tty, it might
cause some problems on CANNOT_DUMP platforms.  If not, then it was
really a bad idea (at least unfair) to slip such changes into the
unrelated event, i.e., the multi-tty merger.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp
Permalink | Reply | 0 comments |
headers
Jason Rumney | 1 May 2008 02:24
Picon

Re: font-backend branch

Jason Rumney wrote:
> The new code seems to be making a poor choice of font for Latin-1 
> characters, it is choosing a symbol font which does not contain the 
> characters for me. This was triggering a bug that is also present in 
> the trunk which caused the crash that Juanma experienced. The choice 
> of font for other Latin characters is also not optimal, as the font 
> used for ASCII contains most of these characters, but in the 
> font-backend branch other fonts are chosen.

Here is an example of how display in the font-backend branch differs 
from the trunk. I have highlighted some areas in the two images that 
look interesting for figuring out what might be going wrong:
Permalink | Reply | 0 comments |
headers
Vinicius Jose Latorre | 1 May 2008 02:34
Picon
Favicon

Re: Proposal: diff-remove-trailing-blanks


>>>>      (while (re-search-forward "^[+!>] .*?[ \t]+$" (point-max) t)
>>>>         
>>> In unified diffs, there is no white space after `+'. In other diff
>>> types, its seems that there is:
>>>
>>> +foo (changed or added line, unified diff)
>>>       
>>>> foo (changed or added line, normal diff)
>>>>         
>>> ! foo (changed line, context diff)
>>> + foo (added line, context diff)
>>>
>>> The solution is to test the format type and adapt the regexp for it:
>>>
>>> (diff-beginning-of-hunk 'try-harder)
>>> (setq (diff-hunk-style))
>>> (case style
>>>     (unified (setq re ...)) ;; (+)
>>>     (context (setq re ...)) ;; (+! )
>>>     (t (setq re ...))) ;; (> )
>>>
>>>       
>> Ok, so, maybe the functions below fix all of this.
>>     
> [snip]
>   
>>      (while (re-search-forward "^[+!>].*?[ \t]+$" (point-max) t)
>>     
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kenichi Handa | 1 May 2008 03:01

Re: font-backend branch

In article <w1bq3rxfah.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:

> On a RHEL5.1 x86_64 system, I did:

> ./configure --with-x --with-x-toolkit=athena --without-toolkit-scroll-bars
> make bootstrap

> and received this build error:

> xfaces.c: In function 'x_update_menu_appearance':
> xfaces.c:3768: error: expected ',' or ';' before 'const'
> xfaces.c:3785: error: 'suffix' undeclared (first use in this function)
> xfaces.c:3785: error: (Each undeclared identifier is reported only once
> xfaces.c:3785: error: for each function it appears in.)
> xfaces.c:3791: warning: comparison of distinct pointer types lacks a cast
> make[2]: *** [xfaces.o] Error 1

Ah, I've never tried --with-x-toolkit=athena.

> Just a missing `;' at the end of line 3761.
[...]
> The same line is missing the `F' from Ffont_xlfd_name.

Thank you for finding the error.  I've just comitted a fix.

---
Kenichi Handa
handa <at> ni.aist.go.jp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Óscar Fuentes | 1 May 2008 03:04
Picon

Re: Proposal: diff-remove-trailing-blanks

Vinicius Jose Latorre <viniciusjl <at> ig.com.br> writes:

>>>      (while (re-search-forward "^[+!>].*?[ \t]+$" (point-max) t)
>>>     
>>
>> As every change indicator is followed by a white space in non-unified
>> format, this regexp matches every change on normal and context
>> formats. This is not bad, as the trailing whitespace condition is tested
>> again below for the source file, which is what matters. But then, you
>> could use a simpler regexp above ("^[+!>]", for instance), for behaving
>> the same with diff formats.
>>   
>
> Ok, but the search in diff buffer is only for modified lines with
> trailing blanks,
> so there is less finds/replacements in the source file.

Precisely, my point is that non-unified format has a trailing blank for
empty new lines, even when the new line has no trailing blank. You can
check that yourself adding an empty new line to a file, diff it in
`context' or `normal' format and you can check that the diff has a blank
space after the `>' or `+'.

[snip]

>> Do you intend to install it on CVS soon?
>>   
>
> Well, can I install diff-kill-trailing-whitespace
> and diff-show-trailing-whitespace into diff-mode?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miles Bader | 1 May 2008 04:57
Picon
Gravatar

Re: patch for optional inhibit of delete-other-windows(IDE feature)

Richard M Stallman <rms <at> gnu.org> writes:
>     I chose "pin" because in some gui toolkits there is a widget that looks
>     like a little needle/pin that you can use to "fasten" the window and not
>     go away on certain operations.
>
> That is horribly cryptic and unclear.  We should rename it before
> installing it.

It's a pretty common term for this usage though.  [A related example is
"pinning" memory to prevent it from being paged out.]

-Miles

--

-- 
Year, n. A period of three hundred and sixty-five disappointments.
Permalink | Reply | 1 comment |
headers
Glenn Morris | 1 May 2008 05:54
Picon

Re: font-backend branch

Kenichi Handa wrote:

> I've just committed new codes in font-backend branch.  Those
> who have reported font-backend-related bugs, please test
> that branch.

Of the problems I've reported, your branch fixes these two:

font-lock faces use different font with font-backend
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00651.html

font height problems with font-backend
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00620.html

This issue is still present:

Xresource pane.menubar.*font no longer takes effect
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00314.html
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01683.html

Also, I have a new issue now, in that Emacs starts with the right
font, but in the wrong size. I have in ~/.Xdefaults:

Emacs.font: -misc-fixed-medium-r-normal-*-14-*-100-100-*-*-iso8859-1

But Emacs starts with a bigger font (misc fixed 9x15 it seems).
If I select 7x13 or 7x14 from the shift-mouse-1 "Misc" menu, I get the
font I want.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Jonathan Rockway | 1 May 2008 06:23
Picon
Gravatar

Re: Very interesting analysis of "the state of Emacs"

* On Wed, Apr 30 2008, David Hansen wrote:
> There are some small languages that implement this (e.g. Lua or Scheme
> (not in the standard but it's a natural use for continuations)).  The
> main problem I would see is emacs dynamic scope, e.g. what's the value
> of a variable in one thread if another one let binds it.

I don't think let bindings are the problem, it's easy for two
invocations of the same function to have separate dynamic scopes.
Consider:

  (defun foo nil (let (a b c) (bar)))
  (defun bar nil (message "(a %s) (b %s) (c %s)" a b c))

If we start two foos in parallel, everything works:

  1:                          2:
  foo                         foo
  let #<scope (a, b, c) 0x1>  let #<scope (a, b, c) 0x2>
  bar (uses scope 0x1)        bar (uses scope 0x2)

Basically, each invocation is logically a separate process.  I don't see
any problems with something like this.  The dynamic scope is not a
show-stopper, anyway.

The issue is when we start putting global variables into the mix:

  (defvar shared 42)
  (defun foo nil (incf shared) (incf shared))
  (defun bar nil (decf shared))
(Continue reading)

Permalink | Reply | 10 comments |

Gmane