Bugtracker::

FS#475: Viewport width for documents longer than 100 lines incorrectly calculated.

Albert Hwang — 2011-11-16T10:45:22Z

When viewing a file that is over 100 lines in length, and when "view line numbers" is enabled, and "word wrap" is enabled, unexpected behaviors occur:

1) When you get to the end of the line, the viewport scrolls for one character before wrapping.
2) When printing the document, the last character on long lines disappear.

I'm guessing the width of the viewport is being calculated under the assumption that the Line Number Column is only 2 characters long.

FS#474: Cannot perform ctrl-tab navigation when in search field

Jerrold Poh — 2011-10-18T19:18:24Z

To replicate:

- Type ctrl-f to open the search box at the bottom of the screen
- Notice how the cursor is focused on the search box
- Now type ctrl-tab to switch tabs
- Nothing happens

Note, this also happens when using the ctrl-1, ctrl-2 shortcuts to switch tabs.

Oh another note, the version this affects is 2.0.2 (though it doesn't appear in the drop down)

FS#473: Crashes on Tab key, cursor between { and //

Richard Heath — 2011-10-14T09:49:21Z

Repeatably, if I have the code below with the cursor before //mess:

if (doCell){//mess($(doCell).innerHTML);

using tab to put space before comment causes e-text 2.0.1 to crash out

FS#472: PHP function comments don't collapse properly

Tobias Elod Zoltan — 2011-05-23T03:20:10Z

If comments aren't lined up with each other as is the case with a docblock function description the lines don't collapse properly. Which can be a nuisance when working with long things like Codeigniter where everything is commented and libraries are rarely under 1000 lines.

FS#471: e add a strange character '' to some files

Christoph Terwey — 2011-05-03T08:49:06Z

e v1.0.43, seems to add a strange character to the beginning of some files sometimes. It's only displayed in vi as a (http://www.fileformat.info/info/unicode/char/feff/index.htm) and is also removeable only in some low level editors like vi. Even SVN has problems to reverse this error. This character is not shown in browsers but keeps corrupting our layouts, which is really annoying because of the difficult removal. We didn’t find a pattern, it happens really rarely. Are you familiar with this kind of bug or is this maybe already fixed in a newer version of e? Thanks in advance!

FS#470: The "go to" functionality of the Rails bundle produces wrong paths

Steffen Poulsen — 2011-03-29T07:18:08Z

- Windows 7 Enterprise, 64 bit.
- E Text installled in: "d:\Program Files (x86)\e"
- Cygwin installed in "d:\cygwin"

Clean install of both programs, no customizations.

Following the rails bundle tutorial, I have created "d:\cygwin\home\sp\blog\app\controllers\blog_controller.rb" with this content

class BlogController < ApplicationController

def index
@posts = Post.find_all_by_published(true)
end

end

Now I position the cursor in the index method and press SHIFT-CTRL-WIN-DOWN. From the menu, if I press "1" to go to the functional test, e text tries to create this file:

"D:\cygwin\home\sp\blog\cygdrive\d\cygwin\home\sp\blog\test\functional\blog_controller_test.rp"

Similar locations are suggested for the other options ("Go to View" etc)

It seems the "d:\cygwin\home\sp\blog\" part of the path is expanded into "d:\cygwin\home\sp\blog\cygdrive\d\cygwin\home\sp\blog\" - which is of course not found in the filesystem.

Is there any way I can work around this? I.e.

- by hacking the related files (go_to_alternate_file.rb or command_go_to_file.rb)?
- by setting a magic environment var in cygwin?
- by any other method?

I think I have seen a related post at http://e-texteditor.com/forum/viewtopic.php?t=3896&highlight=cygwin - however, no suggestion for a workaround is given there.

I will like such a member of the "last generation" trying to use the next generation text editor, and not even being able to complete the first tutorial :-)

I hope you have a suggestion for me ....

Best regards,
Steffen

FS#469: Installing the Zen bundles from the bundles manager didn't seem to work at all in v1.43

Terry Britton — 2011-01-25T15:56:52Z

Installing the Zen bundles from the bundles manager didn't seem to work at all in v1.43.

Without un-installing the existing version, I downloaded the zipped Zen-Coding TextMate bundle from Google Code and extracted its files over the ones in the C:\Users\yourname\AppData\Roaming\e\InstalledBundles folder, and after reloading the bundles everything worked fine.

Zen-Coding is super! Glad to see it is being integrated into the v2 of e!

Read more:

http://code.google.com/p/zen-coding/

http://www.smashingmagazine.com/2009/11/21/zen-coding-a-new-way-to-write-html-code/

Terry

FS#468: Several TAB-triggered snippets in Zen ex: ta:r[tab] results in ta:right instead of text-align:right

Terry Britton — 2011-01-25T15:56:03Z

rooc wrote:
I've noticed a few bugs:

1. Zen CSS
ta:r[tab] results in ta:right instead of text-align:right

This seems to only affect the tab-triggered snippets. Using CTRL-e executes the expansions just fine.

Removing the colon in the snippet seems to allow it to work.

In Win7:
C:\Users\yourname\AppData\Roaming\e\InstalledBundles\Zen-CSS.tmbundle\Snippets\text-align_right.tmSnippet
Code:

content
text-align:${TM_CSS_SPACE}right;$0
name
text-align:right
scope
source.css
tabTrigger

tar

uuid
4305D952-FFB2-4677-8051-51EEBFB5F0CD

Continuing along this vein:
ta:c returns
ta:color:#000; [broken!]

ta:j returns nothing but a tab space [broken!]

however, colons work in some other TAB-triggered snippets:
tal:a works fine!
text-align-last:auto;

Yet tal breaks with other colon modifiers
tal:l broken
tal:c broken
tal:r broken

Anybody have any guesses why this would be?

Terry

FS#466: High CPU usage when typing in 2.0.1

jmpllu — 2011-01-16T17:16:19Z

When using e V2.0.1 on Windows XP SP3 I regularly experience very high CPU usage when entering text. I see this behaviour when starting e, opening a single .txt file 20K in size (the problem doesn't seem to occur on smaller files) and then typing some characters. CPU usage shoots up to 40-90% and the text appears on the screen extremely slowly. The problem is intermittent - I can return to e a few minutes later and enter text without high CPU usage or any display lag. A few minutes after that the problem has returned.

I saw some advice on another CPU-related topic to look at the Thread view of Process Explorer when such problems occur. The thread using all of the CPU has start address 0x2b4a95.

I'm not using TortoiseGit or any other plugins (I saw that these were implicated in other CPU issues).

I'd appreciate your assistance since this is rendering the editor unusable.

FS#465: Dialog Boxes are opened out of screen after loggin into PC through remote desktop

Igor Ivoilov — 2011-01-10T04:06:57Z

It happens to me in version 2.0b and happened to all previous versions.