unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Diagnosing a curious minibuffer problem (proliferating, weird initial contents)
@ 2015-01-20 17:05 Florian v. Savigny
  2015-01-21  4:26 ` Michael Heerdegen
  0 siblings, 1 reply; 4+ messages in thread
From: Florian v. Savigny @ 2015-01-20 17:05 UTC (permalink / raw)
  To: help-gnu-emacs



Dear wizards,

I need some assistance on how to pinpoint, diagnose and/or reproduce a
problem with minibuffer initial contents. I tend to think that I
caused this problem myself, but since I have deactivated (i.e. moved to a
file that is not loaded) the function which I would most consider
suspicious, I am at a loss.

The symptoms are as follows:

- When I start Emacs, and for a good deal of activity, everything is
  normal.

- After a while (and I cannot specify it more exactly; the moment when
  it starts seems unpredictable), commands which use completing-read
  (even M-x, but also functions which I have written myself) start to
  have inappropriate stuff as initial content. As far as I can
  remember, this inappropriate stuff is all file names.

- If this goes on longer, more inappropriate stuff is appended to the
  initial content, i.e. after a while, e.g. M-x offers you a long
  string of concatenated file names. You can either choose to delete
  this long monster, or you can get rid of it by typing M-p, which
  gives you shorter minibuffer contents.

- and so on (the monster gets longer and longer)


[speculation]

To me, this looks as if functions which use completing-read consult
some variable to decide what to use as INITIAL-INPUT, and I have
somehow managed to systematically clutter this variable. This is a bit
weird, though, because they usually offer just completion, no intial
contents. And it's just one possibility anyway.

[/speculation]

I have no idea how to get to the root of the problem. I cannot edebug
completing-read, in any case. (That is what I would try otherwise,
anyway.)

Can anybody give me any advice on how to pinpoint, isolate, reproduce,
provoke this problem? I would be awfully grateful, because my "Emacs
system" is complex and I need to run it every day.

Thank you so much!

Best regards,

Florian

-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld



^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Diagnosing a curious minibuffer problem (proliferating, weird initial contents)
       [not found] <<87r3uptmbj.fsf@bertrandrussell.Speedport_W_723V_1_36_000>
@ 2015-01-20 17:49 ` Drew Adams
  0 siblings, 0 replies; 4+ messages in thread
From: Drew Adams @ 2015-01-20 17:49 UTC (permalink / raw)
  To: Florian v. Savigny, help-gnu-emacs

> - After a while (and I cannot specify it more exactly; the moment when
>   it starts seems unpredictable), commands which use completing-read
>   (even M-x, but also functions which I have written myself) start to
>   have inappropriate stuff as initial content. As far as I can
>   remember, this inappropriate stuff is all file names.
> 
> - If this goes on longer, more inappropriate stuff is appended to the
>   initial content, i.e. after a while, e.g. M-x offers you a long
>   string of concatenated file names. You can either choose to delete
>   this long monster, or you can get rid of it by typing M-p, which
>   gives you shorter minibuffer contents.
> 
> Can anybody give me any advice on how to pinpoint, isolate, reproduce,
> provoke this problem? I would be awfully grateful, because my "Emacs
> system" is complex and I need to run it every day.

First of all, check what happens without your init file: `emacs -Q'.
If you see the same problem, try to note a recipe to reproduce it and
file a bug report, giving that recipe: `M-x report-emacs-bug'.

If you do not see the problem with `emacs -Q' then recursively bisect
your init file to find the culprit code.  You can use command
`comment-region' to comment out 1/2 of it, then 3/4, then 7/8, 15/16, etc.
You can use `C-u' with `comment-region' to uncomment the region.

This is a *binary search*, so it is very quick.  It is the way to proceed
always, but *especially* if your "Emacs system is complex".  Do not
try to debug a giant sac of stuff - break it down systematically.

If you have a question after finding the culprit code/setting, post it here.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Diagnosing a curious minibuffer problem (proliferating, weird initial contents)
  2015-01-20 17:05 Florian v. Savigny
@ 2015-01-21  4:26 ` Michael Heerdegen
  2015-01-21  8:31   ` Marcin Borkowski
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Heerdegen @ 2015-01-21  4:26 UTC (permalink / raw)
  To: help-gnu-emacs

florian@fsavigny.de (Florian v. Savigny) writes:

> I have no idea how to get to the root of the problem. I cannot edebug
> completing-read, in any case. (That is what I would try otherwise,
> anyway.)

I would try trace-function-background on completing-read and check with
which args it is called when the problem appears.  Especially check the
INITIAL-INPUT arg.

In any case, using the normal debugger (not edebug) is useful,
e.g. debug-on-entry completing-read, check how it is called etc.

Check elements of minibuffer-setup-hook whether there could be the
culprit.

Finally, the mysterious initial inputs must be stored somewhere.  Try to
find out with `apropos-value'.


Michael.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Diagnosing a curious minibuffer problem (proliferating, weird initial contents)
  2015-01-21  4:26 ` Michael Heerdegen
@ 2015-01-21  8:31   ` Marcin Borkowski
  0 siblings, 0 replies; 4+ messages in thread
From: Marcin Borkowski @ 2015-01-21  8:31 UTC (permalink / raw)
  To: help-gnu-emacs


On 2015-01-21, at 05:26, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Finally, the mysterious initial inputs must be stored somewhere.  Try to
> find out with `apropos-value'.

Good point.  Also, rzgrep-ing through Emacs Lisp sources might help.

> Michael.

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-01-21  8:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <<87r3uptmbj.fsf@bertrandrussell.Speedport_W_723V_1_36_000>
2015-01-20 17:49 ` Diagnosing a curious minibuffer problem (proliferating, weird initial contents) Drew Adams
2015-01-20 17:05 Florian v. Savigny
2015-01-21  4:26 ` Michael Heerdegen
2015-01-21  8:31   ` Marcin Borkowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).