Tab not working to create bullet list

I can confirm the tab/indent issue. Workaround is to select part of the line and then hit tab. For example, to create a new bullet and indent it:

<[><]><space><shift+left><tab>

This is a side effect of the fix for Bug #506818. Reverted in rev186.

This revert fixes the newline thing, but the tab/indent issue still remains, with codemonkey's workaround as a, well, workaround. Is this still a bug, then, or is that expected behavior? Should I post a separate bug?

On Fri, Jan 15, 2010 at 6:46 AM, vroetman <email address hidden> wrote:
> This revert fixes the newline thing, but the tab/indent issue still
> remains, with codemonkey's workaround as a, well, workaround. Is this
> still a bug, then, or is that expected behavior? Should I post a
> separate bug?

Can you describe in more detail what you mean by the tab/indent issue?

If I type "*<tab>" or "*<space><tab>" I get a bullet that is indented.
So seems to me all aworks as expected.

Regards,

Jaap

Odd. When I type "*<tab>"
then it keeps it as a literal '*' followed by a tab (long space)

When I type "*<space><tab>" I get a bullet followed by a tab (long space)
Only when I highlight as codemonkey suggested does it indent, but then it doesn't remember the indent on the next line.

I do not understand why. I am using
python-gtk2 2.16.0-0ubuntu1
libgtk2.0-0 2.18.3-1ubuntu2.1

I tried this tab thing on another computer, and it works as expected.
On my computer, <shift-tab> works, just not <tab>
Since both computers are running jaunty, I find it very puzzling that they behave differently.

On Wed, Jan 20, 2010 at 11:51 AM, vroetman <email address hidden> wrote:
> I tried this tab thing on another computer, and it works as expected.
> On my computer, <shift-tab> works, just not <tab>
> Since both computers are running jaunty, I find it very puzzling that they behave differently.

Is it possible that you have some non-standard keyboard (hardware or
configuration) with the result that the key code given to the
application is different?

You could open up the source file zim/gui/pageview.py and un-comment
two debug statements in the do_key_press method (around line 1655) and
check for differences.

I just tried it on another account on the same computer and it works fine there. So it's definitely related to something in my personal settings somewhere, maybe gtk or gnome settings or something related to scim (although it behaves the same if I change the input method).

Uncommenting your debug statements, the working profile says:
KEY Tab (65289)
STATE <flags 0 of type GdkModifierType>

But the non-working profile says:
KEY Tab (65289)
STATE <flags GDK_MOD2_MASK of type GdkModifierType>

I have no idea what this GTK_MOD2_MASK is and why it is set.

On Wed, Jan 20, 2010 at 2:10 PM, vroetman <email address hidden> wrote:
> Uncommenting your debug statements, the working profile says:
> KEY Tab (65289)
> STATE <flags 0 of type GdkModifierType>
>
> But the non-working profile says:
> KEY Tab (65289)
> STATE <flags GDK_MOD2_MASK of type GdkModifierType>
>
> I have no idea what this GTK_MOD2_MASK is and why it is set.

This is a meta key. By default MOD1 is the Alt key, MOD2 can be an
alternative windows / apple / media key. The modifier mask means that
this meta key is pressed in combination with the tab key.

This causes zim to ignore the tab, because we do not want to indent on
shift-tab, ctrl-tab etc. so any mask is ignored.

One fix would be to make the check more discriminating for
ctrl/shift/alt and ignore other modifiers. But I would like to
understand better what causes this mod2 flag.

Regards,

Jaap

Jaap Karssenberg wrote:
> On Wed, Jan 20, 2010 at 2:10 PM, vroetman <email address hidden> wrote:
>> But the non-working profile says:
>> KEY Tab (65289)
>> STATE <flags GDK_MOD2_MASK of type GdkModifierType>

> One fix would be to make the check more discriminating for
> ctrl/shift/alt and ignore other modifiers. But I would like to
> understand better what causes this mod2 flag.

I also would like to know what causes this mod2 flag in my profile, but
as of yet I have no idea.

Re-opened bug because MOD2 issue not fixed yet.

I can confirm this with 0.44 on my Ubuntu Karmic (64-bit) system. The only way to get indented checkboxes there is to use codemonkeys workaround.

Indenting works well though on my netbook which is also running 0.44 on Ubuntu Karmic (32-bit). I can't think of any relevant difference in the personal settings of both systems.

I can confirm this with 0.44 on my Ubuntu 8.04 32bit system (same situation; works on one computer, doesn't work on the other unless I use a workaround). In what may be a related issue, if I select a long, wrapping line of text and hit tab to indent it, when I refresh the page it adds extra blank lines above and below; thus, I'm stuck with no workable way to use bullet indenting or regular text indentation.

@nick: the issue you describe with blank lines is not related, this issue is about keybinding for indenting. Please open a new report and detail the behavior you see and how to reproduce.

I also enabled the debugging code and saw I always have GDK_MOD2_MASK enabled (not just for tab) and I'm also seeing this problem.

xmodmap outputs, that:
mod2 Num_Lock (0x4d)

however, toggling num lock does not make a difference (maybe it's handled specially for the laptop keyboard "numpad" to work?). when I disable the mod2 alltogether with:
xmodmap -e 'clear mod2'

most of the other key combos requiring alt stop working (like alt-tab) while the indentation still does not work and sitll shows GDK_MOD2_MASK modifier.

some googling shows " * GDK_MOD2_MASK (don't know what; always on on my computer), ":
http://trac.campware.org/campcaster/changeset/1623/trunk/livesupport/products/gLiveSupport

and at least some people have implemented modifier lists that they accept (not sure if it's because of the same problem or not):
http://cryptosystem.org/projects/mod4/gnome-settings-daemon.patch

I have posted a comment (#6) https://bugs.launchpad.net/zim/+bug/490764
this bug and bug 490764 seems related to me. What is the difference between them?
Is it about zim version: zim bzr checkout 185?

I am using zim 0.44 on Ubuntu 9.10. I can't create sub-item bullet and box lists using the wiki-syntax.

Some more experimentation lead to a way to fix this issue temporarily:

xkbwatch -> the third row is partially lit

xmodmap -e 'add mod2 = Num_Lock Meta_L'
Pressed Meta_L (key with windows logo on my kb)

xkbwatch -> nothing is lit

I can restore the old situation:
xmodmap -e 'clear mod2'
xmodmap -e 'add mod = Num_Lock'

And creating bullets works fine in zim UNTIL I press Num lock, at which point it stays stuck again (visible with xkbwatch) until I go through the procedure again. It looks like possibly broken X behaviour but I don't nearly know enough about X internals to debug it any further.

Are other users seeing the same problem by any chance laptop users? I have a hunch that it may have something to do with the Fn key handling for laptop keyboards but then again I might be way off.

I also have the problem here and someone reported it in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570736 too.

I'm a laptop user but I'm using 2 externals keyboards (possibly connected at the same time through USB). I'm running up-to-date Debian sid.

On further tests here, it looks like GDK_MOD2_MASK is always set when NumLock is activated. So I can get the proper zim behaviour simply by deactivating NumLock on the keyboard. When I switch it back on, I get the problem again. I'm not sure what changed recently to explain that we now get this information in the state information but there must be something I guess.

I think I have enough info on this issue now to fix it. Will just
ignore all keyboard state masks excepts shift, control & alt (mod1).
Will try to include this in Monday's release.

Committed patch to only check ctrl, shift & alt key masks and ignore any other masks. I believe this should fix the issue.

... fix in rev217