#3692 std:: in C++ remains unindented as a label

closed-fixed
None
7
2014-08-20
2012-05-05
Kazutoshi Satoda
No

Reproduction recipe:
1. start jEdit -nosettings -noplugins .
2. set the mode of the Untitled-1 to c++.
3. type "void f() {" and Enter.
-> The cursor position at the next line should be indented.
4. type "std:".
-> The line should be unindented as a line with a label.
5. type another ":" and form "std::".
-> The line should be indented as it was at step 3.

It used to be working as described above, but with jEdit trunk r21630,
step 5 fails and "std::" remains unindented as a label.

This looks a regression caused by r21630 which introduced a condition
where electricKeys (":" here) works, as a fix for bug #1936678.
http://sourceforge.net/support/tracker.php?aid=1936678

Discussion

    • assigned_to: nobody --> jarekczek
     
    • status: open --> closed-fixed
     
  • I tried trunk r21670 and saw the same problem. I verified that the
    electric keys mode are shown as "on" for c++ mode in Editing options
    pane.

     
    • status: closed-fixed --> open-fixed
     
  • Kazutoshi, please check once more. Electric keys "on" means that nothing blocks them. It has worked for me always. With r21670 I have proper indentation of std:: in both "on" and "smart" modes. I just checked on Windows. On Linux I tested it dozen times.

    This is my test file:
    void f() {
    std:

    When I add ":" at the end, std moves one indentation unit to the right. In status bar c++ is stated.

     
  • I think I got it. You wrote "I verified" electric keys mode. Probably the property has invalid value. Once you accept the options it should go away. I must remember to provide a sane behaviour for incorrect property value. Currently it is "almost smart" :)

    to test:
    jEdit.getProperty("buffer.electricKeysMode")

     
  • I confirmed that jEdit.getProperty("buffer.electricKeysMode") is null
    in my recipe, and after pressing [OK] in the Editing options pane, it
    works and the property is "on".

    I wonder how the property of mine and yours become different under
    -nosettings.

     
  • I'm sorry. I should have followed your steps exactly, it would make it clear at once. I never tested with -nosettings. The problem with property initialization is now fixed by r21674.

     
  • The code causing the bug was removed in r21723 and a better fix applied in r21725.

     
    • assigned_to: jarekczek --> k_satoda
    • status: open-fixed --> closed-fixed