headers
Lars Magne Ingebrigtsen | 1 Jul 2011 01:00
Face
Picon
Favicon
Gravatar

bug#5664: 23.1.92; view-lossage

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> For eshell i didn't find good solution appart putting in my .emacs:
>
> (setenv "LC_ALL" "C")
>
> Work fine but may create other encoding problems in others places.
>
> The best thing should be that all emacs shell don't obey to locale
> setting for password prompt, i thing the word "password" in
> international well known.

You mean setting LC_ALL to C for all subshells?  I'm not sure that's
what most people would want.  But having the passwords show up in clear
text in the shell buffers is totally icky, too.  (I just fixed comint to
do the password recognition for the

[larsi <at> quimbies ~/src/emacs/trunk/lisp]$ ssh root <at> quimby
Password: 
Response: 

case just now, though.)

But for other locales: Perhaps Shell mode should have an interactive
function like `M-x shell-query-password', so that people can trigger the
non-echoing entry mode at will?  Or perhaps a keystroke to switch off
echoing, that would be ended when typing RET?

--

-- 
(domestic pets only, the antidote for overdose, milk.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lars Magne Ingebrigtsen | 1 Jul 2011 01:44
Face
Picon
Favicon
Gravatar

bug#4359: 23.1.50; ^G in M-x grep mode with git grep

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>> This would be an ad-hoc workaround that does not work for the next
>> tool.  What is needed is that the command is called such that git or
>> the pager doesn't think they are in an interactive environment.
>
> That is easy, use a pipe instead of a pty (see process-connection-type).

Are there any reasons why `M-x grep' and friends
(i.e. `compilation-start', really) shouldn't bind
`process-connection-type' to nil?

That is, do any of the `compile'-derived functions need a pty?

--

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Permalink | Reply | 0 comments |
headers
Ulrich Neumerkel | 1 Jul 2011 01:50
Picon
Favicon

bug#4359: 23.1.50; ^G in M-x grep mode with git grep

Lars Magne Ingebrigtsen:
>Are there any reasons why `M-x grep' and friends
>(i.e. `compilation-start', really) shouldn't bind
>`process-connection-type' to nil?

M-x grep highlights the actual matches.  So this is not a simple pipe.
Permalink | Reply | 6 comments |
headers
Lars Magne Ingebrigtsen | 1 Jul 2011 02:01
Face
Picon
Favicon
Gravatar

bug#4359: 23.1.50; ^G in M-x grep mode with git grep

Ulrich Neumerkel <ulrich <at> complang.tuwien.ac.at> writes:

> Lars Magne Ingebrigtsen:
>>Are there any reasons why `M-x grep' and friends
>>(i.e. `compilation-start', really) shouldn't bind
>>`process-connection-type' to nil?
>
> M-x grep highlights the actual matches.  So this is not a simple pipe.

Right, so when grep detects that it's not a PTY, it switches the
GREP_COLOR(S) stuff off?  And there's no way to force that to be on?

--

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Permalink | Reply | 5 comments |
headers
Juri Linkov | 1 Jul 2011 03:11
Favicon
Gravatar

bug#4359: 23.1.50; ^G in M-x grep mode with git grep

>>>Are there any reasons why `M-x grep' and friends
>>>(i.e. `compilation-start', really) shouldn't bind
>>>`process-connection-type' to nil?
>>
>> M-x grep highlights the actual matches.  So this is not a simple pipe.
>
> Right, so when grep detects that it's not a PTY, it switches the
> GREP_COLOR(S) stuff off?  And there's no way to force that to be on?

Yes, grep switches colors off if it's not a PTY:

http://thread.gmane.org/gmane.emacs.devel/83316/focus=83449
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Jul 2011 03:32
Picon

bug#8869: Unjustified selection time-out

>> I was not sure how the interaction between read_kbd being 0 and
>> different types of events (keyboard, mouse vs the rest) are supposed
>> to work.  But if you are sure then that is good.  Anyway we have a
>> long time to release yet :-)
> I am as sure as anyone can be from staring at that particular piece of
> code.  So let's see ;-)
>> BTW, should the bug be closed?
> Yeah; closing.

FWIW, I still see the same problem.

        Stefan
Permalink | Reply | 12 comments |
headers
Daiki Ueno | 1 Jul 2011 03:44
Gravatar

bug#8963: 24.0.50; gnus-no-server tries to connect to IMAP server

Lars Magne Ingebrigtsen <lmi <at> gnus.org> writes:

>> (setq gnus-select-method '(nnnil "")
>>       gnus-secondary-select-methods
>>       '((nnimap "a"
>> 		(nnimap-address "a.example.org")
>> 		(nnimap-username "daiki")
>> 		(nnir-search-engine imap))
>> 	(nnimap "b"
>> 		(nnimap-address "b.example.com")
>> 		(nnimap-username "dueno")
>> 		(nnir-search-engine imap))))
>
> What `gnus-no-server' does is start Gnus on level 2 instead of the
> default level 5 level.  So if you have groups on level 1 and 2,
> `gnus-no-server' will still contact the servers with groups on those
> levels.

I'm not sure that gnus-secondary-select-methods actually works, but Gnus
in Emacs 23 (or earlier) doesn't contact to the server even if I have
the above gnus-secondary-select-methods setting.

My understanding is that levels are per-group and not per-server, and
all groups defined in ~/.newsrc.eld have level 3.  So I'm wondering
which group Gnus is trying to open.

Regards,
--

-- 
Daiki Ueno
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stefan Monnier | 1 Jul 2011 04:55
Picon

bug#8968: arc-mode 7z writing support

> I'd like to install a patch that implements update/delete operations
> for 7z archives in arc-mode.el:

Go ahead,

        Stefan
Permalink | Reply | 16 comments |
headers
Stefan Monnier | 1 Jul 2011 05:15
Picon

bug#8803: 23.3; backtrace should use find-function-source-path to find source

> In the mean time, does the patch below work for you?

I installed it and assume it's fixed.  Please reopen the bug if not.

        Stefan
Permalink | Reply | 0 comments |
headers
Thierry Volpiatto | 1 Jul 2011 06:41
Picon
Gravatar

bug#8926: 24.0.50; pcomplete regression

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>>> Yup.  Because among the various completion cases, the case for "files"
>>>>> used to return a list and now returns a function.  Both are valid
>>>>> completion tables.  Any caller of pcomplete-completions should expect to
>>>>> receive a completion table and not just a list of strings.  It may very
>>>>> well receive a list of strings (which is one kind of completion table),
>>>>> but it may just as well receive something else.
>>>> Yes i saw that, and it's what i didn't understand.
>>> 
>>> BTW, the reason for the above change was not just to fix a bug when
>>> using pcomplete-completions-at-point but also so that partial-completion
>>> now works with pcomplete-entries (so you can "cd ~/e/e TAB" to go to
>>> ~/etc/emacs).
>> Yes, but the downside is now that it is hard to use by external
>> libraries outside the context of emacs shell/eshell.
>
> Presumably such code already handles completion tables, so having to
> handle a completion table rather than a list of strings shouldn't be
> that much of a problem.  Calling `all-completions' shouldn't scare
> those authors.
The problem is not here, the problem is we have now to do extra
computing to extract the context (i.e command?, lisp-sym?, filename?...).
before, running `pcomplete-completions' was doing all the job, now we
have to use also (funcall (pcomplete-entries) string nil nil) to guess
filename, and then decide what to do.

e.g
(all-completions what (pcomplete-completions))
now we have to extract "what", before `pcomplete-completions' was guessing
(Continue reading)

Permalink | Reply | 2 comments |

Gmane