Bug 57307 - Basic IDE: adding variable to Watch window performs incorrectly if variable name contains_underscores
Summary: Basic IDE: adding variable to Watch window performs incorrectly if variable n...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected)
3.4.2 release
Hardware: All All
: medium minor
Assignee: Andreas Heinisch
Whiteboard: target:7.0.0
: 130920 (view as bug list)
Depends on:
Blocks: Macro-VBA
  Show dependency treegraph
Reported: 2012-11-20 08:14 UTC by sasha.libreoffice
Modified: 2020-04-28 10:05 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Selection/Watch failures (123.90 KB, image/png)
2013-01-04 16:49 UTC, LeMoyne Castle

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2012-11-20 08:14:20 UTC
Basic IDE problem: If we place cursor on variable with underscores in name and click "Enable Watch (F7)" for adding variable to Watch window, it performs incorrectly. Adds only part of name.
Problem seen also if double click on such variable name in program's text. Only part of name selected.

Steps to reproduce:
0. Start any LO module, for example, Writer
1. Press Alt-F11, in dialog "LibreOffice Basic Macros" press "New" and then "Ok"
2. In Basic IDE enter something like this:

Sub Main
End Sub

3. Place cursor on variable name and press "Enable Watch (F7)"
Expected: added variable with correct name to window "Watch"
Actually: added only part of name, for example First instead of First_Result

reproduced in 3.4.2 on Windows XP 32 bit and in 3.6.3 on RFR 17 64 bit

Workaround: select correct name of variable manually and press F7
Comment 1 LeMoyne Castle 2012-12-22 05:19:52 UTC
Confirmed in build from 12/20 master.  This issue is a more general IDE interface issue of selecting whole identifiers (on dbl click, on add to watch, ???).  

Selection in BASIC IDE should extend the selection from cursor to cover an entire identifier that contains any legal character.  This should include extending the selection to whole keywords that contain other chars invalid for identifiers (like the $ at the end of CHR$()).  I can confirm that is a long-standing issue.  Moved to NEW.
Comment 2 LeMoyne Castle 2013-01-04 16:49:30 UTC
Created attachment 72513 [details]
Selection/Watch failures

Shows all manner of selected dreck in the Watch Window including: parts of vars, parts of multiple vars, etc.
Comment 3 QA Administrators 2015-01-05 17:51:27 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-01-22 14:16:16 UTC
Still doing it.

Win 7 Pro 64-bit Version:
Build ID: 07e84cae983c08afdba03018413a19d01abb3006
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-19_06:15:38
Comment 5 Oliver Specht (CIB) 2015-12-18 10:00:28 UTC
The selection in the Basic IDE is done with a generic method in 
TextView::MouseButtonDown(const MouseEvent & rMouseEvent) (vcl/source/edit/textview.cxx) using the i18n::XBreakIterator implementation.

For Basic there should be the possibility to call a custom 'select word' method.
Comment 6 Peter Davis 2016-05-22 22:41:02 UTC
WIN 10 32&64bit LO CALC BASIC IN IDE: When stepping thru a program, hovering over variablenames containing an internal underscore: the values do not popup. Works fine for variablenames without underscores.

Simple Test: Variables named A and B and A_B even tried [A_B] but hovering over A_B or [A_B] produces no popup except individually on the A or B within the A_B or [A_B] and they were the values of the singleletter variablenames.

Further on the program utilizes the value of the A_B variablename correctly
Comment 7 Peter Davis 2016-05-22 23:06:07 UTC
WIN 10 PRO 32&64 Bit Also tried A__B (double underscore) and [A B] 
blank not underscore in variablename in Brackets. Both these fail in the same way.
Comment 8 Xisco Faulí 2017-07-13 10:53:11 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 9 Jean-Francois Nifenecker 2017-08-19 08:18:08 UTC
Might be related to this bug: variable selection is not easy in the IDE when variables contain underscores. A triple click selects the whole line instead of selecting the identifier only.
Second, this is not consistent with Calc and Writer where a triple click actually selects "words" containing underscores.

Wanted behaviour: triple-clicking an identifier containing underscore(s) selects the identifier only.
Current behaviour: selects the whole line.
Comment 10 himajin100000 2019-04-21 18:03:52 UTC
When your selection length is 0, Basic IDE tries to find what is the name of the identifier


2.  it relies on BreakIterator for Word Break


3. BreakIterator uses data for "edit_word" (I'm not so sure)


4. So-called underscore,whose official name is U+005F LOW LINE and who is in "Punctuation, Connector [Pc]" Category is categorized into ExtendNumLet in UAX#29


5. WB13a and WB13b says this character breaks neither before and after alphabets.


While icu4c's official data has a section for WB13a/WB13b,


LibreOffice does not have such a section.


Can this be the cause?


ICU's break iterator does not consider underscores as word-breaking punctuation 
Comment 11 Andreas Heinisch 2020-01-07 19:43:37 UTC
I committed a patch related to this issue (https://bugs.documentfoundation.org/show_bug.cgi?id=57879), but I am not satisfied with the change: https://gerrit.libreoffice.org/#/c/core/+/86362/

Should we add a function just to the edit engine, because this functionality is needed in many places? Or extend the Breakiterator interface with a function, e.g., expandWord?
Comment 12 Andreas Heinisch 2020-01-12 14:28:24 UTC
Comment 13 Commit Notification 2020-02-13 06:21:36 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":


tdf#57307 - Expand word boundaries to include connector punctuations

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 14 Andreas Heinisch 2020-04-28 10:05:52 UTC
*** Bug 130920 has been marked as a duplicate of this bug. ***