unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#9814: 23.3; unguarded setq of default-directory in ido.el
@ 2011-10-20 18:53 Dave Abrahams
  2011-10-29  5:43 ` Chong Yidong
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Abrahams @ 2011-10-20 18:53 UTC (permalink / raw)
  To: 9814


I'm sorry that I don't have a reproducer at the moment.  I was having
some failures during startup that would leave my Emacs unable to change
buffers with `M-x switch-to-buffer', which was remapped to
ido-switch-buffer, because it would attempt to make a Tramp connection
to some nonexistent host.  I could get around this by `M-: (setq
default-directory "~")', so I went hunting in ido.el for mentions of
default-directory and found 2 instances of (setq default-directory...)
that were not apparently surrounded by a let.  This seems like a likely
cause of the problem.

In GNU Emacs 23.3.1 (x86_64-apple-darwin10.8.0, Carbon Version 1.6.0 AppKit 1038.36)
 of 2011-09-12 on pluto.luannocracy.com
Windowing system distributor `Apple Inc.', version 10.6.8
configured using `configure  '--with-mac' '--enable-mac-app' '--prefix=/usr/local/stow/emacs-23.3' 'CC=gcc -arch x86_64''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  highlight-changes-visible-mode: t
  diff-auto-refine-mode: t
  recentf-mode: t
  pretty-control-l-mode: t
  Info-breadcrumbs-in-mode-line-mode: t
  workgroups-mode: t
  shell-dirtrack-mode: t
  me-minor-mode: t
  show-paren-mode: t
  ido-everywhere: t
  global-auto-revert-mode: t
  display-time-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mac-mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-n C-n C-p C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 





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

* bug#9814: 23.3; unguarded setq of default-directory in ido.el
  2011-10-20 18:53 bug#9814: 23.3; unguarded setq of default-directory in ido.el Dave Abrahams
@ 2011-10-29  5:43 ` Chong Yidong
  2011-10-31 19:24   ` Dave Abrahams
  0 siblings, 1 reply; 4+ messages in thread
From: Chong Yidong @ 2011-10-29  5:43 UTC (permalink / raw)
  To: Dave Abrahams; +Cc: 9814

Dave Abrahams <dave@boostpro.com> writes:

> I'm sorry that I don't have a reproducer at the moment.  I was having
> some failures during startup that would leave my Emacs unable to change
> buffers with `M-x switch-to-buffer', which was remapped to
> ido-switch-buffer, because it would attempt to make a Tramp connection
> to some nonexistent host.  I could get around this by `M-: (setq
> default-directory "~")', so I went hunting in ido.el for mentions of
> default-directory and found 2 instances of (setq default-directory...)
> that were not apparently surrounded by a let.  This seems like a likely
> cause of the problem.

I'm not too familiar with ido, and do not know whether those setqs are
intentional.  Could you try let-binding default-directory in those
locations and test it out for a while, and see if there is any effect?

=== modified file 'lisp/ido.el'
*** lisp/ido.el	2011-10-26 08:42:22 +0000
--- lisp/ido.el	2011-10-29 05:42:48 +0000
***************
*** 2381,2389 ****
  
         ((eq method 'alt-file)
  	(ido-record-work-file filename)
! 	(setq default-directory ido-current-directory)
! 	(ido-record-work-directory)
! 	(find-alternate-file filename))
  
         ((memq method '(dired list-directory))
  	(if (equal filename ".")
--- 2381,2389 ----
  
         ((eq method 'alt-file)
  	(ido-record-work-file filename)
! 	(let ((default-directory ido-current-directory))
! 	  (ido-record-work-directory)
! 	  (find-alternate-file filename)))
  
         ((memq method '(dired list-directory))
  	(if (equal filename ".")
***************
*** 2421,2432 ****
  
         ((eq method 'write)
  	(ido-record-work-file filename)
! 	(setq default-directory ido-current-directory)
! 	(setq filename (concat ido-current-directory filename))
! 	(ido-record-command 'write-file filename)
! 	(add-to-history 'file-name-history filename)
! 	(ido-record-work-directory)
! 	(write-file filename t))
  
         ((eq method 'read-only)
  	(ido-record-work-file filename)
--- 2421,2432 ----
  
         ((eq method 'write)
  	(ido-record-work-file filename)
! 	(let ((default-directory ido-current-directory))
! 	  (setq filename (concat ido-current-directory filename))
! 	  (ido-record-command 'write-file filename)
! 	  (add-to-history 'file-name-history filename)
! 	  (ido-record-work-directory)
! 	  (write-file filename t)))
  
         ((eq method 'read-only)
  	(ido-record-work-file filename)






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

* bug#9814: 23.3; unguarded setq of default-directory in ido.el
  2011-10-29  5:43 ` Chong Yidong
@ 2011-10-31 19:24   ` Dave Abrahams
  2013-07-09  4:46     ` Leo Liu
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Abrahams @ 2011-10-31 19:24 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 9814


on Fri Oct 28 2011, Chong Yidong <cyd-AT-gnu.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> I'm sorry that I don't have a reproducer at the moment.  I was having
>> some failures during startup that would leave my Emacs unable to change
>> buffers with `M-x switch-to-buffer', which was remapped to
>> ido-switch-buffer, because it would attempt to make a Tramp connection
>> to some nonexistent host.  I could get around this by `M-: (setq
>> default-directory "~")', so I went hunting in ido.el for mentions of
>> default-directory and found 2 instances of (setq default-directory...)
>> that were not apparently surrounded by a let.  This seems like a likely
>> cause of the problem.
>
> I'm not too familiar with ido, and do not know whether those setqs are
> intentional.  Could you try let-binding default-directory in those
> locations and test it out for a while, and see if there is any effect?

I've made the changes... I guess the best report you can expect, unless
I get myself into trouble at startup again, is that it has no effect.
Will you check back with me in a week?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com





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

* bug#9814: 23.3; unguarded setq of default-directory in ido.el
  2011-10-31 19:24   ` Dave Abrahams
@ 2013-07-09  4:46     ` Leo Liu
  0 siblings, 0 replies; 4+ messages in thread
From: Leo Liu @ 2013-07-09  4:46 UTC (permalink / raw)
  To: Dave Abrahams; +Cc: Chong Yidong, 9814-done

On 2011-11-01 03:24 +0800, Dave Abrahams wrote:
> I've made the changes... I guess the best report you can expect, unless
> I get myself into trouble at startup again, is that it has no effect.
> Will you check back with me in a week?

I believe this bug might have been fixed already. It might have
something to do with ido-may-cache-directory trying tramp hosts.

Leo





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

end of thread, other threads:[~2013-07-09  4:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-20 18:53 bug#9814: 23.3; unguarded setq of default-directory in ido.el Dave Abrahams
2011-10-29  5:43 ` Chong Yidong
2011-10-31 19:24   ` Dave Abrahams
2013-07-09  4:46     ` Leo Liu

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).