Drew Adams | 3 Sep 19:15 2015
Picon

RE: char equivalence classes in search - why not symmetric?

> Yes, and you can count me among those objections. 
> When I first started with emacs, case folding by default was something
> I liked a lot, before I ever knew how to configure this stuff.
> I also only learned about lax whitespace when it became the default (IIRC).
> It was a feature that already existed and yet I had no idea because
> it wasn't default.

Emacs _should_ work on improving discoverability, IMO, but that
is a separate discussion.

IMO and FWIW, it is misguided to provide confusing, dwim behavior
by default.  Hard for a newbie to guess what the behavior really
is, because it is too complex, conditional, contextual, whatever.

The argument that we have this nifty feature and newbies won't
discover it on their own easily, so let's foist it upon them
from the outset, as the default behavior, is quite misguided.

What should be done is to have simple, obvious default behavior,
easy to fathom.  AND to have easy ways to discover alternate,
optional, fancy behavior that some of us might be convinced is
handier, more powerful, more elegant, or more clever.

Discoverability is not an argument for choosing any default
behavior.  Poor discoverability is an argument for improving
discoverability.  Nothing more.

That should be a no-brainer, IMO, but we hear this over and over
again.  Developers like to show off the clever things they come
up with.  That's human and normal.  Add such things, sure, but
(Continue reading)

Kaushal Modi | 3 Sep 18:31 2015
Picon

yes-or-no-p prompt conditionally broken in master?

Hi all,

I tend to keep my e
​​
macs build updated with the master every few days.

My last build was 2 days back at this commit: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a3c31adea4970b8a7fc7f495e6a6a6d4a93e69ce and everything worked fine.

PROBLEM:
- When on latest master, for ANY yes-or-no-p prompt, for the first prompt I cannot see the prompt question. At times, all I see is the cursor at the very left in the minibuffer. At times, I see no cursor and have to assume that the minibuffer is in focus. I blindly need to hit y or n to proceed (for example when quitting emacs). Some times, 2nd prompt onwards the prompt questions start appearing fine.
- This issue goes away if I revert to the above linked commit with my emacs config.
- This issue also goes away in an emacs -Q session while on the latest commit on master.

Below are all the commits after that commit that works for me.
So some package I have installed is clashing with one of the below commits.

I tried debugging but cannot narrow down to the problem. Can one of the authors would know if their commit could have possibly changed how yes-or-know-p prompt display behaved? A proper direction will help me debug the problem faster.

| Dmitry Gutov    | vc-git-mode-line-string: Explicitly re-apply the faceHEADmaster  |
| Paul Eggert     | Treat initial-scratch-message as a doc string                    |
| Paul Eggert     | Fix describe-char bug with glyphs on terminals                   |
| Paul Eggert     | Follow text-quoting-style in display table init                  |
| K. Handa        | Fix typo                                                         |
| K. Handa        | Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs           |
| K. Handa        | fix previous change                                              |
| David Caldwell  | * lisp/vc/vc-hooks.el (vc-refresh-state): New command            |
| Paul Eggert     | Escape ` and ' in doc                                            |
| Stefan Monnier  | Generalize the prefix-command machinery of C-u                   |
| Paul Eggert     | Rework quoting in tutorial                                       |
| Paul Eggert     | Setup quote display only if interactive                          |
| Katsumi Yamaoka | Use defalias at the top level                                    |
| Paul Eggert     | terminal-init-w32console mimicks command-line                    |
| Paul Eggert     | Display replacement quotes with shadow glyphs                    |
| Michael Albinus | * lisp/net/tramp-sh.el (tramp-methods) <sudo>: Mask "Password:". |

PS: One of the packages I have installed is http://elpa.gnu.org/packages/minibuffer-line.html and I thought that that might be causing the problem. But disabling that did not fix this.
Simen Heggestøyl | 3 Sep 17:50 2015
Picon

seq-some-p and nil

Hi!

Currently it's not possible to use `seq-some-p' to check if a sequence
contains some `nil' value. For instance:

(seq-some-p #'null '(1 2))
     ⇒ nil

Which is good, but:

(seq-some-p #'null '(1 nil 2))
     ⇒ nil

How to distinguish the two cases?

Two solutions come to my mind: 1) Make `seq-some-p' a pure t/nil
predicate, or 2) Make it behave like `some' in Common Lisp, which is
to return the first non-nil value which is returned by an invocation
of the predicate. So in CL:

(some #'null '(1 2))
     ⇒ nil

And:

(some #'null '(1 nil 2))
     ⇒ t

And even:

(some #'1+ '(5 4 3))
     ⇒ 6

What do you think?

-- Simen
Richard Stallman | 3 Sep 17:38 2015
Picon
Picon

lax whitespace search

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

When we discussed this a few days ago, I thought I found that only SPC
did a lax search.

However, I just found that C-j was also doing a lax search.
I put this text in a Fundamental mode buffer

foo D is on the
Desk

and typed C-s C-j D.  It found both Ds.

That is clearly wrong.  If I wanted a lax whitespace search, I'd type
SPC.

Please fix this so that C-j searches only for itself.

--

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Alexander Shukaev | 3 Sep 02:18 2015
Picon

Reimplementation of `called-interactively-p'

Hello,

I found [1] quite interesting.  Was this already incorporated into
Emacs at some point or not?  I guess it would be reasonable to address
those bugs.

[1] https://gist.github.com/DarwinAwardWinner/6517641

Uwe Brauer | 2 Sep 18:38 2015
Picon

sub and superscripts: without «_» and «^»


Hello

I asked this on auctex-dev but it might be question concerning core
functionality of GNU emacs:

It is possible to display super and sub indices lowered and rised, but
the «_» and «^» are still visible.

(Xemacs can display, based on very different implementation indeed sub
and super scripts without the «_» and «^», however relies on a orphaned
package)

Are there any plans to implement such a feature?

Thanks

Uwe Brauer 

Uwe Brauer | 2 Sep 15:28 2015
Picon

backward compatibility GNU emacs 24 / 25 diary lib.

Hello

In GNU emacs 24 diary-lib contained

(define-obsolete-function-alias 'make-diary-entry 'diary-make-entry "23.1")

In 25 this alias was deleted causing problems in some old code of mine.
Why do you break backward compatibility on purpose?

Regards

Uwe Brauer  

Drew Adams | 1 Sep 18:40 2015
Picon

`char-fold-table'

Why is `char-fold-table' a defconst?

When this feature was introduced, while applauding it I
pointed to the aim of letting users and libraries define
their own equivalence classes of chars, for character
folding.

I was told to hold off, that while that is a goal, we
should not discuss it now because that might interfere
with accomplishing a preliminary version of char folding.
And that users could always modify the char table provided
or create their own, to modify the behavior.

OK.

So here we are now, with char folding.  Great.  So can
we now consider facilitating users defining their own
classes of characters?  Or making it easy for them to
modify the default equivalence classes?

Making `char-fold-table' a defconst seems wrong.  What's
the right way to enable users and code to customize such
things?

Not only do we hard-code the equivalence classes, but we
don't even tell users what they are.  Not really.  The
only thing they have so far is option - nay, defvar,
`character-fold-search', whose doc tells them only that

 "some characters will match entire groups of characters.
  For instance, " will match all variants of double quotes
  and the letter a will match all of its accented versions
  (and then some)"

"some characters"?  "For instance"?  "(and then some)"?

Yes, I know that the doc for this feature is still to be 
written, and that this the feature is still a work in
progress.  But let's please progress it - in the direction
of more and better info for users and helping users modify
and extend the behavior.

Wieland Hoffmann | 1 Sep 18:28 2015
Picon

[PATCH] ; Clarify :create in auth-source's docs

* lisp/gnus/auth-source.el: Clarify :create's meaning by rewriting a
sentence.
---
 lisp/gnus/auth-source.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/gnus/auth-source.el b/lisp/gnus/auth-source.el
index 3f426bf..b4e319a 100644
--- a/lisp/gnus/auth-source.el
+++ b/lisp/gnus/auth-source.el
 <at>  <at>  -560,7 +560,7  <at>  <at>  other properties will always hold scalar values.
 Typically the :secret property, if present, contains a password.

 Common search keys are :max, :host, :port, and :user.  In
-addition, :create specifies how tokens will be or created.
+addition, :create specifies if and how tokens will be created.
 Finally, :type can specify which backend types you want to check.

 A string value is always matched literally.  A symbol is matched
--

-- 
2.5.1

Drew Adams | 1 Sep 17:49 2015
Picon

`character-fold-search' should be a user option, like `case-fold-search'

Subject line says it all.  Users should be able to customize
this variable, to decide for themselves, without fiddling with
`setq', whether search starts by default with or without
character folding.  They should be able to find this easily,
as an option in custom group `matching', right alongside
`case-fold-search'.

No?

I customized `case-fold-search' to nil long ago, and I will
likely do the same for `char-fold-search': set it to nil.
By default I want search to distinguish different characters.

Different users have different uses and different preferences.

Fortunately, the behavior can be toggled.  But the default
behavior should also be customizable.  Users should not need
to use `setq' for `char-fold-search' but be able to customize
`case-fold-search'.  This is a (minor) step backward, IMO.

Drew Adams | 1 Sep 17:46 2015
Picon

char equivalence classes in search - why not symmetric?

When character folding is turned on, shouldn't you be able to
search for á and find (match) a, à, ã, ª, â, å, and ä?

I think so.  Currently you cannot - you can only do the reverse:
search for a and find any of the above.  a is treated specially.
Why?

I suppose that the logic behind the current implementation is
to mirror what we do with case-fold searching.  But is that the
right thing in this case?

For case-fold searching, it was thought that if you bother to
hold the Shift key and thus use an uppercase letter then you
want to match case, and otherwise you do not (case-insensitive).

This was essentially, I think, a shortcut for programmers, and
it was introduced at a time when much of the code being searched
was case-ambivalent.  (UNIX was still pretty much an exception
at that point, in distinguishing lowercase letters.)

Whether or not this behavior for case-fold is still a good thing
is questionable now, I think.  I don't think it is necessary now
or particularly useful.  And I think it can be confusing to
newbies.  Why should searching for A be different from searching
for a, wrt case matching?

But I'm not really questioning the behavior of case-fold
searching now.  I am questioning applying this same behavior
to char folding.

To me, folding a group of chars together for search purposes
should be symmetric - go both ways.  It should, in effect,
treat the given group of chars as equivalent - as an
equivalence class wrt searching.

Why not?  Why, when char folding, treat plain a specially for
searching?  Why not treat á, a, à, ã, ª, â, å, and ä the same?
Isn't that the point here?  We are telling Isearch that they
are equivalent.  Why pick one of them as the canonical
search-pattern to use for finding any of them?  Why privilege
a over á, a, à, ã, ª, â, å, and ä?

Now most of the time I, like most people, will by typing a
instead of á into a search string.  But that's not really the
point.  I think users should be able to use any members of an
equivalence class of chars indifferently.

And when it comes to chars other than letters, it might well
be that some users, with some keyboards, will find some chars
in an equivalence class easier to type than others.  Let them
use/type whichever they like, no?

This feature, welcome as it is, seems only half-baked, so far.
How about equality for char-folding equivalence?


Gmane