[Orgmode] Re: Clock history, C-u C-c C-x C-i not working properly

[Bernt Hansen]

Carsten Dominik <address@hidden> writes:

> On Aug 12, 2010, at 2:40 AM, Bernt Hansen wrote:
>
>> Markus Heller <address@hidden> writes:
>>
>>> Bernt Hansen <address@hidden> writes:
>>>
>>>> Markus Heller <address@hidden> writes:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I have had this issue for quite a while, and now it's finally
>>>>> time to
>>>>> post it.  I'm using emacs 23.2.1 and orgmode 7.01trans
>>>>> (release_7.01g.73.g29354) on windoze XP, together with Bernt's
>>>>> clock
>>>>> history setup.
>>>>>
>>>>> If I hit C-u C-c C-x C-i, the list of tasks to clock in starts
>>>>> somewhere in the middle, right now at ``[J]''.  I've had this
>>>>> issue on
>>>>> emacs 22 and with orgmode 6.36 ...
>>>>
>>>> My list on Windows XP, Emacs 23.2.1 is also a bit weird.  The
>>>> choices
>>>> for my list are:
>>>>
>>>> [d] [1] [2] [5] [6] [7] [8] [9] [A] [B] [C] [D] [M] [O] [R]
>>>>
>>>> On linux with a full clock history I get
>>>>
>>>> [d] [1] [2] ... [9] [A] [B] ... [R] [S] with no gaps
>>>>
>>>> I've noticed problems with the menu on my EEE PC which has a reduced
>>>> screen size so it couldn't display the entire menu and displayed
>>>> the end
>>>> instead of beginning of the menu.  I've since reduced
>>>> org-clock-history-length from 36 to 28 so it fits on that device.
>>>
>>> I tried reducing org-clock-history-length to 12, but to no avail.
>>> It's
>>> not that the list doesn't fit in the buffer, it starts at [J] and
>>> shows
>>> only [J] through [Z] with no gaps.  I don't see an error message in
>>> the
>>> minibuffer ...
>>>
>>> Would it help if I attached a screenshot?
>>
>> No I don't think attaching a screenshot will really add any value at
>> this point.  I'm looking at the org-clock-select-task function to
>> try to
>> determine why it comes up with these weird selections.
>
> These selection characters are made by doing computations with
> character numbers.
> maybe Windows has a different underlying font (not ascii, something
> else), where
> specific characters are located at different positions?

It's also not consistent.  Right now my windows version behaves the same
as linux, [1] .. [9] [A] .. [S] with no gaps.

As Carsten stated the character selections are based on ASCII and maybe
this doesn't work if the file is in some other weird encoding.

I haven't been able to reproduce the bad behaviour at will yet.

-Bernt