Bean | Jan 10 2009 |
I'm sorry, but Bean doesn't act like TexEdit in this situation. In Apples TextEdit, if you have some text selected and do a search & replace, the selection is ignored and instead the whole text gets edited, but in Bean the whole selected text gets deleted, no search & replace, Bean simply deletes the selected text! That's the difference, TextEdit just ignores the selection and searches & replaces in the whole document, - but Bean _deletes_ the text selection (means: the selected text isn't there anymore, no search & replace in the whole text like in TexEdit, Bean _deletes_ the selected text.) Yes I can undo Bean's behaviour, but what's the reason for deleting the selected text in that situation? If I want to delete some selected text, I usually use the delete command - I don't expect that "function" in search & replace... Well, maybe my english is to bad to make clear were I see the problem. Anyway, thanks for your reply. Mac OS 10.4.11, PPC
(Version 2.0.4b) | |
| [ Reply ] | |
Bean | Jan 10 2009 |
I'm sorry, but Bean doesn't act like TexEdit in this situation. In Apples TextEdit, if you have some text selected and do a search & replace, the selection is ignored and instead the whole text gets edited, but in Bean the whole selected text gets deleted, no search & replace, Bean simply deletes the selected text! That's the difference, TextEdit just ignores the selection and searches & replaces in the whole document, - but Bean _deletes_ the text selection (means: the selected text isn't there anymore, no search & replace in the whole text like in TexEdit, Bean _deletes_ the selected text.) Yes I can undo Bean's behaviour, but what's the reason for deleting the selected text in that situation? If I want to delete some selected text, I usually use the delete command - I don't expect that "function" in search & replace... Well, maybe my english is to bad to make clear were I see the problem. Anyway, thanks for your reply. Mac OS 10.4.11, PPC
(Version 2.0.4b) | |
| [ Reply ] | |
A Better Finder Rename | Dec 24 2008 |
POWDERED BEAN 2 Hi PUBLICSPACE (developer), Related to your comment "a market in full recession" on Sep 18 2008: I'll take you up on that. Now that we have "a market in full recession" worldwide, even in the Euro-zone, should'nt the price beeing lowered to something reasonable now? You know, at least fuel is much cheaper now... Merry christmas to you ;-)
(Version 8.0.7) | |
| [ Reply ] | |
A Better Finder Rename | Dec 24 2008 |
POWDERED BEAN 2 Hi PUBLICSPACE (developer) Related to your comment "a market in full recession" on Sep 18 2008: I'll take you up on that. Now that we have "a market in full recession" worldwide, even in the Euro-zone, should'nt the price beeing lowered to something reasonable now? You know, at least fuel is much cheaper now... Merry christmas to you ;-)
(Version 8.0.7) | |
| [ 1 Reply - Reply ] | |
Bean | Dec 24 2008 |
many thanks for your tip, that works, but nonetheless it is a svere bug. In Apples TextEdit, if you have some text selected and do a search & replace, the selection is ignored and the whole text gets changed (also not a very Mac-like behavior, I think), - but nothing will be lost like in Bean. If it is somehow against Apples legendary logic of usability to search just inside the selection if the user has made a selection, then this kind of logic at least should not lead to data loss in any application, wether it is based on Apples Textkit or not. I'm sure not everyone knows the trick you mentioned here and therefore Bean should not behave like that. Unwanted deletion of data is a very critical thing. Besides that Bean is a great app. My big thanks to the developer. Merry christmas to all.
(Version 2.0.3b) | |
| [ 3 Replies - Reply ] | |
Replies:
Bean | Jan 8 2009 |
JNRH The find panel and its behavior are supplied by OS X. The find panel behaves identically in Text Edit and all other apps that use the system-supplied find panel. Not that the behavior you describe is desirable, but it is standard OS X find panel behavior. Incidentally, Cmd-z will undo a find and replace, so data is not really 'lost' because the action is undoable.
(Version 2.0.4b) | |
Bean | Jan 10 2009 |
I'm sorry, but Bean doesn't act like TexEdit in this situation. In Apples TextEdit, if you have some text selected and do a search & replace, the selection is ignored and instead the whole text gets edited, but in Bean the whole selected text gets deleted, no search & replace, Bean simply deletes the selected text! That's the difference, TextEdit just ignores the selection and searches & replaces in the whole document, - but Bean _deletes_ the text selection (means: the selected text isn't there anymore, no search & replace in the whole text like in TexEdit, Bean _deletes_ the selected text.) Yes I can undo Bean's behaviour, but what's the reason for deleting the selected text in that situation? If I want to delete some selected text, I usually use the delete command - I don't expect that "function" in search & replace... Well, maybe my english is to bad to make clear were I see the problem. Anyway, thanks for your reply. Mac OS 10.4.11, PPC
(Version 2.0.4b) | |
Bean | Jan 10 2009 |
JNRH I did some more research on this (I am Bean's developer). For me, under both Tiger and Leopard, when I open a file in Text Edit, select all text, open the Find panel, type 'a' under Find and 'b' under Replace, then press the Replace or the Replace & Find button, all the selected text is replaced with 'b.' So the whole selection is replaced with 'b.' Do you find this to be true? Let me know if we are talking about two different issues. Apple's Pages behaves similarly. So does OpenOffice Aqua. MS Word X reduces the selection size down to the first occurrence of the Find string, but doesn't replace it. I will consider changing the behavior of the Find panel in Bean, because I agree with you that the Replace action should apply only to the text selection. But I am afraid of altering the standard way of doing things. Apparently the text selection typically takes precedence over the Find string when Replace is used, based on the behavior of the apps I described above, although that may simply be fore historical reasons.
(Version 2.0.4b) | |
|
Main
