From: florian@fsavigny.de (Florian v. Savigny)
To: help-gnu-emacs@gnu.org
Subject: Diagnosing a curious minibuffer problem (proliferating, weird initial contents)
Date: Tue, 20 Jan 2015 18:05:04 +0100 [thread overview]
Message-ID: <87r3uptmbj.fsf@bertrandrussell.Speedport_W_723V_1_36_000> (raw)
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
next reply other threads:[~2015-01-20 17:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 17:05 Florian v. Savigny [this message]
2015-01-21 4:26 ` Diagnosing a curious minibuffer problem (proliferating, weird initial contents) Michael Heerdegen
2015-01-21 8:31 ` Marcin Borkowski
[not found] <<87r3uptmbj.fsf@bertrandrussell.Speedport_W_723V_1_36_000>
2015-01-20 17:49 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3uptmbj.fsf@bertrandrussell.Speedport_W_723V_1_36_000 \
--to=florian@fsavigny.de \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).