Bug 57983

Summary:	Cannot search for tab, and yen key also disabled
Product:	LibreOffice	Reporter:	Matt Rosin <mattr>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	medium
Version:	3.5.2 release
Hardware:	Other
OS:	macOS (All)
Whiteboard:
Crash report or crash signature:		Regression By:

Description Matt Rosin 2012-12-07 15:40:10 UTC

Search and replace for tab fails in two different ways.

1. Typing the tab key in the source text area of the search and replace dialog (or in the Find toolbar) does not work, though it should.

2. Typing the yen key (used as backslash in Japanese computers) and t to compose the tab regex does not work, though it should.

Background:

I discovered this by pasting text from an excel chart which inserted tons of tabs. I was surprised I could not easily delete all tabs.

Just typing a tab does not work!

The background of #2 above is as follows.

It has always been the case that on Japanese keyboards, the backslash symbol is replaced with a Yen mark symbol (Y with two lines through it). They are the same ASCII code and when you type a regex in perl for example, you are typing the yen key.

The characters in question (this may not render correctly on your screen) are "¥" (yen) and "\" (backslash).

LibreOffice breaks this so that it is not possible to search for a tab or other regex using the backslash. It is also inexplicably impossible to search for a tab by typing a tab.

(I finally was able to search for a regex by copying the backslash from the help window.)

There is at least on the mac a little-known way (option + yen key) to create a backslash character, but nobody knows/understands backslash. On a MacBook Pro, the delete key is at the upper right below the eject key. To the left of the delete key is the Yen key. Shift-Yen gives a pipe symbol. Option-Yen gives a backslash (which I didn't know until today after owning it and programming for over three years).

Therefore both the yen key + t and backslash + t should work as a regex, since different keyboards/computers may have a backslash key.

Recommendation:
A. Allow user to type a tab with the tab key and search for it.
B. Interpret the half-width yen mark (I believe it is ascii 92) plus a regex symbol (n,t,s,r…) as a backslash.

Additional enhancement recommendation:
C. This kind of problem, i.e. searching for glyphs in other languages, or deep in the unicode tables, might be common problem. It would be useful for LO to include a Keyboard Substitutions page in the LO global preferences area (perhaps linked from the Search and Replace dialog as well) that would allow the user to designate substitute keys or macro strings such as [:space:] or _unicodesnowman_ to search for things that would be really difficult for most users to figure out how to input.

Comment 1 retired 2013-11-22 15:29:43 UTC

Hi Matt, thanks for the report.

* type cmd + f (to open search dialogue)

searching for tab key should be possible. Please see this WIKI https://wiki.openoffice.org/wiki/Documentation/How_Tos/Regular_Expressions_in_Writer#Tabs.2C_newlines.2C_paragraphs_.5Ct_.5Cn_.24

Typing a tab won't work because tab moves through the LO main window options. Also note  pasting into the search field is currently broken. https://bugs.freedesktop.org/show_bug.cgi?id=49853

I don't have a Yen Key on my keyboard so we'd need another japanese user to confirm this bug I guess.

I'm honestly a bit unsure where to go with this report. Tab seems possible (see wiki).

Could you check if the latest LO release 4.1.3.2 does improve the situation? Maybe it's the best to open new bugs for the specific cases? This bug is a little too complex and covers too many different special cases to be easily dealt with I think.

Feel free to update the bug with some new test results and set it back to UNCONFIRMED. Or create new bugs for the individual problems (which I suggest) and close this here as INVALID.

Comment 2 QA Administrators 2014-06-01 21:30:50 UTC

Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

Comment 3 QA Administrators 2014-07-08 17:18:35 UTC

Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO