headers
Lennart Borgman | 1 Oct 2005 01:02
Picon
Picon
Favicon

Re: Problem with national characters in XHTML

Piet van Oostrum wrote:

>>LB> Evaling (unify-8859-on-decoding-mode 1) does not change the behaviour of
>>LB> C-q 3 4 4 RET. It still enters a character that (following-char) reports as
>>    
>>
>
>  
>
>>LB>   2276 (04344, 0x8e4)
>>    
>>
>
>That is just the internal representation of the character in Emacs. It's
>not important. What matters is what Emacs writes to your file. When you
>write out utf-8 (for example by giving the command
>(set-buffer-file-coding-system 'utf-8) it will write out C3 A4, 
>whereas if you use (set-buffer-file-coding-system 'latin-1) it will write
>out E4.
>  
>
So you mean that at a - what should I call it? - "text semantic level" 
the utf-8 char and the latin-1 char has the same meaning?
Permalink | Reply | 2 comments |
headers
Nick Roberts | 1 Oct 2005 01:11
Picon

New speedbar version

 > A new version of speedbar.el has been checked in.

The file gdb-ui.el has used speedbar.el over the last two years to display
watch expressions.  Now, with supposedly a month or so to go before the
release, it doesn't.  There are 290 differences between this version and the
previous one.  The ChangeLog entry is:

	* speedbar.el: New version 1.0pre3.

If this is deemed reasonable behaviour then its probably not worth debating
the issue.

Nick
Permalink | Reply | 1 comment |
headers
Richard M. Stallman | 1 Oct 2005 01:50
Picon
Picon

Re: [christopher.ian.moore <at> gmail.com: Emacs very slow opening file]

    When Emacs is running diff itself, it could start the output off with
    an appropriate -*- type string overriding a possible local variables
    block.  Or it could append a solitary ^L to the output (which is the
    normal way of telling Emacs not to look further backward for a local
    variables section).

That would work.  However, if the other idea can work--recognize that
the Local Variables list is inside a diff hunk--that would work more
generally.
Permalink | Reply | 1 comment |
headers
Chong Yidong | 1 Oct 2005 02:13
Favicon

Re: New speedbar version

Nick Roberts <nickrob <at> snap.net.nz> writes:

> The file gdb-ui.el has used speedbar.el over the last two years to display
> watch expressions.  Now, with supposedly a month or so to go before the
> release, it doesn't.  There are 290 differences between this version and the
> previous one.  The ChangeLog entry is:
> 
> 	* speedbar.el: New version 1.0pre3.
> 
> If this is deemed reasonable behaviour then its probably not worth debating
> the issue.

Unfortunately, checking in the new version of Speedbar (which has been
undergoing development in its own tree for two years) was itself one
of the items needed for the release.  See, for example,

http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00202.html
Permalink | Reply | 504 comments |
headers
Daniel Brockman | 1 Oct 2005 03:19
X-Face
Picon
Gravatar

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

Jason Rumney <jasonr <at> gnu.org> writes:

> I didn't see the original, but I strongly disagree that 10
> seconds is too long for reading a potentially long message
> in a tooltip.

Me too.  Why stop displaying it after 10 seconds even?
That limit seems really arbitrary and annoying.

> As long as the user is not using the keyboard or mouse,
> what harm is there in continuing to display the tooltip?

Exactly.  Why not keep displaying it until the user starts
typing or moves the mouse away from the tooltipped object?
After all, if the user has not yet done one of those things,
he or she is probably still reading the tooltip.

--

-- 
Daniel Brockman <daniel <at> brockman.se>
Permalink | Reply | 16 comments |
headers
Tomas Zerolo | 1 Oct 2005 06:29
Picon

Re: Problem with national characters in XHTML

On Sat, Oct 01, 2005 at 01:02:31AM +0200, Lennart Borgman wrote:
> Piet van Oostrum wrote:
[...]
> >That is just the internal representation of the character in Emacs. It's
> >not important. What matters is what Emacs writes to your file. When you
> >write out utf-8 (for example by giving the command
[...]
> So you mean that at a - what should I call it? - "text semantic level" 
> the utf-8 char and the latin-1 char has the same meaning?

Yes. You put that nicely. The *character* (a dieresis) stays the same.
The *representation* (loosely referred to as `encoding') changes.

I said loosely, because on more complex things as utf-8 there are
actually two layers: the `character set', mapping each character to an
integer (aka `code point', which in this case would be UNICODE or
ISO-10646, which nowadays are equivalent), and the representation in a
file, which may be utf-8 (most common), ucs-16 or whatnot.

Now the advantage of utf-8: it is a variable-width encoding, and uses up
just one byte for one ASCII character (on ASCII it uses the same code
points). So you can interpret an ASCII file ``as-is'' as an utf-8 file.

For higher characters (the ones, for example with codes >127 in
iso-8859-1 (aka Latin1)), you need more than one byte in utf-8. AFAIK,
up to 6 bytes, but don't take that too seriously.

The disadvantage is: it is a variable-width encoding, so you have to
process a text sequentially, byte-for-byte to get the character
boundaries right (it's designed to re-synchronize gracefully, though).
(Continue reading)

Permalink | Reply | 0 comments |
headers
martin rudalics | 1 Oct 2005 09:34
Picon
Picon

Re: jit-lock refontifies too much

Richard wrote:
 >      > That is why I suggested recording these ppss values in text
 >      > properties of the first character on a line--so that they would stay
 >      > around for comparison later.
 >
 >     That would be fine.  But recording these properties for each and every
 >     line fontified would introduce too much overhead.
 >
 > I suspect think it is comparable to the amount of space used by
 > font-lock mode now.  Maybe less.  If so, why is it too much?
 >

I somewhat fell between two stools here.  With respect to my first
proposal Stefan judged ".. yet-another-text-property is a waste of
precious CPU and memory resources."

 >      > Another possible advantage is: if things are not in sync for the first
 >      > line after the end of the changed text, it might be in sync on a
 >      > subsequent line, and that could avoid refontifying most of the lines
 >      > on the screen.
 >      >
 >
 >     I can think of two interpretations for "things are not in sync":
 >
 > It means "the before and after ppss values do not match".
 >
 > You're arguing this can't happen very easily.  Maybe that is true.
 >

I didn't argue that.  Complete ppss are hardly ever "in sync" after a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andreas Schwab | 1 Oct 2005 10:20
Picon

Re: new version of allout.el - patch and ChangeLog

Ken Manheimer <ken.manheimer <at> gmail.com> writes:

> good question - i wasn't aware of pgg.  can you tell me more about it?

pgg has been developed as part of Gnus.  It hasn't been distributed as
part of Emacs before, but Emacs 22 will contain it as part of the Gnus
subsystem.

> google points me at only emacs-wiki stuff (for a search on "emacs gpp")
> or xemacs-related stuff (for "xemacs gpp")...

http://www.gnupg.org/(en)/related_software/frontends.html#fend_mua-PGG

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 2 comments |
headers
Andreas Schwab | 1 Oct 2005 10:08
Picon

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

Daniel Brockman <daniel <at> brockman.se> writes:

> Jason Rumney <jasonr <at> gnu.org> writes:
>
>> I didn't see the original, but I strongly disagree that 10
>> seconds is too long for reading a potentially long message
>> in a tooltip.
>
> Me too.  Why stop displaying it after 10 seconds even?
> That limit seems really arbitrary and annoying.

If a tooltip cannot be read in 10 seconds then it is too long, IMHO.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 15 comments |
headers
YAMAMOTO Mitsuharu | 1 Oct 2005 13:28
Picon

ATSUI support on Carbon Emacs

At the request of the maintainer, I installed ATSUI support on Carbon
Emacs to the trunk.  It does not change anything unless -DUSE_ATSUI is
specified at compile time.  It is still somewhat experimental, and has
some known problems:

  * Cursor movement is sometimes slow because of the excessive redraw
    of overlapping/overlapped rows.
    http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00705.html

  * Tall characters get thicker because they are overdrawn when
    overlapping rows are redrawn.  This is the verical version of the
    following problem:
    http://lists.gnu.org/archive/html/emacs-devel/2005-01/msg00729.html

  * Sole diacritical marks and right-to-left texts are not displayed
    correctly.

  * A JISX0212 character in HELLO (C-h h) is not displayed by default.
    (I don't mean all of the remaining characters are displayed by
    default.)  A workaround is to evaluate
    (define-translation-hash-table 'ucs-mule-cjk-to-unicode
     ucs-mule-cjk-to-unicode).

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp
Permalink | Reply | 31 comments |

Gmane