njw@ATHENA.MIT.EDU (Nicholas John Williams) (07/25/90)
I recently came across a bug with cutting and pasting inside of ez: A piece of text in one file contains characters from the `symbola' font (i.e. the characters are in the symbola style). This piece of text is selected and the `copy' operation performed. The text is then pasted into a new file. The new file now contains the pasted text surrounded in the symbola environment, but the style called `symbola' is not defined correctly in the new file - its definition is blank. This means that the characters in that style will not be seen correctly, and the only way to get around this once the text has been pasted, is to edit the file with vi or something and fill in the correct definition of symbola. I should think that this would happen with any style pasted into a file which does not use a template defining that style (for example, pasting a "syntax example" from a help file into a default ez file produces the same effect). Has anybody out there got an idea of the best way to fix this problem? I would guess it to be something to do with changing the paste code so it ensures the new stylesheet has all the neccessary styles. Nick Williams. ------------------ njw@athena.mit.edu njw@doc.imperial.ac.uk
maria+@ANDREW.CMU.EDU ("Maria G. Wadlow") (07/27/90)
Excerpts from internet.info-andrew: 24-Jul-90 Lost styles when cutting&pa.. Nicholas J. Williams@ATH (1219) > A piece of text in one file contains characters from the `symbola' font > (i.e. the characters are in the symbola style). This piece of text is > selected and the `copy' operation performed. The text is then pasted > into a new file. The new file now contains the pasted text surrounded > in the symbola environment, but the style called `symbola' is not > defined correctly in the new file - its definition is blank. This means > that the characters in that style will not be seen correctly, and the > only way to get around this once the text has been pasted, is to edit > the file with vi or something and fill in the correct definition of > symbola. This was a design decision. The original goal of the templates was that people could either use the default definitions for styles or create their own definitions. We did not want the system to indiscriminately override a definition that the user had explicitly put in place. Therefore, style definitions are never carried with cut or copied text, because we could never ensure that we wouldn't accidentally overwrite an existing, but different, definition for that style. Maria
maria+@ANDREW.CMU.EDU ("Maria G. Wadlow") (07/27/90)
Excerpts from mail: 26-Jul-90 Re: Lost styles when cuttin.. Sean McLinden@dsl.pitt.e (1837) > This seems like a perfect place (one of many) where the user should be > able to specify a preference. I don't know the validity of this statement > but it seems more likely to me that the user would want to copy an object > with it's attributes *and* values than that they would want to copy an > object with the attributes but the values inherited from the new environment. > At least, I would think that the former was common enough that one would > want to have the option of that type of functionality. In the current paradigm used by the text inset, style definitions hold true throughout a given document. This paradigm has many benefits, however it also means that if I define the style "foo" to mean bold, everywhere that "foo" is used in the document, it will mean bold. If I find some text in another document which includes a "foo" style, where "foo" is defined to mean italic, when I paste it into my document (and the style definition comes along, as suggested), all text wrapped in a "foo" style throughout the document will now be italic. We didn't think that people would like that effect. It might be nice to have a system that has preferences which control every aspect of the system. However at some level, paradigm choices have to be made. Given the choices that were made and the paradigms that exist in the system now, I don't believe that the suggested change would be consistent with the mental model we are trying to espouse. Maria
njw@ATHENA.MIT.EDU (Nicholas John Williams) (07/27/90)
Excerpts from atk: 26-Jul-90 Re: Lost styles when cuttin.. "Maria G. Wadlow"@andrew (1257) > This was a design decision. The original goal of the templates was that > people could either use the default definitions for styles or create > their own definitions. We did not want the system to indiscriminately > override a definition that the user had explicitly put in place. Okay, so it's nice and won't override a user's definition of a style because it will not copy a definition across. However, if the user has not defined that style anyway, then they end up copying across styles which have no attributes defined and the normal user has no way of fixing this (messing with lookz is okay for some people, but the contortions neccessary to edit a style which does not appear on a menu is just too much hassle - users do not want to do this). When copying styles across, I believe the correct action would be to check to see if a style exists. If it does exist, then do nothing (so adhering to the design decision of not overwriting a user's definition), else it *should* add the definition. Excerpts from atk: 26-Jul-90 Re: Lost styles when cuttin.. Sean McLinden@dsl.pitt.e (1837) > This seems like a perfect place (one of many) where the user should be > able to specify a preference. I don't know the validity of this statement > but it seems more likely to me that the user would want to copy an object > with it's attributes *and* values than that they would want to copy an > object with the attributes but the values inherited from the new environment. I'm not sure that it should be a preference - If the code "did the right thing" as I see it above, then there is no need for another preference. Nick.
maria+@ANDREW.CMU.EDU ("Maria G. Wadlow") (07/28/90)
Excerpts from mail: 26-Jul-90 Re: Lost styles when cuttin.. Sean McLinden@dsl.pitt.e (2404) > Disagree (respectfully). Design should, after all, follow user needs > if you are developing user tools (the customer is always right). If the > model doesn't fit the application, you don't necessarily tell the > applications developer that he doesn't have a problem because you don't > have a solution. You can't have consistency if you make every design > choice a matter of user preference, but you can design a flexible model > that supports other ways of looking at things. I don't disagree with this statement. Quoting my statement in an earlier message: Excerpts from internet.info-andrew: 26-Jul-90 Re: Lost styles when cuttin.. Maria G. Wadlow (1551+0) > Given the choices that were made and the paradigms that exist in the > system now, I don't believe that the suggested change would be > consistent with the mental model we are trying to espouse. I am not arguing that the current paradigm is the correct or best or most flexible one, just that it is the one we currently use. If you suggest changing the current paradigm to one that supports the functionality being discussed, that's one thing (though I am certainly not signing up to do it). But I don't believe that adding options without regard to maintaining consistency with the current system is in the best interest of the user. Maria