I’m using WordHighlight. I disabled the add-on for a while after reading your comment, but it happened again. Very difficult to reproduce. I don’t think WordHighlight is the problem. It just happened to me on dev builds. Not in stable.
Is there any way to help with an output, command or something to display some debug information?
[quote=“jps”]Dev Build 2132 is out now, with buttons in the gutter for folding indented regions. You can disable them with the new fold_buttons file setting.
[/quote]
Instead of a triangles it seems the markers should be (+) or (-) in keeping with the Sublime look. Or reduce the size of the triangles.
[quote=“tito”]I’m using WordHighlight. I disabled the add-on for a while after reading your comment, but it happened again. Very difficult to reproduce. I don’t think WordHighlight is the problem. It just happened to me on dev builds. Not in stable.
Is there any way to help with an output, command or something to display some debug information?[/quote]
ctrl+tilde
sublime.log_commands(True)[quote=“DSHugo”]
[quote=“tito”]Sometimes I want to select some text by normal dragging and sublime start crazy one line below and also it select more portions of other lines. I was not paying attention and I can’t see a way to reproduce this. This happens with these two dev builds.
Anyone seeing this?[/quote]
Definitely seeing this too occasionally. Are you, by any chance, using WordHighlight plugin? I’m not 100% sure yet, but it seems that selection glitching at least happens more often with it installed, both under Linux and Windows XP. The worst part is that I can’t reproduce it properly, though.
What I can definitely say, is that when it happens, selecting text with mouse starts selection one line below of where it should actually be, and if done towards the end of the file, selection ends at the last symbol regardless of where the mouse is.[/quote]
I think the problem is with “scroll_past_end” option, I just had the same issue after I set it to false in my user file settings…
EDIT: I tried to reproduce it and apparently it happens when you have scroll_past_end option set to false, then you fold something in the last lines of your code and try to select anything near those lines.
EDIT 2: The problem is with pyparadigm’s tagmatcher plugin
[quote=“weslly”]
Definitely seeing this too occasionally. Are you, by any chance, using WordHighlight plugin? I’m not 100% sure yet, but it seems that selection glitching at least happens more often with it installed, both under Linux and Windows XP. The worst part is that I can’t reproduce it properly, though.
What I can definitely say, is that when it happens, selecting text with mouse starts selection one line below of where it should actually be, and if done towards the end of the file, selection ends at the last symbol regardless of where the mouse is.
I think the problem is with “scroll_past_end” option, I just had the same issue after I set it to false in my user file settings…
EDIT: I tried to reproduce it and apparently it happens when you have scroll_past_end option set to false, then you fold something in the last lines of your code and try to select anything near those lines.
EDIT 2: The problem is with pyparadigm’s tagmatcher plugin[/quote]
This might be because SublimeTagmatcher searches on every change of the selection. If it has to search real far, it can cause some stuttering on selection especially with the rapid changing of selection due to the drag select etc.
I had created a fork to fix things like this myself, but also added a lot of other things. You can check out my BracketHighlighter plugin which merged SublimeBracket and SublimeTagmatcher. I debounced the highlighting to cut down on how many times the highlighting was occuring. I also placed limits to keep it from bogging down things. It is all configurable as well in case you don’t like the response of things and has additional features. If you end up trying the plugin but still see issues, you can create an issue on the git site and I can look into the issue, otherwise, I would create an issue on pyparadigm’s plugin site and try to work with him to get it fixed.
There will be an update for WordHighlight today, roughly after 12 hours. When it comes, would somebody of you guys who have it already installed and have selection glitch, give the feedback if the update helped (e.g. here or using the issue tracker)? I will be testing it myself anyway, but having other users feedback helps a lot.
[quote=“atomi”]It may be much more usable if there was a single keyboard shortcut for only toggling code folding.
This way it wont be necessary to have folding markers in the gutter to fold code.[/quote]
A single key binding to toggle folding doesn’t provide an easy way to fold the current function if the caret isn’t currently at the top level of indentation. The current bindings are designed so that you can keep pressing the fold key until you’ve folded to the level you’re happy with. There is a fold_unfold command (in fold.py) if you’d like a binding to toggle folding.
I don’t see that having one binding instead of two would have any influence over the gutter fold buttons: they simply provide a way to fold using the mouse.
This somewhat exists: if you unfold using a key binding, the unfolded text will be selected. Pressing fold again without changing the selection will refold the selected text.
Didn’t know which of the posts to reply to regarding this but just to confirm that this also happens for me with WordHighlighter enabled, and doesn’t happen with it disabled.
For those wanting to reproduce it’s quite simple. First off it appears that scroll_past_end needs to be false, and WordHighlighter need to be installed and not disabled. But the actual bug occurs when you have a file that goes over the height of the window (thus invoking scrolling), and if you are scrolled all the way to the bottom and then delete lines. (Actually you could also be not scrolled quite to the bottom, but delete a number of lines that is greater than the number of lines left off-page.) Then, until you next scroll, the bug happens. Upon scrolling, the layout appears to reset itself.
So this could be a bug not in WordHighlight specifically but it could be that the WH plugin is exposing an underlying bug in the view/scrolling code. (Or yeah it could just be WH.)
This definitely only started for me a couple of dev releases ago. I’ve been meaning to bring it up but keep forgetting to.
There’s also a long standing bug of the minimap not being updated for code folding until there’s some kind of repaint (scroll action, of focus goes out of Sublime window, for example). This is not a biggie as you can just scroll and it updates, but just worth mentioning.
Thank you, it helped a great deal. At least I can now confirm this part of the bug has something to do with WordHighlight calling view.add_regions. It seems that having:
class WordHighlightListener(sublime_plugin.EventListener):
def on_selection_modified(self,view):
...
view.add_regions("WordHighlight", regions, "comment", false) <= "problem"Having the “problem” line called more than once in a row (roughly 0.1 sec for me) causes the bug (e.g. clicking once causes selection changed event to fire twice). Maybe it is because an “on_selection_modified” event is invoked too frequently for the previous run of code to complete and exit, or whatever.
There is, as already mentioned, a second part of the bug, however. The one when selection starts on the line below the pointer – right where it should be, but one line below. I can’t reproduce this with the method, suggested by alexrussell.
Found some folding bug (PHP):
if (isset($_SESSION'user'])) {
// ...
}
Folded.
if (isset($_SESSION'user']))
{
// ...
}
Not folded.
There is a WordHighlight update available, which partially fixes the problem Alexrussell described in detail — it shouldn’t manifest as much, if barely (at the expense of a bunch of workarounds I don’t like). The core of the bug, however, seems to lay somewhere in ST internals — either that, or the API is misused by the plugin.
Hi, I have been experimenting with the ST2 beta and I am loving the folds, but apparently there is a bug. If I write the text below only the first two lines get a folding arrow and if I click on the second the first one disapears.
asdf
asdf
asdf
asdfIm on Lion 10.7.2.
This is by design: fold arrows are only shown where there’s two or more lines to be folded, to reduce clutter in the gutter
I still have the issue describe here: https://forum.sublimetext.com/t/file-change-detection/21/1#p15592
Any ETA for a fix or any idea for a workaround ?
startup, version: 2132 windows x64 channel: dev
Having a serious bug right now causing segfaults, 2132 on Ubuntu 10.04:
Reproduction:
Open Folder F1, bringing up window.
Open Folder F2, bringing up window.
Start typing in an editor tab within F2. No text appears. It happens to direct to the open tab in F1.
Close F1 window. Type in open tab in F2. Segfault.
Repeat 1.
Close all tabs in F1. Type in F2 open tab. Nothing seems to register. Open new file in F1, type in F2. Input goes again to active tab in F1.
Again, try closing F1 window. Type in F2. Segfault.
Seems like there’s a focus problem, with F2 window’s keystrokes going to F1. However, pressing things like ctrl-P for opening dialogs still works in F2, but the text is still going to F1.
Ideas? Sounds like an off-by-1 bug in window selection/focus.
FYI: This does NOT reproduce on OSX 10.6 with 2132.
Wondering if this might be related to some caching of the input focus? And maybe 2128’s API:
API: window.run_command() will run text commands, dispatching them via input focus
[quote=“johnnydvc”]
[quote=“jps”]
You can edit the Default (Windows).sublime-mousemap file[/quote]
How about Linux?
Where can this option be disabled?[/quote]
I don’t know what the question was, but the key maps and mouse maps come in three variants, for each platform:
Default (Windows).sublime-mousemap
Default (OSX).sublime-mousemap
Default (Linux).sublime-mousemap