Glenn Morris | 1 May 2012 03:08
Picon

bug#9741: 24.0.90; configure: prefer -ltinfo over -lncurses

Version: 24.2

Sven Joachim wrote:

> It would be nice if `configure' were looking for libtinfo and prefer
> to use -ltinfo over -lncurses.

Implemented (for gnu* systems).

Eli Zaretskii | 1 May 2012 04:42
Picon

bug#11351: 24.1.50; marker does not point anywhere

> Date: Mon, 30 Apr 2012 18:21:25 -0400
> From: Sam Steingold <sds <at> gnu.org>
> Cc: 11351 <at> debbugs.gnu.org
> 
> f 26
> #26 0x0000000000594f05 in marker_position (marker=36849115) at
> /home/sds/src/emacs/trunk/src/marker.c:777
> 777         error ("Marker does not point anywhere");

This is bug #9642, which was supposed to be fixed a couple of days
ago.  Is this a recent build?  If not, can you resync with the master
repository?

Glenn Morris | 1 May 2012 05:49
Picon

bug#11376: 24.1.50; Different background color before and after code


Please keep the debbugs addressed cc'd.

jasox lispy wrote (on Mon, 30 Apr 2012 at 14:26 +0200):

> On picture I run Emacs in standard way, now I tested starting emacs
> with 'emacs -Q' and get same bug (it is not clear white color). Can
> you please use gimp or other color picker to test on your system.

I tried on two different systems. The background is everywhere
#FFFFFF, so I don't think I can help you.

The last suggestion I have is that you send a minimal example file
that shows the problem, and say precisely at what positions you see
the different colours. Eg "at point 10, the bg is XXX, at point 100,
the bg is YYY".

Sam Steingold | 1 May 2012 05:55
Picon

bug#11351: 24.1.50; marker does not point anywhere

On Mon, Apr 30, 2012 at 22:42, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Mon, 30 Apr 2012 18:21:25 -0400
>> From: Sam Steingold <sds <at> gnu.org>
>> Cc: 11351 <at> debbugs.gnu.org
>>
>> f 26
>> #26 0x0000000000594f05 in marker_position (marker=36849115) at
>> /home/sds/src/emacs/trunk/src/marker.c:777
>> 777         error ("Marker does not point anywhere");
>
> This is bug #9642, which was supposed to be fixed a couple of days
> ago.  Is this a recent build?  If not, can you resync with the master
> repository?

is this recent enough?
(emacs-bzr-version "108056 cyd <at> gnu.org-20120427141602-0ahy51h0haplvlr9")
(emacs-version "24.1.50.3" "GNU Emacs 24.1.50.3
(x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2012-04-27 ")

--

-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

Glenn Morris | 1 May 2012 05:59
Picon

bug#11351: 24.1.50; marker does not point anywhere

Sam Steingold wrote:

> is this recent enough?
> (emacs-bzr-version "108056 cyd <at> gnu.org-20120427141602-0ahy51h0haplvlr9")

Nope.

http://lists.gnu.org/archive/html/emacs-diffs/2012-04/msg00487.html

martin rudalics | 1 May 2012 10:09
Picon
Picon

bug#11365: 24.1.50; quitting gdb does not restore window configuration

 >> Which command does "quit" run - `gdb-delete-frame-or-window'?
 >
 > dunno. the code indicates that, but the function seems too simple to
 > remove all those subordinate windows and buffers.

So you have to check your key bindings ;-)

martin

martin rudalics | 1 May 2012 10:08
Picon
Picon

bug#8368: 24.0.50; "temp" means "help" - rename or at least document

 > IF a programmer wants a temp buffer without that help
 > stuff then s?he can do something like what I wrote, as a workaround: define a
 > macro that uses `w-o-t-t-b', but first removes the help-stuff hooks and restores
 > them afterward.  That's all.

S?he could also write such a macro from scratch and post the result here
together with a suitable name.

 > Your suggestion was IIUC to instead use `w-o-t-t-b' and just turn off help-mode
 > in the BODY.  OK, but that means that help-mode is entered and exited for
 > nothing - the hooks are run uselessly.

Who cares?  The overhead for removing and adding a hook (with all the
necessary protection) is just as high.

 > That's all I was pointing out.  Nothing
 > wrong with such useless work, but it, like my workaround, does not seem like the
 > solution to the problem.

We agree here.

 >> Obviously, dealing with `temp-buffer-show-hook' in
 >> `with-output-to-plain-temp-buffer' isn't necessary either if you don't
 >> run `help-mode-setup' before.
 >
 > Ah, yes.  Of course that means paying even more attention etc.
 >
 > Anyway, thanks for thinking about this.  I really would like to see Emacs fixed
 > in this regard.  To my mind (not having thought much about it, and being pretty
 > ignorant about it), I would think that inheritance could be used to factor out
(Continue reading)

Juri Linkov | 1 May 2012 11:15
Favicon
Gravatar

bug#11378: 24.1.50; Suggestion: Let M-i in isearch cycle `search-invisible'

> There are more isearch filters that could share the same map `M-s f'.

Actually, currently these isearch filters can be used only one at a time.

It would be more useful to allow multiple filters by transforming
`isearch-filter-predicate' from the variable defining a predicate to the
hook-like list defining a set of predicates all of which should satisfy
for the search hit.

The default value could be a list with the current default element
`isearch-filter-visible'.  And it still could allow a symbol as its value
for backward compatibility.

Juri Linkov | 1 May 2012 11:03
Favicon
Gravatar

bug#11381: 23.3; isearch-search-and-update issue?

> Hi I'm trying to use the following macro as defined on the emacs wiki:
>
> http://emacswiki.org/emacs/SearchAtPoint#toc10

Looking at how this page presents 12 ways to invent the wheel,
the question arises: why not help people with some basic functionality
in isearch.el that could be used to build commands that will
work reliably and without such problems as reported by this bug report.

ISTM, what people are trying to achieve can be divided into the
three wishes:

1. Start Isearch with an initial search string, such as the
   word/symbol at point.

   One way would be to add a new argument to all commands
   that start Isearch.  But the drawback is that there are
   too many such commands (isearch-forward, isearch-backward,
   isearch-forward-regexp etc.)

   A better method is to add a global variable
   e.g. `isearch-string-initial' that will allow the user
   to define the initial search string.

2. Yank a thing at point to the search string
   (mostly a symbol/identifier).

   This means adding more yanking commands to accompany the existing
   `isearch-yank-word', `isearch-yank-word-or-char', etc.

(Continue reading)

linkk lispy | 1 May 2012 11:26
Picon

bug#11376: 24.1.50; Different background color before and after code



On Tue, May 1, 2012 at 5:49 AM, Glenn Morris <rgm <at> gnu.org> wrote:

Please keep the debbugs addressed cc'd.

ok 
jasox lispy wrote (on Mon, 30 Apr 2012 at 14:26 +0200):

> On picture I run Emacs in standard way, now I tested starting emacs
> with 'emacs -Q' and get same bug (it is not clear white color). Can
> you please use gimp or other color picker to test on your system.

I tried on two different systems. The background is everywhere
#FFFFFF, so I don't think I can help you.

The last suggestion I have is that you send a minimal example file
that shows the problem, and say precisely at what positions you see
the different colours. Eg "at point 10, the bg is XXX, at point 100,
the bg is YYY".
 
eg.

            (print "something")



Gmane