Carsten Dominik <carsten.domi...@gmail.com> writes: > On Aug 12, 2010, at 2:40 AM, Bernt Hansen wrote: > >> Markus Heller <helle...@gmail.com> writes: >> >>> Bernt Hansen <be...@norang.ca> writes: >>> >>>> Markus Heller <helle...@gmail.com> 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 _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode