My problems is that the GUI Emacs doesn't render all glyphs correctly.
In some situations certain characters are rendered as squares while
XTerm renders them correctly. I use exactly the same font in XTerm and
Emacs (GUI). The font is:

-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1

Here's an example: With the mentioned font and with Emacs inside XTerm
the command

C-h C-\ ipa RET ; (describe-input-method 'ipa)

displays correctly all except five characters. The glyphs of those five
characters are most likely missing from the font. But inside GUI Emacs
every single one of those IPA characters are rendered as squares. If I
use ipa input method to actually insert those characters to a buffer,
they show just fine.

Sometimes I see squares in Gnus *Article* buffer in other people's
messages, but those characters show just fine if I copy&paste them from
GUI Emacs to XTerm window. At least U+6EC1 is one of them.

Hi,

I am trying to build a rexexp that does the following:
I have a text file where I want to replace

Medicine:One:Two €12.00

With

Medicine €12.00

Because I have more than one entry `Medicine' (and they
differ slightly, something like `Medicine:Three:Four' and
so on) I have to do it with `quere-replace-regexp'.
With regexp-builder I found this:

Medicine:.*[^€.0-9]

This works both in regexp-builder and a scratch buffer, but
unfortunately not in a file. If applied on a file replace-regexp
strips everything from the first `:'.

Kind regards
henry

I need a function and hope that somebody can help implement
it.

The purpose is to simplify diff -u for human viewing by
eliminating trivial changes, including line moves.

My algorithm is very simple:

1. Process the text after the + or - with PROCESSOR.
Default: no processing.
2. Of the + and - lines, show only those with unique
text.
3. Replace lines like "@@ -1,3 +1,6 @@" with "...".

The unique lines step detects line moves. It will also
eliminate duplicated lines, but that's OK.

The processing step lets you specify what else is trivial
besides line moves. For example, if you don't need to see
changes that involve commenting and uncommenting, you pass a
function that deletes "^#". This makes both sides of the
diff uncommented.

On Thu, Nov 20, 2008 at 11:40 AM, Nordlöw gmail.com> wrote:

Rodolfo Medina gmail.com> writes:

James Cloos jhcloos.com> writes:

When I do a cross-buffer cut-and-paste from a buffer with syntax
highlighting to one that doesn't have any highlighting I find that
the highlighting from the source buffer is preserved, which I don't
want.

I have not been able to find a way to get rid of this "imported"
highlighting, other than killing the buffer and revisiting the
file, which is pretty annoying. E.g. "M-x fundamental-mode" won't
do it.

Is there a simpler way of getting rid of this unwanted highlighting
(or of avoiding it in the first place)?

TIA!

Kynn

I've had similar problems with several major modes I've written.

Cobol for example doesn't even have a comment character, anything
after a particular column is a comment
TAL uses ! as both begin and end and eol is also an implicit end....

So ! this is a comment!but this isn't! and this is
but this isn't

Anyway, the only really good way to get useful results is by
specifying
font-lock-syntactic-keywords in your font-lock-defaults statement.

It's not a terribly simple process.
Some years ago, when I was writing all those modes, I was pretty
fluent and could spout off just exactly how to do it. Fortunately I
answered several how-to questions in several Emacs NGs so my notes are
available.

Try this thread. I think it's pretty complete in covering what you
need to know.

http://groups.google.com/group/comp.emacs/browse_thread/thread/c1b7de4489be181

stuart wrote:

I use very large fonts. This causes many things in emacs to be
unreadable. The biggest ones are:

1. C-h f, C-h v, etc.: in order to read, I have to manually adjust
fill-column and reformat paragraphs. Difficult.

2. Man pages. I don't know how to adjust the fill column.

Is there a fix for both of these?

Notes:

Note that readability also improves when fill-column is
short. This is why magazines and newspapers and some
science papers have short columns.

Also note that some people are likely to start using
org-mode on small devices.

Is it possible to use a shorter fill-column, say 60, in
docstrings?

I realize that this might be difficult, if the code
itself uses a long fill-column, unless there is a way
to make fill-paragraph work differently on docstrings.
I also realize that it might be hard to automate the
fixing of existing docstrings.

Hello,

I have been working on a new major mode and it is striking me that, for
example, lisp-mode doesn't use generic-mode or derived-mode. It seems to
define just a couple of functions which set specific parameters. When
should generic-modes or derived-modes be created?

Any tutorial on creating new major modes around?

Cheers,

Daniel Pittman rimspace.net> writes: