headers
Martin Fredriksson | 1 Dec 2003 01:39
Picon

Re: MacOS X: Carbon Emacs problem

On 6 nov 2003, at 22.06, Rolf Marvin Bøe Lindgren wrote:

> If I call LaTeX from GNU Emacs under Carbon (i.e. the usual way), then
> processing takes ages.  if I run Emacs without Carbon, i.e. emacs -nw,
> then LaTeX processing runs at the same speed as when called from the
> shell.
>
> latest cvs build of GNU Emacs (this has been this way for a long time
> now), latest version of auc-tex.

I experience the same.  I think the reason may be that it takes longer 
to log the result in the latex output buffer on Emacs/Carbon?

/m

--
Martin Fredriksson <m <at> rfc.se>, phone: +46 730 59 77 00
Guide Konsult Göteborg AB, Sweden
Permalink | Reply | 3 comments |
headers
Kenichi Handa | 1 Dec 2003 01:43

Re: eight-bit char handling in emacs-unicode

In article <jwvad6hlwu1.fsf-monnier+emacs/devel <at> vor.iro.umontreal.ca>, Stefan Monnier
<monnier <at> IRO.UMontreal.CA> writes:
>>>  I can't answer this question without knowing the answer to my question:
>>>  what is string-make-unibyte used for.

>>  It is used for converting a multibyte string to unibyte
>>  before it is inserted in a unibyte buffer.

> I meant `what is "converting from multibyte to unibyte" used for'.
> I.e. it can be used for different things in different contexts and I can't
> answer in general, so I need a concrete case.

It is used for not loosing information about text even if
you kill a text in a multibyte buffer and paste it in a
unibyte buffer.  When you kill the just pasted text of a
unibyte buffer and paste it in the original multibyte
buffer, you recover the same character sequence.

Anyway, I already showed you this example:

  In Latin-2 environment but the default encoding is CTEXT.

In that case also, inserting multibyte latin-2 string in
unibyte buffer works the same way as in this case:

  In Latin-2 environment and the default environment is iso-latin-2.

And, that's because the functionality of string-make-unibyte
doesn't have to know about coding system.  All it has to
know is which character set to use.
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Kastrup | 1 Dec 2003 02:16
Picon
Picon

Re: MacOS X: Carbon Emacs problem

Martin Fredriksson <martin <at> rfc.se> writes:

> On 6 nov 2003, at 22.06, Rolf Marvin Bøe Lindgren wrote:
> 
> > If I call LaTeX from GNU Emacs under Carbon (i.e. the usual way),
> > then processing takes ages.  if I run Emacs without Carbon,
> > i.e. emacs -nw, then LaTeX processing runs at the same speed as
> > when called from the shell.
> >
> > latest cvs build of GNU Emacs (this has been this way for a long
> > time now), latest version of auc-tex.
> 
> I experience the same.  I think the reason may be that it takes
> longer to log the result in the latex output buffer on Emacs/Carbon?

Let me guess.  You are working on a single processor system.  The
reason for this may well be something which I already brought up here
once which will on _many_ single processor operating systems result
in _very_ inefficient operation: when Emacs is listening on a pipe,
it will wake up and process a single byte willingly.  But while Emacs
is processing this single byte (and Emacs usually is rated an
interactive application by the scheduler and thus does not get
preempted), the application producing the byte does not get any CPU
time.  So when Emacs has finished processing that single byte and
gives back the CPU to the scheduler, the output generating program
will again just generate a single byte (or sometimes line) before
Emacs gets control of the CPU again.  But it is maximally inefficient
to have a pipe only be processed with such small units.

Try some of the following remedies:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Stallman | 1 Dec 2003 02:45
Picon
Picon

Re: Creating recursive customization types / widgets

    (define-widget 'child 'default
      "Base widget for recursive datastructures.

    You need to set :type to the widget type for the datastructure you
    want to define, and set :match to a function that matches the
    datastructure.  If the datastructure is not recursive, you don't have
    to set :match."

It looks like a good feature, but I can't really understand
that doc string, so it needs to be somewhat clearer.
Permalink | Reply | 8 comments |
headers
Richard Stallman | 1 Dec 2003 02:45
Picon
Picon

Re: doc elisp intro cross reference fixes

    Maybe one needs to think more radical thoughts: Where is the sense in
    allowing me to do (setq global-font-lock-mode t) even though it has no
    effect?

    Now, maybe changing setq to invoke the Custom setter would be too
    weird.

    But maybe it is possible to change Custom such that it doesn't need
    those variables?

Setting the variable with setq may not be useful, but looking at its
value is useful.  It makes no sense to eliminate the variable.
Permalink | Reply | 0 comments |
headers
Martin Fredriksson | 1 Dec 2003 03:23
Picon

Re: MacOS X: Carbon Emacs problem

Thanks for a very informative (and quick!) answer.  The 'dd obs=8k' 
really improved speed!  Great!  The filter did not noticably improve 
speed; I have not experimented with different sleep times (do you want 
me to do that?).

I understand your explanations, but I know much too little about the 
issues to have a clear opinion about what fix is right.

Thanks again!

Martin F

On 1 dec 2003, at 02.16, David Kastrup wrote:

> Martin Fredriksson <martin <at> rfc.se> writes:
>
>> On 6 nov 2003, at 22.06, Rolf Marvin Bøe Lindgren wrote:
>>
>>> If I call LaTeX from GNU Emacs under Carbon (i.e. the usual way),
>>> then processing takes ages.  if I run Emacs without Carbon,
>>> i.e. emacs -nw, then LaTeX processing runs at the same speed as
>>> when called from the shell.
>>>
>>> latest cvs build of GNU Emacs (this has been this way for a long
>>> time now), latest version of auc-tex.
>>
>> I experience the same.  I think the reason may be that it takes
>> longer to log the result in the latex output buffer on Emacs/Carbon?
>
> Let me guess.  You are working on a single processor system.  The
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 1 Dec 2003 03:31

Replace starttls.el with GNUTLS based version?

How many uses STARTTLS?  For SMTP or IMAP?  The external program
'starttls' isn't widely available (e.g., not packaged by Debian) and
it uses OpenSSL, so I would like to replace the current starttls.el
with a (partially) backwards compatible version that uses GNUTLS.  It
is currently installed in Gnus CVS contrib/starttls.el, and I have
been using it for a while.

The only problem I perceive is that if anyone is using client X.509
certificates, they will have to move from `starttls-extra-args' to
`starttls-extra-argument'.  (That is the backwards incompatible part.)
Because there appear to be a bug in the "starttls" application that
make client authentication useless because the verification result is
ignored, I suspect not many uses X.509 client certificates with
STARTTLS, or at least not anyone who cares enough about security to
audit the tools they use.  So nobody, even users that have configured
client certificates, would lose security by changing to anonymous TLS
with gnutls-cli.  However, they can increase security by setting the
new s-e-a variable.

So, does anyone have an opinion for or against moving
gnus/contrib/starttls.el into gnus/lisp/starttls.el and
emacs/lisp/gnus/starttls.el?  In Emacs, lisp/gnus/imap.el have to be
modified as well (it currently use hard coded filenames, and assumes
things about how the old starttls.el was implemented), but
lisp/mail/smtpmail.el work with STARTTLS unmodified.

To test this in Gnus, simply copy contrib/starttls.el over
lisp/starttls.el and rebuild.
(Continue reading)

Permalink | Reply | 13 comments |
headers
David Kastrup | 1 Dec 2003 03:35
Picon
Picon

Re: MacOS X: Carbon Emacs problem

[Toppost rearranged]

Martin Fredriksson <m <at> rfc.se> writes:

> > Let me guess.  You are working on a single processor system.  The
> > reason for this may well be something which I already brought up
> > here once which will on _many_ single processor operating systems
> > result in _very_ inefficient operation: when Emacs is listening on
> > a pipe, it will wake up and process a single byte willingly.  But
> > while Emacs is processing this single byte (and Emacs usually is
> > rated an interactive application by the scheduler and thus does
> > not get preempted), the application producing the byte does not
> > get any CPU time.  So when Emacs has finished processing that
> > single byte and gives back the CPU to the scheduler, the output
> > generating program will again just generate a single byte (or
> > sometimes line) before Emacs gets control of the CPU again.  But
> > it is maximally inefficient to have a pipe only be processed with
> > such small units.
> >
> > Try some of the following remedies:
> >
> > M-x customize-variable TeX-command-list RET
> >
> > And then append to the TeXing command you usually use
> >
> > |dd obs=8k
> >
> > which should fill the pipe with much larger chunks.  Another
> > possibility is to do
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miles Bader | 1 Dec 2003 08:49
Picon
Picon

Re: dired: don't mark summary line

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> >> Would this patch help?
> >> -  (or (looking-at "^$\\|^. *$\\|^. total\\|^. wildcard\\|^. used\\|^. find")
> >> +  (or (looking-at "^$\\|^. *$\\|^. total\\|^. wildcard\\|^. used\\|^. find\\|^. insgesamt")
> 
> > Note that the same problem occurs for _every_ locale (e.g., I've seen it with
> > LANG set to ja_JP); it might be better to ignore any lines with less than
> > some number of spaces in them, or something like that.
> 
> Why not just check that the line has the drwxrwxrwx thingy ?
> We already have a fine regexp for it,

Indeed, and the comment in `dired-between-files' suggests using
(save-excursion (not (dired-move-to-filename))) which basically just
ends up using dired-permission-flags-regexp as you suggest (that regexp
can't be used directly with looking-at, because it doesn't match from
the beginning of a line).

The following patch seems to do the right thing in a non-english locale,
without any message dependencies; despite the comment it's not
perceptibly slow for me:

diff -up /usr/local/src/emacs-tiling/lisp/dired.el /tmp/dired.el
--- /usr/local/src/emacs-tiling/lisp/dired.el	2003-11-18 18:19:34.000000000 +0900
+++ /tmp/dired.el	2003-12-01 16:43:23.000000000 +0900
 <at>  <at>  -2383,9 +2383,5  <at>  <at>  FILES is the list of marked files."
   ;; Point must be at beginning of line
-  ;; Should be equivalent to (save-excursion (not (dired-move-to-filename)))
-  ;; but is about 1.5..2.0 times as fast. (Actually that's not worth it)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kim F. Storm | 1 Dec 2003 11:15
Picon

Re: The display margin

David Kastrup <dak <at> gnu.org> writes:

> storm <at> cua.dk (Kim F. Storm) writes:
> 
> > Maybe also an image :keymap property, but that will require more
> > work, so I will have to investigate further before doing so.
> 
> I've been using keymaps on images for years already (via the display
> property or so).  It was the only way to make an image clickable
> since you could not enquire whether a click position was on an image
> or on text beside it (at least for images on zero-width overlays).

What I meant was an "image map" feature, i.e. where different areas
(hot-spots) of an image had different pointer shapes and key bindings.

--

-- 
Kim F. Storm <storm <at> cua.dk> http://www.cua.dk
Permalink | Reply | 3 comments |

Gmane