all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: No coding system used for environment variables
@ 2008-07-24  0:01 Chong Yidong
  2008-07-24  0:10 ` Jason Rumney
  2008-07-24  0:10 ` bug#38: " Jason Rumney
  0 siblings, 2 replies; 6+ messages in thread
From: Chong Yidong @ 2008-07-24  0:01 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu, Jason Rumney; +Cc: 38, emacs-devel

> It seems there is no coding system applied to values of environment
> variables.

What's the current situation with this bug?  Jason's patch was reverted,
but nothing else seems to have been done after that.

Two objections were made to Jason's patch: (i) some coding systems are
not ready until some .elc files get loaded (relevant for special cases,
such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
so variables such as `nm' in Fexpand_file_name may not point to valid
data after that.

If no elegant solution is forthcoming, I'd suggest simply documenting
(i) as a limitation, and dealing with (ii) by simply turning off GC in
the affected part of the function.

I noticed that the patch posted at

http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html

has not been checked into the trunk either.




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

* bug#38: No coding system used for environment variables
@ 2008-07-24  0:01 Chong Yidong
  0 siblings, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2008-07-24  0:01 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu, Jason Rumney; +Cc: 38, emacs-devel

> It seems there is no coding system applied to values of environment
> variables.

What's the current situation with this bug?  Jason's patch was reverted,
but nothing else seems to have been done after that.

Two objections were made to Jason's patch: (i) some coding systems are
not ready until some .elc files get loaded (relevant for special cases,
such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
so variables such as `nm' in Fexpand_file_name may not point to valid
data after that.

If no elegant solution is forthcoming, I'd suggest simply documenting
(i) as a limitation, and dealing with (ii) by simply turning off GC in
the affected part of the function.

I noticed that the patch posted at

http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html

has not been checked into the trunk either.






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

* bug#38: No coding system used for environment variables
  2008-07-24  0:01 No coding system used for environment variables Chong Yidong
  2008-07-24  0:10 ` Jason Rumney
@ 2008-07-24  0:10 ` Jason Rumney
  1 sibling, 0 replies; 6+ messages in thread
From: Jason Rumney @ 2008-07-24  0:10 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 38, emacs-devel

Chong Yidong wrote:
>> It seems there is no coding system applied to values of environment
>> variables.
> 
> What's the current situation with this bug?  Jason's patch was reverted,
> but nothing else seems to have been done after that.
> 
> Two objections were made to Jason's patch: (i) some coding systems are
> not ready until some .elc files get loaded (relevant for special cases,
> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
> so variables such as `nm' in Fexpand_file_name may not point to valid
> data after that.
> 
> If no elegant solution is forthcoming, I'd suggest simply documenting
> (i) as a limitation, and dealing with (ii) by simply turning off GC in
> the affected part of the function.

I think the GC part can be handled the same way as in bug #93

> I noticed that the patch posted at
> 
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
> 
> has not been checked into the trunk either.

I think the bug reported there is the same as #93, which is fixed in the
trunk, but not the branch AFAIK.






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

* Re: No coding system used for environment variables
  2008-07-24  0:01 No coding system used for environment variables Chong Yidong
@ 2008-07-24  0:10 ` Jason Rumney
  2008-07-24  0:30   ` bug#38: " Chong Yidong
  2008-07-24  0:30   ` Chong Yidong
  2008-07-24  0:10 ` bug#38: " Jason Rumney
  1 sibling, 2 replies; 6+ messages in thread
From: Jason Rumney @ 2008-07-24  0:10 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 38, YAMAMOTO Mitsuharu, emacs-devel

Chong Yidong wrote:
>> It seems there is no coding system applied to values of environment
>> variables.
> 
> What's the current situation with this bug?  Jason's patch was reverted,
> but nothing else seems to have been done after that.
> 
> Two objections were made to Jason's patch: (i) some coding systems are
> not ready until some .elc files get loaded (relevant for special cases,
> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
> so variables such as `nm' in Fexpand_file_name may not point to valid
> data after that.
> 
> If no elegant solution is forthcoming, I'd suggest simply documenting
> (i) as a limitation, and dealing with (ii) by simply turning off GC in
> the affected part of the function.

I think the GC part can be handled the same way as in bug #93

> I noticed that the patch posted at
> 
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
> 
> has not been checked into the trunk either.

I think the bug reported there is the same as #93, which is fixed in the
trunk, but not the branch AFAIK.




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

* bug#38: No coding system used for environment variables
  2008-07-24  0:10 ` Jason Rumney
@ 2008-07-24  0:30   ` Chong Yidong
  2008-07-24  0:30   ` Chong Yidong
  1 sibling, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2008-07-24  0:30 UTC (permalink / raw)
  To: Jason Rumney; +Cc: 38, emacs-devel

Jason Rumney <jasonr@gnu.org> writes:

>> Two objections were made to Jason's patch: (i) some coding systems are
>> not ready until some .elc files get loaded (relevant for special cases,
>> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
>> so variables such as `nm' in Fexpand_file_name may not point to valid
>> data after that.
>> 
>> If no elegant solution is forthcoming, I'd suggest simply documenting
>> (i) as a limitation, and dealing with (ii) by simply turning off GC in
>> the affected part of the function.
>
> I think the GC part can be handled the same way as in bug #93

Okay.  Could you put your patch back in, with the proper GC handling?

>> I noticed that the patch posted at
>> 
>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
>> 
>> has not been checked into the trunk either.
>
> I think the bug reported there is the same as #93, which is fixed in the
> trunk, but not the branch AFAIK.

Could you port this fix to the branch?  Thanks.






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

* Re: No coding system used for environment variables
  2008-07-24  0:10 ` Jason Rumney
  2008-07-24  0:30   ` bug#38: " Chong Yidong
@ 2008-07-24  0:30   ` Chong Yidong
  1 sibling, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2008-07-24  0:30 UTC (permalink / raw)
  To: Jason Rumney; +Cc: 38, YAMAMOTO Mitsuharu, emacs-devel

Jason Rumney <jasonr@gnu.org> writes:

>> Two objections were made to Jason's patch: (i) some coding systems are
>> not ready until some .elc files get loaded (relevant for special cases,
>> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
>> so variables such as `nm' in Fexpand_file_name may not point to valid
>> data after that.
>> 
>> If no elegant solution is forthcoming, I'd suggest simply documenting
>> (i) as a limitation, and dealing with (ii) by simply turning off GC in
>> the affected part of the function.
>
> I think the GC part can be handled the same way as in bug #93

Okay.  Could you put your patch back in, with the proper GC handling?

>> I noticed that the patch posted at
>> 
>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
>> 
>> has not been checked into the trunk either.
>
> I think the bug reported there is the same as #93, which is fixed in the
> trunk, but not the branch AFAIK.

Could you port this fix to the branch?  Thanks.




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

end of thread, other threads:[~2008-07-24  0:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-24  0:01 No coding system used for environment variables Chong Yidong
2008-07-24  0:10 ` Jason Rumney
2008-07-24  0:30   ` bug#38: " Chong Yidong
2008-07-24  0:30   ` Chong Yidong
2008-07-24  0:10 ` bug#38: " Jason Rumney
  -- strict thread matches above, loose matches on Subject: below --
2008-07-24  0:01 Chong Yidong

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.