SourceForge has been redesigned. Learn more.
Close

#448 beep on error

closed-accepted
None
5
2012-08-08
2012-07-30
No

I have problems catching an assertion error that spontaneously happens on completion popups. If I only know that it happens just now...

So I introduced beeping on any output. Probably this is a useful feature. What do you think about introducing a new option pane called "Debugging" in which I would place an entry "beep on errors"?

I'm attaching a patch that does beep, without configuration options yet.

Discussion

  • Jarek Czekalski

    Jarek Czekalski - 2012-07-30

    beeping patch

     
  • Dale Anson

    Dale Anson - 2012-07-30

    Definitely this needs a way to be turned off. I can see this being extremely annoying. Rather than a new option pane, how about adding a checkbox to the Activity Log settings?

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-01

    beep configurable through Activity Log settings

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-01

    I did it this way, but it's not the best option. I had to add propertiesChanged after ok in these settings. It interferes with viewing the activity log, as it causes a bunch of new log entries. A new patch attached. Any other suggestions?

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-02

    Attaching one more patch that bypasses jEdit.propertiesChange() call and changes Log settings directly. This is sort of workaround, but commented appropriately.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-02

    beep configurable without propertiesChanged call

     
  • Dale Anson

    Dale Anson - 2012-08-02

    Hey Jarek, what revision did you create your patch against? It looks like you're using mercurial rather than svn to create the patch, so the svn revision numbers aren't included. I tried applying your patch against 21969, and it mostly failed.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-02

    Sorry, Dale. The revision was correct but we became victims of dos artifacts. My patch was done under Windows and cr-lf's screwed it up. After I edited the patch and made it plain \n, it turned out that jedit_en.props file requires windows line endings. Finally I needed to update this file manually. The result is a patch file prepared on unix, that should cause no more problems to you.

    Damned Windows. Creating patches under it is painful. And these mixed files in svn. Maybe svn:eol_style is able to help somehow? I never used it.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-02

    patch from 2012-08-02 against r21969

     
  • Steve

    Steve - 2012-08-02

    It is almost always best to use eol-style=native in svn. If you check out on your Windows box, it will convert all the files to windows style when it creates your working copy. Same on *nix. When you add a file, it stores the file in your native format but later users who modify the file see it as their native type. When they check in changes, the svn is smart enough to convert the endings to the correct format before it builds the diff package that is actually transmitted to the server.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-03

    Most jedit files already had "native", I converted the forgotten ones to this state. So now the patch should either apply cleanly or not at all.

    Previous patch was too sensitive and I changed the beep level to the level specified with -log command line parameter. It defaults to WARNING.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-03

    -p1 \r\n patch for r21971

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-08

    After these several days of trials I introduced the feature in r21989, for 5.1.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-08-08
    • assigned_to: nobody --> jarekczek
    • status: open --> closed-accepted
     

Log in to post a comment.