Hello,
if I recall correctly, there is only spoken of space before (or perhaps
after) a "text line" in Writer.
There are paragraph attributes in (german) "Einzüge und Abstände"
(perhaps in English 'Indents and Distances") "Abstand Über" or "Unter
Absatz" (Engl. perhaps Distence above / under) and "Zeilenabstand"
(perhaps "line distance").
Perhaps you control the parapraph attributes?
MfG
G. Marxen
Am 28.06.2012 18:55, schrieb Rory O'Farrell:
On Thu, 28 Jun 2012 16:45:54 +0000 (UTC)
Armin Le Grand <[email protected]> wrote:
Rob Weir <[email protected]> wrote:
On Thu, Jun 28, 2012 at 6:57 AM, Armin Le Grand <[email protected]> wrote:
Hi Kevin,
Kevin Grignon <[email protected]> wrote:
KG01-see comments inline.
On Thursday, June 28, 2012, Dan wrote:
Srinivasulu Bhattaram wrote:
I have a text file, which has one space before every line
How to remove this using search and replace option
For carriage return or <Enter>, I learnt that we hould use "\n" (quotes
not included) and keep Regular Expressions on.
But I do not know what is code for space
KG01 - Why is this so complicated. Such system language hides the power of
the tool. The tool should understand natural language inputs.
I already thought the same. Regular expressions are mighty, but only
(guessed) 5% of the users understand it (as with many mighty things). My
first idea was to add buttons which add the 'coded' entries tothe
expression, e.g.: Button 'Space' adds '\n' when pressed to the text field.
Same for 'Start of Line' adding '^'. Much more to be defined, may someone
knowing regular expressions well list more of them.
Another way would be to allow tokens like <Space> which get translated to
'\n' internally before using the expression, but then the user would again
have to remember multiple tokens and how they are spelled (need to be
valid, possible errors which need to be handled).
Maybe a mix of both, press button 'Space' adds the (human readable) token
<Space> which itself is not editable (represents a single character).
Hmmm...
Have you seen what the SlickEdit coding editor has? Here is their
search dialog:
http://people.apache.org/~robweir/slickedit-re-dialog.png
So you can click a button to pop out a list of common RE patterns.
Interesting. What is inserted into the text field, then? Some
human-readable tokens, or the RE ones?
But this is more of an aid to someone who already understands RE's.
I'm not sure we can do much to make this conceptually much easier for
end users, since regular expressions have a certain amount of
essential complexity. Or would it make sense to support more than one
RE variation, maybe full RE, but also DOS-style with only * and ?
qualifiers?
That is what MSDEV (Developer studio) does. It allows to choose between
'Wildcarts' and 'Regular expression', where the first one accepts simple
'*' placeholders. An alternative for users, but limited. Maybe a good
compromize...
-Rob
Perhaps we could explore ways to provide such system-oriented syntax to the
user in the context of the task. In other words, update the UI design to
include a way to evoke a cheat sheet, or even better, implement a way for
the user to insert syntax using natural language, with the system
interpreting behind the scenes.
I suppose this is a broader usability theme that appears throughout the
toolset. We should explore ways reduce the complexity of system-oriented
command inputs and make advanced capabilities more consumable to less
technical users.
After all, this is a tool to help people capture their thoughts and share
ideas - not a development environment.
Thoughts?
Can any one let me know?
seena
If you are using a carriage return (shift+<Enter>) or <Enter>, you can
use this: "^ " (^ followed by a space). Regular Expressions must be on.
The replace box should be empty.
Search and replace as you did using "\n" above.
--Dan
------------------------------**------------------------------**---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Perhaps a valid solution might be a rewrite of Find and Replace, simplifying it
and allowing it to use various tokens so that Regular Expression usage was
completely concealed or even disabled.
Then add (if permitted by the author) AltSearch,
http://extensions.services.openoffice.org/en/search/node/altsearch
or advise its download as an extension; this is a much more powerful mechanism
and which could be available but out of the way of the inexperienced User.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
