Cursor position on mouse click past end-of-file (macro fix?)

[econoplas]

I am experiencing a minor usability issue as I am adjusting to Zeus, and I would not dare to really even call it a bug... I will leave that up to the moderator to decide.

I am a new Zeus user using 3.97h, and am very happy with the macro capability... I finally have an editor that I can script in the language of my choice (ruby or lua or python) rather than having to learn some archaic C syntax. Good work! In fact, I am trying to figure out if I can fix some unusual Zeus mouse click behavior through the use of a macro.

Here are the two behaviors I am seeing.

1. When I single-click the left mouse button anywhere past the last character of the last line of the file, most Windows editors position the cursor on the last line. I commonly rely on this behavior to quickly position my cursor at the end of the file. Not many users may use this "feature"... so may not have been reported before. I would expect Zeus to position the cursor either in the column that I clicked on the last line of the file (consistent with how it acts for other lines in the file) or position cursor at the end of the last line (consistent with Visual Studio). But Zeus simply ignores my mouse click.

2. So I thought I would write a macro to position the cursor on the last character of the last line and bind it to double-click trigger, but I will need to detect when the double click occurred past the end of the file. But before assigning a macro to double-click trigger, I thought I would see what it does presently. So I positioned my cursor in the middle of a line that was a few lines from the end of the file. THen I double click past the end of the document, and Zeus leaves the cursor in its present position and highlights the word under the cursor... Very strange.

I still may be able to write a double-click trigger macro, but I suspect that since Zeus is not repositioning my cursor to the end of the file, that I am not going to have an easy way to detect that the double-clicked event occurred past the end of file so I can act on this information accordingly.

Thanks in advance for any help/insight into how to proceed with overcoming this. It is a minor issue as I said, I can probably learn to work around it in a couple of hours.

Otherwise I like zeus very much so far. I did end up binding "Up" key to MoveLineUpEx and "Down" key to MoveLineDownEx based on piecing together information from other prior forum postings, which makes the cursor Up/Down movement in "no man's land" more like Visual Studio behavior to which many (non-brief) users are accustomed. Thanks for adding the MoveLine*Ex functions.

Keep up the good work!

[jussij]

I finally have an editor that I can script in the language of my choice (ruby or lua or python) rather than having to learn some archaic C syntax. Good work!

Thank you

In fact, I am trying to figure out if I can fix some unusual Zeus mouse click behavior through the use of a macro.

The scripting of the mouse clicks in Zeus are a little limiting

You can script the double click with a macro by using the Options, Editor Options menu, Triggers section.

I will see if it is also possible to add a script for the single mouse click.

1. When I single-click the left mouse button anywhere past the last character of the last line of the file, most Windows editors position the cursor on the last line.

I see what you mean.

Not many users may use this "feature"...

I have to admit I am one such user.

I commonly rely on this behavior to quickly position my cursor at the end of the file.

One reason I suspect I have never seen this is my keymapping of choice is the BreifEx.

In that keymap three hits of the End key gets me to the end of the file and three hits of the Home key get's me to the start of the file.

but I will need to detect when the double click occurred past the end of the file.

Good point

What you have found is a limitation in the design of this mouse event handling

I will look to add some extra arguments to this trigger and pass in the mouse x and y click locations.

and Zeus leaves the cursor in its present position and highlights the word under the cursor... Very strange.

Luckily I can explain this one.

What happened was this:

1) The click past the end of the document did not move the cursor and was ignored

2) The double click came along and did the default behaviour which is to highlight the word under the current cursor

But as you point out this is very strange behaviour.

I think this tells me that Zeus needs to also move the cursor to the end of document as you suggested.

While where on this topic, your double click macro needs to tell Zeus if it should also handle the event.

You do this by using the set_return_code macro function.

Code: Select all

-- set the return code to one indicating we don't want the default handler to fire
set_return_code(1);

I still may be able to write a double-click trigger macro

This is not going to work because as you correctly pointed out the cursor does not move and you don't know where the mouse click happened.

But I will make the required changes to Zeus and put out a new beta.

It is a minor issue as I said, I can probably learn to work around it in a couple of hours.

For me this is exactly the sort of bug report/issue I enjoy.

My philosophy is Zeus should be able to do most things via a script, but as you have correctly pointed out it can't in this case

But this will be possible in the next beta due out shortly

Keep up the good work!

Thanks for the feedback and watch this space for a new beta that should be out shortly.

Cheers Jussi

[jussij]

There is a new Zeus beta found here: http://www.zeusedit.com/z300/ze397k-beta.zip

This latest beta passes the mouse X and Y line click location as arguments and it also adds a new mouse click trigger.

So with this new version the following Lua macro will implement the behaviour you described earlier:

Code: Select all

function key_macro()
    local MouseY = nil

    -- parse the macro arguments looking for the mouse details
    for i = 1, argc(), 1 do
        -- look out for the Mouse Y location
        local index, length, value = string.find(argv(i - 1), "MouseY=([%d:]+)")

        if value ~= nil then
            MouseY = value
            break
        end
    end

    if MouseY ~= nil then
        if tonumber(MouseY) > get_line_count() then
            -- move to the end of the document
            MoveDocumentEnd()

            -- set the return code to one indicating we don't want the default handler to fire
            set_return_code(1);
        end
    end
end

key_macro() -- run the macro

Cheers Jussi

[econoplas]

Jussi, thanks for the quick response.

The new 3.97k beta 1 mouse click support works great. In fact, I expanded your script slightly to address one of the other issues I was having a little trouble adjusting to, namely that when I click past the end of any line the cursor is positioned in the whitespace area rather than just past the end of the line.

I really like the fact that Zeus allows me the power to do this. Very nice.

Your level of support makes Zeus that much better to use. Thanks so much.

Below is my expanded script in case anyone finds it useful. I have it bound to the new Mouse Click trigger that you provided in 3.97k beta 1 and newer.

Note: The forum server replaces all occurrences of "Mouse X" (with no intervening space) with "none" for some reason, so I had to get a little creative in order to post my macro code. Otherwise I would have used "Mouse X" (without the space) rather than 'mx' in order to be consistent with your naming of the MouseY variable

Code: Select all

function key_macro()
    local mx, MouseY = nil, nil

    -- parse the macro arguments looking for the mouse details
    for i = 1, argc(), 1 do
        -- look out for the Mouse Y location
        local index, length, value = string.find(argv(i - 1), "MouseY=(%d+)")

        if value ~= nil then
            MouseY = value
        else
            index, length, value = string.find(argv(i - 1), "Mouse".."X=(%d+)")
            if value ~= nil then
                mx = value
            end
        end
    end

    if MouseY ~= nil then
        if tonumber(MouseY) > get_line_count() then
            -- move to the end of the document
            MoveDocumentEnd()

            -- set the return code to one indicating we don't want the default handler to fire
            set_return_code(1);
        else
            if mx ~= nil then
                local llen = string.len(get_line_text(MouseY))
                local indX = cursor_to_index(MouseY, mx)
                if indX > llen then
                    set_line_pos(tonumber(MouseY))
                    MoveLineEnd()
                    -- set the return code to one indicating we don't want the default handler to fire
                    set_return_code(1)
                end
            end
        end
    end
end

key_macro() -- run the macro

Edit 4/12/2012 - Minor tweak to my script example above to use cursor_to_index to properly handle tab indentation.

[econoplas]

Jussi,

I forgot to mention that I am seeing different behavior with the font rendering on 3.97k Beta 1 vs 3.97h...

If you open the script above in Lua mode and use the default coloring settings for lua (which uses Reserved Words to use "Bold" font weight)... I am seeing somewhat unusual rendering such as the "." overlapping the "g" in lines that contain string.find for example, or the cursor overlapping part of the "n" character when I position the cursor at the end of a line such as

Code: Select all

        if value ~= nil then

For now, I went through all of the document types that I use regularly and changed the font for "Reserved Words" from "Bold" weight to "Medium" weight and this is a suitable work-around.

Thought you'd like to know I saw what I think might be a slight regression bug in the font rendering in 3.97k beta 1 vs 3.97h.

I saw this problem with Droid Sans Mono and Lucida Console fonts, which seem to have different character width for "Bold" vs "Medium" font weights. I did not see the issue if I switched to Courier New which doesn't seem to support a separate "Bold" font. Of course I use "Western" locale, US English version of windows.

Thanks for writing Zeus. Keep up the good work!

[jussij]

Note: The forum server replaces all occurrences of "Mouse X" (with no intervening space) with "none" for some reason

This is very strange. I did a grep of the phpBB source code for any signs of Mouse X but found nothing.

I guess this has to go down as a phpBB mystery.

If you open the script above in Lua mode and use the default coloring settings for lua (which uses Reserved Words to use "Bold" font weight)...

What happened was the Font Weight was added to the Coloring section of the Document Type many versions ago.

But then a visually impaired Zeus user upgraded only to find he could no longer set the font to Bold using the Options, Editor Options menu, Font panel.

So the way the font weight worked had to be changed.

The new rule is if the weight in the Options Editor, Options menu, Font panel is set to Medium then Zeus will use the Font weight form the Document Type.

But if the weight in the Options, Editor Options menu, Font panel is anything but Medium then that overrides the weight found in the Document Type.

I am seeing somewhat unusual rendering such as the "." overlapping the "g" in lines

This sounds like the fonts settings have been corrupted.

Since the font details where changed this could be because a bug was introduced in the upgrading of these settings.

One way to force an font upgrade is by going to the Options, Editor Options menu, Fonts panel, changing the details and then apply the changes.

For now, I went through all of the document types that I use regularly and changed the font for "Reserved Words" from "Bold" weight to "Medium" weight and this is a suitable work-around.

This is another way to force the upgrade.

Thought you'd like to know I saw what I think might be a slight regression bug in the font rendering in 3.97k beta 1 vs 3.97h.

It does sound like there is a bug in the font upgrade code between these two versions

I will do some testing at this end.

Thanks for the feedback.

Cheers Jussi