Wolfgang.Friebel | 1 Apr 2008 15:52
Picon
Favicon

Interaction between $LANG and Display Charset (nl_langinfo(CODESET))

There was recently a discussion around using nl_langinfo(CODESET).

I do have a similar problem with that routine. Many users on our site do 
run either pine or the newer alpine in an environment where many mails
still in the ISO-8859-1(5) charset are exchanged. Users who have set their 
LANG variable to something UTF8 like are very pleased with alpine, 
for those who are working under LANG=C (there are legitimate reasons for 
them to do so) alpine is less useable than pine.

The reason is that nl_langinfo(CODESET) returns ANSI... for LANG=C or for 
an unset LANG variable and that does force setting of the display charset.

While most terminal emulators do not have any problem with umlauts, the 
value of ANSI... for the display charset prevents its display from within 
alpine. Looking to the code I have not seen any way to influence that 
default behaviour by an option in pine.conf.

Training the users to change a setting inside alpine is a support 
nightmare and setting it centrally cannot be done as either the UTF8 
fraction or the other part would have by default a garbled umlauts 
display.

My solution was to set the display charset to something sensible if it 
turned out to start with ANSI... Ideally the unknown charset value could 
be used for that default setting. My patched alpine just uses a fixed 
string (ISO-8859-15). It does display nicely umlauts even if the LANG 
variable does indicate that umlauts would not be known. As the ISO-8859 
charsets are supersets of ANSI-... this should not break anything.

Is there a chance that such a behaviour gets realized in an upcoming 
(Continue reading)

Wolfgang.Friebel | 1 Apr 2008 16:10
Picon
Favicon

Proposal for folder history/collection change

A nice new feature in alpine is keeping the history of visited mail 
folders within a collection and browsing through the list using the arrow 
keys.

That required the introduction of CTRL-N/P for changing the collections.
My previous proposal to use in addition PgUp/Dn for changing the 
collections was not taken and now seems also impractical to me. Maybe a 
different approach would work:

If I browse to the begin or end of the folder history the next key press 
could me take to the previous or next collection. There again the history
could be walked up and down or if no history for that collection does 
exist yet to just display the new collection with the folder part left 
empty.

This resembles the behaviour of keys in some shells and should be familiar 
at least to the Linux/UNIX folks.

Is this an acceptable proposal?
--

-- 
Wolfgang Friebel                   Deutsches Elektronen-Synchrotron DESY
Phone/Fax:  +49 33762 77372/216    Platanenallee 6
Mail: Wolfgang.Friebel AT desy.de  D-15738 Zeuthen  Germany
Mike Brudenell | 1 Apr 2008 16:31
Picon
Favicon

Re: strange imap directory/folder [.] thing

Greetings -

> On Sat, 29 Mar 2008, Patrick J. Collins wrote:
>> However, this collinator-2007 shows up as:
>> collinator-2007[.]   -- which I am assuming means alpine thinks  
>> it's a mailbox, and I go into it and it says "[Folder  
>> 'collinator-2007' opened with 0 messages]"
>
> On 31 Mar 2008, at 19:33, Matt Ackeret wrote:
> I don't remember all of the details, but I *think* if you turn on
>      [X]  Hide Empty Directories
> that it will seem more sane.

Hmmm, this solution makes it sound as if you are seeing "dual-use  
folders" (my phrase, not an official one)...

With some storage formats (eg, Berkeley/UNIX/mbox/mbx) a 'thing' you  
think of as being a folder within your mail client can contain EITHER  
messages OR subfolders, but not both.  This is because messages get  
stored in a *text file* of that name, whereas subfolder get stored as  
*directories* of that name.  And of course it isn't possible in the  
standard UNIX filesystem to have both a text file and a directory  
stored with the same name in a given location.

However other mailbox storage formats (eg, Maildir) do allow messages,  
subfolders, or both to be stored within a 'thing' thought of as being  
a folder in your mail client.

For this latter type of 'dual-use' folders there is (if I understand  
this rightly!) a difference between "nameoffolder" and  
(Continue reading)

David Carter | 1 Apr 2008 17:18
Picon
Picon
Favicon

Re: strange imap directory/folder [.] thing

On Tue, 1 Apr 2008, Mike Brudenell wrote:

> Greetings -
>
>> On Sat, 29 Mar 2008, Patrick J. Collins wrote:
>>> However, this collinator-2007 shows up as:
>>> collinator-2007[.]   -- which I am assuming means alpine thinks it's a 
>>> mailbox, and I go into it and it says "[Folder 'collinator-2007' opened 
>>> with 0 messages]"
>> 
>> On 31 Mar 2008, at 19:33, Matt Ackeret wrote:
>> I don't remember all of the details, but I *think* if you turn on
>>     [X]  Hide Empty Directories
>> that it will seem more sane.
>
> Hmmm, this solution makes it sound as if you are seeing "dual-use 
> folders" (my phrase, not an official one)...

I agree. If the IMAP server supports dual use mailboxes, then every 
mailbox is also a potential directory. In the following folder list:

   INBOX a/    b     c[/]      (Hide Empty Directories set)

"a" is a directory, "b" is a mailbox, and "c" is a mailbox which contains 
subsidiary mailboxes.

--

-- 
David Carter                             Email: David.Carter@...
University Computing Service,            Phone: (01223) 334502
New Museums Site, Pembroke Street,       Fax:   (01223) 334679
(Continue reading)

Steve Hubert | 1 Apr 2008 18:31
Favicon

Re: Proposal for folder history/collection change

On Tue, 1 Apr 2008, Wolfgang.Friebel@... wrote:

> A nice new feature in alpine is keeping the history of visited mail folders 
> within a collection and browsing through the list using the arrow keys.
>
> That required the introduction of CTRL-N/P for changing the collections.
> My previous proposal to use in addition PgUp/Dn for changing the collections 
> was not taken and now seems also impractical to me. Maybe a different 
> approach would work:
>
> If I browse to the begin or end of the folder history the next key press 
> could me take to the previous or next collection. There again the history
> could be walked up and down or if no history for that collection does exist 
> yet to just display the new collection with the folder part left empty.
>
> This resembles the behaviour of keys in some shells and should be familiar at 
> least to the Linux/UNIX folks.
>
> Is this an acceptable proposal?

This does seem like a nice idea. We don't have any free cycles to work on 
it at the moment but we hope we can get to it. Thanks.

Steve
Steve Hubert | 1 Apr 2008 18:45
Favicon

Re: Interaction between $LANG and Display Charset (nl_langinfo(CODESET))

On Tue, 1 Apr 2008, Wolfgang.Friebel@... wrote:

> There was recently a discussion around using nl_langinfo(CODESET).
>
> I do have a similar problem with that routine. Many users on our site do run 
> either pine or the newer alpine in an environment where many mails
> still in the ISO-8859-1(5) charset are exchanged. Users who have set their 
> LANG variable to something UTF8 like are very pleased with alpine, for those 
> who are working under LANG=C (there are legitimate reasons for them to do so) 
> alpine is less useable than pine.
>
> The reason is that nl_langinfo(CODESET) returns ANSI... for LANG=C or for an 
> unset LANG variable and that does force setting of the display charset.
>
> While most terminal emulators do not have any problem with umlauts, the value 
> of ANSI... for the display charset prevents its display from within alpine. 
> Looking to the code I have not seen any way to influence that default 
> behaviour by an option in pine.conf.
>
> Training the users to change a setting inside alpine is a support nightmare 
> and setting it centrally cannot be done as either the UTF8 fraction or the 
> other part would have by default a garbled umlauts display.
>
> My solution was to set the display charset to something sensible if it turned 
> out to start with ANSI... Ideally the unknown charset value could be used for 
> that default setting. My patched alpine just uses a fixed string 
> (ISO-8859-15). It does display nicely umlauts even if the LANG variable does 
> indicate that umlauts would not be known. As the ISO-8859 charsets are 
> supersets of ANSI-... this should not break anything.
>
(Continue reading)

Eduardo Chappa | 1 Apr 2008 18:48

Re: strange imap directory/folder [.] thing

On Mon, 31 Mar 2008, Patrick J. Collins wrote:

:) > I don't remember all of the details, but I *think* if you turn on
:) >       [X]  Hide Empty Directories                                               
:) > that it will seem more sane.
:) 
:) Ahhh.. Yes, that fixed it.  Thank you!

There is, however, a big drawback that everyone needs to understand.

The setting above is GLOBAL. That means that it will work on every 
collection. For example, if you have two collections, one in that IMAP 
server, the other local, then the setting will apply to both.

Why is this important?

Because Directories may disappear. Either in that collection or in another 
collection.

Consider the situation in which a directory is inside another directory. 
As in "Direc1/Direct2/folder". If you remove "folder" and "Direct2" is 
left empty, then opening "Direc1" will not see Direct2, and you will not 
be able to delete Direc1, because it contains Direct2 (well, you would 
have to disable the configuration option first, but then you probably 
forgot you enabled it in the first place, so you will waste a  lot of time 
chasing that problem around).

In other words, the solution that you are using, is not a solution but a 
workaround. It does not solve the problem, it hides it.

(Continue reading)

Steve Hubert | 1 Apr 2008 19:01
Favicon

Re: Proposal for folder history/collection change

On Tue, 1 Apr 2008, Wolfgang.Friebel@... wrote:

> If I browse to the begin or end of the folder history the next key press 
> could me take to the previous or next collection. There again the history
> could be walked up and down or if no history for that collection does exist 
> yet to just display the new collection with the folder part left empty.
>
> This resembles the behaviour of keys in some shells and should be familiar at 
> least to the Linux/UNIX folks.

But wait a minute. I'm having second thoughts. The history that is 
accessed with the up and down arrows isn't collection-specfic. That is, 
going through the list with up arrow will change both the folder name and 
the folder collection that goes with that name. There isn't a separate 
history for each collection.

I'm probably misunderstanding the proposal.

Steve

Matt Ackeret | 1 Apr 2008 20:53
Picon
Favicon

Re: strange imap directory/folder [.] thing

On Tue, 1 Apr 2008, Eduardo Chappa wrote:
>Consider the situation in which a directory is inside another directory. 
>As in "Direc1/Direct2/folder". If you remove "folder" and "Direct2" is 
>left empty, then opening "Direc1" will not see Direct2, and you will not 
>be able to delete Direc1, because it contains Direct2 (well, you would 
>have to disable the configuration option first, but then you probably 
>forgot you enabled it in the first place, so you will waste a  lot of time 
>chasing that problem around).

It seems to me like delete should 'just work' in this case, and delete
the (empty) sub-folders too.  There's no chance for real data loss, simply
deleting already empty folders, right?

It's vaguely similar to the package concept on Mac OS X, where there can
be a folder of stuff, but in the Finder (the normal UI for interacting
with the filesystem), it acts like a file.
Wolfgang.Friebel | 1 Apr 2008 20:55
Picon
Favicon

Re: Proposal for folder history/collection change

On Tue, 1 Apr 2008, Steve Hubert wrote:

> But wait a minute. I'm having second thoughts. The history that is accessed 
> with the up and down arrows isn't collection-specfic. That is, going through 
> the list with up arrow will change both the folder name and the folder 
> collection that goes with that name. There isn't a separate history for each 
> collection.
>
> I'm probably misunderstanding the proposal.
>
Yes, you are right. I have not excessively used that feature up to now and 
was not aware of the combined history. Maybe a small modification of the 
proposal would work:

If I am at the end of the history I could start cycling through the folder 
collections in forward direction starting from the current one and would
stop before reaching the current collection again. At the begin of the 
history I would do the same in reverse direction.

I must admit it sounds more complicated than the proposal before and is 
probably more work to implement. If I find some spare time I could try 
coding it and find out whether it is something our users would like.

--

-- 
Wolfgang Friebel

Gmane