Artur Malabarba | 30 Nov 16:54 2015

Char-folding: how can we implement matching multiple characters as a single "thing"?

I pushed this feature a couple of days ago, but I had to disable it
now (the code is in `character-fold-to-regexp').

For those who don't know, the way char-folding works is by replacing
each character in the search string with a regexp of the characters it
can match.
For instance, a character-folding search for "fi" is actually a regexp
search for "\\(?:ḟ\\|[fᶠḟⓕf𝐟𝑓𝒇𝒻𝓯𝔣𝕗𝖋𝖿𝗳𝘧𝙛𝚏]\\)\\(?:i[̀-̨̣̰̄̆̈̉̌̏̑]\\|[iì-ïĩīĭįǐȉȋᵢḭỉịⁱℹⅈⅰⓘi𝐢𝑖𝒊𝒾𝓲𝔦𝕚𝖎𝗂𝗶𝘪𝙞𝚒]\\)".

As you can see, this multiplies the length of the string by a factor
of about 45. But that's still acceptable.

However, this only includes foldings for the 'f' character and the 'i'
character independently. As it happens, the string "fi" can also match
the ligature 'fi'.
Now, for the sake of conciseness, let me denote the f and i regexps
above as [f] and [i].

The code I pushed a couple of days ago added support for multi-char
matches (such as "fi" matching that ligature), but returning a regexp
like this: "\\([f][i]\\|fi\\)"
This might not look like much. It only adds a few chars to a regexp
that already has about 90. But the problem is that it introduces a new

Let's say we want to search for the word "fix". The letters 'i' and
'x' could also represent the character 'ⅸ' (roman numeral nine). So
the only way to write that regexp is:
Now the pattern [x] (which I remind you has ~ 40 chars) appears twice
(Continue reading)

Michael Heerdegen | 30 Nov 16:26 2015

Is `kbd' idempotent?


is `kbd' idempotent?

I want to prompt the user for a key sequence in any common format.  If
he enters a string and already uses the format that `kbd' outputs, can
it be bad to call `kbd' on the input?



Paul Eggert | 30 Nov 06:25 2015

getting emacs-25-to-master merges working again

Today I got burned again by a bug in Emacs master that has been fixed in 
emacs-25.  Right now, my impression is that the master branch has serious 
unfixed bugs; I wouldn't recommend it for routine use. At some point we need to 
get emacs-25 merged with master, to fix the bugs. I drafted a patch to help do 
this (attached). It still needs work but I thought I'd send what I have, to help 
get the ball rolling.

The main problem in getting merging to work again is that changes to ChangeLog.2 
in emacs-25 will collide with changes to ChangeLog.2 in the master. The attached 
patch attempts to fix this by renaming ChangeLog.2 to ChangeLog-25.0 in 
emacs-25, and to create a new file ChangeLog-25.1 in master, such that 'make 
change-history' updates ChangeLog-25.0 in emacs-25 and updates ChangeLog-25.1 in 
master.  That way, the two sets of histories ordinarily shouldn't overlap and 
changes to one shouldn't collide with the other.

Undoubtedly there will be kinks in this process that need to be ironed out, 
e.g., when backporting changes from master to emacs-25. One way to iron them out 
will be to review and/or improve this patch. Another is to install this patch, 
do a merge, and deal with the resulting fallout.  Either will take nontrivial work.

I'm thinking, though, that there should be a better way, by using the --cherry 
option of 'git log', and by generating ChangeLog.2 and/or ChangeLog-25.1 
specially during a merge. I haven't had time to investigate this yet, though.
Artur Malabarba | 30 Nov 01:09 2015

Some textual changes to the Emacs website

WRT the contents of this page:

On 29 Nov 2015 10:11 pm, "Nicolas Petton" <nicolas <at>> wrote:
> > Are you taking suggestions on content changes?
> Not at this point (well, you can send your suggestions anyway, I'll keep
> them for later).

I suggest we improve the following sentence:
> Content-sensitive editing modes, including syntax coloring, for a variety of file types including plain text, source code, and HTML.

"Content-sensitive editing modes" is cryptic even to me. I would just use "Specialized support" or "Specialized functionality" (I actually don't like the word specialised here, but I'm drawing blank on something better).

Also "a variety of" is one hell of an understatement. I think I'd say "Dozens of" (or are we in the hundreds?).

On another sentence. "A large number of extensions that add other functionality," sounds like addons you have to download or install somehow. But it's actually referring to builtin stuff like org mode and gnus.
How about "An entire ecosystem of functionality beyond text editing,"?

Fabrice Popineau | 29 Nov 23:34 2015

make check


Is there any reason why `make check' on the master branch stopped working ?
Or is it only me ?

make[1] : on entre dans le répertoire « /c/source/emacs/build-x64/test »
make[2] : on entre dans le répertoire « /c/source/emacs/build-x64/test »
make[2]: ***  Aucune règle pour fabriquer la cible « ../../emacs/test/lisp/abbrev-tests.log », nécessaire pour « check-maybe ». Arrêt.
make[2] : on quitte le répertoire « /c/source/emacs/build-x64/test »

It is telling me that there is no rule for making the target  ../../emacs/test/lisp/abbrev-tests.log

What am I missing ?

Thanks in advance,

raman | 29 Nov 22:13 2015

Typo on emacs Web site

in the history section.



Eli Zaretskii | 29 Nov 17:34 2015

Please add comments to isearch.el

Would someone "in the know" please add commentary to isearch.el to
explain how the various options are passed to the commands defined
there and affect or not affect them?

The isearch.el commands are implemented using complex multi-layered
system of functions and macros that make it very hard to figure out,
just by looking at the code, which options affect what commands and in
what ways.  About the only way to find that out is by trying each
command, which is very inefficient.  I think it will help make this
file much more maintainable if commentary were added there explaining
how all of this works.  Thanks in advance.

David González Gándara | 29 Nov 13:33 2015

Packed transcribe created

I have just created the folder and copied the code of the module "transcribe" to the ELPA repository
Nicolas Petton | 29 Nov 00:29 2015

First draft of the Emacs website

Hi guys,

I think I'm ready to show my work on the website of Emacs:

A few notes:

- It's a work in progress
- I only worked on the homepage
- It's not yet responsive
- Many links don't work yet
- I haven't changed much the content of the website itself, it's mostly

Feedback welcome!

Dmitry Gutov | 28 Nov 21:41 2015

Re: bug#22029: 25.1.50; etags/tag search seems to fail

Please keep emacs-devel in Cc.

On 11/28/2015 10:38 PM, jpff wrote:
> I have never been directed to a branch in all the years I have been
> following the development code, decades rather.

AFAIR, we at least did that for emacs-24, during the previous 
development cycle.

> Anyway branch emacs-25 does not build wit
> rm -f src/
> echo timestamp > src/
> cd . && /bin/sh /home/jpff/GNU/emacs/build-aux/missing automake-1.13
> --gnu -a -c lib/Makefile
> make: *** No rule to make target 'test/', needed by
> 'Makefile'. Stop.

I have no idea what any of that means.
Why don't you do the build the easy way?

make clean # could be unnecessary
make bootstrap

Drew Adams | 28 Nov 06:04 2015

lax matching is not a great default behavior

This has been discussed somewhat, but I don't think there was
any actual proposal to change the behavior.  So here goes.

Does it still make sense to make search and replacement
use lax matching, i.e., fold stuff, by default?

I don't think it does.  I think that users, especially
new users, would be less confused if Emacs defaulted to
literal searching - no whitespace, case, "character",
or other folding by default.

Folding features and their combinations and customizations
will only increase in the future (at least I hope so -
that's a good thing).  The starting point that is the
least ambiguous, least surprising, and least difficult for
a user to discover and understand is zero folding: literal

I realize that this would change the longstanding practice
of having letter-case folding be default.  I think that
choice made sense back when most programming languages and
OS's did not have a letter-case difference.  But I don't
think it is the best choice for the default behavior now.

Same for whitespace folding, though that is not longstanding.

Even more so for "character" folding, i.e., ignoring
diacriticals and differences among quote marks etc. (and
some other ad hoc equivalences).  Such classes might be
clear to those who are familiar with them, and this folding
feature can certainly be useful.  But I don't think it is
the right choice for the default behavior.

Literal search is dead simple, plain, obvious, boring, clear.

Anyone who wants to go further, and fold whitespace, for
instance, can easily ask Emacs how to do that and find out
that there is a simple toggle key for it.  Starting with
whitespace folding turned on, on the other hand, can be
confusing, particularly for programmers, who often care
about which whitespace chars, and how many, they are
searching for.

Similarly for case fold.  Let's start with WYTIWYSF: what
you type is what you search for.  Anyone who wants to
abstract from letter case can easily ask Emacs how to do
that and find out that a simple toggle key suffices.

(Yes, there is also the "clever" complication of automatic
case-fold-search change when an upper-case char is present.
I don't propose any change in that regard now, but I do
think that its time is also soon up.  Not so useful as a
default behavior, IMO.  And I don't think it was a great
idea to copy the same cleverness for "character" folding.
But this is a different story.)

It's likely I won't have more to say about this.  I think
the pros & cons are pretty straightforward.  It's more a
question of choosing than arguing reasons at this point,
I expect.